升级MySQL需紧盯error.log日志、mysql_upgrade输出、连接心跳及进程端口状态，并在业务高峰前持续监控至少10分钟以捕获隐性兼容问题。
盯住错误日志，这是升级过程的“生命体征”
MySQL 升级失败时，error.log 从不撒谎。它不是辅助信息，而是第一响应源。升级中一旦服务起不来、连接被拒、表打不开，问题一定先写进这里。
- 路径通常为 /var/log/mysql/error.log 或 /usr/local/mysql/data/$(hostname).err；不确定就执行 SHOW VARIABLES LIKE 'log_error'; 查准位置
- 实时跟踪：用 tail -f /var/log/mysql/error.log，别关终端，尤其在 systemctl start mysql 后的前 90 秒
- 关键信号包括：Port already in use（端口冲突）、InnoDB initialization failed（引擎加载失败）、Table upgrade required（系统表结构不匹配）
- 别等升级完再翻日志——很多崩溃是静默发生的，进程已退出，但日志里留着最后一行 Aborted connection 或 mysqld got signal 11把 mysql_upgrade 的输出当“诊断报告”看mysql_upgrade（MySQL 8.0 前）或自动触发的元数据升级流程，不是“点一下就完事”的按钮，它的 stdout/stderr 是兼容性问题的明细单。
- 必须重定向输出：mysql_upgrade --verbose > upgrade.log 2>&1，否则关键提示一闪而过
- 真正要警觉的不是“OK”，而是这些词：Repairing table（说明表结构有损坏或版本不兼容）、needs upgrade（某张系统表未适配）、Error 后跟具体表名（如 mysql.innodb_table_stats）
- 如果看到 Skipping system table 'xxx' because it's already up to date，反而是好现象；但若全程无任何 Repairing 或 Upgrading 字样，要怀疑是否压根没跑对实例（比如连错了 socket 或端口）
用连接 + 简单查询做“心跳检测”
日志和工具输出都是“过去式”，而业务能否连上、能否读一行数据，才是升级后“活着”的直接证据。
- 写个 3 行脚本循环探测：while ! mysql -uroot -p$PASS -e "SELECT 1" >/dev/null 2>&1; do sleep 5; done && echo "UP"
- 每 10 秒查一次 SELECT 1，连续 3 次失败就发告警（可用 curl 推企业微信/钉钉）
- 注意：MySQL 8.0 默认认证插件是 caching_sha2_password，老客户端（如 MySQL 5.7 客户端、某些 Python MySQLdb 驱动）会报 Client does not support authentication protocol ——这不是监控脚本的问题，是权限层兼容性断裂，得提前改用户：ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'xxx';升级窗口内临时加一层“进程存活+端口响应”双保险
别依赖“服务启动成功”就认为万事大吉。MySQL 进程可能启动了，但卡在初始化阶段（比如重建 mysql.innodb_index_stats 表），此时端口通、进程在，但任何真实查询都超时。
- 用 pgrep mysqld | wc -l 每分钟检查进程数，归零即告警
- 用 nc -zv 127.0.0.1 3306 &>/dev/null && echo "port ok" || echo "port down" 验证端口可写（nc 比 telnet 更适合脚本）
- 更进一步：在升级前部署一个轻量 mysqld_exporter，配合 Prometheus 抓取 mysql_up{instance="xxx"} 和 mysql_global_status_threads_connected，5 分钟没变化就人工介入
mysql_upgrade（MySQL 8.0 前）或自动触发的元数据升级流程，不是“点一下就完事”的按钮，它的 stdout/stderr 是兼容性问题的明细单。
- 必须重定向输出：mysql_upgrade --verbose > upgrade.log 2>&1，否则关键提示一闪而过
- 真正要警觉的不是“OK”，而是这些词：Repairing table（说明表结构有损坏或版本不兼容）、needs upgrade（某张系统表未适配）、Error 后跟具体表名（如 mysql.innodb_table_stats）
- 如果看到 Skipping system table 'xxx' because it's already up to date，反而是好现象；但若全程无任何 Repairing 或 Upgrading 字样，要怀疑是否压根没跑对实例（比如连错了 socket 或端口）
用连接 + 简单查询做“心跳检测”
日志和工具输出都是“过去式”，而业务能否连上、能否读一行数据，才是升级后“活着”的直接证据。
- 写个 3 行脚本循环探测：while ! mysql -uroot -p$PASS -e "SELECT 1" >/dev/null 2>&1; do sleep 5; done && echo "UP"
- 每 10 秒查一次 SELECT 1，连续 3 次失败就发告警（可用 curl 推企业微信/钉钉）
- 注意：MySQL 8.0 默认认证插件是 caching_sha2_password，老客户端（如 MySQL 5.7 客户端、某些 Python MySQLdb 驱动）会报 Client does not support authentication protocol ——这不是监控脚本的问题，是权限层兼容性断裂，得提前改用户：ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'xxx';升级窗口内临时加一层“进程存活+端口响应”双保险
别依赖“服务启动成功”就认为万事大吉。MySQL 进程可能启动了，但卡在初始化阶段（比如重建 mysql.innodb_index_stats 表），此时端口通、进程在，但任何真实查询都超时。
- 用 pgrep mysqld | wc -l 每分钟检查进程数，归零即告警
- 用 nc -zv 127.0.0.1 3306 &>/dev/null && echo "port ok" || echo "port down" 验证端口可写（nc 比 telnet 更适合脚本）
- 更进一步：在升级前部署一个轻量 mysqld_exporter，配合 Prometheus 抓取 mysql_up{instance="xxx"} 和 mysql_global_status_threads_connected，5 分钟没变化就人工介入
mysql.innodb_index_stats 表），此时端口通、进程在，但任何真实查询都超时。
- 用 pgrep mysqld | wc -l 每分钟检查进程数，归零即告警
- 用 nc -zv 127.0.0.1 3306 &>/dev/null && echo "port ok" || echo "port down" 验证端口可写（nc 比 telnet 更适合脚本）
- 更进一步：在升级前部署一个轻量 mysqld_exporter，配合 Prometheus 抓取 mysql_up{instance="xxx"} 和 mysql_global_status_threads_connected，5 分钟没变化就人工介入
真正容易被忽略的，是升级后头 10 分钟——日志安静、进程在、端口通、SELECT 1 成功，但某个定时任务第一次调用 JSON_EXTRACT() 就报错，因为 5.7 的 JSON 函数在 8.0 里行为微调了；或者主从复制突然断在 GTID_PURGED 不一致。这些不会出现在升级日志里，只能靠业务侧真实流量暴露。所以监控不是“升级时开一下”，而是“新版本上线后至少盯满第一个业务高峰”。
