MySQL升级前须验证Ansible变量和目录权限：检查mysql_data_dir、mysql_conf_file路径及/var/lib/mysql属主；mysql_package_name需匹配系统包名；升级包需放files/并校验sha256；用shell模块执行mysql_upgrade并预置login-path；滚动升级需serial:1控制顺序，先升从库并检查Seconds_Behind_Master为0，主库升级前后手动启停复制；启动失败常见原因包括systemd unit未更新、配置路径错误、缺少--initialize；8.0.16+须改用mysqld --upgrade。
MySQL升级前必须验证的Ansible变量和目录权限
Ansible本身不执行MySQL升级逻辑，它只负责下发命令、替换文件、重启服务。真正决定升级是否成功的是你定义的变量和目标主机环境。常见失败点是mysql_data_dir、mysql_conf_file路径写错，或mysql_user对/var/lib/mysql没有读写权限。
- 用
stat模块提前检查/var/lib/mysql属主是否为mysql用户，否则mysqld --upgrade会静默失败 -
mysql_package_name要严格匹配仓库中包名，例如Ubuntu 22.04用mysql-server，而CentOS 7用mysql-community-server - 升级包必须放在
files/下且校验sha256sum，避免因网络中断导致部分下载
用shell模块安全执行mysql_upgrade并捕获错误
Ansible的command模块无法处理交互式提示（如输入root密码），也不支持mysql_upgrade在5.7+版本中已弃用的事实。必须改用shell模块配合mysql_config_editor预置登录信息。
- 先运行
mysql_config_editor set --login-path=local --user=root --password，再调用mysql_upgrade --login-path=local --force - 务必加
ignore_errors: yes和failed_when判断返回码，因为mysql_upgrade在无变更时退出码为1，不代表失败 - 升级后立即执行
mysql -e "SELECT VERSION();"确认版本已更新，避免误判“升级完成”
滚动升级时如何避免主从同步中断
Ansible默认并行执行，若直接对主从集群批量升级，从库可能在主库升级中途尝试拉取binlog，触发Got fatal error 1236。必须控制执行顺序和状态检查。
- 用
serial: 1限制每次只升级一台，结合when: inventory_hostname in groups['mysql_slaves']先升从库 - 升级每台从库前，加任务检查
SHOW SLAVE STATUS\G中Seconds_Behind_Master是否为0 - 主库升级前，手动执行
STOP SLAVE;并在升级完成后用START SLAVE;恢复，不能依赖Ansible自动重连
升级后mysqld无法启动的三个高频原因
Ansible报告changed: true不代表MySQL服务真正可用。很多团队卡在启动失败却查不到日志，本质是systemd未加载新unit文件或配置语法错误。
- 检查
/usr/lib/systemd/system/mysqld.service是否被新版包覆盖，旧版常含LimitNOFILE=65536，新版可能删了导致打开文件数不足 - 运行
mysqld --defaults-file=/etc/my.cnf --verbose --help | grep "basedir\|datadir"确认路径解析正确，避免my.cnf里!include指向不存在的文件 - 升级后首次启动必须加
--initialize-insecure（仅测试环境）或用mysqld --initialize生成新data目录，否则报错Can't start server: Bind on TCP/IP port
mysql_upgrade在8.0.16+版本彻底移除，必须改用mysqld --upgrade；而Ansible Playbook若沿用老模板，会在升级到8.0.23时静默跳过兼容性检查，直到应用连不上才暴露问题。 
