MariaDB在Linux上的复制与同步机制

MariaDB 在 Linux 上的复制与同步机制

一 核心概念与工作流程

• 复制本质是将主库的数据变更以事件形式写入二进制日志（binlog），从库通过I/O 线程拉取这些事件并写入本地中继日志（relay log），再由SQL 线程回放，从而保持数据一致。主库为每个复制连接启动dump 线程向从库发送 binlog。该模型支持一主多从、级联复制等拓扑。复制的三种常见一致性模型为：异步（默认，性能高、可能丢事务）、半同步（至少一个从库确认收到才返回，折中）、同步（所有从库确认，强一致但性能代价高）。复制格式支持STATEMENT、ROW、MIXED，生产常用 ROW 以减少语义差异带来的不确定性。

二 复制类型与适用场景

• 基于位置的复制（File & Position）：从库记录主库的 binlog 文件名与偏移，配置直观，适合新集群或配合备份恢复的起点定位。
• 基于 GTID 的复制：每个事务具备全局唯一 ID，从库告知主库已执行的 GTID 集合，主库仅发送未执行事务，故障切换与级联更简单、可重复执行性强。
• 拓扑与变体：
  • 一主多从：读写分离、读扩展、备份节点。
  • 级联复制：从库再作为上游主库，减轻主库复制压力。
  • 双主/环形（Master–Master）：双向同步，写负载可分担，但需避免自增冲突与循环复制，常用于双活/就近写入场景。

三 快速上手 基于位置的主从搭建

• 前提
  • 两台 Linux 主机安装 MariaDB，网络互通，开放 3306；主从server-id 唯一；建议时间同步（如 NTP）；主库已有数据需先做一次一致性备份作为复制起点。
• 主库配置（/etc/my.cnf 或 /etc/mysql/my.cnf）
  • 启用复制基础参数：
    • [mysqld] 段添加：server-id=1、log-bin（如：/var/log/mysql/mysql-bin.log）、建议 binlog-format=ROW、按需设置 binlog-do-db 或 replicate-do-db、以及 bind-address 为内网地址。
  • 创建复制账号并获取起点：
    • CREATE USER ‘repl’@‘%’ IDENTIFIED BY ‘StrongPass!’;
    • GRANT REPLICATION SLAVE ON . TO ‘repl’@‘%’;
    • FLUSH PRIVILEGES;
    • FLUSH TABLES WITH READ LOCK;
    • SHOW MASTER STATUS; 记录 File 与 Position；
    • UNLOCK TABLES;
    • 备份数据（如 mysqldump --single-transaction --databases your_db > backup.sql），将备份拷贝至从库。
• 从库配置
  • [mysqld] 段添加：server-id=2、relay-log（如：/var/log/mysql/mysql-relay-bin.log）、可选 log-bin（级联复制时需要）、read-only=1（避免误写）、按需设置 replicate-do-db。
  • 恢复主库备份：mysql -u root -p < backup.sql
  • 配置复制起点并启动：
    • CHANGE MASTER TO
      • MASTER_HOST=‘master_ip’,
      • MASTER_USER=‘repl’,
      • MASTER_PASSWORD=‘StrongPass!’,
      • MASTER_LOG_FILE=‘mysql-bin.000001’,
      • MASTER_LOG_POS=123;
    • START SLAVE;
    • SHOW SLAVE STATUS\G 检查 Slave_IO_Running 与 Slave_SQL_Running 均为 Yes。
• 验证
  • 主库插入数据，从库查询验证一致性；如需切换为 GTID，可在数据追平后在线启用 GTID 并切换复制方式。

四 关键配置与运维要点

• 一致性保障
  • 建议主库开启 sync_binlog=1（每次提交落盘），权衡性能与持久性；从库可结合 relay_log_recovery=1 提升崩溃恢复后的复制连续性。
• 复制格式与数据差异
  • 生产优先 ROW，减少函数/触发器/NOW() 等带来的不确定性；STATEMENT 更省日志但语义敏感；MIXED 为自动切换策略。
• 复制过滤
  • 使用 binlog-do-db / replicate-do-db 控制库级复制，谨慎使用库/表级过滤以避免跨库外键、触发器不一致；跨库事务在过滤场景下可能异常。
• 半同步复制
  • 安装 semisync 插件（如 rpl_semi_sync_master / rpl_semi_sync_slave），主库设置 rpl_semi_sync_master_enabled=1，从库设置 rpl_semi_sync_slave_enabled=1，可显著降低异步复制的丢失风险。
• 监控与故障排查
  • 常用命令：SHOW MASTER STATUS、SHOW SLAVE STATUS\G（关注 Last_Error、Exec_Master_Log_Pos、Seconds_Behind_Master）、SHOW PROCESSLIST；常见异常包括 server-id 冲突、GTID 集合不一致、主从 lower_case_table_names 不一致、UUID 冲突（/var/lib/mysql/auto.cnf）、网络/防火墙阻断、权限错误等。

五 常见拓扑与注意事项

• 一主多从：读扩展与备份友好，适合大多数 OLTP 场景；从库可配置不同硬件规格承载报表/分析流量。
• 级联复制：缓解主库复制线程压力，但延迟会叠加，建议控制级联深度。
• 双主/环形：实现双向写入与就近访问，但需处理自增主键冲突（如奇偶/分段）、避免循环（如 log-slave-updates 与复制过滤策略）、应用侧幂等与冲突解决。
• 版本与平台：主从版本尽量一致；Linux 上注意 SELinux/防火墙 策略、目录权限（如 binlog/relay-log 路径）、系统时间同步与存储 I/O 能力。