ディスク障害時にTiDBがリカバリをやってくれるか確かめてみます
障害には、さまざまなケースや影響範囲が考えられますので、まずは検証シナリオを決めようと思います。
どのデータを、どのタイミングで、どのような方法で、壊すのか。
また、どのような障害対策を期待できるか、などなど。
そもそもTiDBは物理データをどこに保存しているか
SST(Sorted String Table)ファイルにデータ保存するとマニュアルにありました。
メモリのデータがある程度溜まったら、RocksDBがSSTにフラッシュしてくれるようです。
SSTファイルはレベル分けされるようで、あるレベルのSSTファイルのサイズが大きくなったら、複数SSTをマージし、レベルアップするようです。
おさらいとして、TiKVのアーキテクチャ
※ 引用: https://docs.pingcap.com/tidb/stable/rocksdb-overview
とりあえず、INSERT文実行しSSTファイルに書き込まれるか確認してみます
端末Aから、tikv-serverのwriteシステムコールを追ってみます
Dockerコンテナにログイン
(base) appurunoMacBook-Air:~ apple$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
364aef630ecd kindest/node:v1.21.1 "/usr/local/bin/entr…" 12 hours ago Up 29 minutes 127.0.0.1:50709->6443/tcp kind-control-plane
(base) appurunoMacBook-Air:~ apple$ docker exec -it 364aef630ecd /bin/bash
root@kind-control-plane:/#
straceコマンドなど存在しなかったらインストール
root@kind-control-plane:/# apt-get update
root@kind-control-plane:/# apt-get install strace
root@kind-control-plane:/# apt-get install lsof
root@kind-control-plane:/# apt-get install vim
tikv-serverプロセスのプロセスIDを確認
root@kind-control-plane:/# ps -ef | grep tikv-server | grep -v grep
root 1892 1197 3 Dec10 ? 00:01:28 /tikv-server --pd=http://basic-pd:2379 --advertise-addr=basic-tikv-0.basic-tikv-peer.tidb-cluster.svc:20160 --addr=0.0.0.0:20160 --status-addr=0.0.0.0:20180 --advertise-status-addr=basic-tikv-0.basic-tikv-peer.tidb-cluster.svc:20180 --data-dir=/var/lib/tikv --capacity=0 --config=/etc/tikv/tikv.toml
tikv-serverプロセスのwriteシステムコールを追跡
straceコマンドの引数に上述のプロセスIDを指定し実行します。
root@kind-control-plane:/# strace -Tfe trace=write -p 1892
別端末Bから、TiDBへ接続しINSERTを実行します
tidb-cluster名前空間のサービスリストを確認
(base) appurunoMacBook-Air:~ apple$ kubectl get svc -n tidb-cluster
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
basic-discovery ClusterIP 10.96.96.27 <none> 10261/TCP,10262/TCP 9h
basic-grafana ClusterIP 10.96.182.77 <none> 3000/TCP 9h
basic-monitor-reloader ClusterIP 10.96.215.171 <none> 9089/TCP 9h
basic-pd ClusterIP 10.96.188.54 <none> 2379/TCP 9h
basic-pd-peer ClusterIP None <none> 2380/TCP 9h
basic-prometheus ClusterIP 10.96.146.74 <none> 9090/TCP 9h
basic-tidb ClusterIP 10.96.12.186 <none> 4000/TCP,10080/TCP 9h
basic-tidb-peer ClusterIP None <none> 10080/TCP 9h
basic-tikv-peer ClusterIP None <none> 20160/TCP 9h
basic-tidbサービスはポート番号4000で待ち受けているようです。
ポート4000をフォーワード
(base) appurunoMacBook-Air:~ apple$ kubectl port-forward -n tidb-cluster svc/basic-tidb 4000 > pf4000.out &
[1] 969
mysqlコマンドでTiDBサーバに接続し、INSERTを実行します。
(base) appurunoMacBook-Air:~ apple$ mysql -h 127.0.0.1 -P 4000 -u root
mysql> use test;
mysql> create table test(id int);
mysql> insert into test values(1);
端末Aから、straceの出力を確認し、書き込み先ファイルを特定
strace出力で、writeシステムコールの抜粋
... ...
[pid 3059] write(28, "\tj\232w\242\0\0013\r\0\0\0\0\0\0\2\0\0\0\1\23\1\2\0\0\0\0\0\0\3\352\1"..., 169) = 169 <0.000892>
[pid 3061] write(40, "-\243\315.e\0\1\216\33\0\0\0\0\0\0\2\0\0\0\5\2$zt\200\0\0\0\0\0\0\377"..., 108) = 108 <0.011160>
... ...
どうやら、プロセスID3059,3061から、ファイルディスクリプター28、40に対し書き込みが行われたようです。
write先ファイルを特定
lsofコマンで、tikv-serverプロセスが開いている、ファイルディスクリプター28、40が何者か確認します。
root@kind-control-plane:/# lsof -p 1892 | grep -w 28w
tikv-serv 1892 root 28w REG 254,1 241309 3018866 /var/lib/tikv/raft/000006.log
root@kind-control-plane:/# lsof -p 1892 | grep -w 40w
tikv-serv 1892 root 40w REG 254,1 159865 3018951 /var/lib/tikv/db/000017.log
/var/lib/tikv/raft/000006.logはRaftログで、
/var/lib/tikv/db/000017.logはRocksDBログかなー。
単純にINSERT一発実行しただけでは、データがSSTに書き込まれないようです
処理されるデータ量が少ないため、メモリ上である程度データ溜まってから、SSTファイルにフラッシュされると推測されます。
SSTファイルにすぐデータを書き込みたいが、何か方法はないか
PingCAP社の資料からは見当たらないため、手っ取り早くSlackのask-tugチャンネルで聞いています。
終わりに
結局、ディスク障害検証は次回に持ち越しとなりそうです。
やはり、ストレージのメカニズムをきちんと理解してから、着手した方がよいかもです。。。