- Newest
- Most votes
- Most comments
The issue is that in MySQL 8.4 LTS, the mysql_native_password plugin is not only deprecated but is disabled by default.
Even if you set your authentication_policy to include it, the server cannot use the method because the underlying plugin isn't loaded. DBeaver likely succeeds because it defaults to a newer driver/mechanism, whereas your application (likely PHP/PDO based on the error code) is strictly trying to use the method assigned to the user.
Steps to Resolve:
Edit your MySQL 8.4 Parameter Group.
- Locate the parameter: mysql_native_password.
- Change its value from OFF (or 0) to ON (or 1).
- Save the changes.
- Reboot your RDS instance (this is a static parameter and requires a manual reboot to take effect).
Why this happens:
In MySQL 8.0, the plugin was built-in and active. In 8.4, it was moved to a separate dynamic plugin that must be explicitly enabled via the configuration before the authentication_policy can utilize it.
"Beginning with MySQL 8.4.0, the deprecated mysql_native_password authentication plugin is no longer enabled by default. To enable it, start the server with --mysql-native-password=ON..."
source: https://dev.mysql.com/doc/refman/8.4/en/mysql-nutshell.html
PS: Since this method is deprecated, plan to migrate your application clients and users to caching_sha2_password before the next major version release.
According to the MySQL 8.4 Release Notes -> https://dev.mysql.com/doc/relnotes/mysql/8.4/en/news-8-4-0.html , the mysql_native_password plugin is disabled by default. Setting the authentication_policy is not enough; you must explicitly enable the plugin by setting the mysql_native_password parameter to 1 (ON) in your RDS Parameter Group and rebooting the instance.
see also:
If the parameter is already ON and the reboot is confirmed, check the specific user account in the database:
SELECT user, host, plugin FROM mysql.user WHERE user = 'your_app_user';
If the plugin column shows caching_sha2_password instead of mysql_native_password, you may need to explicitly revert the user's authentication method:
ALTER USER 'your_app_user'@'%' IDENTIFIED WITH mysql_native_password BY 'your_password';
This ensures the individual account matches your application's requirements, even if the global server plugin is now active.
Relevant content
- AWS OFFICIALUpdated 9 months ago
I had forgotten to mention this, but the "mysql_native_password" setting in the parameter group is set to "ON", so I don't think that can be the fix. Or at least not the whole fix.
Check if the Parameter Group status shows 'pending-reboot' in the RDS console. Since mysql_native_password is a static parameter, it requires a manual reboot to actually take effect.
You can verify the live status by running this command in DBeaver: SHOW VARIABLES LIKE 'mysql_native_password';
If it returns OFF, the engine hasn't applied the change yet. If it's ON, check if your authentication_policy uses the 8.4 syntax: mysql_native_password .
Well, I think I may have found what the problem is. If I connect the to the database that's on MySQL 8.4.3, and run SHOW VARIABLES LIKE 'mysql_native_password', it doesn't return with anything. Not even "OFF". Just no variable by that name. And that's after rebooting the database. The parameter group attached to that database has it set to "ON", and the authentication_policy is set to *:mysql_native_password, but according to the command results in DBeaver, it's not even there.
I noticed you mentioned that the variable doesn't even show up as 'OFF' in DBeaver. This suggests the engine hasn't initialized the plugin at all. Could you double-check the Status of the Parameter Group in your RDS console? Ensure it explicitly says 'In-sync'. If it says 'Pending-reboot', the changes haven't been applied yet, even if you performed a manual restart previously. Sometimes a specific sequence is required (Apply Change -> Verify Pending Status -> Reboot) for static parameters like mysql_native_password to be recognized by the engine.
It does say "In Sync". For what it's worth, I checked the "non-upgraded" database, which is still at MySQL 8.0.4 and it shows the same lack of a variable, although that may just be because mysql_native_password is the default there.