TiDB 検証ライフ(4-自動フェイルオーバーの確認)

# いよいよTiDBクラスタのフェイルオーバー検証です

## まず、TiDBが提供するフェイルオーバー機能を理解

全てのコンポーネントがフェイルオーバー機能を持っているとのことです。

- PDクラスタ
- TiDBクラスタ
- TiKVクラスタ
- TiFlashクラスタ

フェイルオーバーの待機タイムアウト時間をコンポーネント別設定可能で、デフォルト値は5分になっていました。

``` charts/tidb-operator/values.yaml
controllerManager:
 ...
 # autoFailover is whether tidb-operator should auto failover when failure occurs
 autoFailover: true
 # pd failover period default(5m)
 pdFailoverPeriod: 5m
 # tikv failover period default(5m)
 tikvFailoverPeriod: 5m
 # tidb failover period default(5m)
 tidbFailoverPeriod: 5m
 # tiflash failover period default(5m)
 tiflashFailoverPeriod: 5m
```

※ 引用元: PingCAP社のマニュアル
https://docs.pingcap.com/tidb-in-kubernetes/stable/use-auto-failover

## TiDBサーバのプロセスを強制終了し、どうなるか検証してみました

TiDBサーバが異常終了し、外部からのリクエストを受け付けなくなった際、自動復旧してくれるかを確認してみたかったです。

プロセスだけでなく、Podやノードが異常終了した際も、フェイルオーバーできるとのことですが、それは今後やってみようと思います。

### Pod一覧とステータスを確認します

パラメータに、TiDBクラスタのデプロイ時に作成した名前空間を指定する必要があります(ここではtidb-cluster)。

```
$ kubectl get pods -o wide -n tidb-cluster
NAME                              READY   STATUS    RESTARTS   AGE   IP            NODE                 NOMINATED NODE   READINESS GATES
basic-discovery-f699b74cd-4s8c2   1/1     Running   1          42h   10.244.0.7    kind-control-plane   <none>           <none>
basic-monitor-0                   3/3     Running   3          42h   10.244.0.10   kind-control-plane   <none>           <none>
basic-pd-0                        1/1     Running   1          42h   10.244.0.9    kind-control-plane   <none>           <none>
basic-tidb-0                      2/2     Running   2          42h   10.244.0.3    kind-control-plane   <none>           <none>
basic-tikv-0                      1/1     Running   1          42h   10.244.0.5    kind-control-plane   <none>           <none>
```

### Dockerコンテナ一覧とステータスを確認します

```
$ docker ps
CONTAINER ID   IMAGE                  COMMAND                  CREATED        STATUS          PORTS                       NAMES
17818ffab074   kindest/node:v1.21.1   "/usr/local/bin/entr…"   43 hours ago   Up 16 minutes   127.0.0.1:50444->6443/tcp   kind-control-plane
```

`CONTAINER ID`の値をコピーしておきます。

### Dockerコンテナにログインします

上述の`CONTAINER ID`の値を指定します。

```
$ docker exec -it 17818ffab074 /bin/sh
```

### tidb-serverプロセスを確認します

```
# ps -ef | grep tidb-server | grep -v grep
root        1656     625  4 Dec05 ?        00:00:40 /tidb-server --store=tikv --advertise-address=basic-tidb-0.basic-tidb-peer.tidb-cluster.svc --host=0.0.0.0 --path=basic-pd:2379 --config=/etc/tidb/tidb.toml --log-slow-query=/var/log/tidb/slowlog
```

プロセスID`1656`をコピーしておきます。

### tidb-serverプロセスを強制終了します

```
# kill -9 1656
```

### しばらく経ったら、再度tidb-serverプロセスを確認します

```
# ps -ef | grep tidb-server | grep -v grep
root       13557     625 10 00:00 ?        00:00:01 /tidb-server --store=tikv --advertise-address=basic-tidb-0.basic-tidb-peer.tidb-cluster.svc --host=0.0.0.0 --path=basic-pd:2379 --config=/etc/tidb/tidb.toml --log-slow-query=/var/log/tidb/slowlog
```

tidb-serverプロセスが復旧されました、プロセスIDも変更されています。やったー。
1分未満で復旧できたので、冒頭でご案内したフェイルオーバー設定ファイルではなく、別設定ファイルまたは固定値になっているかもしれません(宿題とさせてください)。

## 終わりに

簡単な検証でしたが、自分のショボい環境でもTiDBの高可用性が享受できそうです。
今後もTiDBの特徴をいろいろ検証してみようと思います。

## 余談

SlackにTiDB Communityがありましたので、ask-tugチャンネルに質問してみました(TUGはTiDB User Groupの略称)。

https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap

TiDB Operatorなしで自動フェイルオーバーを設定可能かの質問については、Noと回答頂きました。
さらに、TiDBをKubernetesではなく、オンプレミスにデプロイした場合も、自動フェイルオーバー可能かを聞いています(回答待ち)。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/61975/62e22b34-8edf-b8bc-2457-b1a5b72ca289.png)