MySQL主从同步面试核心20问：从原理到实战深度拆解

一、核心原理篇

1. 主从同步基础流程（必考）
答：

• 主库：事务提交后生成binlog，由Dump线程发送给从库
  
• 从库：
  
  
  
  • I/O线程：吸收binlog写入relay log，受slave_net_timeout控制网络超时（默认3600秒）
    
  • SQL线程：剖析relay log执行SQL，单线程计划是经典瓶颈
    
  
  
• 核心文件：master.info（毗连信息）、relay-log.info（执行进度）
  

2. 异步复制 vs 半同步复制（高频）
答：

• 异步复制：主库提交事务后立刻相应客户端，不等待从库确认（高性能，可能丢数据）
  
• 半同步复制（rpl_semi_sync_master_enabled=1）：
  
  
  
  • 至少一个从库ACK确认收到日记后才返回客户端
    
  • 超时退化为异步复制（rpl_semi_sync_master_timeout=1000毫秒）
    
  
  

---

二、设置与监控篇

3. 主从搭建关键步调（实操题）
答：

1. -- 主库  
2. CREATE USER 'repl'@'%' IDENTIFIED BY 'Slave@123';  
3. GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';  
4. SHOW MASTER STATUS; -- 记录File和Position  
6. -- 从库  
7. CHANGE MASTER TO  
8. MASTER_HOST='master_ip',  
9. MASTER_USER='repl',  
10. MASTER_PASSWORD='Slave@123',  
11. MASTER_LOG_FILE='mysql-bin.000001',  
12. MASTER_LOG_POS=154;  
13. START SLAVE;  

复制代码

4. 怎样监控主从延迟（监控计划题）
答：

• 内置指标：
  
  1. SHOW SLAVE STATUS\G  
  2. -- Seconds_Behind_Master（可能不准）  
  3. -- Read_Master_Log_Pos vs Exec_Master_Log_Pos  

  复制代码
• 外部工具：
  
  
  
  • Percona Toolkit的pt-heartbeat：时间戳比对（需NTP同步）
    
  • 监控中继日记堆积量：SHOW GLOBAL STATUS LIKE 'Relay_Log_Space'
    
  
  

---

三、故障排查篇

5. Slave_SQL_Running=No的排查思绪（高频故障）
答：

1. -- 查看具体错误  
2. SHOW SLAVE STATUS\G  
3. /*  
4. Last_Errno: 1062  
5. Last_Error: Duplicate entry '1001' for key 'PRIMARY'  
6. */  
8. -- 临时跳过错误（生产慎用）  
9. STOP SLAVE;  
10. SET GLOBAL sql_slave_skip_counter = 1;  
11. START SLAVE;  
13. -- 根治方案：  
14. 1. 主从数据一致性校验（pt-table-checksum）  
15. 2. 手动修复冲突数据  
16. 3. 重建从库（严重不一致时）  

复制代码

6. 网络闪断导致主从断开怎样优化？
答：

• 修改超时参数加快重连（默认1小时太长）：
  
  1. # my.cnf  
  2. slave_net_timeout = 10      -- 超时时间（秒）  
  3. master-connect-retry = 5    -- 重试间隔  

  复制代码
• 共同TCP Keepalive参数优化：
  
  1. net.ipv4.tcp_keepalive_time = 60  
  2. net.ipv4.tcp_keepalive_probes = 3  
  3. net.ipv4.tcp_keepalive_intvl = 10  

  复制代码

---

四、性能优化篇

7. 主从延迟的六大优化方案（架构计划题）
答：

• 从库层面：
  
  
  
  • 开启并行复制（5.7+）：slave_parallel_workers=4
    
  • 升级硬件：SSD更换HDD，提升IOPS
    
  • 调整事务提交计谋：sync_binlog=0, innodb_flush_log_at_trx_commit=2
    
  
  
• 架构层面：
  
  
  
  • 分库分表减少单库压力
    
  • 使用ProxySQL实现读写分离
    
  • 添加缓存层减少DB查询
    
  
  

8. GTID复制办理了哪些痛点？（进阶考点）
答：

• 传统复制问题：依赖binlog文件名和position，切换主库需手动对齐
  
• GTID上风：
  
  
  
  • 全局唯一事务ID格式：server_uuid:事务序号
    
  • 自动定位同步点，无需手动指定binlog位置
    
  • 强同等性保障：通过enforce_gtid_consistency控制事务安全
    
  
  

---

五、高可用篇

9. MHA高可用方案原理（架构计划）
答：

• 故障转移流程：
  
  
  
  • 检测主库不可用（一连ping失败）
    
  • 选举最新从库（对比relay log进度）
    
  • 其他从库切换新主（通过CHANGE MASTER命令）
    
  
  
• 核心上风：
  
  
  
  • 支持GTID和传统复制
    
  • 自动修复数据差别（通过差别binlog）
    
  • VIP漂移对应用透明
    
  
  

10. 延迟从库的应用场景（容灾计划）
答：

1. CHANGE MASTER TO MASTER_DELAY = 3600; -- 延迟1小时执行  

复制代码

• 核心价值：
  
  
  
  • 误删数据快速规复（在延迟窗口内克制同步）
    
  • 防范逻辑错误（如错误的UPDATE全表更新）
    
  • 应对极端数据破坏场景
    
  
  

---

六、终极压轴题

11. 计划一个主从同步监控系统（架构计划题）
答：

• 数据采集层：
  
  
  
  • 从库状态：SHOW SLAVE STATUS
    
  • 延迟检测：pt-heartbeat --check
    
  • 错误日记监控：ELK收集分析ERROR日记
    
  
  
• 告警规则：
  
  
  
  • 同步线程状态非常（Slave_IO/SQL_Running ≠ Yes）
    
  • 延迟超过阈值（如 > 60秒）
    
  • 特定错误码（1062主键冲突、1032数据不存在）
    
  
  
• 可视化展示：
  
  
  
  • Grafana展示：延迟趋势图、线程状态矩阵
    
  • 拓扑图：主从关系与健康状态
    
  
  
• 自动化处理：
  
  
  
  • 邮件/钉钉关照
    
  • 自动跳过可忽略错误（通过预定义白名单）
    
  • 联动K8s进行Pod重建（容器化环境）
    
  
  

---

七、面试技巧点睛

• 原理类问题：采用"总分结构"，先说整体流程，再拆解核心组件
  
• 故障排查：展示系统化头脑，按"检查状态->分析日记->定位缘故原由->修复验证"四步走
  
• 架构计划：结合业务场景谈选型，如"金融场景需用半同步+无损复制"
  
• 手写命令：夸大关键参数，如CHANGE MASTER必须指定MASTER_AUTO_POSITION=1（GTID场景）
  

保举