mysql双机热备需严格对齐server-id、版本和初始数据，binlog_format必须为row，change master to参数须实时获取，从库设read_only仅防误操作，须配合监控与校验工具保障一致性。
MySQL双机热备（Master-Slave）不是配完 CHANGE MASTER TO 就能自动高可用的，它本质是单向日志复制通道，故障不自愈、主从不自动切换、数据不一致时不会报错——必须手动验证、持续监控、配合外部工具才能用得稳。
server-id、版本、初始数据三处必须对齐
90% 的同步失败或 SHOW SLAVE STATUS\G 显示 Seconds_Behind_Master: NULL 或 IO/SQL_Running: No，都卡在这三点：
-
server-id必须全局唯一且非 0：主库设为101，从库就得是102（建议用 IP 段末位），不能照抄模板写成都是1 - 从库 MySQL 版本 ≥ 主库：5.7 主库配 5.6 从库会直接报
Unknown system variable 'gtid_mode'；8.0 主库若开启require_row_format，从库也得支持 - 初始数据必须严格一致：仅靠
START SLAVE不拉历史数据；主库已有业务表，必须先用mysqldump --single-transaction --master-data=2导出，再导入从库，否则 binlog 起始点错位，后续所有同步都不可信
binlog_format 必须设为 ROW，别碰 STATEMENT
默认 STATEMENT 模式在含 NOW()、UUID()、SYS_DATE() 等非确定性函数的语句下，主从执行结果不同，导致数据静默偏差——生产环境禁止使用。
- 确认方式：
SELECT @@binlog_format;，不是STATEMENT才算过关 - 修改配置：
binlog_format = ROW加入[mysqld]段，重启生效（MySQL 5.7+ 支持动态改，但建议重启以保稳定） - 如果主库已用
STATEMENT写入大量日志，切勿中途改模式，需重做从库初始化
CHANGE MASTER TO 的参数不能靠猜，必须现场取
MASTER_LOG_FILE 和 MASTER_LOG_POS 是从主库实时状态读出来的，不是配置文件里写的文件名或固定数字。错一位，整个复制链就断。
- 主库上执行：
SHOW MASTER STATUS\G，只取File和Position两列值（例如mysql-bin.000003和154） - 从库执行：
CHANGE MASTER TO MASTER_HOST='192.168.1.100', MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=154; - 注意：
MASTER_PORT默认 3306 可省略；但若主库改了端口，必须显式写上，否则连不上 - 密码字段名是
MASTER_PASSWORD，不是MASTER_PASS或PASSWORD，拼错会报Access denied
从库务必设为 read_only，但别信它能防所有写入
read_only = 1 能阻止普通用户写入，但对拥有 SUPER 权限的账号（包括复制线程自身）无效——这是设计使然，不是 bug。
- 加在从库
my.cnf的[mysqld]段，重启生效；MySQL 5.7+ 可动态设：SET GLOBAL read_only = ON; - 它真正作用是防误操作、标示角色、配合中间件识别只读节点，不是数据一致性保险栓
- 如果从库被人工执行了
INSERT/UPDATE，后续主库同表同主键写入会触发主键冲突，Slave_SQL_Running直接挂掉，必须人工跳过或修复
最易被忽略的是：没有定期校验主从数据一致性（比如用 pt-table-checksum），也没有监控 Seconds_Behind_Master 是否持续增长——等发现不一致时，往往已错过最佳修复窗口。
