vttablet健康检查每5秒上报mysql连接、复制延迟、事务活跃度等状态，供vtgate路由和failover决策；failover分手动与自动（需显式启用），触发前须满足连续3次健康检查失败等条件，并校验候选主库复制完整性、binlog一致性及元数据正确性。
VTTablet 的健康检查（healthcheck）和故障转移（failover）是 Vitess 高可用架构的核心机制。健康检查用于持续评估 Tablet 实例是否可服务，而 failover 则在检测到不可恢复故障时，由 VTGate 或 VTCTLD 协调执行主从切换。二者联动紧密，但触发条件和行为逻辑有明确区分。
healthcheck 的核心指标与上报机制
每个 VTTablet 会周期性（默认每 5 秒）向本地或指定的 HealthCheck 模块（通常由 VTGate 或独立的 HealthCheck service 维护）上报自身状态。关键指标包括：
-
MySQL 连接可用性：能否成功连接本地 MySQL 实例（如执行
SELECT 1） -
复制状态：对从库（REPLICA/RO）检查
Seconds_Behind_Master是否超阈值（默认 30 秒），主库（MASTER）则忽略此项 -
事务活跃度：检查最近是否有写入或提交（如通过
SHOW MASTER STATUS的File/Position变化） -
服务状态字段：
TabletType（如 MASTER、REPLICA）、PrimaryTermStartTime（主库任期时间戳）等元数据是否合理
这些信息被聚合后，供 VTGate 路由决策（如避开延迟过高的从库），也作为 failover 的输入依据。
failover 的两类触发方式及条件
Vitess 支持手动和自动两种 failover，但自动 failover 默认关闭，需显式配置启用。触发前提均为健康检查持续判定实例异常：
- 主库（MASTER）失联：连续多次（默认 3 次，间隔 5 秒）healthcheck 报告主库不可达（连接失败 + 无响应），且无其他正常 MASTER 存在时，自动 failover 才可能启动
-
主库复制停滞或脑裂风险：主库虽能连通，但复制 IO/SQL 线程停止、或
Seconds_Behind_Master持续为 NULL / 异常值，结合PrimaryTermStartTime陈旧，可能被判定为“不可靠主库” -
人工干预优先：即使满足自动条件，Vitess 仍要求 operator 显式执行
vtctlclient PlannedReparentShard或EmergencyReparentShard；自动流程仅在开启--enable-auto-failover且配置了replication_health_check_interval和failure_detection_period后才尝试协调选举新主
关键配置参数影响判断边界
以下参数直接决定 healthcheck 敏感度与 failover 决策窗口：
-
--health-check-interval（VTTablet 启动参数）：控制上报频率，默认 5s；值越大，故障发现越慢 -
--failure-detection-period（VTCTLD 或 HealthCheck service）：定义“连续失败多少次才算宕机”，默认 3×interval -
--max-replication-lag（shard 级配置）：从库延迟上限，超此值 healthcheck 标记为 unhealthy，影响读路由，也可能触发 re-parent 前置检查 -
--enable-auto-failover（VTCTLD 启动参数）：必须设为 true 才允许系统自动发起 failover 流程
failover 实际执行的关键约束
即使触发条件满足，Vitess 仍会校验多项安全前提才执行切换：
- 候选新主库（通常是延迟最小的 REPLICA）必须通过
mysqlctl ping和SHOW SLAVE STATUS验证复制链完整 - 原主库若短暂恢复，但已丢失部分 binlog（如 crash 后重启未启用
sync_binlog=1），Vitess 会拒绝 failover 并报错binlog position mismatch - 所有参与节点的
tablet_alias和keyspace/shard元数据必须一致，否则 VTCTLD 拒绝操作 - failover 过程中，VTGate 会短暂拦截写请求（
QueryNotServed错误），直到新主注册完成并广播更新
