Kubernetes 上的 TiDB 集群故障自动转移

故障自动转移是指在 TiDB 集群的某些节点出现故障时，TiDB Operator 会自动添加一个节点，保证 TiDB 集群的高可用，类似于 K8s 的 Deployment 行为。

由于 TiDB Operator 基于 StatefulSet 来管理 Pod，但 StatefulSet 在某些 Pod 发生故障时不会自动创建新节点来替换旧节点，所以，TiDB Operator 扩展了 StatefulSet 的这种行为，添加了 Auto Failover 功能。

Auto Failover 功能在 TiDB Operator 中默认开启。部署 TiDB Operator 时，可通过设置 charts/tidb-operator/values.yaml 文件的 controllerManager.autoFailover 为 false 关闭该功能：

  1. controllerManager:
  2.  serviceAccount: tidb-controller-manager
  3.  logLevel: 2
  4.  replicas: 1
  5.  resources:
  6.    limits:
  7.      cpu: 250m
  8.      memory: 150Mi
  9.    requests:
  10.      cpu: 80m
  11.      memory: 50Mi
  12.  # autoFailover is whether tidb-operator should auto failover when failure occurs
  13.  autoFailover: true
  14.  # pd failover period default(5m)
  15.  pdFailoverPeriod: 5m
  16.  # tikv failover period default(5m)
  17.  tikvFailoverPeriod: 5m
  18.  # tidb failover period default(5m)
  19.  tidbFailoverPeriod: 5m
  20.  # tiflash failover period default(5m)
  21.  tiflashFailoverPeriod: 5m

pdFailoverPeriod、tikvFailoverPeriod、tiflashFailoverPeriod 和 tidbFailoverPeriod 默认均为 5 分钟，它们的含义是在确认实例故障后的等待超时时间，超过这个时间后，TiDB Operator 就开始做自动的故障转移。

实现原理

TiDB 集群有 PD、TiKV 和 TiDB 三个组件，它们的故障转移策略有所不同，本节将详细介绍这三种策略。

PD 故障转移策略

假设 PD 集群有 3 个节点，如果一个 PD 节点挂掉超过 5 分钟（pdFailoverPeriod 可配置），TiDB Operator 首先会将这个 PD 节点下线，然后再添加一个新的 PD 节点。此时会有 4 个 Pod 同时存在，待挂掉的 PD 节点恢复后，TiDB Operator 会将新启动的节点删除掉，恢复成原来的 3 个节点。

TiKV 故障转移策略

当一个 TiKV 节点无法正常工作后，该节点的状态会变为 Disconnected，30 分钟（通过 pd.config 文件中 [schedule] 部分的 max-store-down-time = "30m" 来配置）后会变成 Down 状态，TiDB Operator 会在此基础上再等待 5 分钟（tikvFailoverPeriod 可配置），如果该 TiKV 节点仍不能恢复，就会新起一个 TiKV 节点。待挂掉的 TiKV 节点恢复后，TiDB Operator 不会自动删除新起的节点，用户需要手动减少 TiKV 节点，恢复成原来的节点数。操作方法是将该 TiKV 节点从 TidbCluster 对象的 status.tikv.failureStores 字段中删除：

  1. kubectl edit tc -n ${namespace} ${cluster_name}
  1. ...
  2. status
  3.   tikv:
  4.     failureStores:
  5.       "1":
  6.         podName: cluster1-tikv-0
  7.         storeID: "1"
  8.       "2":
  9.         podName: cluster1-tikv-1
  10.         storeID: "2"
  11. ...

cluster1-tikv-0 节点恢复后，将其删除后变为：

  1. ...
  2. status
  3.   tikv:
  4.     failureStores:
  5.       "2":
  6.         podName: cluster1-tikv-1
  7.         storeID: "2"
  8. ...

TiDB 故障转移策略

假设 TiDB 集群有 3 个节点，TiDB 的故障转移策略跟 Kubernetes 中的 Deployment 的是一致的。如果一个 TiDB 节点挂掉超过 5 分钟（tidbFailoverPeriod 可配置），TiDB Operator 会添加一个新的 TiDB 节点。此时会有 4 个 Pod 同时存在，待挂掉的 TiDB 节点恢复后，TiDB Operator 会将新启动的节点删除掉，恢复成原来的 3 个节点。

TiFlash 故障转移策略

当一个 TiFlash 节点无法正常工作后，该节点的状态会变为 Disconnected，30 分钟（通过 pd.config 文件中 [schedule] 部分的 max-store-down-time = "30m" 来配置）后会变成 Down 状态，TiDB Operator 会在此基础上再等待 5 分钟（tiflashFailoverPeriod 可配置），如果该 TiFlash 节点仍不能恢复，就会新起一个 TiFlash 节点。待挂掉的 TiFlash 节点恢复后，TiDB Operator 不会自动删除新起的节点，用户需要手动减少 TiFlash 节点，恢复成原来的节点数。操作方法是将该 TiFlash 节点从 TidbCluster 对象的 status.tiflash.failureStores 字段中删除。

示例如下，假如有两个 TiFlash Pod 异常：

  1. kubectl edit tc -n ${namespace} ${cluster_name}
  1. status
  2.   tiflash:
  3.     failureStores:
  4.       "1":
  5.         podName: cluster1-tiflash-0
  6.         storeID: "1"
  7.       "2":
  8.         podName: cluster1-tiflash-1
  9.         storeID: "2"

cluster1-tiflash-0 Pod 恢复后，将其删除后变为：

  1. status
  2.   tiflash:
  3.     failureStores:
  4.       "2":
  5.         podName: cluster1-tiflash-1
  6.         storeID: "2"