MySQL 8.0 警告日志爆满排查：3步定位sha256_password废弃告警源

戴夫健身

237人浏览 · 2026-07-05 16:11:10

戴夫健身 · 2026-07-05 16:11:10 发布

MySQL 8.0 警告日志爆满排查：3步定位sha256_password废弃告警源

MySQL 8.0 的错误日志突然被大量废弃警告刷屏？这可能是由于旧版客户端或配置不当的应用仍在尝试使用已被弃用的 sha256_password 认证插件。本文将带您深入分析问题根源，并提供一套完整的排查与解决方案。

1. 问题现象与背景分析

当打开MySQL错误日志文件时，您可能会看到如下重复出现的警告信息：

2025-03-31T02:16:18.973249Z 58388 [Warning] [MY-013360] [Server] Plugin sha256_password reported: ''sha256_password' is deprecated and will be removed in a future release. Please use caching_sha2_password instead'

这种警告信息会以极高的频率出现，导致日志文件迅速膨胀，甚至可能填满磁盘空间。要理解这个问题，我们需要先了解MySQL认证插件的演进：

mysql_native_password ：MySQL 5.7及之前版本的默认认证插件
sha256_password ：MySQL 5.7引入的基于SHA-256的认证插件
caching_sha2_password ：MySQL 8.0引入的新一代默认认证插件

caching_sha2_password 相比前两者有以下优势：

更高的安全性：采用更强大的加密算法
更好的性能：通过缓存机制减少加密计算开销
未来兼容性：将成为MySQL长期支持的认证标准

2. 三步骤诊断流程

2.1 第一步：确认当前认证插件配置

首先检查服务器的默认认证插件设置：

SHOW VARIABLES LIKE 'default_authentication_plugin';

预期输出应为：

+-------------------------------+-----------------------+
| Variable_name                 | Value                 |
+-------------------------------+-----------------------+
| default_authentication_plugin | caching_sha2_password |
+-------------------------------+-----------------------+

2.2 第二步：识别问题连接源

使用以下SQL查询找出仍在使用 sha256_password 的用户：

SELECT user, host, plugin 
FROM mysql.user 
WHERE plugin = 'sha256_password';

如果返回结果为空，说明问题可能来自临时连接或配置错误的客户端。

2.3 第三步：追踪问题连接

安装并启用 connection_control 插件来捕获失败的登录尝试：

INSTALL PLUGIN CONNECTION_CONTROL SONAME 'connection_control.so';
INSTALL PLUGIN CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS SONAME 'connection_control.so';

然后查询失败的连接记录：

SELECT * FROM information_schema.connection_control_failed_login_attempts;

典型输出可能显示如下：

+-----------------------------------------------+-----------------+
| USERHOST                                      | FAILED_ATTEMPTS |
+-----------------------------------------------+-----------------+
| 'mysql_router5_da1ufs1lvt0b'@'172.16.200.153' | 22              |
| 'NCAPP'@'192.168.200.153'                     | 1154            |
+-----------------------------------------------+-----------------+

3. 解决方案与优化建议

3.1 方案一：更新用户认证方式

对于已识别的使用 sha256_password 的用户，执行以下命令更新其认证方式：

ALTER USER 'username'@'host' IDENTIFIED WITH caching_sha2_password BY 'password';

3.2 方案二：客户端兼容性处理

对于无法立即更新的旧客户端，可采用临时兼容方案：

修改服务器配置 （不推荐长期使用）：

SET GLOBAL default_authentication_plugin='mysql_native_password';

创建兼容用户 ：

CREATE USER 'legacy_app'@'%' IDENTIFIED WITH mysql_native_password BY 'password';

3.3 方案三：日志过滤与抑制

如果警告信息仍然过多，可以配置错误日志过滤：

SET GLOBAL log_error_suppression_list='MY-013360';

注意：此方法会抑制所有同类型警告，可能掩盖其他潜在问题

4. 预防措施与最佳实践

为避免类似问题再次发生，建议采取以下预防措施：

升级检查清单 ：
- 应用客户端库版本验证
- 连接字符串配置审查
- 自动化测试覆盖认证场景
监控指标设置 ：
- 异常认证尝试次数
- 废弃插件使用率
- 日志增长率告警

迁移路线图 ：

graph TD
  A[识别所有依赖应用] --> B[测试caching_sha2_password兼容性]
  B --> C{是否兼容?}
  C -->|是| D[直接迁移]
  C -->|否| E[制定过渡方案]
  E --> F[临时使用兼容插件]
  F --> G[安排应用升级]

在实际运维中，我们曾遇到一个典型案例：某金融系统升级后，日志每小时增长2GB。通过上述方法，最终定位到是遗留的报表系统使用了旧版JDBC驱动，更新驱动后问题立即解决。