MariaDB多源复制数据同步实现
日志传输环节
- 二进制日志（Binlog）：主库开启二进制日志功能，记录数据库的所有写操作。每个事务会按照顺序记录在Binlog中，Binlog以文件形式存储，文件名通常为
hostname-bin.xxxxxx，其中xxxxxx是日志文件编号。
- I/O线程：从库启动I/O线程，连接到每个主库。I/O线程向主库发送请求，获取主库Binlog的位置信息（通常是文件名和偏移量）。主库接收到请求后，从指定位置开始将Binlog内容发送给从库的I/O线程。
- 中继日志（Relay Log）：I/O线程接收到Binlog内容后，将其写入到从库本地的中继日志中。中继日志的文件名格式为
hostname-relay-bin.xxxxxx，同样记录了主库的写操作，是主库Binlog在从库的临时副本。
应用环节
- SQL线程：从库启动SQL线程，负责读取中继日志中的内容，并将其解析为SQL语句在从库上执行。SQL线程按照中继日志中的记录顺序，逐一执行SQL语句，从而使从库的数据与主库保持一致。
- 多源复制协调：在多源复制场景下，从库会为每个主库维护独立的I/O线程和中继日志。SQL线程会按顺序依次读取各个中继日志，并应用其中的事务，确保每个主库的数据都能准确同步到从库。
故障恢复机制
主库故障
- 自动检测：从库的I/O线程会定期尝试连接主库，如果连接失败，会标记该主库为不可用。
- 自动重连：从库会在一定时间间隔后自动尝试重新连接故障的主库。如果主库恢复正常，I/O线程可以重新建立连接，继续从上次中断的位置同步Binlog。
- 跳过故障事务：如果主库故障导致部分事务未完整同步到从库，从库的SQL线程在应用中继日志时，可能会遇到错误。在这种情况下，可以通过设置
slave_skip_errors参数，让SQL线程跳过特定错误，继续应用后续事务。但这种方式可能会导致数据不一致，需谨慎使用。
网络中断
- I/O线程暂停：网络中断时，从库的I/O线程无法与主库通信，会暂停从主库读取Binlog的操作。
- 自动恢复：当网络恢复后，I/O线程会自动尝试重新连接主库。如果连接成功，会根据之前记录的Binlog位置信息，从断点处继续同步数据。
手动干预恢复详细操作流程
主库故障
- 确认主库故障：通过监控工具或从库日志（如
SHOW SLAVE STATUS\G查看Seconds_Behind_Master持续增大或变为NULL等）判断主库是否故障。
- 切换主库（可选）：如果有备用主库，可以在从库上使用
CHANGE MASTER TO语句切换到备用主库。例如：
STOP SLAVE;
CHANGE MASTER TO
MASTER_HOST='new_master_host',
MASTER_USER='replication_user',
MASTER_PASSWORD='replication_password',
MASTER_LOG_FILE='new_master_binlog_file',
MASTER_LOG_POS=new_master_binlog_position;
START SLAVE;
- 处理未同步事务：如果需要确保数据一致性，可通过主库备份恢复故障主库，然后重新配置从库与主库的复制关系。或者分析中继日志，手动处理未同步的事务。
- 修复主库并重新配置复制：如果主库可以修复，修复后在从库上重新配置复制关系，让从库重新连接主库同步数据。
网络中断
- 确认网络中断：通过从库日志（如I/O线程报错
Can't connect to master等）判断网络中断。
- 等待网络恢复：一般情况下，无需手动干预，等待网络恢复后，从库I/O线程会自动重连主库继续同步。
- 手动重连（异常情况）：如果网络恢复后，从库未能自动重连，可以手动停止并重启从库复制：
STOP SLAVE;
START SLAVE;
- 检查同步状态：使用
SHOW SLAVE STATUS\G检查从库的同步状态，确保Slave_IO_Running和Slave_SQL_Running都为Yes，Seconds_Behind_Master为0或在合理范围内。
