mysql升级过程中如何监控_mysql升级监控方法

盯住错误日志，这是升级过程的“生命体征” 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 分钟没变化就人工介入

真正容易被忽略的，是升级后头 10 分钟——日志安静、进程在、端口通、

SELECT 1

JSON_EXTRACT()

GTID_PURGED