After upgrading a busy server to MySQL 8.0.34 I noticed that my error logs was filling up with tons of these errors. Hundreds of them a second is causing some noticeable cost when they are going to CloudWatch Logs. It looks like the deprecation notice started in MySQL 8.0.34.
2023-08-18T22:01:12.183036Z 19100582 [Warning] [MY-013360] [Server] Plugin mysql_native_password reported: ''mysql_native_password' is deprecated and will be removed in a future release. Please use caching_sha2_password instead'
I could see that all of my active users were using the mysql_native_password plugin with this query:
mysql> select user, host, plugin from mysql.user; +------------------+-------------+-----------------------+ | user | host | plugin | +------------------+-------------+-----------------------+ | user1 | % | mysql_native_password | | user2 | % | mysql_native_password | | user3 | % | mysql_native_password | | mysql.infoschema | localhost | caching_sha2_password | | mysql.session | localhost | caching_sha2_password | | mysql.sys | localhost | caching_sha2_password | | rdsadmin | localhost | mysql_native_password | +------------------+-------------+-----------------------+ 7 rows in set (0.01 sec)
Some googling pointed me to this Stack Overflow article which was somewhat related, and where I figured out how to change the authentication plugin for each user with the command:
ALTER USER user2@'%' IDENTIFIED WITH caching_sha2_password BY 'the_password';
After updating each account, they look correct in the mysql user table:
mysql> select user, host, plugin from mysql.user; +------------------+-------------+-----------------------+ | user | host | plugin | +------------------+-------------+-----------------------+ | user1 | % | caching_sha2_password | | user2 | % | caching_sha2_password | | user3 | % | caching_sha2_password | | mysql.infoschema | localhost | caching_sha2_password | | mysql.session | localhost | caching_sha2_password | | mysql.sys | localhost | caching_sha2_password | | rdsadmin | localhost | mysql_native_password | +------------------+-------------+-----------------------+ 7 rows in set (0.00 sec)
But the error continued at the same volume, so even though the Database user accounts seem to be configured correctly, the MySQL client library that I’m using must still be falling back to mysql_native_password. This application is using PHP 7.4.3, so it’s not too old, and some references indicate that support for caching_sha2_password was released in PHP 7.2, so that shouldn’t be the problem.
I see that the default_authentication_plugin variable is set to mysql_native_password, but this database instance is hosted on RDS, and that configuration value is not modifiable.
I see that the MySQL log_error_suppression_list is also available and could be configured to suppress only the MY-013360 error. Unfortunately, this value is not configurable using MySQL8 Parameter groups.
In the mean time, I’m spending several dollars per day in Cloudwatch logs for this, so to turn it off, I was able to disable deprecation notices from being logged by setting the global log_error_verbosity value to 1 (instead of the default of 2).
This prevented the error from filling up the logs for now. Next I can try upgrading the application to PHP 8 and checking into specific connection parameters that may force it to use caching_sha2_password.
Do you have more or updated information? Or just questions? Please let everybody know in the comments below. FWIW, I’ve created an AWS Re:Post topic requesting the addition of log_error_suppression_list in a parameter group. Feel free to vote that up if you run into this issue.
Thanks for your information,
This continues to happen with RDS MySQL 8.0.35.
did you solve the problem?
The AWS RePost topic has been upvoted a bit, but no word from the AWS team on if they will implement the proper fix for this. In the mean time, I have logs suppressed and have not updated any other servers past 8.0.33.
Have you tried to use ‘log_error_suppression_list’ to supress the specific MY-013360 warning? I tested this on MySQL 8.0.35 by adding the following line in my.cnf (and restarted MySQL):
log_error_suppression_list = “013360”
After this I no longer get the MY-013360 warnings in the error logs. From the docs:
“The log_error_suppression_list system variable applies to events intended for the error log and specifies which events to suppress when they occur with a priority of WARNING or INFORMATION. For example, if a particular type of warning is considered undesirable “noise” in the error log because it occurs frequently but is not of interest, it can be suppressed.”
More information here: https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_log_error_suppression_list
Yes, that would be the desired way to prevent this error. Since this instance is hosted on RDS, though, that setting is not currently modifiable. The link to AWS Repost is a request for Amazon to make this setting able to be configured by customers. It looks like it has attracted some attention and may happen soon.
Hi Brandon,
Thanks a lot for your post. I0ve the same issue.
My environment is: WordPress 6.4.2 / php-fpm 8.2 and Mysql 8.0.35.
I’ve change the field “plugin” on users table from “mysql_native_password” to “caching_sha2_password” and warning logs still reporting.
Hope an AWS deploying for this log_error_suppression_list feature.
@velloraposo, your users won’t be able to connect when you just change the mysql.user.plugin field. Your mysql.user.authentication_string needs to be encrypted again, using the new plugin. The correct way is to pass both plugin and password per SQL, like Brandon wrote above:
ALTER user ‘yourusername’@’hostname’ IDENTIFIED WITH caching_sha2_password BY ‘yourpassword’;
For anybody still seeing this, upgrading to MySQL 8.0.38 effectively fixes this by only logging the warning once