MariaDB在Linux上的高可用实现
一、方案总览与选型
- Galera Cluster 多主同步：多节点同时可读写，数据强一致（依赖认证复制），适合对一致性与可用性同时有要求的业务。典型搭配为 HAProxy/Keepalived 做连接入口与故障剔除，或结合 Pacemaker/Corosync 做资源管理与自动切换。Galera 的同步复制对 InnoDB/XtraDB 有效，MyISAM 不支持同步复制。适合读写都分散、需要自动故障转移的场景。
- 主从复制 + VIP/Keepalived：一主多从或半主从，写主读从，通过 Keepalived 管理 VIP 实现故障漂移，简单可控，适合读多写少、可接受异步复制延迟的场景。
- 主从复制 + Pacemaker/Corosync：在复制基础上引入集群资源管理器，对 VIP、MariaDB 服务、磁盘/网络 等资源做编排与仲裁，适合已有 Pacemaker 栈、需要更强编排能力的场景。
二、方案一 Galera Cluster + HAProxy/Keepalived（多主，读写分离可选）
- 架构要点
- 至少 3 节点 组成 Galera 集群，提供多主写入与自动节点恢复；前端用 HAProxy 做健康检查与负载均衡，配合 Keepalived 提供 VIP 统一入口，避免单点。
- 关键配置步骤
- 安装 Galera 组件（以 CentOS/RHEL 为例）
- 安装软件包：MariaDB-Galera-server、MariaDB-client、galera、rsync（部分系统需先启用 EPEL 并安装 socat）。
- 配置 MariaDB（/etc/my.cnf.d/ 或 /etc/mysql/mariadb.conf.d/）
- 启用 InnoDB；设置唯一 server-id；开启 binlog（ROW）；配置 wsrep 提供者（如 wsrep_provider=/usr/lib64/galera/libgalera_smm.so）、集群名、节点地址与名称等。
- 初始化集群
- 选择一个节点作为“种子节点”首次启动，其余节点加入；引导完成后验证 wsrep_cluster_size 与复制状态。
- 部署 HAProxy
- 配置 backend 使用 httpchk（或 tcp-check）对 3306 做健康检查，设置 inter 2000 rise 2 fall 3 等阈值；算法可选 leastconn/roundrobin/source；将异常节点自动摘除。
- 部署 Keepalived
- 配置 VIP 与 nopreempt/state；通过 vrrp_script 对 HAProxy 或 mysqld 做存活探测，主机故障自动切换 VIP 到备机。
- 验证
- 停掉任一数据库节点或 HAProxy，确认 VIP 漂移、业务连接不断、集群重新收敛。
- 适用与注意
- 优点：多主写入、自动故障转移、对应用透明；缺点：写冲突需业务规避，复制为“近同步”，网络抖动会放大影响；仅 InnoDB/XtraDB 受益。
三、方案二 主从复制 + Keepalived VIP（简单双机）
- 架构要点
- 一主一从（或多从），写主读从；Keepalived 管理 VIP 与故障切换；应用直连 VIP。
- 关键配置步骤
- 主从搭建
- 主库开启 log_bin、server_id，创建复制用户；从库设置 server_id，执行 CHANGE MASTER TO 指向主库并启动复制。
- 半同步复制（可选）
- 安装 semisync 插件，提升数据到达从库的可靠性（仍非强一致）。
- Keepalived 配置
- 定义 VIP、优先级、抢占策略；健康检查脚本探测 3306 或基于 mysqladmin/自定义脚本；主机宕机 VIP 漂移到从库，从库可设置 read_only=1 避免误写。
- 验证
- 主库宕机/网络隔离后，确认 VIP 切换、从库可接管读流量；主库恢复后按策略切回或保持主从。
- 适用与注意
- 优点：部署简单、运维门槛低；缺点：写单点，切换存在数据延迟窗口，需应用容忍或配合中间件实现读写分离与重试。
四、方案三 主从复制 + Pacemaker/Corosync（资源编排与仲裁）
- 架构要点
- 在复制基础上引入 Corosync 做节点通信与仲裁，Pacemaker 编排 VIP、MariaDB 服务、挂载、网络 等资源，实现更可控的故障切换与约束管理。
- 关键配置步骤
- 安装组件
- 安装 pacemaker、corosync（以及常用工具如 pcs）。
- 配置 Corosync
- 设定 totem、quorum、nodelist、interface 等，确保法定人数与冗余链路。
- 配置 Pacemaker
- 通过 pcs 创建资源：如 IPaddr2（VIP）、systemd:mariadb、必要的 filesystem/pingd 约束；设置 colocation、order、migration-threshold、failure-timeout 等策略。
- 健康检查与切换
- 配置探针（monitor interval）、超时与迁移策略；模拟故障验证 VIP 与实例 的迁移顺序与数据一致性。
- 适用与注意
- 优点：编排能力强、可纳入更大规模的集群栈；缺点：复杂度与运维成本更高，需合理规划仲裁与隔离策略。
五、通用落地要点与避坑清单
- 数据一致性与存储引擎：Galera 仅对 InnoDB/XtraDB 有效，MyISAM 表不会受益于同步复制；全局事务与自增需合理设计（如 wsrep_auto_increment_control、auto_increment_offset/increment）。
- 时间同步：务必部署 chrony/ntpd，避免节点间时钟漂移导致复制或仲裁异常。
- 网络与防火墙：开放 3306（数据库）、VRRP（Keepalived，常见 112）、以及 Galera 所需端口（如 4567/4568/4444）；跨机房部署需考虑延迟与带宽。
- SST/IST 与流控：为 Galera 配置合适的 SST 方法（如 rsync/xtrabackup-v2） 与带宽/并发参数，避免大库初始化或节点追赶时拖垮集群。
- 连接入口治理：生产建议使用 HAProxy + Keepalived VIP 或 Pacemaker VIP，并配置健康检查、熔断与重试，避免将应用直连单节点。
- 监控与演练：监控 wsrep_local_state_comment、wsrep_cluster_size、复制延迟、VIP 漂移事件；定期做主从切换/节点宕机演练，验证 RTO/RPO 是否符合 SLA。