# Upgrade from 5.7.43-47 to 8.0.33-25 fails in dd::upgrade\_57::fill\_dd\_and\_finalize (both percona servers) **URL:** \ **Category:** MySQL & MariaDB\ **Created:** [September 13, 2023, 4:38pm UTC](https://forums.percona.com/t/upgrade-from-5-7-43-47-to-8-0-33-25-fails-in-dd-fill-dd-and-finalize-both-percona-servers/25161 "2023-09-13T16:38:31Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![egel](https://avatars.discourse-cdn.com/v4/letter/e/e36b37/32.png) [@egel](https://forums.percona.com/u/egel)\ **Post date:** [September 13, 2023, 4:38pm UTC](https://forums.percona.com/t/upgrade-from-5-7-43-47-to-8-0-33-25-fails-in-dd-fill-dd-and-finalize-both-percona-servers/25161/1 "2023-09-13T16:38:31Z")
Hello there. During upgrade I encountered error that seems to be similar to bug: Bug #88042 (fixed in 8.0.4). the process is trivial. restore data directory from 5.7 backup startup 8.0.33-25 executables The error log (relevant part): … stack\_bottom = 7fb49ce7e150 thread\_stack 0x100000 /usr/sbin/mysqld(my\_print\_stacktrace(unsigned char const\*, unsigned long)+0x29) [0x55885098a3a9] /usr/sbin/mysqld(print\_fatal\_signal(int)+0x291) [0x55884f3ef991] /usr/sbin/mysqld(handle\_fatal\_signal+0xa5) [0x55884f3efb35] /lib64/libc.so.6(+0x36e40) [0x7fb4a1293e40] /usr/sbin/mysqld(+0x2d51fe5) [0x558850dfafe5] /usr/sbin/mysqld(dict\_load\_table(char const\*, bool, dict\_err\_ignore\_t, std::\_\_cxx11::basic\_string\ const\*)+0x866) [0x558850dfd3a6] /usr/sbin/mysqld(dict\_table\_open\_on\_name(char const\*, bool, bool, dict\_err\_ignore\_t)+0x3a3) [0x558850dbee13] /usr/sbin/mysqld(dd\_upgrade\_table(THD\*, char const\*, char const\*, dd::Table\*, TABLE\*)+0xc60) [0x558850e22710] /usr/sbin/mysqld(+0x28b809f) [0x55885096109f] /usr/sbin/mysqld(+0x28bf75e) [0x55885096875e] /usr/sbin/mysqld(dd::upgrade\_57::migrate\_all\_frm\_to\_dd(THD\*, char const\*, bool)+0x633) [0x5588509692e3] /usr/sbin/mysqld(dd::upgrade\_57::fill\_dd\_and\_finalize(THD\*)+0xfa) [0x558850957f3a] /usr/sbin/mysqld(+0x1436bde) [0x55884f4dfbde] /usr/sbin/mysqld(+0x2ed2873) [0x558850f7b873] /lib64/libc.so.6(+0x830ca) [0x7fb4a12e00ca] /lib64/libc.so.6(+0xfb5ec) [0x7fb4a13585ec] Any thoughts? ideas? Thanks. ---
**Author:** ![Michael\_Coburn](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/michael_coburn/32/18_2.png) [@Michael\_Coburn](https://forums.percona.com/u/Michael_Coburn)\ **Post date:** [September 13, 2023, 4:56pm UTC](https://forums.percona.com/t/upgrade-from-5-7-43-47-to-8-0-33-25-fails-in-dd-fill-dd-and-finalize-both-percona-servers/25161/2 "2023-09-13T16:56:37Z")
> [@egel](#): > > /usr/sbin/mysqld(dict\_load\_table(char const\*, bool, dict\_err\_ignore\_t, std::\_\_cxx11::basic\_string\ const\*)+0x866) [0x558850dfd3a6] > /usr/sbin/mysqld(dict\_table\_open\_on\_name(char const\*, bool, bool, dict\_err\_ignore\_t)+0x3a3) [0x558850dbee13] > /usr/sbin/mysqld(dd\_upgrade\_table(THD\*, char const\*, char const\*, dd::Table\*, TABLE\*)+0xc60) [0x558850e22710] Looks like mysqld crashes when trying to open a specific table. There is likely corruption in the ibd file. If you are able to identify which table this is, you can try to see if you can trigger mysqld to crash on reading from the table with: ```auto SELECT * FROM ``` If you want to try to repair it before doing the upgrade, you can do: ```auto ALTER TABLE ENGINE=InnoDB; ``` And if mysqld still crashes after doing the ALTER, then you’ll likely have to upgrade using logical dump / load, for example from mydumper or mysql-shell ---
**Author:** ![egel](https://avatars.discourse-cdn.com/v4/letter/e/e36b37/32.png) [@egel](https://forums.percona.com/u/egel)\ **Post date:** [September 13, 2023, 5:10pm UTC](https://forums.percona.com/t/upgrade-from-5-7-43-47-to-8-0-33-25-fails-in-dd-fill-dd-and-finalize-both-percona-servers/25161/3 "2023-09-13T17:10:11Z")
Hello, Thank you very much. I 've able to startup using the same data directory from backup on 5.7 however the upgrade process is failing If there is corruption it would be corrupted in both versions isn’t? Evgeni ---
**Author:** ![egel](https://avatars.discourse-cdn.com/v4/letter/e/e36b37/32.png) [@egel](https://forums.percona.com/u/egel)\ **Post date:** [September 13, 2023, 5:19pm UTC](https://forums.percona.com/t/upgrade-from-5-7-43-47-to-8-0-33-25-fails-in-dd-fill-dd-and-finalize-both-percona-servers/25161/4 "2023-09-13T17:19:12Z")
> [@egel](#): > > dd\_upgrade\_table Forgot to add another part of the log: " 2023-09-13T17:06:56.824282Z 1 [System] [MY-011012] [Server] Starting upgrade of data directory. 2023-09-13T17:06:56.824300Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started. 2023-09-13T17:07:01.629682Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended. 2023-09-13T17:07:01Z UTC - mysqld got signal 11 ; Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware. BuildID[sha1]=ca49d76ef174ee7e1c54a2f96f416aa56b1c07aa Server Version: 8.0.33-25 Source distribution " and there is coming stack trace . Thanks. ---
**Author:** ![egel](https://avatars.discourse-cdn.com/v4/letter/e/e36b37/32.png) [@egel](https://forums.percona.com/u/egel)\ **Post date:** [September 13, 2023, 9:33pm UTC](https://forums.percona.com/t/upgrade-from-5-7-43-47-to-8-0-33-25-fails-in-dd-fill-dd-and-finalize-both-percona-servers/25161/5 "2023-09-13T21:33:39Z")
Update. I found the tables and it seems I do hit bug but different one: There is tables that prevent me from upgrade. I don’t see any reason. CREATE TABLE `f1` ( `id` bigint(20) unsigned NOT NULL AUTO\_INCREMENT, `text` varchar(255) COLLATE ascii\_bin NOT NULL, PRIMARY KEY (`id`), FULLTEXT KEY `text` (`text`) ) ENGINE=InnoDB AUTO\_INCREMENT=112 DEFAULT CHARSET=ascii COLLATE=ascii\_bin CREATE TABLE `f2` ( `id` int(10) unsigned NOT NULL, `text` varchar(255) CHARACTER SET ascii COLLATE ascii\_bin NOT NULL, PRIMARY KEY (`id`), FULLTEXT KEY `text` (`text`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 What do you think? Thanks!