| Bug #92609 | Upgrade to 8.0.12 fails | ||
|---|---|---|---|
| Submitted: | 1 Oct 2018 1:37 | Modified: | 3 Jan 2019 11:34 |
| Reporter: | Frederic Steinfels | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Installing | Severity: | S2 (Serious) |
| Version: | 8.0.12 | OS: | Fedora (28) |
| Assigned to: | CPU Architecture: | x86 (64BIT) | |
| Tags: | 8.0, fails, upgrade | ||
[1 Oct 2018 1:37]
Frederic Steinfels
[1 Oct 2018 8:47]
MySQL Verification Team
Please describe here step by step how you did the upgrade process. Thanks.
[1 Oct 2018 14:23]
Frederic Steinfels
According to this site: https://www.if-not-true-then-false.com/2010/install-mysql-on-fedora-centos-red-hat-rhel/ dnf install https://dev.mysql.com/get/mysql80-community-release-fc28-1.noarch.rpm however there was an error message about conflicting packages with already installed version 5.7 so I did an "rpm -e --justdb mysql-community-server" I was reading the internet about such problems. I am not alone with that. I tried several times restarting mysqld with systemctl restart mysqld I was checking out the permissions of the file and directory and except that the mysql directory was symlinked, permissions are ok. I can copy the db to a virtual machine where you try yourself if you want without the risk of loss of data.
[1 Oct 2018 16:32]
MySQL Verification Team
Thank you for the feedback. Sorry but you have not followed the correct upgrade process from 5.7 to 8.0, please read and follow the instructions in our Manual; https://dev.mysql.com/doc/refman/8.0/en/updating-yum-repo.html Important For important information about upgrading from MySQL 5.7 to 8.0, see Upgrading from MySQL 5.7 to 8.0.
[1 Oct 2018 19:37]
Frederic Steinfels
There is no relevant difference between those two instructions. Both end up with installing the 8.0 RPM which is the same. The mysql_upgrade will be called anyway when starting the server and that is the time when mysqld fails. Starting mysql_upgrade by hand will not work as the server needs to be running.
[2 Oct 2018 10:11]
Frederic Steinfels
Please reopen the bug.
[2 Oct 2018 11:18]
MySQL Verification Team
Please read: https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/upgrading-strategies.html
[2 Oct 2018 12:28]
Terje Røsten
Seems like contents of database is more important than package format (RPM in this case). Can you describe any less common feature you have enabled? Are you using FULLTEXT search (FTS)? Are tables InnoDB only or mix with MyISAM and InnoDB?
[2 Oct 2018 15:08]
Frederic Steinfels
Yes, I am using Innodb and MyIsam and a lot of triggers and stored procedures. While googling this, somebody wrote that he had a newline missing at the end of one of his triggers. Doing a divide and conquer is quite expensive in time due to the amount of tables I have. DB is about 40 Gigabytes.
[2 Oct 2018 19:59]
Terje Røsten
Hi again, excuse my ignorance, but what do you mean by "newline missing at the end of one of his triggers"? This information might helps us create a re-producer.
[2 Oct 2018 20:49]
Frederic Steinfels
Unless the log given will ring a bell, there is basically no way to reproduce unless you go to my test machine to try yourself. Please PM me. I read about this newline stuff on google somewhere but I cant find it anymore. As I could not start mysql 8.0, I was unable to edit my stored procedures so I had to downgrade.
[5 Oct 2018 11:35]
Frederic Steinfels
I forgot to write: I am using fulltext indexes on some tabeles.
[8 Oct 2018 7:36]
Sivert Sørumgård
The error indicates that the triggers listed in the trigger file are in an incorrect order. Editing a trigger file to redefine the order, then trying an upgrade, will lead to the same error.
[8 Oct 2018 8:38]
Truong Duong
Might I meet same issue. The work around is delete all .TRG file (or move them to out side of mysql data folder) then update. After success we can re-create the trigger. Other solution if you still running on MySQL 5.7.23 (lasted version) is dump all trigger to sql file, delete it and re-import the dump file to recreate all trigger with MySQL 5.7.23 file format. After that you are free to update to MySQL 8.0.12. I did both of above solutions on my three database server, all are work well.
[9 Oct 2018 5:17]
MySQL Verification Team
Bug #92696 marked as duplicate of this one
[10 Oct 2018 7:56]
Terje Røsten
Hi Frederic! Can you try the workaround as suggested by Truong?
[10 Oct 2018 14:56]
Frederic Steinfels
It worked! I was able to upgrade this way. # mysqldump --triggers --no-create-db --no-data --no-create-info --all-databases -uroot -p >triggers.sql # systemctl stop mysqld # cd /var/lib/ # cp -rp mysql mysql.bak # cd mysql # rm */*.TRG # dnf install mysql-community-server # dnf update # systemctl restart mysqld <fixing my my.cnf> # systemctl start mysqld # mysql_upgrade -u root -p # mysql -u root -p <triggers.sql
[24 Nov 2018 18:07]
Daniel Price
Posted by developer: Fixed as of the upcoming 8.0.14 release, and here's the changelog entry: Triggers were loaded into memory in an incorrect order when upgrading from MySQL 5.7 to MySQL 8.0, causing an assertion failure.
