上周把一个老项目从 MySQL 8.0 升到 8.4,mysqld --initialize 阶段直接失败,翻 error log 末尾看到一行:Plugin 'mysql_native_password' is not loaded。当时第一反应是某个初始化脚本里写了 IDENTIFIED WITH mysql_native_password,可我把项目翻了个底朝天也没找到这样的语句。真正的问题出在 my.cnf 里一条从 5.7 时代一直抄下来的配置:default_authentication_plugin=mysql_native_password。
从 MySQL 8.0 开始,官方默认认证插件就换成了 caching_sha2_password,到 8.4 时 mysql_native_password 默认不再加载,配置里再让服务端拿它当默认认证,自然就炸了。那这个报错到底怎么解?是退回老版本,还是把项目里所有账号改一遍,或者干脆让 8.4 把旧插件打开?我花了一晚上把几条路都试了一遍,下面按实际排查顺序写清楚,希望能让同样被这个报错卡住的人少走点弯路。如果你是从 8.0 之后就没再关注过认证插件变化的老开发,这篇也值得花五分钟看完。
1. 我踩到的现场:同一句报错,三种不同姿势
1.1 启动即挂的场景
先说第一种。升级后第一次执行初始化或者直接启动 mysqld,服务起不来,error log 里能看到 Plugin 'mysql_native_password' is not loaded。这种场景一般不是代码在显式创建旧认证账号,而是 my.cnf 或启动参数里带着一句类似 default_authentication_plugin=mysql_native_password 的配置。
这句配置在 5.7 升 8.0 的早期确实有效。当时大量用了多年的老驱动不支持 caching_sha2_password,DBA 只能靠它把新建用户的默认认证方式拉回旧协议。可到了 8.4,插件默认不加载,服务启动时尝试把这个插件设成默认认证,直接报错退出。
这种场景下,一开始最容易被误导。我见过有人把配置删掉,服务起来了,可一查 mysql.user 发现所有存量账号的 plugin 字段还是 mysql_na
