MySQL Bugs: #92696: When in-place upgrading an existing datadir to 8.0.12 server crashes on startup

Bug #92696	When in-place upgrading an existing datadir to 8.0.12 server crashes on startup
Submitted:	6 Oct 2018 8:45	Modified:	9 Oct 2018 6:40
Reporter:	Truong Duong	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	MySQL Server: Installing	Severity:	S2 (Serious)
Version:	8.0.12	OS:	Fedora (28 64 bit4.16.5-300.fc28.x86_64)
Assigned to:		CPU Architecture:	Any

Description:
I updated mysql from 5.7.23 to 8.0.12.

When in-place upgrading an existing datadir to 8.0.12 server crashes on startup:

mysqld: ../../mysql-8.0.12/sql/dd/upgrade/table.cc:1075: bool dd::upgrade_57::add_triggers_to_table(THD*, TABLE*, const String_type&, const String_type&): Assertion `t->get_event() >= t_type && (t->get_event() > t_type || t->get_action_time() >= t_time)' failed

... Lot of other information log here but for other things

[ERROR] Found partially upgraded DD. Aborting upgrade and deleting all DD tables. Start the upgrade process again.
...
[ERROR] Data Dictionary initialization failed.
[ERROR] Aborting

How to repeat:
Create new database on MySQL 5.7
Create table and import my triggers which on the attachment files
Update to MySQL 8.0.12
It will crash on start

This is the triggers which caused mysql udpate error

Attachment: triggers.tar.gz (application/gzip, text), 2.12 KiB.

There is a workaround:

1. Backup your trigger sql code
2. Delete all ".TRG" files on all of your database
3. Start mysql 8.0.12
4. Re-create your trigger from your backup sql statement

Hello Truong,

Thank you for the report.
I tried to reproduce reported issue with the provided *.TRG files but not seeing any issues at my end during the in-place upgrade. Could you please also provide logical dump of tables associated with the triggers? Thank you!

regards,
Umesh

Hi Umesh Shastry,

I already updated my MySQL server so I dump this data structure from fallback server which is running 5.7.23-log - MySQL Community Server (GPL). I am not sure it is same with my original server or not.

Just one more note about my last error is the update was processed two steps from an older mysql:

1. First of all, we was using MySQL-Cluster-server-gpl-7.3.12-1.el7 installed from RPM file
2. Then I removed it and reinstall MySQL 5.7.23 from this repo https://dev.mysql.com/get/mysql80-community-release-fc28-1.noarch.rpm (By disable MySQL 8 and re-active MySQL 5.7)
3. After installed and started MySQL 5.7, I ran mysql_update to update system database
4. I wait until the replication slave finished synced all data and install MySQL 8
5. Then it ran into error when I tried to start it up.

I think might it has some problem while imported the old trigger which are created by MySQL-Cluster-server-gpl-7.3.12

Hello,

I did the same update on my second server, it has same database structure and the it is used to use as our master in the replication, it was MySQL 5.7.23. I didn't see any error on that updating.

So I think the problem wasn't trigger or database structure, might the issue was database created on MySQL Cluster then updated to MySQL 5.7.23 contain some strange thing so it's triggers cannot be updated to MySQL 8

Thank you for the feedback. Please check https://bugs.mysql.com/bug.php?id=92609 about the trigger issue commented in last comment, could be this issue a duplicate?. Thanks.

I got error similar with that item except I don't see any error before "mysqld: ../../mysql-8.0.12/sql/dd/upgrade/table.cc:1075", my MySQL only gets error with trigger, I also don't use any symlink.
My installation steps are same with Frederic Steinfels even I didn't read the same instruction. I also didn't see any conflict or error while installing.

I was deleted all .TRG file then did the update so I am have no idea about edit the trigger file.

I think might Frederic Steinfels see same issue with me.

Thank you Truong for the requested details.
I tried to reproduce reported issue using provided dump file but not seeing any issues on OL7, CentOS7, Ubuntu etc. 

-
rm -rf 92696
bin/mysqld --initialize-insecure --basedir=$PWD --datadir=$PWD/92696 --log-error-verbosity=3
bin/mysqld --no-defaults --basedir=$PWD --datadir=$PWD/92696 --core-file --socket=/tmp/mysql_ushastry.sock --port=3333 --log-error=$PWD/92696/log.err 2>&1 &

- import all_tructure
- cleanly shutdown 5.7 instance, in-place upgrade - bring up 8.0.12, use 5.7 datadir

-- $PWD=mysql-8.0.12
bin/mysqld --no-defaults --basedir=$PWD --datadir=<path/to>/mysql-5.7.23/92696 --core-file --socket=/tmp/mysql_ushastry.sock --port=3333 --log-error=<path/to>/mysql-5.7.23/92696/log.err 2>&1 &
	   
- connect, upgrade without any issues.

Imho looking at Bug #92609, this is most likely duplicate of Bug #92609. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the original bug instead.

Thank you for your interest in MySQL.

regards,
Umesh

Hi Umesh, thanks for your checking. Could you please help me to check this case - is was the my update steps:

1. I created database on MySQL-Cluster-server-gpl-7.3.12-1.el7 installed from RPM file
2. Then I removed it and reinstall MySQL 5.7.23 from this repo https://dev.mysql.com/get/mysql80-community-release-fc28-1.noarch.rpm (By disable MySQL 8 and re-active MySQL 5.7)
3. After installed and started MySQL 5.7, I ran mysql_update to update system database
4. It will has some error with the old ndb database, just drop that database.
5. Then it ran into error when I tried to start it up.

I think might it has some problem while imported the old trigger which are created by MySQL-Cluster-server-gpl-7.3.12

If you still cannot reproduce my error, it's ok to mark duplicate with #92609

I just don't know if the error was caused by MySQL Cluster 7.3.12 or not.