いよいよ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

プロセスID1656をコピーしておきます。

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の略称)。

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

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