mariadb高可用主从复制核心是稳定同步与故障可接管：需配置唯一server-id、row格式binlog、最小权限复制账号；验证slave_io_running、slave_sql_running及seconds_behind_master；启用半同步提升一致性；结合mha或keepalived+双主实现自动故障转移。
配置 MariaDB 高可用主从复制集群，核心在于稳定同步 + 故障可接管。单纯主从只是数据冗余，要真正“高可用”，必须叠加监控、自动故障转移或双主+VIP等机制。下面按生产环境常见做法，分四步讲清关键操作和避坑要点。
主从基础复制必须配稳
这是高可用的前提，任何上层方案都依赖它可靠运行：
-
主库（Master）：确保
server-id唯一（如1），开启log-bin，推荐binlog_format=ROW；禁用系统库同步可加binlog_ignore_db=mysql，但不要忽略information_schema或performance_schema（它们不写 binlog）。 -
从库（Slave）：
server-id必须与主库不同（如2），建议启用read_only=ON防止误写；若需级联或后续升级为新主，加上log_slave_updates=ON。 -
复制账号：在主库创建最小权限用户，例如：
CREATE USER 'repl'@'192.168.3.%' IDENTIFIED BY 'StrongPass@2026';GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.3.%';
注意网段精确控制，避免用'%'暴露公网。 -
启动复制前：主库执行
SHOW MASTER STATUS;记下File和Position；从库用CHANGE MASTER TO精确指定这两个值，再执行START SLAVE;。
验证同步状态不能只看 Yes/No
SHOW SLAVE STATUS\G 输出里，重点盯三个字段：
-
Slave_IO_Running: Yes—— 表示能连上主库并拉取日志；如果为No，先查网络、防火墙、账号密码、主库是否启用了skip_networking。 -
Slave_SQL_Running: Yes—— 表示中继日志能正常重放；若为No，大概率是 SQL 冲突（如从库手动写了同名表）、字符集不一致或 GTID 模式下位置错乱。 -
Seconds_Behind_Master: 0—— 数值持续为 0 才算实时；若缓慢增长，检查从库磁盘 I/O、大事务未提交、或主库sync_binlog=0导致日志刷盘延迟。
半同步复制提升数据一致性
默认异步复制下，主库提交即返回，从库可能还没收到日志。启用半同步后，主库会等待至少一个从库确认接收并写入 relay log 才响应客户端，大幅降低脑裂风险：
- 主库执行：
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';SET GLOBAL rpl_semi_sync_master_enabled = 1; - 从库执行：
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';SET GLOBAL rpl_semi_sync_slave_enabled = 1; - 重启从库的 IO 线程生效：
STOP SLAVE IO_THREAD; START SLAVE IO_THREAD; - 验证：
SHOW VARIABLES LIKE 'rpl_semi_sync%';和SHOW STATUS LIKE 'Rpl_semi_sync%';查看是否 active。
高可用接管需要外部工具或双主架构
MariaDB 自身不提供自动主从切换。生产中常用两种路径：
-
MHA（Master High Availability）：轻量 Perl 工具，监控主库心跳，异常时自动提升一个从库为新主，并重写其余从库的
CHANGE MASTER TO。需额外部署管理节点，依赖 SSH 免密和 Perl 环境。 -
Keepalived + 双主（Active-Passive）：两台 MariaDB 互为对方的主库（各自
server-id不同，均开log_slave_updates），再用 Keepalived 绑定一个虚拟 IP（VIP）。主库宕机后 VIP 漂移到备用节点，应用通过 VIP 访问，感知不到切换。注意务必设置auto-increment-offset和auto-increment-increment避免主键冲突。
