Server upgraded mysql 8.4 to 9.7
Hello
Yesterday one of my servers updated the mysql84-community-release package. It disabled the mysql8.4 channel and enabled the mysql9.7 channel inside the mysql-community.repo file
2026-04-21T20:02:21-0300 SUBDEBUG Upgrade: mysql84-community-release-el9-4.noarch
2026-04-21T20:02:21-0300 SUBDEBUG Upgraded: mysql84-community-release-el9-3.noarch
And the cpanel nightly update upgraded the mysql version to 9.7:
[2026-04-22 00:13:04 -0300] [/usr/local/cpanel/scripts/update-packages] (1/7): mysql-community-common-9.7.0-1.el9.x86_6 7.1 MB/s | 607 kB 00:00
[2026-04-22 00:13:04 -0300] [/usr/local/cpanel/scripts/update-packages] (2/7): mysql-community-client-9.7.0-1.el9.x86_6 27 MB/s | 3.8 MB 00:00
[2026-04-22 00:13:04 -0300] [/usr/local/cpanel/scripts/update-packages] (3/7): mysql-community-client-plugins-9.7.0-1.e 686 kB/s | 1.5 MB 00:02
[2026-04-22 00:13:04 -0300] [/usr/local/cpanel/scripts/update-packages] (4/7): mysql-community-libs-9.7.0-1.el9.x86_64. 41 MB/s | 1.5 MB 00:00
[2026-04-22 00:13:04 -0300] [/usr/local/cpanel/scripts/update-packages] (5/7): mysql-community-icu-data-files-9.7.0-1.e 1.0 MB/s | 2.3 MB 00:02
[2026-04-22 00:13:04 -0300] [/usr/local/cpanel/scripts/update-packages] (6/7): mysql-community-devel-9.7.0-1.el9.x86_64 2.9 MB/s | 7.8 MB 00:02
[2026-04-22 00:13:04 -0300] [/usr/local/cpanel/scripts/update-packages] (7/7): mysql-community-server-9.7.0-1.el9.x86_6 9.3 MB/s | 56 MB 00:06
[2026-04-22 00:13:04 -0300] [/usr/local/cpanel/scripts/update-packages] Upgrading : mysql-community-common-9.7.0-1.el9.x86_64 1/14
[2026-04-22 00:13:04 -0300] [/usr/local/cpanel/scripts/update-packages] Upgrading : mysql-community-client-plugins-9.7.0-1.el9.x86_64 2/14
[2026-04-22 00:13:04 -0300] [/usr/local/cpanel/scripts/update-packages] Upgrading : mysql-community-libs-9.7.0-1.el9.x86_64 3/14
This broke the user connections because we were using mysql_native_password
I managed to start mysql with --skip-grant-tables to make a full backup, remove mysql 9.7, reinstall mysql 8.4 and restore all databases:
# mysqld --skip-grant-tables &
# mysqldump --all-databases --routines --triggers --events --single-transaction > full_backup.sql
I wonder if this happened to anyone else, very uncommom behavior.
-
Just found the support topic confirming
Unfortunately too late.
0 -
Same issues across our entire fleet of servers
1 -
we have same issue
I have opened support ticket but no replay from cpanel.
0 -
Same issue - waiting for a solution.
0 -
Just waiting
0 -
Hello,
Thank you for contacting us back at cPanel Technical Support!
At this time, our development team is actively working on this matter. I can see that we have an autofixer in the works to prevent any accidental upgrades, however, this is still being worked on and validated.
You can follow this article to receive an email notification when a solution is published in the product.
MySQL8.4 upgraded to MySQL9.7 during nightly updates.
It was a pleasure to assist you today. Please do not hesitate to reply if you have any further questions.
cpanel support give standard reply without solution0 -
restore a backup.
0 -
Thiago Voltolini Thiago Voltolini
Can you tell us how you solved it? I couldn't do the dump because MySQL isn't running.
0 -
Benito as @... pointed out, verify the mysql error_log to check whats wrong on your configuration.
I had to comment out this lines:
mysql_native_password
default-authentication-plugin
authentication_policy
innodb_log_file_size
innodb_buffer_pool_instancesAlso you need to execute the mysqld command as the mysql user:
su -s /bin/bash mysql
mysqld --skip-grant-tables &You can do a full dump with --all-databases or run a per database dump:
for a in `mysql -e "show databases" | awk {'print $1'} | grep -v 'Database'` ; do mysqldump --routines --triggers --events $a > $a ; done0 -
@... you need to run the mysql service with no privs to be able to access and dump databases:
su -s /bin/bash mysql
mysqld --skip-grant-tables &0 -
hello
I face this problem
[root@cat ~]# mysql < mysql97_dump.sql
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)0 -
Luckly I was able to roll back to an earlier server snapshot to before the update was installed.
I have a few questions on tying steps based on what's in the guide at https://support.cpanel.net/hc/en-us/articles/39925555560471-MySQL8-4-upgraded-to-MySQL9-7-during-nightly-updates...
I've disabled auto updated but editing /etc/cpupdate.conf toCPANEL=release
RPMUP=manual
SARULESUP=manual
STAGING_DIR=/usr/local/cpanel
UPDATES=manualRan the repo commands...
yum-config-manager --disable mysql-9.7-lts-community mysql-tools-9.7-lts-community
yum-config-manager --enable mysql-8.4-lts-community mysql-tools-8.4-lts-community
But not sure about the versionlock options at the end of the page. Would this still allow 8.4 to receive patches?0 -
Followed cPanel instructions and reverted to 8.4, but still crashed, as soon as i comment out authentication_policy and native_password and restart, restartmysql reverts it.
0 -
Update - April 23 - The details in the support article are correct, and it also appears that MySQL has resolved the upstream issue with their repositories. That doesn't help you if the damage has already happened to your server, but at this point we have a few options:
-we've released an autofixer to help prevent users from receiving the update, which went out last night
-the support article has copy/pastable steps to resolve the issue if your server experienced the upgrade
-if you have *any* doubts at all, feel free to submit a ticket.0 -
Thanks cPRex, it is safe now to re-enable automatic updates?
0 -
[Server] Server upgrade from '80409' to '90700' started.
[Server] Server upgrade from '80409' to '90700' completed.
Looks like I was upgraded to MySQL 9. Just to confirm - has anyone successfully restored following the posted cPanel steps? Are you running full cPanel backups prior?0 -
Yes, it is safe to reactivate automated updates at this time as the upstream issue has been resolved. This was posted by the MySQL team this morning:
We have addressed both issues in the YUM repositories. Previously, updating `mysql84-community-release` caused the repo configuration to disable the 8.4 repositories and enable the 9.7 repositories automatically. This has now been fixed. Existing 8.4 users will continue to receive MySQL 8.4 updates, while new installations will default to MySQL 9.7. Thanks!
Once we know with certainty this is correct we'll remove our autofixer.
0 -
I followed the steps and was able to revert back successfully.
cPRex - My only question is I did not do the version lock step — should I go ahead with that or is this definitely resolved? It's safe to leave that out now?0 -
At this point we've confirmed the repositories are clean. If you wanted to do that version lock and wait a day just in case, no one would blame you at this point.
0 -
I'm on 134.0.17 when this occurred to my server, and notice 134.0.19 is available. Is it safe to upgrade before I attempt the workaround, or should I do the workaround first?
0 -
At this point you shouldn't need to do any workarounds to the machine before an update.
0 -
Maybe I wasn't clear enough. I'm on 134.0.17 and MySQL got updated to 9.7 which left my server (database) in a broken state. As I understand it, I do need to do the workaround.
Can I update to 134.0.19, or should I do the workaround first?0 -
Thanks for the clarification - I would get things working normally back on 8.4 first before doing any additional work on the server. The update itself isn't going to fix or revert anything for you automatically - I wish it could!
1 -
My database is HUGE and making a copy of /mysql/ isn't a viable option for me. I don't have the space for it. Is it possible to just nuke the database, install 8.4, and restore via a backup?
0 -
I don't see why not? We don't have specific steps for that process though, but that seems like a valid solution to me.
0 -
I tried to follow the guide, but jumped over the backup (step 1), but already at step 4 it throws a lot of errors:
[root@server ~]# /scripts/restartsrv_mysql
Waiting for “mysql” to start ……info [restartsrv_mysql] systemd failed to start the service “mysqld” (The “/usr/bin/systemctl restart mysqld.service --no-ask-password” command (process 3713434) reported error number 1 when it ended.): Job for mysqld.service failed because the control process exited with error code.
See "systemctl status mysqld.service" and "journalctl -xe" for details.
Cpanel::Exception::ModuleLoadError/(XID nuepbg) The system failed to load the module “Cpanel::Database::MySQL::MySQL97” because of an error: Can't locate Cpanel/Database/MySQL/MySQL97.pm in @INC (you may need to install the Cpanel::Database::MySQL::MySQL97 module) (@INC entries checked: /usr/local/cpanel /usr/local/cpanel/3rdparty/perl/542/cpanel-lib/x86_64-linux /usr/local/cpanel/3rdparty/perl/542/cpanel-lib /usr/local/cpanel/3rdparty/perl/542/lib/x86_64-linux /usr/local/cpanel/3rdparty/perl/542/lib /opt/cpanel/perl5/542/site_lib/x86_64-linux /opt/cpanel/perl5/542/site_lib) at (eval 30) line 1.
BEGIN failed--compilation aborted at (eval 30) line 1.
at /usr/local/cpanel/Cpanel/LoadModule.pm line 155.
Cpanel::LoadModule::load_perl_module("Cpanel::Database::MySQL::MySQL97") called at /usr/local/cpanel/Cpanel/Database.pm line 37
Cpanel::Database::__ANON__() called at /usr/local/cpanel/Cpanel/Database.pm line 40
Cpanel::Database::new("Cpanel::Database") called at /usr/local/cpanel/Cpanel/MysqlUtils/MyCnf/Migrate.pm line 704
Cpanel::MysqlUtils::MyCnf::Migrate::_check_for_config_errors("/etc/my.cnf") called at /usr/local/cpanel/Cpanel/MysqlUtils/MyCnf/Migrate.pm line 746
Cpanel::MysqlUtils::MyCnf::Migrate::_scrub_invalid_value("/etc/my.cnf") called at /usr/local/cpanel/Cpanel/MysqlUtils/MyCnf/Migrate.pm line 795
Cpanel::MysqlUtils::MyCnf::Migrate::scrub_invalid_values("/etc/my.cnf") called at /usr/local/cpanel/Cpanel/MysqlUtils/MyCnf/Migrate.pm line 635
Cpanel::MysqlUtils::MyCnf::Migrate::migrate_my_cnf_file("/etc/my.cnf", 9.7) called at /usr/local/cpanel/Cpanel/ServiceManager/Services/Mysql.pm line 301
Cpanel::ServiceManager::Services::Mysql::_attempt_to_repair_mysql_configuration() called at /usr/local/cpanel/Cpanel/ServiceManager/Services/Mysql.pm line 94
Cpanel::ServiceManager::Services::Mysql::restart_attempt(Cpanel::ServiceManager::Services::Mysql=HASH(0x30f6380), 1) called at /usr/local/cpanel/Cpanel/ServiceManager/Base.pm line 910
Cpanel::ServiceManager::Base::start(Cpanel::ServiceManager::Services::Mysql=HASH(0x30f6380)) called at /usr/local/cpanel/Cpanel/ServiceManager/Services/Mysql.pm line 65
Cpanel::ServiceManager::Services::Mysql::start(Cpanel::ServiceManager::Services::Mysql=HASH(0x30f6380)) called at /usr/local/cpanel/Cpanel/ServiceManager/Base.pm line 783
Cpanel::ServiceManager::Base::restart(Cpanel::ServiceManager::Services::Mysql=HASH(0x30f6380), "graceful", undef) called at /usr/local/cpanel/Cpanel/ServiceManager/Base.pm line 585
Cpanel::ServiceManager::Base::run_from_argv(Cpanel::ServiceManager::Services::Mysql=HASH(0x30f6380), "--verbose") called at bin/restartsrv_base.pl line 144
scripts::restartsrv_base::__ANON__() called at /usr/local/cpanel/3rdparty/perl/542/cpanel-lib/Try/Tiny.pm line 100
eval {...} called at /usr/local/cpanel/3rdparty/perl/542/cpanel-lib/Try/Tiny.pm line 91
Try::Tiny::try(CODE(0x2869170), Try::Tiny::Catch=REF(0x103a400)) called at bin/restartsrv_base.pl line 188
scripts::restartsrv_base::run() called at bin/restartsrv_base.pl line 800 -
I just wanted to add that I enabled the updates a few minutes ago, ran them, and MySQL broke again. I followed the 25-step fix and was still having issues. I had to reset the cPanel password so the user could use phpMyAdmin, and I also had to create new users for the databases.
Everything seems to be working now; I enabled the version lock.
0 -
Okay, I'm in a pinch, my server couldn't even restore from backup.
live_tail_log encountered an internal error: (XID 5arvg3) The system failed to locate either the file “/var/cpanel/transfer_sessions/servernbacku20260423213619KyMy/.master.log” or the file “/var/cpanel/transfer_sessions/servernbacku20260423213619KyMy/master.log”.
live_tail_log encountered an internal error: (XID yr8h7j) The system failed to locate either the file “/var/cpanel/transfer_sessions/servernbacku20260423213619KyMy/.master.log” or the file “/var/cpanel/transfer_sessions/servernbacku20260423213619KyMy/master.log”.
live_tail_log encountered an internal error: (XID 3hqb5w) The system failed to locate either the file “/var/cpanel/transfer_sessions/servernbacku20260423213619KyMy/.master.log” or the file “/var/cpanel/transfer_sessions/servernbacku20260423213619KyMy/master.log”.
live_tail_log encountered an internal error: (XID g6a6bu) The system failed to locate either the file “/var/cpanel/transfer_sessions/servernbacku20260423213619KyMy/.master.log” or the file “/var/cpanel/transfer_sessions/servernbacku20260423213619KyMy/master.log”.
live_tail_log encountered an internal error: (XID 2wr6mh) The system failed to locate either the file “/var/cpanel/transfer_sessions/servernbacku20260423213619KyMy/.master.log” or the file “/var/cpanel/transfer_sessions/servernbacku20260423213619KyMy/master.log”.
live_tail_log encountered an internal error: (XID wdcsse) The system failed to locate either the file “/var/cpanel/transfer_sessions/servernbacku20260423213619KyMy/.master.log” or the file “/var/cpanel/transfer_sessions/servernbacku20260423213619KyMy/master.log”.
live_tail_log encountered an internal error: (XID azpp3j) The system failed to locate either the file “/var/cpanel/transfer_sessions/servernbacku20260423213619KyMy/.master.log” or the file “/var/cpanel/transfer_sessions/servernbacku20260423213619KyMy/master.log”.
live_tail_log encountered an internal error: (XID ug32zw) The system failed to locate either the file “/var/cpanel/transfer_sessions/servernbacku20260423213619KyMy/.master.log” or the file “/var/cpanel/transfer_sessions/servernbacku20260423213619KyMy/master.log”.
live_tail_log encountered an internal error: (XID szqbuv) The system failed to locate either the file “/var/cpanel/transfer_sessions/servernbacku20260423213619KyMy/.master.log” or the file “/var/cpanel/transfer_sessions/servernbacku20260423213619KyMy/master.log”.
live_tail_log encountered an internal error: (XID r4tn8n) The system failed to locate either the file “/var/cpanel/transfer_sessions/servernbacku20260423213619KyMy/.master.log” or the file “/var/cpanel/transfer_sessions/servernbacku20260423213619KyMy/master.log”.
live_tail_log encountered the maximum allowed errors (10) and will not continue.and this:
Could not restore account “psn100”: time out reached<br/>
Can't backups in CPanel be to large?! I have a huge database, it's gonna take some time. There really can't be any time requirements when restoring from backup.
Edit: Found this in my process list, I guess its still running?
transfer_session - servernbacku20260423213619KyMy - RESTORE:1
0 -
Ragowit - it would likely be best to create a ticket so this can be examined directly.
0 -
Benito your mysql config might be broken to 9.7
Check your logs and remove unreconised variables likemysql_native_password
default-authentication-plugin
authentication_policy
innodb_log_file_size
innodb_buffer_pool_instancesAlso do not restart mysql with "/scripts/restartsrv_mysql" as it seems to add this variables to the config file again as other users pointed.
Run it manually as I mentioned above
su -s /bin/bash mysql
mysqld --skip-grant-tables &Then you can dump your databases
0
Please sign in to leave a comment.
Comments
34 comments