数据库主从复制原理与实践
字数 1573 2025-11-07 12:34:03
数据库主从复制原理与实践
题目描述
数据库主从复制(Master-Slave Replication)是一种常见的数据冗余与读写分离技术,通过将主库(Master)的数据变更同步到一个或多个从库(Slave),实现数据备份、负载均衡和高可用性。面试中常考察其核心原理、同步流程、数据一致性保障及典型问题解决方案。
一、主从复制的基本架构
- 角色定义:
- 主库(Master):接收所有写操作,并记录数据变更日志(如二进制日志Binlog)。
- 从库(Slave):订阅主库的变更日志,异步或半同步地重放这些操作,保持与主库数据一致。
- 核心组件:
- Binlog(二进制日志):主库记录数据变更的日志文件,格式支持Statement(SQL语句)、Row(行数据变更)或Mixed(混合模式)。
- I/O线程:从库连接主库,拉取Binlog并写入本地中继日志(Relay Log)。
- SQL线程:从库读取Relay Log,解析并执行其中的SQL或行变更操作。
二、主从复制的完整流程
-
主库启用Binlog:
- 配置主库的
server-id和log_bin参数,确保每个变更操作(如INSERT/UPDATE)被记录到Binlog。 - 例如:MySQL中通过
SET GLOBAL server_id=1和log_bin=mysql-bin启用。
- 配置主库的
-
从库配置主库连接:
- 通过
CHANGE MASTER TO命令指定主库的IP、端口、Binlog文件名和位置(或GTID)。 - 示例:
CHANGE MASTER TO MASTER_HOST='192.168.1.100', MASTER_USER='repl_user', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154;
- 通过
-
数据同步过程:
- 步骤1:从库的I/O线程向主库发起连接,请求从指定位置开始拉取Binlog。
- 步骤2:主库的Binlog Dump线程将Binlog内容发送给从库的I/O线程。
- 步骤3:I/O线程将接收到的Binlog事件顺序写入从库的Relay Log。
- 步骤4:从库的SQL线程读取Relay Log,解析事件并重放SQL操作(如执行INSERT)。
- 步骤5:从库定期更新当前同步的Binlog位置信息,确保重启后能继续同步。
三、主从复制的数据一致性保障
-
异步复制(默认):
- 主库提交事务后立即返回成功,不等待从库确认。
- 风险:主库宕机可能导致从库数据丢失(弱一致性)。
-
半同步复制(Semi-Sync):
- 主库提交事务后,至少等待一个从库接收并写入Relay Log后才返回成功。
- 配置方式(MySQL):
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; SET GLOBAL rpl_semi_sync_master_enabled=1;
-
全同步复制(Group Replication):
- 基于Paxos协议,要求所有节点确认事务后才提交,保证强一致性(但性能较低)。
四、典型问题与解决方案
-
主从延迟:
- 原因:从库SQL线程单线程重放(MySQL 5.6前)、网络延迟、主库写压力大。
- 优化:
- 启用并行复制(如MySQL的
slave_parallel_workers)。 - 使用行格式Binlog(Row模式)减少锁竞争。
- 启用并行复制(如MySQL的
-
数据冲突:
- 场景:误操作在从库写入数据,导致主从数据不一致。
- 预防:设置从库
read_only=ON,禁止非复制线程的写操作。
-
主从切换:
- 手动切换:
- 主库停写,确保从库追平Binlog。
- 将从库设为新主库,其他从库重新指向新主库。
- 工具辅助:使用MHA(Master High Availability)或Orchestrator自动化切换。
- 手动切换:
五、实践建议
- 监控指标:
Seconds_Behind_Master:主从延迟秒数。Slave_IO_Running/Slave_SQL_Running:复制线程状态。
- 容灾演练:定期模拟主库故障,测试切换流程和数据完整性。
通过以上步骤,主从复制的核心原理、同步流程及常见问题解决方案得以系统化呈现,为实际生产环境部署提供理论支撑。