数据库主从复制原理与实践
字数 1573 2025-11-07 12:34:03

数据库主从复制原理与实践

题目描述
数据库主从复制(Master-Slave Replication)是一种常见的数据冗余与读写分离技术,通过将主库(Master)的数据变更同步到一个或多个从库(Slave),实现数据备份、负载均衡和高可用性。面试中常考察其核心原理、同步流程、数据一致性保障及典型问题解决方案。

一、主从复制的基本架构

  1. 角色定义
    • 主库(Master):接收所有写操作,并记录数据变更日志(如二进制日志Binlog)。
    • 从库(Slave):订阅主库的变更日志,异步或半同步地重放这些操作,保持与主库数据一致。
  2. 核心组件
    • Binlog(二进制日志):主库记录数据变更的日志文件,格式支持Statement(SQL语句)、Row(行数据变更)或Mixed(混合模式)。
    • I/O线程:从库连接主库,拉取Binlog并写入本地中继日志(Relay Log)。
    • SQL线程:从库读取Relay Log,解析并执行其中的SQL或行变更操作。

二、主从复制的完整流程

  1. 主库启用Binlog

    • 配置主库的server-idlog_bin参数,确保每个变更操作(如INSERT/UPDATE)被记录到Binlog。
    • 例如:MySQL中通过SET GLOBAL server_id=1log_bin=mysql-bin启用。
  2. 从库配置主库连接

    • 通过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;  
      
  3. 数据同步过程

    • 步骤1:从库的I/O线程向主库发起连接,请求从指定位置开始拉取Binlog。
    • 步骤2:主库的Binlog Dump线程将Binlog内容发送给从库的I/O线程。
    • 步骤3:I/O线程将接收到的Binlog事件顺序写入从库的Relay Log。
    • 步骤4:从库的SQL线程读取Relay Log,解析事件并重放SQL操作(如执行INSERT)。
    • 步骤5:从库定期更新当前同步的Binlog位置信息,确保重启后能继续同步。

三、主从复制的数据一致性保障

  1. 异步复制(默认)

    • 主库提交事务后立即返回成功,不等待从库确认。
    • 风险:主库宕机可能导致从库数据丢失(弱一致性)。
  2. 半同步复制(Semi-Sync)

    • 主库提交事务后,至少等待一个从库接收并写入Relay Log后才返回成功。
    • 配置方式(MySQL):
      INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';  
      SET GLOBAL rpl_semi_sync_master_enabled=1;  
      
  3. 全同步复制(Group Replication)

    • 基于Paxos协议,要求所有节点确认事务后才提交,保证强一致性(但性能较低)。

四、典型问题与解决方案

  1. 主从延迟

    • 原因:从库SQL线程单线程重放(MySQL 5.6前)、网络延迟、主库写压力大。
    • 优化
      • 启用并行复制(如MySQL的slave_parallel_workers)。
      • 使用行格式Binlog(Row模式)减少锁竞争。
  2. 数据冲突

    • 场景:误操作在从库写入数据,导致主从数据不一致。
    • 预防:设置从库read_only=ON,禁止非复制线程的写操作。
  3. 主从切换

    • 手动切换
      1. 主库停写,确保从库追平Binlog。
      2. 将从库设为新主库,其他从库重新指向新主库。
    • 工具辅助:使用MHA(Master High Availability)或Orchestrator自动化切换。

五、实践建议

  1. 监控指标
    • Seconds_Behind_Master:主从延迟秒数。
    • Slave_IO_Running/Slave_SQL_Running:复制线程状态。
  2. 容灾演练:定期模拟主库故障,测试切换流程和数据完整性。

通过以上步骤,主从复制的核心原理、同步流程及常见问题解决方案得以系统化呈现,为实际生产环境部署提供理论支撑。

数据库主从复制原理与实践 题目描述 数据库主从复制(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)。 示例: 数据同步过程 : 步骤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): 全同步复制(Group Replication) : 基于Paxos协议,要求所有节点确认事务后才提交,保证强一致性(但性能较低)。 四、典型问题与解决方案 主从延迟 : 原因 :从库SQL线程单线程重放(MySQL 5.6前)、网络延迟、主库写压力大。 优化 : 启用并行复制(如MySQL的 slave_parallel_workers )。 使用行格式Binlog(Row模式)减少锁竞争。 数据冲突 : 场景 :误操作在从库写入数据,导致主从数据不一致。 预防 :设置从库 read_only=ON ,禁止非复制线程的写操作。 主从切换 : 手动切换 : 主库停写,确保从库追平Binlog。 将从库设为新主库,其他从库重新指向新主库。 工具辅助 :使用MHA(Master High Availability)或Orchestrator自动化切换。 五、实践建议 监控指标 : Seconds_Behind_Master :主从延迟秒数。 Slave_IO_Running / Slave_SQL_Running :复制线程状态。 容灾演练 :定期模拟主库故障,测试切换流程和数据完整性。 通过以上步骤,主从复制的核心原理、同步流程及常见问题解决方案得以系统化呈现,为实际生产环境部署提供理论支撑。