MySQL主从复制基于binlog+relay log异步重放，需ROW格式、开启log-bin、唯一server-id；GTID提升切换可靠性但须全集群统一启用；延迟监控须结合Seconds_Behind_Master与File/Position比对。
主从复制靠的是 binlog + relay log 两级日志流转
MySQL 主从复制不是实时内存同步，而是基于日志的异步（或半同步）重放。主库把所有写操作记录到 binlog，从库通过 I/O 线程拉取并存为 relay log，再由 SQL 线程顺序执行其中的事件。
关键点在于：binlog 格式必须为 ROW 或 MIXED（不推荐 STATEMENT，因函数、临时表、非确定性语句易导致主从不一致）；主库需开启 log-bin，从库需设置 server-id 且唯一。
-
binlog_format = ROW是生产环境事实标准，能精确捕获行级变更 - 从库的
relay_log文件默认命名规则是hostname-relay-bin.xxxxxx，不建议手动修改其路径，否则CHANGE MASTER TO可能失效 - SQL 线程单线程回放 relay log，这是传统主从的性能瓶颈，MySQL 5.7+ 的
slave_parallel_workers > 0可按库/事务分发，但需配合slave_parallel_type = LOGICAL_CLOCK
START SLAVE 启动失败常见原因和检查项
执行 START SLAVE 后，SHOW SLAVE STATUS\G 中 Slave_IO_Running 或 Slave_SQL_Running 为 No，说明链路中断。不能只看 Seconds_Behind_Master 是否为 NULL。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- IO 线程失败：检查主库网络可达性、复制用户权限（
REPLICATION SLAVE）、主库binlog文件是否被清理（show master logs对比Master_Log_File）、主库磁盘满导致binlog写入失败 - SQL 线程失败：最常见于主从数据不一致引发的唯一键冲突、表结构不一致（如从库少字段）、DDL 执行失败（如
DROP TABLE在从库不存在）、或binlog_format = STATEMENT下调用NOW()/UUID()导致时间/值不一致 - 跳过错误需谨慎：
SET GLOBAL sql_slave_skip_counter = 1仅对STATEMENT格式有效；mysqlbinlog --stop-never解析 relay log 定位具体出错 SQL 更可靠
GTID 模式让主从切换更可控，但要求全集群统一开启
启用 GTID（gtid_mode = ON + enforce_gtid_consistency = ON）后，每个事务有全局唯一标识，不再依赖 File/Position。故障切换时，新主库可直接告诉从库“从这个 GTID 集合之后开始同步”，避免找错 binlog 偏移量。
- GTID 开启必须重启 MySQL 实例，且主从必须同时开启，混合模式不可行
- 使用
CHANGE MASTER TO MASTER_AUTO_POSITION = 1替代手工指定MASTER_LOG_FILE和MASTER_LOG_POS - GTID 不保证事务执行顺序完全一致（例如跨库并发事务在主库提交顺序与从库回放顺序可能不同），但能确保最终一致性
- 慎用
RESET MASTER：它会清空所有 binlog 并重置 GTID_EXECUTED，若从库尚未消费完，会导致无法继续同步
主从延迟大不只是网络问题，要盯住 Seconds_Behind_Master 的真实含义
Seconds_Behind_Master 显示的是 SQL 线程执行位置距离当前时间的秒数，不是 IO 线程拉取延迟。它为 0 仅表示“已执行完当前 relay log 中所有事件”，不代表没有积压——如果 IO 线程卡住，这个值可能长时间为 0，但实际已落后。
- 真正判断延迟要看：
Relay_Master_Log_File和Exec_Master_Log_Pos是否追上主库的File/Position（用SHOW MASTER STATUS对比） - 大事务是最大延迟源：一个耗时 30 分钟的
UPDATE在从库单线程回放，就会卡住后续所有事务 - 从库负载过高（如慢查询、备份、统计分析）也会拖慢 SQL 线程，建议从库关闭
query_cache_type，避免缓存锁竞争 - 监控不能只看
Seconds_Behind_Master，应结合Seconds_Behind_Master IS NULL（线程异常）、Retrieved_Gtid_Set与Executed_Gtid_Set差集大小（GTID 模式下更准）
SELECT @@global.gtid_mode AS gtid_mode, @@global.enforce_gtid_consistency AS enforce_gtid_consistency, @@global.binlog_format AS binlog_format, @@global.log_bin AS log_bin;主从复制看似配置简单，但 binlog 格式、GTID 开关时机、SQL 线程卡点、以及监控指标的真实含义，这几处一旦设错或忽略，高可用就变成高不可靠。
