GCP部署MySQL报Error 9001最大连接超时 root账号也提示连接过多

该故障为McAfee MySQL Audit审计插件日志轮转异常触发的连接子系统全局锁死锁，与GCP底层资源、MySQL内核本身无关联：

• 监控无指标异常的原因：审计插件在配置的每日06:25:00轮转触发点，会提前持有MySQL连接认证模块的全局互斥锁；如果轮转流程因为文件句柄占用、权限不足、脚本执行超时等原因卡住，该锁会被持续持有不会释放。
• 报错与实际现象不符的原因：所有新发起的连接请求（包括root账号的预留管理连接）都会因拿不到全局互斥锁进入等待队列，等待超过连接超时阈值后直接抛出Error 9001: Max connect timeout报错；这些处于锁等待状态的连接不会被计入MySQL的活跃连接数统计，因此监控面板看到的连接数、CPU、内存、IO、磁盘使用率均无异常升高，属于锁阻塞导致的假连接数打满，并非业务流量真的耗尽连接配额。
• 可疑点对应逻辑：故障当日日志轮转未触发，说明轮转流程在启动后立刻卡住，直接导致全局锁持续持有，直到重启MySQL服务才被强制释放，和故障时间线完全吻合。

• 故障发生时如果还能通过本地socket方式登录MySQL，可手动执行日志轮转流程：先将当前审计日志文件重命名为备份文件，再执行SET GLOBAL audit_log_flush = ON;强制刷盘触发日志切换，全局锁释放后等待10~30秒，积压的连接请求会自动处理完成，无需重启服务。
• 如果已经完全无法登录数据库，直接重启MySQL进程即可快速恢复，该故障不会导致InnoDB已提交事务的数据丢失。

• 优先使用审计插件内置的日志轮转能力，废弃外部cron+logrotate的轮转方案，在MySQL配置文件中添加以下参数即可实现自动轮转，避免外部脚本执行异常触发锁问题：

# 单审计日志文件达到1G时自动触发轮转
audit_log_rotate_on_size = 1073741824
# 最多保留30个历史审计日志文件
audit_log_rotations = 30
# 轮转后自动刷盘释放文件句柄
audit_log_flush = ON

• 因特殊需求必须使用外部logrotate轮转的，需要在logrotate配置中添加copytruncate参数替代默认的文件重命名逻辑，同时在postrotate回调中强制执行SET GLOBAL audit_log_flush = ON;，避免插件持续持有旧文件句柄导致轮转失败。
• 给审计日志存储目录配置750权限，属主修改为MySQL运行用户，避免权限不足导致轮转操作被拒绝。
• 新增专项监控：采集审计日志文件大小变化指标，若日志文件大小超过配置的轮转阈值、且连续2个采集周期无大小变化，立刻触发告警，提前发现轮转失败隐患。

内容的提问来源于stack exchange，提问作者Sammy Lin