MariaDB主从复制到底是什么原理？
核心流程
- 主库会将数据变更以事件的形式写入二进制日志 Binary Log（binlog），这是 MariaDB 主从同步的基础。
- 从库启动复制后，会创建I/O 线程连接主库；主库则为每个从库连接分配一个Binlog Dump 线程，持续把 binlog 事件发送给从库。从库的 I/O 线程接收到这些事件后，会写入本地的中继日志 Relay Log。
- 随后，从库上的SQL 线程会读取 Relay Log，并按顺序重放其中的事件，从而让从库数据尽量与主库保持一致。
- MariaDB 复制默认是异步的：主库提交事务时，不会等待从库确认事件已接收或执行，因此从库通常会有一定的秒级延迟（Seconds_Behind_Master）。
线程与文件
- 线程模型
- 主库：会为每一个从库连接创建一个Binlog Dump 线程，专门负责发送 binlog。
- 从库：包含一个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：由 MariaDB 根据语句特性自动在 STATEMENT 和 ROW 之间选择，兼顾性能与一致性。
- 数据一致性要点
- 默认的异步复制存在延迟，也有一定的数据丢失风险，例如主库宕机时，部分 binlog 事件可能尚未传输到从库。
- 从库通常会配置为read-only，以防止应用直接写入从库而破坏主从复制一致性（不过超级用户依然可以写入）。
- MariaDB 主从复制并不是直接复制磁盘上的数据文件，而是基于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进行检查与验证）。
