Mysql Server Error
I am suddenly getting error while accesing mysql ,even phpmyadmin in cpanel is not working giving error mysqli_sql_exception: Permission denied,pls help
-
this is happing for all sites in WHM
0 -
same
0 -
I can confirm. Any workarounds? It's critical
0 -
nothing,same issue persist
0 -
Any updates?
0 -
This happened after an automated cpanel update. The cpanel logs state:
"[2025-04-15 08:25:01 +0200] warn [mysqluserstore] /usr/local/cpanel/scripts/mysqlconnectioncheck failed: The “/usr/local/cpanel/scripts/mysqlconnectioncheck” command (process 4813) reported error number 1 when it ended.:
[2025-04-15 08:25:56 +0200] warn [cpses_tool] Error while connecting to MySQL: (XID 5jb2kb) The system failed to connect to the “MySQL” database “mysql” because of an error: CR_CONNECTION_ERROR (Can't connect to local server through socket '/var/lib/mysql/mysql.sock' (2))
Error while connecting to MySQL: (XID 5jb2kb) The system failed to connect to the “MySQL” database “mysql” because of an error: CR_CONNECTION_ERROR (Can't connect to local server through socket '/var/lib/mysql/mysql.sock' (2)) at /usr/local/cpanel/Cpanel/Mysql/Basic.pm line 437.
[2025-04-15 08:26:06 +0200]: “/usr/local/cpanel/scripts/restartsrv_mysql --html --wait --verbose” called by (5000 - whostmgr - resmysql)
[2025-04-15 08:26:07 +0200] info [restartsrv_mysql] systemd failed to start the service “mysql” (The “/usr/bin/systemctl restart mysql.service --no-ask-password” command (process 5012) reported error number 1 when it ended.): Job for mysql.service failed because the control process exited with error code.
See "systemctl status mysql.service" and "journalctl -xeu mysql.service" for details."
syslog:
Apr 15 07:59:52 m4329 kernel: [ 9549.692647] audit: type=1400 audit(1744696792.289:163): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="/usr/sbin/mysqld" pid=81033 comm="apparmor_parser"
Apr 15 07:59:52 m4329 mysqld[81034]: 2025-04-15T05:59:52.624494Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.42) starting as process 81034
Apr 15 07:59:52 m4329 mysqld[81034]: 2025-04-15T05:59:52.636260Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
Apr 15 07:59:53 m4329 mysqld[81034]: 2025-04-15T05:59:53.070331Z 1 [ERROR] [MY-012209] [InnoDB] Multiple files found for the same tablespace ID:
Apr 15 07:59:53 m4329 mysqld[81034]: 2025-04-15T05:59:53.070380Z 1 [ERROR] [MY-012202] [InnoDB] Tablespace ID: 854 = ['****.ibd', '****s.ibd']
Apr 15 07:59:53 m4329 mysqld[81034]: 2025-04-15T05:59:53.070402Z 1 [ERROR] [MY-012202] [InnoDB] Tablespace ID: 855 = ['****.ibd', '*****.ibd']
Apr 15 07:59:53 m4329 mysqld[81034]: 2025-04-15T05:59:53.070412Z 1 [ERROR] [MY-012202] [InnoDB] Tablespace ID: 856 = ['borted with error Failed, retry may succeed.
Apr 15 07:59:53 m4329 mysqld[81034]: 2025-04-15T05:59:53.070860Z 1 [ERROR] [MY-010334] [Server] Failed to initialize DD Storage Engine
Apr 15 07:59:53 m4329 mysqld[81034]: 2025-04-15T05:59:53.071061Z 0 [ERROR] [MY-010020] [Server] Data Dictionary initialization failed.
Apr 15 07:59:53 m4329 mysqld[81034]: 2025-04-15T05:59:53.071137Z 0 [ERROR] [MY-010119] [Server] Aborting
Apr 15 07:59:53 m4329 mysqld[81034]: 2025-04-15T05:59:53.072240Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.42) MySQL Community Server - GPL.
Apr 15 07:59:53 m4329 systemd[1]: mysql.service: Main process exited, code=exited, status=1/FAILURE
Apr 15 07:59:53 m4329 systemd[1]: mysql.service: Failed with result 'exit-code'.0 -
I've having the same issue!
0 -
So far I've found a solution. BUT I'm not advising anyone to follow my steps. Do it at your own risk.
1. Backup the database folder /var/lib/mysql
2. Rename the database folder to mysql_old
3. Rebuild mySQL from WHM>Upgrade Database version
4 Create a new database root password
5. Check that mySQL works
6. restore the accounts via the backup/restore function of WHM
7. recreate each dbUser for each account and assign to the respective database
So far this works...
0 -
I fix it by doing a yum undo by doing the following ...
yum history list
Then looked for the dodgy update, confirmed it was the right one with ..
yum history info <id>
And then used this command to undo it.
yum history undo <id>
I also had to do a root database password update as well after doing the yum undo.
0 -
Yes your trick worked for me,thanks a lot!
It looks like a bad update from yum or cpanel has crashed mysql for many hours,removing that update does work.
0 -
I’m also facing this issue following a scheduled updates at 00:50 GMT last night. I see a couple of suggested remedies above but want to tread carefully in what is my production environment so would be good to understand the recommended fix suggested by cPanel. Raised a ticket with them before seeing this thread, but no response yet.
0 -
Cpanel hasn't released a recommended fix yet, not 100% sure they are even accepting this as a bug - but the issue is that the update decided to update MySql 8.4.4 to 8.4.5. The only solution I could find was to undo the update using "yum history undo" and versionlock so it doesn't update again,
1 -
Any suggestions for the Ubuntu 22.04 rollback? Yum doesn't work there
0 -
Thanks Darren. This MySql version upgrade is definitely what looks to have triggered my issue. The logs show 8.4.4 shutting down for the update and now I am on 8.4.5.
Can you be any more specific on the steps to yum undo/lock and exactly what needs to happen with the db root password reset. I am tech savvy but don’t often getting into debugging things this deep in the system!
0 -
"yum history list" will show a list of all the yum updates with IDs - you should be able to determine which one caused it, by looking at the time it was done.
If you do a yum history info <ID> it'll give you more information - showing that it upgraded the mysql.
Once you know its the correct one ... do a yum history undo <id> and let it do its thing.
I think when the upgrade happened, cpanel tried to reset the "root" password to make it work which is why it's breaks that bit ... so within WHM goto "Change Database Root Password" and just reset it back to what it was.
Verison locking ... if you goto https://support.cpanel.net/hc/en-us/articles/1500013004522-How-to-version-lock-RPM-packages that gives you information on how to install it and then i use
"yum versionlock mysql-community-*"
to versionlock it.
Hope that helps.
1 -
I’m not sure I know what the database root password was originally, so changing it back might be a challenge!
I’m wondering if the password complexity rules have changed, and what was once a compliant password no longer is. Maybe a password reset is all that is required, but unsure what the consequences are, or where that new password needs to be updated.
0 -
You may not need to reset your root password but I did - doing the yum undo does bring back the websites, without the need of resetting the root password. But the root password is needed for basic WHM functions and it would update anything which needs it.
I had to use the original root password, as i use acronis backup which needs that password to backup and restore the databases.
1 -
Hello Darren,
thanks SO MUCH, tried everything the last 7 hours...
Don´t we have to lock:
yum versionlock mysql-community-* AND
yum versionlock mysql-cloud-*0 -
I only did "yum versionlock mysql-community-*" as mysql-cloud is the 8.4.5 version and it isn't installed on the server, so can't really be versionlocked.
1 -
This was the culprit update for my mysql issues
1 -
For me it was the upgrade from 8.0.41 to 8.0.42 (Ubuntu 22.04.5 - cPanel 124.0.34).
0 -
Cpanel has listed this issue now -->
2 -
Thats my fix :)
1 -
Hi,
It appears that these issues are related to a recent updated pushed out by MySQL that changed the data directory. As others have mentioned here, downgrading the affected packages is the only workaround for now. We also suggest version locking these packages until a permanent fix is released so the packages do not get automatically updated again. The article Sumitra Madgulkar has more detailed steps on the workaround.
For Ubuntu, I don't believe that apt has the functionality to undo transactions from a history search, but you can check the /var/log/dpkg.log file on Ubuntu to see which MySQL packages were upgraded recently and then manually replace them with the previous versions of the package.
0 -
Hi William,
I had the bad luck of updating mysql from 8.0 to 8.4.5 yesterday and been fighting this ever since. Currently users do not have access to their own databases.
I am guessing I cannot roll back to 8.0. I never had 8.4.4 installed. I am running on Cloudlinux 8.
Any way to fix this?
0 -
Hi William,
Since I'm running Ubuntu, I'm unable to downgrade via yum. I'm concerned though to do a manual downgrade, because restoring all the websites takes too long.
My method (for Ubuntu 22x) worked ok and I'm currently running the latest MySQL without issues. Should I be concerned on the upcoming update/patch?
0 -
Darren - Thank you for the guidance. Had to install yum versionlock first, but not hard to do. Knowing which package to version lock is key, the Cpanel team could usefully update their official guidance page wit that information, which you've shared with us here.
All now up and running while we await the permanent fix.
0 -
Hi,
Tos We've had users in a similar situation where we were able to assist in performing a minor version downgrade, but it was more involved and required manually removing and downgrading some packages. I suggest opening a ticket for assistance with this, as having access to the server would make it easier to assess the situation.
My method (for Ubuntu 22x) worked ok and I'm currently running the latest MySQL without issues. Should I be concerned on the upcoming update/patch?
I suggest ensuring that the MySQL packages do not update again until they release a fix for the issue. For Ubuntu, you should be able to version lock packages with a command similar to the following:
apt-mark hold <package name>
Note that you would want to remove the version lock after the issue is fixed, which you can do with the apt-mark unhold command. We've reported this issue to the MySQL team and are awaiting their response. I will include the link to our report below:
0 -
Hey everyone! Full details on the issue can be found here:
Unfortunately MySQL briefly had the wrong packages in their update tiers, which quickly spread across the internet. If you're still seeing issues with the MySQL system the details in that article should get you taken care of.
1 -
Does that mean we no longer need to versionlock it?
0
Please sign in to leave a comment.
Comments
33 comments