All we need is an easy explanation of the problem, so here it is.
I am doing an in-place upgrade from mysql 5.7.26 to 5.7.33. I have done from 5.6 to 5.7 for serveral hosts and did not face this issue.
Followed below steps
- Took a VM snapshot and mysqldump as well.
- systemctl stop mysqld
- removed mysql 5.7.26 rpms
- yum install mysql-community-common-5.7.33-1.el7.x86_64
- yum install mysql-community-libs-5.7.33-1.el7.x86_64
- yum install mysql-community-libs-compat-5.7.33-1.el7.x86_64
- yum install mysql-community-client-5.7.33-1.el7.x86_64
- yum install mysql-community-server-5.7.33-1.el7.x86_64
- systemctl start mysqld
After installed 5.7.33 rpms, when i tried to run mysql_upgrade ,I realized my password is’nt working and then when i checked i saw a new empty /etc/my.cnf file and new instance under /var/lib/mysql. I could still see my actual data directory intact.
Why is this issue because i never faced it before. If i replace the empty my.cnf with my actual my.cnf and restart the mysqld service, will it be a solution to my problem.
How to solve :
I know you bored from this bug, So we are here to help you! Take a deep breath and look at the explanation of your problem. We have many solutions to this problem, But we recommend you to use the first method because it is tested & true method that will 100% work for you.
Dont know why this issue. Removing 5.7.26 rpms actually renames the /etc/my.cnf to /etc/my.cnf.rpmsave. Installing 5.7.33 rpms creates a plain new /etc/my.cnf . So when i start mysqld, it creates a new datadir in /var/lib/mysql. After removing old rpms, i renamed /etc/my.cnf.rpmsave to /etc/my.cnf and started mysqld and ran mysql_upgrade. All good now. I upgraded to mysql 5.7.33 in many servers, did not face the issue anywhere. only difference i see is my.cnf is owned by mysql in working servers while it is owned by root in current scenario
Note: Use and implement method 1 because this method fully tested our system.
Thank you 🙂