MySQL主从复制配置前必须检查的5个点：server_id全局唯一且非零；主库binlog_format=ROW；主库log-bin已启用且路径可写；从库relay_log路径有写权限且磁盘空间充足；主从时区一致。
MySQL主从复制配置前必须检查的5个点
不校验这些，同步延迟或中断几乎必然发生。
-
server_id必须全局唯一，且不能为0或空字符串；主从若重复，从库启动IO_THREAD会静默失败 - 主库必须开启
binlog_format = ROW（尤其涉及 JSON、生成列、时间戳默认值时，STATEMENT模式会丢数据或报错） - 主库
my.cnf中确认已启用log-bin，且路径可写；常见错误是只写了log-bin没给文件名，导致实际未启用 - 从库
relay_log路径需有写权限，且磁盘剩余空间 ≥ 主库日志峰值日增长量 × 2，否则SQL_THREAD会卡住 - 主从时区必须一致：
SELECT @@time_zone;应返回相同结果；否则TIMESTAMP类型字段在复制中会偏移
mysqldump + binlog position 同步的实操要点
这是迁移初期最可控的方式，但位置定位稍有偏差就会导致从库数据不一致。
- 主库执行
FLUSH TABLES WITH READ LOCK;后，立刻运行SHOW MASTER STATUS;记下File和Position—— 这两个值必须和后续mysqldump的--master-data=2输出严格对应 -
mysqldump命令必须加--single-transaction --skip-lock-tables（InnoDB 表），否则锁表时间过长；但注意：该组合对非事务表（如 MyISAM）仍会锁表 - 恢复到从库前，先停掉
slave：STOP SLAVE;，再sourcedump 文件；否则可能因 GTID 冲突或主键重复中断 - 导入完成后，用
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000012', MASTER_LOG_POS=198765432;精确指定起点，不要依赖 dump 文件里的注释行（它可能被编辑器意外截断）
GTID 模式下常见的同步中断原因与修复
启用 gtid_mode=ON 后，传统 position 方式失效，错误处理逻辑完全不同。
- 从库报错
Could not execute Write_rows_v1 event on table xxx; Duplicate entry '123' for key 'PRIMARY'，说明主库有重复写入，但从库已存在该记录 —— 此时不能跳过事务（SET GLOBAL sql_slave_skip_counter = 1无效），必须用SET GTID_NEXT='xxx-yyy-zzz:12345'; BEGIN; COMMIT;注入空事务绕过 - 主库执行了
DROP DATABASE后又重建同名库，从库可能因 GTID 已执行过而拒绝重建语句；需确认SELECT * FROM mysql.gtid_executed WHERE source_uuid = 'xxx' AND interval_start = 12345;是否覆盖该事务 - 切换主库后，新主库的
gtid_purged若不包含旧主库已执行的部分，从库会报Cannot replicate because the master purged required binary logs；此时需用RESET MASTER;清空新主库 GTID 集合，再手动SET GTID_PURGED补全
半同步复制（semisync）开启后性能掉得厉害怎么办
不是所有场景都适合开半同步，它本质是以延迟换一致性。
- 确认插件已加载：
SELECT plugin_name, plugin_status FROM information_schema.plugins WHERE plugin_name LIKE '%semisync%';—— 若状态为DISABLED，需在my.cnf加plugin_load_add = 'semisync_master.so;semisync_slave.so' - 主库设置
rpl_semi_sync_master_timeout = 1000000（单位微秒，即 1 秒），避免单个从库响应慢拖垮全部写入；超时后自动退化为异步，不影响可用性 - 从库仅需启用
rpl_semi_sync_slave_enabled = ON，无需设超时；但必须确保网络抖动时，主库能及时感知从库离线（靠rpl_semi_sync_master_wait_for_slave_count控制等待几个从库响应） - 监控关键指标：
SHOW STATUS LIKE 'Rpl_semi_sync%';中Rpl_semi_sync_master_yes_tx/Rpl_semi_sync_master_no_tx比值持续低于 0.9，说明半同步实效性差，建议关掉或换为 MGR
-- 检查半同步当前状态的常用命令 SHOW VARIABLES LIKE 'rpl_semi_sync%'; SHOW STATUS LIKE 'Rpl_semi_sync%'; SELECT * FROM performance_schema.replication_connection_status\G
GTID 切换、半同步超时阈值、binlog 格式选择——这些不是“配完就完”的开关，而是要随业务写负载、网络质量、故障恢复预期动态调整的参数。漏掉任意一个细节，都可能让高可用变成高不可用。
