linux服务-MariaDB 10.6 Galera Cluster+garbd

MariaDB 10.6 Galera Cluster+garbd

Galera仲裁机制与garbd补票方案（两台节点高可用）

参考：gardb源码下载链接， maraidb galera 部署编译章节，gardb下载仓库

一、Galera的仲裁机制

Galera集群是基于"投票仲裁"的同步复制集群，其高可用能力的核心依赖于Quorum（法定票数）规则------集群必须有超过半数的节点在线且互通，才能正常提供写服务；否则会进入只读模式，仅允许读取数据，以此避免数据不一致（如脑裂）。

• 仲裁核心公式与逻辑

  • 法定票数计算公式：Quorum = (总节点数 / 2) + 1（结果取整数）。该公式决定了不同节点数量的集群，在故障后的可用性差异，这也是两台节点集群的核心痛点所在。

• 两台 vs 三台节点的仲裁差异（核心痛点）

  通过对比可清晰看到，两台节点集群的高可用能力几乎失效，根源就是仲裁机制的约束：

  对比维度	两台节点集群（原生）	三台节点集群（标准生产）
  所需Quorum	2台（(2/2)+1=2）→ 必须全部在线	2台（(3/2)+1=2）→ 仅需多数节点在线
  单节点宕机后状态	剩余1台 < Quorum → 集群只读，完全丧失写能力	剩余2台 ≥ Quorum → 集群正常读写，无服务中断
  网络分区后表现	两台互断 → 两边均1台，均只读 → 整体不可用	分区为1台+2台 → 2台组保持Quorum可写，1台组只读 → 服务不中断
  高可用价值	几乎失效，仅适合测试/演示	生产级高可用，故障无感知

• 两台节点的破局思路

  • 既然两台节点的核心问题是"无法满足Quorum=2的要求"，破局关键就是：在不增加物理数据节点的前提下，补充一个"投票节点"，让集群逻辑上变为3个节点，从而使Quorum降为2（2台节点+1个投票节点即可满足）。Galera Arbitrator（简称garbd）就是为此设计的轻量解决方案。

二、Galera + garbd

2.1、部署前准备

• 仲裁节点补票方案

  • garbd是Galera官方提供的轻量级"虚拟仲裁节点"，它不存储任何数据、不提供数据库服务，仅参与集群的Quorum投票，完美解决两台物理节点的仲裁痛点。部署后集群逻辑结构为：2台数据节点（存储数据+提供服务）+1台仲裁节点（仅投票），既保留Galera同步复制的无数据丢失优势，又无需额外物理服务器。
  • 方案核心优势
    • 轻量无负担：garbd仅为一个进程，CPU/内存消耗可忽略，可直接部署在任意一台数据节点上；
    • 同步复制保障：基于Galera原生同步复制，无传统主主异步复制的数据丢失风险；
    • 高可用达标：单数据节点故障时，剩余1台数据节点+1个garbd满足Quorum=2，集群正常读写；
    • 配置简单：仅需在原有两台Galera节点基础上修改少量配置，无需重构集群。

• 部署步骤

  • 前提：已完成两台节点的Galera基础部署（参考前文环境准备、MariaDB安装步骤），此处仅补充garbd相关配置。

  • 环境规划（示例）

    节点类型	主机名	IP地址	核心角色
    数据节点1	galera-1	10.4.50.163	存储数据、提供服务，同时部署garbd
    数据节点2	galera-2	10.4.50.164	存储数据、提供服务
    仲裁节点	-	10.4.50.163:4567	仅运行garbd进程，参与投票（部署在数据节点1上）

2.2、gardb编译

• 编译前环境准备（必装依赖）

  # 1. 安装基础编译工具链
  yum install -y gcc gcc-c++ cmake make automake autoconf libtool
  
  # 2. 安装核心依赖库（galera-arbitrator-4必需）
  yum install -y boost-devel openssl-devel libatomic_ops-devel
  
  # 3. 安装可选依赖（提升兼容性）
  yum install -y numactl-devel check-devel

• 下载 galera-arbitrator-4 源码

  mkdir /opt/soft && cd /opt/soft
  wget https://archive.mariadb.org//mariadb-10.6.24/galera-26.4.24/src/galera-26.4.24.tar.gz
  tar xf galera-26.4.24.tar.gz
  cd galera-26.4.24
  
  # 1. 创建编译目录（推荐out-of-source编译，避免污染源码）
  mkdir build && cd build
  
  # 2. CMake配置（指定仅编译garbd，设置安装路径）
  cmake \
    -DCMAKE_INSTALL_PREFIX=/usr/local/galera-4 \
    -DWITH_GARBD=ON \          # 仅编译garbd，不编译完整Galera库
    -DWITH_MARIADB=ON \        # 开启MariaDB兼容模式
    -DCMAKE_BUILD_TYPE=Release \
    -DCMAKE_CXX_FLAGS="-DMARIADB_106_COMPAT=1" \  # 显式指定适配10.6
    ..
  
  # 3. 开始编译（-j后接CPU核心数，加速编译，如-j4）
  make -j$(nproc)
  
  # 4. 安装编译好的garbd（安装到指定路径）
  make install

• 数据节点配置

  ############ 集群配置 开始
  # 163改成1, 165改成2
  server-id=1
  # 过期时间最好长一点， 第2台节点，7天过期如果二进制文件无了在启动就无法同步了
  expire_logs_days=7
  log-bin=mysql-bin
  # 强制要求binlog_format（二进制日志格式）必须设置为ROW（行级格式）
  binlog_format=row
  # 禁用语句级复制相关优化，适配ROW格式
  log_slave_updates=ON
  # 关闭二进制日志校验（Galera已做相关校验，避免冲突）
  binlog_checksum=NONE
  
  # 存储引擎（必须InnoDB）
  default-storage-engine=InnoDB
  
  # Galera核心配置
  wsrep_on=ON
  wsrep_provider=/opt/mysqlso/libgalera_smm.so
  # 随便敲,具有唯一性就行
  wsrep_cluster_name="ESCSASSEEQ1"
  wsrep_cluster_address="gcomm://10.4.50.163,10.4.50.165,10.4.50.163:4569"
  # 节点名称， 两台名称必须不一样
  wsrep_node_name="galera-node-1"
  # 节点IP， 这里改一下地址
  wsrep_node_address="10.4.50.163"
  # 同步方式
  wsrep_sst_method=rsync
  # 这里地址也改一下
  wsrep_provider_options="gcache.size=1G;ist.recv_addr=10.4.50.163:4568;gmcast.listen_addr=tcp://0.0.0.0:4567"

• 启动163数据主节点

  # 第一次种子节点，必须要手动初始化
  /opt/maraidb/bin/mysqld \
  --defaults-file=/opt/maraidb/my.cnf \
  --user=mysql \
  --wsrep-new-cluster &
  
  # 查看状态
  /opt/mysql/bin/mysql -uroot -p密码 -e "
    show variables like 'wsrep_cluster_name';  # 集群组名
    show variables like 'wsrep_cluster_address';  # 集群地址
    show status like 'wsrep_ready';  # 集群是否就绪（需为ON）
    show status like 'wsrep_cluster_size';  # 集群有多少台
    show status like 'wsrep_cluster_status';  # 集群状态
  "

• 启动gardb

  • 配置文件

    cat > /opt/EETRUST/common/mysqlso/garb.cnf << EOF
    # Galera Arbitrator (garbd) 配置文件
    # 核心集群配置
    address="gcomm://10.4.50.163,10.4.50.165"
    # wsrep_cluster_name="ESCSASSEEQ1" 必须跟这个保持一致
    group="ESCSASSEEQ1"    
    
    # 仲裁节点专属配置
    options="gcs.fc_limit=9999999;gcs.stateless=yes;gmcast.listen_addr=tcp://0.0.0.0:4569"
    
    # 日志配置（可选，便于排查）
    log="/opt/mysqlso/garbd.log"
    
    # 守护进程模式（后台运行）
    daemon=1
    
    # 工作目录（可选）
    workdir="/opt/mysqlso"
    EOF

  • 启动

    cat > /usr/lib/systemd/system/garb.service << EOF
    [Unit]
    Description=Galera Arbitrator Daemon
    After=network.target mariadb.service
    Requires=network.target
    
    [Service]
    Type=simple
    ExecStart=/opt/mysqlso/garbd -c /opt/mysqlso/garb.cnf
    ExecReload=/bin/kill -HUP \$MAINPID
    Restart=on-failure
    RestartSec=5
    KillMode=process
    TimeoutSec=30
    
    [Install]
    WantedBy=multi-user.target
    EOF

  • 启动服务并查看状态

    # 注意 这里操作前先启动 165， 修改配置，不需要初始化，它会自动加入
    # 加入之后  wsrep_cluster_size  = 2
    
    # 启动garbd并设置开机自启
    systemctl daemon-reload
    systemctl start garb
    systemctl enable garb
    
    # 检查garbd状态（确保Active: active (running)）
    systemctl status garb
    ss -tnlp|grep 4569
    
    # 加入之后，再查看状态
    /opt/mysql/bin/mysql -uroot -p密码 -e "show status like  wsrep_cluster_size';"
    +--------------------+-------+
    | Variable_name      | Value |
    +--------------------+-------+
    | wsrep_cluster_size | 3     |
    +--------------------+-------+

2.3、总结

• garbd故障影响与应对

  • 结合仲裁机制，garbd故障的影响可分为两种场景，核心结论：仅garbd进程故障无影响，garbd+数据节点同时宕机才会导致只读，且可快速应急恢复：
  • garbd是无状态进程，重启后会自动重新加入集群，不影响数据同步；且其投票权重默认低于数据节点，集群仲裁优先级始终以数据节点为主，进一步降低故障影响。

• 分场景影响与处理

  故障场景	集群状态（基于仲裁机制）
  仅garbd进程崩溃（节点1的garbd挂了）	2台数据节点均在线，Quorum=2（满足(2/2)+1=2），集群正常读写
  garbd所在数据节点1整机宕机	仅剩1台数据节点，Quorum不足（需2），集群进入只读

• 总结

  1. 两台节点的核心痛点源于Galera仲裁机制：Quorum=2要求必须全部在线，导致单节点故障即不可用；
  2. garbd方案的本质是"补票"：通过轻量仲裁节点让集群逻辑上变为3节点，使Quorum降为2，既满足仲裁要求，又无需额外物理服务器；
  3. 优势与适用场景：保留Galera同步复制的无数据丢失优势，部署简单、资源消耗低，是两台服务器实现Galera高可用的最优解，适合生产环境使用。