DebianMariaDB主从复制原理

MariaDB主从复制究竟是怎么一回事呢？

核心流程

• 主库将数据的变更以事件形式写入二进制日志 Binary Log（binlog）。
• 从库启动后创建I/O 线程连接主库，主库为每个从库连接生成Binlog Dump 线程，把 binlog 事件持续发送给从库；从库 I/O 线程把这些事件写入本地的中继日志 Relay Log。
• 从库的SQL 线程读取 Relay Log 并重放其中的事件，从而让从库数据与主库保持一致。
• 复制是异步的：主库提交事务与把事件发给从库并不等待从库确认，因此从库通常存在秒级延迟（Seconds_Behind_Master）。

线程与文件

• 线程模型
  • 主库：为每个从库连接创建一个Binlog Dump 线程。
  • 从库：一个I/O 线程（拉取 binlog 到 Relay Log）+ 一个SQL 线程（回放 Relay Log）。
• 关键文件
  • 主库：binlog 文件序列（如 mysql-bin.000001），记录数据变更事件。
  • 从库：Relay Log 文件序列与relay-log.index；以及用于保存连接信息与接收进度的master.info，保存重放进度的relay-log.info。这些文件支持故障重启后从断点继续复制。

复制格式与一致性

• 复制格式由参数binlog-format控制，常见取值为：
  • STATEMENT：记录 SQL 语句；体积小，但在依赖上下文或不确定性函数时可能在不同服务器上产生不同结果。
  • ROW：按行记录变更；一致性更强，体积较大。
  • MIXED：由服务器根据语句特性自动选择 STATEMENT 或 ROW。
• 数据一致性要点
  • 默认异步复制存在延迟与数据丢失风险（主库宕机且未传到从库时）。
  • 从库通常配置为read-only，避免应用直写破坏复制一致性（超级用户仍可写）。
  • 复制不是复制磁盘数据文件，而是基于binlog 事件的日志重放机制。

常见拓扑与用途

• 一主一从：入门与通用读写分离场景。
• 一主多从：读扩展、报表与分析分流。
• 链式级联：A→B→C，降低主库连接与带宽压力。
• 双主（互为主从）：双向同步，配合高可用/故障转移实现更高可用性（需谨慎处理自增与冲突）。

复制时定位与监控的要点

• 查看主库状态：SHOW MASTER STATUS; 获取当前日志文件名与位置（File/Position），用于从库接入起点。
• 查看从库状态：SHOW SLA VE STATUSG 关注
  • Sla ve_IO_Running / Sla ve_SQL_Running：两个线程均为Yes才正常。
  • Seconds_Behind_Master：复制延迟秒数，0 表示基本无延迟。
  • Master_Log_File / Read_Master_Log_Pos：I/O 线程已读到的主库位置。
  • Relay_Master_Log_File / Exec_Master_Log_Pos：SQL 线程已执行到的主库位置。
• 从库接入示例：CHANGE MASTER TO ... , MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=155; START SLA VE;（随后用 SHOW SLA VE STATUSG 校验）。