敏捷模式两节点仲裁模式使用场景

本文介绍敏捷模式两节点部署中三种仲裁模式的适用场景与选择建议。两节点的具体拓扑模版和关键参数，请参考敏捷模式两节点部署拓扑。两节点的运行机制、状态切换和运维限制，请参考敏捷模式支持两节点部署。

仲裁方案选择建议

两节点敏捷模式下，仲裁方案的选择，建议重点从三个维度判断：是否能部署独立仲裁节点、是否需要固定主侧自动接管、是否有现存的高可用体系。

1. 如果可以增加一台独立仲裁节点，并且希望自动接管决策由独立组件统一裁决，建议优先选择 service。这类方案更适合标准化生产部署，也更便于后续统一治理、审计和扩展。对于多套两节点集群，同一个 Tiarbiter/TEM 可以共享使用，为多套集群提供仲裁，因此不要求每套集群都额外部署一台独立仲裁节点。
2. 如果无法增加第三台机器，但业务上可以明确主备关系，并接受固定主侧优先自动接管，建议选择 preset。它部署最简单，适合资源受限场景，但需要提前明确其自动接管边界。
3. 如果客户已经有成熟的 keepalived、VIP 漂移、fencing、云平台编排或其他 HA 流程，并且要求数据库接管逻辑接入现有体系，可考虑 custom-script。这类方案灵活度更高，但对脚本设计的要求也更高。

按场景推荐

preset（预设主从模式）的使用场景

preset 通过固定 primary-label 指定主侧。只有主侧在故障发生时可以自动接管；如果主侧自身故障，从侧不会自动接管，需要人工介入。

适合的场景

• 无法增加第三台机器，也不计划引入外部仲裁系统。
• 业务上已经明确主备关系，并接受主侧优先接管。
• 更看重部署简单、落地快、运维链路短。

不适合的场景

• 希望任意一侧故障后，另一侧都能自动接管。
• 需要将自动接管决策交给独立第三方统一裁决。

service（仲裁服务模式）的使用场景

service 通过外部仲裁服务完成自动接管，可以将接管决策从数据库节点中抽离出来。

适合的场景

• 可以引入独立仲裁服务。
• 希望自动接管决策由独立组件统一裁决。
• 生产环境需要更稳定、可标准化复制的部署方式。
• 存在多套两节点集群，希望由同一个 Tiarbiter/TEM 统一提供仲裁能力。

不适合的场景

• 部署资源受限，无法增加独立仲裁节点。

i

注意

even-replicas.arbitration.endpoints 当前仅支持配置一个仲裁服务地址。

service 模式中的 Tiarbiter/TEM 可以作为共享仲裁组件，为多套两节点 even-replicas 集群提供仲裁服务，不需要每套集群都单独新增一台仲裁机。

custom-script 的使用场景

custom-script 通过本地脚本决定当前侧是否允许自动接管，适合接入已有的运维控制面或高可用编排逻辑。

适合的场景

• 已有 keepalived、VIP 漂移、fencing、共享锁或云平台主备编排机制。
• 希望仲裁条件来自数据库之外的外部事实，例如 VIP 所在侧、云平台角色标签、存储锁所有者或 fencing 结果。
• 团队可以自行维护脚本，并承担后续测试、审计和变更管理。

不适合的场景

• 团队缺少脚本维护能力，或无法保障脚本长期可用。
• 不具备成熟的 keepalived、VIP 漂移、fencing、云平台编排或其他 HA 流程。

脚本仲裁示例：基于 Keepalived VIP

如果当前环境已经通过 keepalived 管理业务 VIP，可以将“当前节点是否持有 VIP”作为脚本仲裁的依据。只有持有 VIP 的一侧才允许自动接管。

下面给出一个根据 VIP 判断当前节点是否为 MASTER 的示例脚本。可将以下脚本保存为 /opt/tidb/bin/keepalived_arbiter.sh，并确保 tidb 用户具备执行权限：

#!/bin/bash

# Check if current node is Keepalived Master
# Usage: ./keepalived_arbiter.sh <VIP>

VIP=$1
echo "CLUSTER_ID=$CLUSTER_ID,LABEL=$LABEL,ACTION=$ACTION,VIP=$VIP"

if [ "$ACTION" == "RESET" ]; then
    exit 0
fi

# Check if VIP argument is provided
if [ -z "$VIP" ]; then
    echo "Error: Virtual IP (VIP) argument is required"
    exit 2
fi

# Function to check VIP using ip command
check_with_ip() {
    if command -v ip &> /dev/null; then
        if ip addr | grep -q "$VIP"; then
            return 0
        fi
    fi
    return 1
}

# Function to check VIP using ifconfig command
check_with_ifconfig() {
    if command -v ifconfig &> /dev/null; then
        if ifconfig | grep -q "$VIP"; then
            return 0
        fi
    fi
    return 1
}

if check_with_ip || check_with_ifconfig; then
    echo "Status: MASTER"
    exit 0
fi

echo "Status: BACKUP"
exit 1

该示例的判定逻辑如下：

• 当 ACTION=CONFIRM 时，脚本检查当前节点是否持有指定 VIP。
• 如果当前节点持有 VIP，则返回 0，允许当前侧自动接管。
• 如果当前节点未持有 VIP，则返回非 0，拒绝自动接管。
• 当 ACTION=RESET 时，脚本直接返回成功，用于清理阶段。

对应的 TiUP 拓扑配置示例如下：

server_configs:
  pd:
    replication.enable-placement-rules: true
    replication.max-replicas: 2
    replication.location-labels: ["dc"]
    replication.isolation-level: "dc"

    replication-mode:
      replication-mode: "even-replicas"
      even-replicas.downgrade-timeout: 15s
      even-replicas.arbitration.type: "custom-script"
      even-replicas.arbitration.script:
        ["/bin/bash", "/opt/tidb/bin/keepalived_arbiter.sh", "192.168.1.100"]

  tikv:
    raftstore.hibernate-regions: false

使用该方案时，需要确认以下几点：

• 两台 PD 节点都部署同一份脚本，且路径一致。
• keepalived 或其他 HA 组件能够保证同一时刻只有一侧持有 VIP。

相关说明

• 如果已经确定仲裁模式，并准备编写部署配置，请参考敏捷模式两节点部署拓扑。
• 如果需要了解两节点模式的状态切换、强制降级和在线修改限制，请参考敏捷模式支持两节点部署。