MySQL主从复制实战：Binlog机制与读写分离高可用方案

单库扛读写已经接近瓶颈，MySQL主从复制是成本最低的扩容与容灾手段：主库承担写入，从库同步副本分担读流量，主库故障时可切换。本文从复制原理、部署配置、读写分离到故障切换，给出完整的落地过程。

Binlog复制原理与线程模型

主从复制的核心载体是binlog。主库开启binlog后，所有写操作按事务顺序记录；从库IO线程拉取主库binlog写入本地relay log，SQL线程读取relay log并串行重放，实现数据同步。复制模型是异步的，主库提交事务不等待从库确认，所以从库会有毫秒级延迟，强一致性场景需要引入半同步复制：

# 主库配置
[mysqld]
server-id = 1
log-bin = /data/mysql/binlog/mysql-bin
binlog_format = ROW
sync_binlog = 1

# 从库配置
[mysqld]
server-id = 2
relay-log = /data/mysql/relaylog/mysql-relay-bin
read_only = 1

server-id全局唯一，ROW格式记录行级变更、兼容性最好。从库开启read_only防止人为写入造成主从数据不一致，即使写入了也要靠复制过滤或延迟复制来兜底。

复制链路搭建与一致性校验

主库导出数据（注意锁一致性）恢复到从库后，设置复制源并启动：

-- 从库执行
CHANGE MASTER TO
  MASTER_HOST='10.0.0.1',
  MASTER_PORT=3306,
  MASTER_USER='repl',
  MASTER_PASSWORD='repl_pass',
  MASTER_LOG_FILE='mysql-bin.000021',
  MASTER_LOG_POS=8912;
START SLAVE;

-- 查看复制状态
SHOW SLAVE STATUS\G

重点关注Slave_IO_Running与Slave_SQL_Running均为YES，Seconds_Behind_Master数值正常。用pt-table-checksum周期性校验主从数据一致性，发现差异后用pt-table-sync修复，把校验与修复都纳入监控告警，主从延迟超过阈值触发告警。

读写分离落地与高可用切换

应用层读写分离可配置在数据源层，也可以引入MyCat、ProxySQL中间件。ProxySQL支持SQL正则路由和实时健康检查，把SELECT路由到从库、写和事务路由到主库：

-- ProxySQL 路由规则示例
INSERT INTO mysql_query_rules (active, match_pattern, destination_hostgroup, apply)
VALUES (1, '^SELECT', 1, 1);   -- SELECT 走从库组
INSERT INTO mysql_query_rules (active, match_pattern, destination_hostgroup, apply)
VALUES (1, '.*', 2, 1);        -- 其余走主库组

高可用切换有两条路线：手动切换场景用MHA，自动化接管故障主库，把原从库提升为新主库；规模化场景用MGR（组复制）或Keepalived + VIP漂移。切换后需要把VIP、代理路由、中间件连接池全部指向新主库，并做数据校验；切换演练定期执行，确保应急流程可操作。

延迟排查与常见故障处理

主从延迟排查顺序：先从库负载是否打满（慢SQL、大事务、DDL锁表）；再查网络带宽是否被大事务消耗；用SHOW SLAVE STATUS观察io线程的SQL线程状态。大事务切分到小事务提交，如批量更新拆批，单次影响行数控制在合理区间；大表DDL操作极耗时间，用pt-online-schema-change在线执行。排查完成后清理binlog避免磁盘占满，主从延迟同时纳入监控，形成从发现、定位、修复到验证的闭环。