MySQL热备无一键方案，必须手动配置主从复制：主库启用ROW格式binlog并设唯一server-id，从库配置正确CHANGE MASTER TO参数及server-id，双主还需设置auto-increment-offset避免冲突。
MySQL 热备在 Linux 上没有“一键开启”的方案，必须靠主从复制（或双主）手动搭建；所谓“热备”，本质是让一台备用库实时同步主库数据，且能随时接管——这要求配置必须严丝合缝，漏掉任意一个关键点，SHOW SLAVE STATUS\G 里 Slave_IO_Running 或 Slave_SQL_Running 就会是 No。
主库必须开 binlog 且格式设为 ROW
binlog_format=STATEMENT 在生产环境极易导致主从不一致（比如用了 NOW()、UUID()、临时表、自增字段等），ROW 格式才真正记录“哪一行被改了”，避免语义歧义。
- 修改 /etc/my.cnf 的 [mysqld] 段，加上：
log-bin = mysql-bin binlog-format = ROW sync_binlog = 1 expire_logs_days = 7
- log-bin 路径需确保 MySQL 进程有写权限（如 /var/log/mysql/ 要提前 chown mysql:mysql）
- 改完必须重启：systemctl restart mysqld
- 验证：运行 mysql -e "SHOW VARIABLES LIKE 'log_bin';" 返回 ON，再查 binlog_format 必须是 ROW
server-id 绝对不能重复，auto.cnf 也得检查
这是最常翻车的点：哪怕只配一台从库，server-id 也必须和主库不同，且不能为 0。
- 主库设 server-id = 101（推荐用 IP 最后一段，如 192.168.1.101 → 101）
- 从库设 server-id = 102，改完同样要重启
- 如果从库是通过拷贝主库数据目录部署的，务必检查 datadir/auto.cnf 文件里的 server-uuid —— 它也必须唯一，否则 IO_THREAD 启动失败，错误日志里会出现 “Found server-uuid ... already in use”
CHANGE MASTER TO 的四个参数必须实时、准确
CHANGE MASTER TO 不是填个 IP 和密码就行，它依赖主库当前精确的 binlog 位置，抄旧值、猜数字、用备份时的快照全都会失败。
- 在主库执行：SHOW MASTER STATUS;，记下 File（如 mysql-bin.000014）和 Position（如 107）
- 在从库执行：CHANGE MASTER TO 时，这俩值必须严格匹配，且：
-
MASTER_HOST不能写localhost或127.0.0.1（除非从库和主库在同一台机器，且明确走 TCP） -
MASTER_USER必须是主库上用GRANT REPLICATION SLAVE ON *.*创建的专用账号，不是root - 如果主库开了防火墙，确保
3306端口对从库 IP 开放
- 执行完 START SLAVE; 后，立刻 SHOW SLAVE STATUS\G，确认两处都是 Yes，而不是卡在 Connecting 或报错 Access denied
双主热备要额外防自增冲突
双主（Master-Master）看似高可用，但默认 AUTO_INCREMENT 会撞车，必须人工干预。
- 主库 A 加：auto-increment-increment = 2，auto-increment-offset = 1
- 主库 B 加：auto-increment-increment = 2，auto-increment-offset = 2
- 这样 A 插入 ID 是 1、3、5…，B 是 2、4、6…，避免主键冲突
- 但要注意：如果其中一台宕机期间另一台写了大量数据，恢复后可能因 GTID 或 binlog 位置错乱导致同步中断——双主实际运维成本远高于单向主从，非强需求不建议上
真正跑得稳的热备，不在配置多炫，而在每个 server-id 是否唯一、每个 MASTER_LOG_POS 是否刚查出来、每个 server-uuid 是否没被复制污染。这些地方一旦出问题，同步就静默卡住，日志里往往只有一行 “Relay log read failure”，排查起来反而比重配还费时间。
