MySQL主从复制与读写分离
一、MySQL主从复制(Replication)
1. 核心原理
-
主库(Master):处理写操作,并将数据变更记录到二进制日志(Binary Log, binlog)。
-
从库(Slave):通过IO线程从主库拉取binlog,保存为中继日志(Relay Log),再由SQL线程重放日志,实现数据同步。
-
复制模式:
-
异步复制(默认):主库不等待从库确认,性能高,但存在数据丢失风险。
-
半同步复制:主库至少等待一个从库接收binlog后才提交事务,平衡性能与安全性。
-
全同步复制:需所有从库确认,延迟高,较少使用。
-
2. 配置步骤
-
主库配置:
# my.cnf server-id=1 log-bin=mysql-bin
CREATE USER 'repl'@'%' IDENTIFIED BY 'password'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%'; FLUSH PRIVILEGES; SHOW MASTER STATUS; -- 记录File和Position
-
从库配置:
# my.cnf server-id=2 relay-log=mysql-relay
CHANGE MASTER TOMASTER_HOST='master_ip',MASTER_USER='repl',MASTER_PASSWORD='password',MASTER_LOG_FILE='mysql-bin.000001',MASTER_LOG_POS=154; START SLAVE; SHOW SLAVE STATUS\G; -- 检查Slave_IO_Running和Slave_SQL_Running
3. 监控与维护
-
主库状态:
SHOW MASTER STATUS;
-
从库状态:
SHOW SLAVE STATUS\G
(关注Seconds_Behind_Master
判断延迟)。 -
故障处理:通过
STOP SLAVE;
和SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
跳过错误。
二、读写分离(Read/Write Splitting)
1. 实现方式
-
应用层逻辑:在代码中区分读写操作,连接不同数据源(如Spring配置多数据源)。
-
中间件代理:
-
ProxySQL:灵活的路由规则,支持负载均衡和故障转移。
-
MySQL Router:官方轻量级中间件,自动路由读/写请求。
-
MaxScale:MariaDB开发的数据库代理,支持复杂查询路由。
-
2. 负载均衡策略
-
轮询(Round Robin):均匀分配读请求。
-
权重分配:根据从库配置分配不同权重。
-
动态路由:基于从库负载或延迟动态调整。
3. 一致性保障
-
强制读主库:对实时性要求高的读操作直连主库。
-
半同步复制:减少数据延迟风险。
-
GTID(全局事务标识):确保事务在集群中唯一,简化故障恢复。
三、优势与挑战
优势
-
性能提升:读操作分散到多个从库,缓解主库压力。
-
高可用性:主库故障时可快速切换从库(需配合MHA、Orchestrator等工具)。
-
数据备份:从库作为实时备份,避免数据丢失。
挑战
-
复制延迟:异步复制可能导致从库数据滞后,需监控
Seconds_Behind_Master
。 -
主库单点故障:需通过集群方案(如InnoDB Cluster)或VIP转移解决。
-
复杂查询路由:某些中间件可能无法处理跨库事务或复杂SQL。
四、实际应用建议
-
场景适配:读多写少(如电商、内容平台)收益最大,写密集场景需谨慎。
-
监控工具:使用Percona Monitoring、Prometheus + Grafana监控复制状态。
-
自动化运维:结合Ansible、Kubernetes实现自动化部署与故障恢复。
-
混合架构:结合分库分表(如ShardingSphere)应对海量数据。