新增从库前必须确认主库 binlog 格式为 row 或 mixed，并记录 show master status 的 file 和 position（gtid 模式除外）；优先使用 xtrabackup 等物理备份初始化，逻辑备份须加 --master-data=2 等参数；启动后需验证 seconds_behind_master、gtid 集合一致性及表级数据，并确保应用连接池和中间件具备故障自动剔除与只读校验能力。
新增从库前必须确认主库的 binlog 格式和位置
MySQL 主从复制依赖主库的 binlog，如果格式不是 ROW 或 MIXED，某些 DML 操作（比如带函数的 UPDATE）可能在从库执行出错或不一致。另外，新从库需要从某个确定的 binlog 文件名和偏移量开始同步，不能靠“当前最新”这种模糊概念。
-
SHOW VARIABLES LIKE 'binlog_format';必须返回ROW（推荐）或MIXED，STATEMENT在复杂查询下风险高 -
SHOW MASTER STATUS;记下返回的File和Position，这是新从库CHANGE REPLICATION SOURCE TO的起点 - 如果主库启用了
gtid_mode=ON，则不需要手动记 position，但所有节点必须统一开启 GTID，且新从库初始化时要用START SLAVE UNTIL SQL_AFTER_GTIDS类逻辑对齐
从库初始化不能只靠 mysqldump —— 大库会丢数据或锁死主库
直接 mysqldump --single-transaction 对小库可行，但对百 GB 级别主库，dump 过程长、网络传输慢、从库导入期间主库 binlog 可能被 purge，导致后续同步失败；更危险的是，没加 --master-data=2 就 dump，根本拿不到一致的起始位点。
- 优先用物理备份：Percona XtraBackup 或
mysqlbackup，支持热备 + 自动记录binlog位置，恢复快、不锁表 - 若必须逻辑备份，至少加上
--master-data=2 --single-transaction --routines --triggers，且确保备份前后主库没执行PURGE BINARY LOGS - 备份完成后，立刻在主库执行
FLUSH BINARY LOGS;，避免旧日志被自动清理，给从库留出同步窗口
从库启动后要验证复制延迟和一致性，不能只看 Slave_IO_Running=Yes
SHOW SLAVE STATUS\G 里 Slave_IO_Running: Yes 和 Slave_SQL_Running: Yes 只代表线程活着，不代表数据准——常见问题包括主从时间不同步导致 Seconds_Behind_Master 假为 0、GTID 跳过事务、或者从库因唯一键冲突卡在 SQL Thread。
- 检查
Seconds_Behind_Master是否持续为 0，且Retrieved_Gtid_Set和Executed_Gtid_Set完全相等（GTID 模式下） - 用
pt-table-checksum对比主从表级数据一致性，尤其关注大表和高频更新表 - 监控
Slave_SQL_Running_State，如果长期停留在Reading event from the relay log，说明 relay log 积压，可能是从库 I/O 或 CPU 瓶颈
读流量切到新从库前，应用层必须支持连接池自动剔除故障节点
加从库不是改个 IP 就完事。应用如果用静态配置直连某台从库，一旦那台宕机或复制中断，请求就会失败；更麻烦的是，有些 ORM 或中间件默认不校验复制状态，把写请求发到从库会报 ERROR 1290 (HY000): The MySQL server is running with the --read-only option。
- 确保数据库连接池（如 HikariCP、Druid）配置了
connection-test-query=SELECT 1和合理的validation-timeout，能及时踢掉不可用从库 - 读写分离中间件（如 MyCat、ShardingSphere）需显式配置
read_only检测逻辑，避免将读请求路由到主库或异常从库 - 上线前做一次人工模拟故障：手动
STOP SLAVE新从库，观察应用是否自动降级到其他从库，且无报错日志
真正难的不是加一台从库，而是让整个链路——从 binlog 生成、物理恢复、复制校验到应用路由——每个环节都默认容忍单点波动。漏掉任意一环，水平扩展就变成单点放大器。
