生产环境应使用MySQL 8.0官方二进制包部署，禁用系统包管理器；主从需严格配置GTID与ROW格式，启用read_only和relay_log_recovery；高可用选型需匹配运维能力，备份必须与binlog清理策略对齐并定期验证。
MySQL 8.0 二进制包部署比 yum/apt 更可控
生产环境不建议用系统包管理器装 MySQL，因为版本老旧、配置路径不统一、启停脚本耦合 systemd 太深，出问题时排查慢。直接用官方 mysql-8.0.x-linux-glibc2.17-x86_64.tar.xz 包更稳妥。
-
解压后用
mysqld --initialize --user=mysql --datadir=/data/mysql初始化，注意记录日志末尾生成的临时 root 密码 -
mysqld_safe已弃用，直接用mysqld启动，配合 systemd 时写好Type=notify和Restart=on-failure - 关键配置必须显式指定：
datadir、socket、log-error、pid-file，避免依赖默认值导致多实例冲突 - 首次启动后立刻执行
ALTER USER 'root'@'localhost' IDENTIFIED BY 'StrongPass123!';，否则临时密码一小时后失效
主从复制不能只靠 CHANGE MASTER TO 就算完
单纯执行 CHANGE MASTER TO 并 START SLAVE 只是起点，生产中常见同步中断、延迟飙升、GTID 不一致等问题，必须前置加固。
- 主库开启
binlog_format=ROW+gtid_mode=ON+enforce_gtid_consistency=ON，从库同样配全，否则后续切换或故障恢复会失败 - 用
mysqldump --single-transaction --master-data=2 --set-gtid-purged=ON做初始数据同步，别用FLUSH TABLES WITH READ LOCK锁全库 - 检查
SHOW SLAVE STATUS\G时重点盯Seconds_Behind_Master（非 NULL）、SQL_Delay（是否被意外设为非零）、Retrieved_Gtid_Set与Executed_Gtid_Set是否连续 - 从库务必设
read_only=ON，并加super_read_only=ON（MySQL 5.7+），防止误操作写入
MHA 或 Orchestrator？选型要看运维人力和故障容忍度
MHA 轻量但已停止维护，Orchestrator 功能全但依赖 Web UI 和后台服务。小团队建议用 Orchestrator；如果只跑几个核心库且不想多维护一个 Go 服务，MHA 仍可短期用，但得自己打补丁防 ssh 连接超时导致 failover 卡住。
- MHA 配置里
master_ip_failover_script必须真实测试过 VIP 漂移，别只写个 echo - Orchestrator 的
raft模式要至少 3 节点，否则脑裂时无法自动仲裁；单节点部署仅用于测试 - 无论哪种方案，都要定期运行
orchestrator-client -c test-failover或masterha_check_repl，不能等真挂了才验证 - 高可用不是“自动切”，而是“切完能查、能写、不丢事务”。务必在从库开启
relay_log_recovery=ON，否则 crash 后 relay log 损坏会导致 GTID 跳变
备份策略必须和 binlog 清理策略对齐
很多线上事故源于备份可用但 binlog 已被 purge，导致恢复到某时间点时缺日志。xtrabackup 全备 + binlog 增量是底线，但清理逻辑常被忽略。
- 用
xtrabackup --backup --target-dir=/backup/full_$(date +%F)，备份后立即执行xtrabackup --prepare，别等到恢复时再做——prepare 失败率远高于 backup -
expire_logs_days不能只看天数，要结合备份周期：比如每周全备，则expire_logs_days至少设为 8，并配合PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 8 DAY)手动清理更稳 - 备份文件权限必须是
mysql:mysql，且目录不可被其他用户写入，否则恢复时mysqld启动报错Can't create/write to file - 所有备份需每周抽样 restore 到隔离环境验证，重点测
SET GLOBAL gtid_purged是否匹配、SELECT COUNT(*)行数是否一致
Threads_connected 突增没告警，Innodb_row_lock_time_avg 持续超 50ms 不感知，或者 Slave_SQL_Running_State 卡在 “Reading event from the relay log” 却没触发通知。这些细节比架构选型更容易引发雪崩。 
