# アベイラビリティゾーン障害時ダウンタイムなし ## 概要 この演習では、TiDBクラスタは3つのアベイラビリティゾーンにまたがってデプロイされており、それぞれがサブネットに対応しています。 サブネット1のネットワークブラックアウトをシミュレートします。これにより、1つのTiDBサーバ、1つのTiKVサーバ、および1つのPDサーバがクラスタから切断されます。 インフラストラクチャの障害は、サーバ側のフェイルオーバーを必要としません。データベースクライアントは自動的に残りのTiDBサーバインスタンスに接続します。 ![80%](https://lab-static.pingcap.com/quick-demo/demo_001_en.png) ### 所要時間 + この演習は約 60 分程度かかります。 ### タスク + TiDBクラスタのステータスとトポロジーを確認します。 + ネットワーク通信を特定のアベイラビリティゾーン全体でブロックします。 + 特定のアベイラビリティゾーンがアクセスできない状況にあっても、TiDBクラスタが機能を維持できることを観察し確認します。 > [!TIP] > 演習環境を起動するには、**開始**をクリックしてください。 > 環境の準備が整ったら、下部のツールバーで **次のモジュール** を選択して **モジュール 1** に進みます。 > そして、ステップバイステップの演習ガイドに従って、ハンズオン環境に接続し、タスクを開始してください。 ## モジュール 1: 3つのアベイラビリティゾーンに TiDB クラスタをデプロイする ### 手順 1. ノード ${LAB:HOST_MONITOR1_PUBLIC_IP} に SSH ログインします。 + 以下のリンクをクリックして、演習用仮想マシンへの3つのSSH接続を開きます： + [ターミナル 1](ssh://monitor1-ssh#1) + [ターミナル 2](ssh://monitor1-ssh#2) + [ターミナル 3](ssh://monitor1-ssh#3) + これで3つのアクティブなターミナルセッションが利用可能になります。 + ログイン後に表示されるバナーは以下のようになります。 ```output , #_ ~\_ ####_ Amazon Linux 2 ~~ \_#####\ ~~ \###| ~~ \#/ ___ ~~ V~' '-> ~~~ / A newer version of Amazon Linux is available! ~~._. _/ _/ _/ Amazon Linux 2023, GA and supported until 2028-03-15. _/m/' https://aws.amazon.com/linux/amazon-linux-2023/ ``` ### 手順 2. 複数のアベイラビリティゾーンにまたがるTiDBクラスタを起動します + [ターミナル 1](ssh://monitor1-ssh#1) で、プロビジョニングされたクラスタトポロジーのYAMLを確認します。 ```bash cat nine-nodes.yaml ``` ```output global: user: "ec2-user" ssh_port: 22 deploy_dir: "/tidb-deploy" data_dir: "/tidb-data" arch: "amd64" server_configs: pd: replication.max-replicas: 3 pd_servers: - host: 10.90.3.145 client_port: 2379 peer_port: 2380 advertise_client_addr: "http://54.203.147.80:2379" - host: 10.90.1.184 client_port: 2379 peer_port: 2380 advertise_client_addr: "http://34.221.154.223:2379" - host: 10.90.2.106 client_port: 2379 peer_port: 2380 advertise_client_addr: "http://35.86.165.210:2379" tidb_servers: - host: 10.90.1.177 port: 4000 status_port: 10080 deploy_dir: /tidb-deploy/tidb-4000 log_dir: /tidb-deploy/tidb-4000/log - host: 10.90.2.16 port: 4000 status_port: 10080 deploy_dir: /tidb-deploy/tidb-4000 log_dir: /tidb-deploy/tidb-4000/log tikv_servers: - host: 10.90.3.115 port: 20160 status_port: 20180 - host: 10.90.2.143 port: 20160 status_port: 20180 - host: 10.90.1.247 port: 20160 status_port: 20180 monitoring_servers: - host: 10.90.4.92 grafana_servers: - host: 10.90.4.92 alertmanager_servers: - host: 10.90.4.92 ``` + TiDBクラスタをデプロイするためにシステム構成を修正します。 ```bash tiup mirror set tidb-community-server-tidb_version-linux-amd64 tiup cluster check nine-nodes.yaml \ --user ec2-user \ -i /home/ec2-user/.ssh/pe-class-key-oregon.pem \ --apply ``` ```output . . . + Try to apply changes to fix failed checks - Applying changes on 10.90.3.145 ... ⠧ Sysctl: host=10.90.3.145 vm.swappiness = 0 + Try to apply changes to fix failed checks - Applying changes on 10.90.3.145 ... ⠇ Sysctl: host=10.90.3.145 vm.swappiness = 0 + Try to apply changes to fix failed checks + Try to apply changes to fix failed checks - Applying changes on 10.90.3.145 ... Done + Try to apply changes to fix failed checks - Applying changes on 10.90.3.145 ... Done + Try to apply changes to fix failed checks - Applying changes on 10.90.3.145 ... Done - Applying changes on 10.90.2.106 ... Done - Applying changes on 10.90.2.143 ... Done - Applying changes on 10.90.1.177 ... Done - Applying changes on 10.90.1.184 ... Done - Applying changes on 10.90.3.115 ... Done - Applying changes on 10.90.1.247 ... Done - Applying changes on 10.90.2.16 ... Done - Applying changes on 10.90.4.92 ... Done ``` + TiDBクラスタをデプロイします。 ```bash tiup cluster deploy tidb-demo tidb_version ./nine-nodes.yaml \ --user ec2-user \ -i /home/ec2-user/.ssh/pe-class-key-oregon.pem \ --yes ``` ```output . . . Cluster `tidb-demo` deployed successfully, you can start it with command: `tiup cluster start tidb-demo --init` ``` + デプロイされたTiDBクラスタを起動します。 ```bash tiup cluster start tidb-demo ``` ```output . . . Started cluster `tidb-demo` successfully ``` ### 手順 3. TiDB クラスタのステータスを確認します + クラスタのキーコンポーネントは、3つのサブネット: 10.90.1.0/24, 10.90.2.0/24, 10.90.3.0/24にそれぞれ分散されています。 + クラスタには3台のPDサーバ、3台のTiKVサーバ、および2台のTiDBサーバが含まれています。 + サブネット10.90.1.0/24には、PDサーバ、TiDBサーバ、およびTiKVサーバがホストされていることを特に確認してください。 + あなたの環境のIPアドレスやサンプル出力は異なるかもしれませんが、サブネット構成は一貫しています。 ```bash tiup cluster display tidb-demo ``` ```output Cluster type: tidb Cluster name: tidb-demo Cluster version: vtidb_version Deploy user: ec2-user SSH type: builtin Dashboard URL: http://35.86.135.34:2379/dashboard Grafana URL: http://10.90.4.7:3000 ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.90.4.7:9093 alertmanager 10.90.4.7 9093/9094 linux/x86_64 Up /tidb-data/alertmanager-9093 /tidb-deploy/alertmanager-9093 10.90.4.7:3000 grafana 10.90.4.7 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000 10.90.1.110:2379 pd 10.90.1.110 2379/2380 linux/x86_64 Up /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.2.63:2379 pd 10.90.2.63 2379/2380 linux/x86_64 Up /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.3.162:2379 pd 10.90.3.162 2379/2380 linux/x86_64 Up|L /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.4.7:9090 prometheus 10.90.4.7 9090/12020 linux/x86_64 Up /tidb-data/prometheus-9090 /tidb-deploy/prometheus-9090 10.90.1.116:4000 tidb 10.90.1.116 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.2.15:4000 tidb 10.90.2.15 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.1.35:20160 tikv 10.90.1.35 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.2.138:20160 tikv 10.90.2.138 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.3.220:20160 tikv 10.90.3.220 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 Total nodes: 11 ``` ## モジュール 2: 読み取りおよび書き込みワークロードを開始する ### 手順 1. テスト用のテーブルを作成する + [ターミナル 2](ssh://monitor1-ssh#2)で、TiDBサーバインスタンスの1つに接続し、テストテーブルを作成し、ターミナルを終了します。 ```bash mysql -h ${HOST_DB1_PRIVATE_IP} -P 4000 -uroot ``` ```sql DROP TABLE IF EXISTS test.dummy; CREATE TABLE test.dummy (id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(80), event JSON); EXIT; ``` ### 手順 2. INSERT ワークロードを適用する + [ターミナル 2](ssh://monitor1-ssh#2)で、サンプルJavaプログラムを実行してINSERTワークロードを起動します。 + プログラムは、2つのワーカーを使用してINSERT操作を実行するためにTiDBサーバインスタンスに接続します。接続されたTiDBサーバが接続を失うと、プログラムは自動的に別の利用可能なTiDBサーバに切り替わります。出力はINSERTリクエストを処理しているTiDBサーバのプライベートIPアドレスを表示します。2つあるはずです。ワークロードを実行したまま、次のステップに進みます。 ```bash cd scripts javac -cp .:misc/mysql-connector-java-5.1.36-bin.jar DemoJdbcEndlessInsertDummyCSP.java java -cp .:misc/mysql-connector-java-5.1.36-bin.jar DemoJdbcEndlessInsertDummyCSP ``` ```output Worker 2 -> TiDB:Thu May 09 07:05:33 UTC 2024 at 10.90.1.116 Worker 1 -> TiDB:Thu May 09 07:05:33 UTC 2024 at 10.90.2.15 Worker 1 -> TiDB:Thu May 09 07:05:34 UTC 2024 at 10.90.1.116 Worker 2 -> TiDB:Thu May 09 07:05:34 UTC 2024 at 10.90.2.15 Worker 1 -> TiDB:Thu May 09 07:05:35 UTC 2024 at 10.90.2.15 Worker 2 -> TiDB:Thu May 09 07:05:35 UTC 2024 at 10.90.1.116 Worker 1 -> TiDB:Thu May 09 07:05:36 UTC 2024 at 10.90.1.116 ... ``` ### 手順 3. サンプル QUERY ワークロードを適用する + [ターミナル 3](ssh://monitor1-ssh#3)で、以下のスクリプトを実行します。スクリプトは2つのTiDBサーバインスタンスに接続してクエリを実行しようとします。1つのTiDBサーバが障害または応答不能になった場合、スクリプトは自動的に別の利用可能なインスタンスに切り替わります。注意すべきは、TiDBサーバインスタンスは接続要求に対して1秒だけ応答するように設定されていることです。これはステップ2のJavaプログラムと同様の設定です。出力はtest.dummyテーブルの行数が着実に増加していることを示します。ワークロードを実行したまま、次のステップに進みます。 ```bash qdb1(){ mysql -h ${HOST_DB1_PRIVATE_IP} -P 4000 -uroot --connect-timeout 1 2>/dev/null << EOF SELECT COUNT(event) FROM test.dummy; EOF } qdb2(){ mysql -h ${HOST_DB2_PRIVATE_IP} -P 4000 -uroot --connect-timeout 1 2>/dev/null << EOF SELECT COUNT(event) FROM test.dummy; EOF } query1(){ echo; date; qdb1 || qdb2 sleep 2; } query2(){ echo; date; qdb2 || qdb1 sleep 2; } while true; do query1; query2; done; ``` ```output Mon May 13 05:27:33 UTC 2024 COUNT(event) 2608 Mon May 13 05:27:35 UTC 2024 COUNT(event) 2612 Mon May 13 05:27:37 UTC 2024 COUNT(event) 2616 Mon May 13 05:27:39 UTC 2024 COUNT(event) 2620 ... ``` ### 手順 4. TiKV リージョンレプリカの設定が3に設定されていることを確認する + [ターミナル 1](ssh://monitor1-ssh#1)に戻り、TiKVリージョンレプリカの設定が3に設定されていることを確認します。これにより、データセンターまたはアベイラビリティゾーンの障害によりTiKVサーバが1つ失われても、残りの2つのTiKVサーバが通常通り運用を続けることができます。 ```bash mysql -h ${HOST_DB1_PRIVATE_IP} -P 4000 -uroot ``` ```sql SHOW CONFIG WHERE type='pd' AND name='replication.max-replicas'; EXIT ``` ```output +------+---------------------+--------------------------+-------+ | Type | Instance | Name | Value | +------+---------------------+--------------------------+-------+ | pd | 52.13.86.218:2379 | replication.max-replicas | 3 | | pd | 34.212.25.193:2379 | replication.max-replicas | 3 | | pd | 34.222.233.112:2379 | replication.max-replicas | 3 | +------+---------------------+--------------------------+-------+ 3 rows in set (0.02 sec) Bye ``` ## モジュール 3: アベイラビリティゾーン1のサブネット1を隔離する ### 手順 1. アベイラビリティゾーン1での完全な障害をシミュレートする + [ターミナル 1](ssh://monitor1-ssh#1)に戻り、スクリプトを実行してアベイラビリティゾーン1の`demo-subnet-1`（アベイラビリティゾーン1のサブネット10.90.1.0/24）をブロックすることで、アベイラビリティゾーン全体の障害をシミュレートします。 ```bash VPC_ID=`aws ec2 describe-vpcs \ --filters "Name=tag:Name,Values=user_unique_tag" \ --query "Vpcs[0].VpcId" \ --output text \ --region us-west-2` SUBNET_ID=`aws ec2 describe-subnets \ --filters "Name=vpc-id,Values=${VPC_ID}" "Name=tag:Name,Values=demo-subnet-1" \ --query "Subnets[0].SubnetId" \ --output text \ --region us-west-2` CAGE_NACL_ID=`aws ec2 describe-network-acls \ --filters "Name=vpc-id,Values=${VPC_ID}" "Name=default,Values=false" "Name=tag:Name,Values=cage" \ --query "NetworkAcls[0].NetworkAclId" \ --output text \ --region us-west-2` ASSOC_ID=`aws ec2 describe-network-acls \ --filters "Name=vpc-id,Values=${VPC_ID}" "Name=default,Values=true" \ --query "NetworkAcls[0].Associations" \ --output text \ --region us-west-2 | grep ${SUBNET_ID} | awk -F" " '{print $1}'` aws ec2 replace-network-acl-association \ --association-id ${ASSOC_ID} \ --network-acl-id ${CAGE_NACL_ID} \ --region us-west-2 ``` ```output { "NewAssociationId": "aclassoc-0402a6103febf799f" } ``` ### 手順 2. 複数のコンポーネントが切断されていることを確認する + [ターミナル 1](ssh://monitor1-ssh#1)で、クラスタのステータスを再度確認して、PD、TiDB、およびTiKVサーバを含む複数のコンポーネントがアベイラビリティゾーンの障害により切断または隔離されていることを確認します。 + サンプル出力では、影響を受けたサーバは`10.90.1.208:2379 pd`、`10.90.1.247:4000 tidb`、および`10.90.1.122:20160 tikv`です。したがって、クラスタコンポーネントの3分の1が接続を失いました。 ```bash tiup cluster display tidb-demo ``` ```output Cluster type: tidb Cluster name: tidb-demo Cluster version: vtidb_version Deploy user: ec2-user SSH type: builtin Dashboard URL: http://52.13.86.218:2379/dashboard Grafana URL: http://10.90.4.74:3000 ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.90.4.74:9093 alertmanager 10.90.4.74 9093/9094 linux/x86_64 Up /tidb-data/alertmanager-9093 /tidb-deploy/alertmanager-9093 10.90.4.74:3000 grafana 10.90.4.74 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000 10.90.1.208:2379 pd 10.90.1.208 2379/2380 linux/x86_64 Down /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.2.39:2379 pd 10.90.2.39 2379/2380 linux/x86_64 Up|L /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.3.68:2379 pd 10.90.3.68 2379/2380 linux/x86_64 Up /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.4.74:9090 prometheus 10.90.4.74 9090/12020 linux/x86_64 Up /tidb-data/prometheus-9090 /tidb-deploy/prometheus-9090 10.90.1.247:4000 tidb 10.90.1.247 4000/10080 linux/x86_64 Down - /tidb-deploy/tidb-4000 10.90.2.33:4000 tidb 10.90.2.33 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.1.122:20160 tikv 10.90.1.122 20160/20180 linux/x86_64 Disconnected /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.2.5:20160 tikv 10.90.2.5 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.3.14:20160 tikv 10.90.3.14 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 Total nodes: 11 ``` ### 手順 3. INSERT および QUERY ワークロードがまだ実行されていることを確認する + [ターミナル 2](ssh://monitor1-ssh#2)と[ターミナル 3](ssh://monitor1-ssh#3)で、サンプルのINSERT/QUERYワークロードがまだ実行されていることを確認します。INSERTおよびQUERYワークロードは、TiDBサーバインスタンス1つのみで機能していることに注意してください。 ```output Worker 1 -> TiDB:Mon May 13 05:51:52 UTC 2024 at 10.90.2.33 Worker 2 -> TiDB:Mon May 13 05:51:52 UTC 2024 at 10.90.2.33 Worker 1 -> TiDB:Mon May 13 05:51:53 UTC 2024 at 10.90.2.33 Worker 2 -> TiDB:Mon May 13 05:51:53 UTC 2024 at 10.90.2.33 Worker 1 -> TiDB:Mon May 13 05:51:54 UTC 2024 at 10.90.2.33 ... ``` ```output Mon May 13 05:51:51 UTC 2024 COUNT(event) 5481 Mon May 13 05:51:54 UTC 2024 COUNT(event) 5485 ... ``` ### 手順 4. アベイラビリティゾーン1の接続性を復元する + [ターミナル 1](ssh://monitor1-ssh#1)で、`demo-subnet-1`の接続性を復元するスクリプトを実行します。実際のシナリオでは、このステップは通常不要です。アベイラビリティゾーンの問題が迅速に解決された場合、ネットワークが復元されると、切断されたコンポーネントはクラスタに自動的に再参加します。アベイラビリティゾーンやデータセンターの問題が長引いている場合、新しいコンポーネントを残りのアベイラビリティゾーンにスケールアウトして切断されたものを退避させることで影響を軽減できます。どのようなアプローチをとっても、TiDBは中断のないビジネス運用を保証します。より高度なTiDBスキルについては、[https://tidb.io/education/](https://tidb.io/education/)をご覧ください。 ```bash VPC_ID=`aws ec2 describe-vpcs \ --filters "Name=tag:Name,Values=user_unique_tag" \ --query "Vpcs[0].VpcId" \ --output text \ --region us-west-2` SUBNET_ID=`aws ec2 describe-subnets \ --filters "Name=vpc-id,Values=${VPC_ID}" "Name=tag:Name,Values=demo-subnet-1" \ --query "Subnets[0].SubnetId" \ --output text \ --region us-west-2` DEFAULT_NACL_ID=`aws ec2 describe-network-acls \ --filters "Name=vpc-id,Values=${VPC_ID}" "Name=default,Values=true" \ --query "NetworkAcls[0].NetworkAclId" \ --output text \ --region us-west-2` ASSOC_ID=`aws ec2 describe-network-acls \ --filters "Name=vpc-id,Values=${VPC_ID}" "Name=default,Values=false" \ --query "NetworkAcls[0].Associations" \ --output text \ --region us-west-2 | grep ${SUBNET_ID} | awk -F" " '{print $1}'` aws ec2 replace-network-acl-association \ --association-id ${ASSOC_ID} \ --network-acl-id ${DEFAULT_NACL_ID} \ --region us-west-2 ``` ```output { "NewAssociationId": "aclassoc-0df1e05cfc70356a8" } ``` ### 手順 5. すべてのクラスタコンポーネントが同期していることを確認する + クラスタのステータスを確認し、以前に切断されたコンポーネントが現在同期していることを確認します。 ```bash tiup cluster display tidb-demo ``` ```output Cluster type: tidb Cluster name: tidb-demo Cluster version: vtidb_version Deploy user: ec2-user SSH type: builtin Dashboard URL: http://52.13.86.218:2379/dashboard Grafana URL: http://10.90.4.74:3000 ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.90.4.74:9093 alertmanager 10.90.4.74 9093/9094 linux/x86_64 Up /tidb-data/alertmanager-9093 /tidb-deploy/alertmanager-9093 10.90.4.74:3000 grafana 10.90.4.74 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000 10.90.1.208:2379 pd 10.90.1.208 2379/2380 linux/x86_64 Up /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.2.39:2379 pd 10.90.2.39 2379/2380 linux/x86_64 Up|L /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.3.68:2379 pd 10.90.3.68 2379/2380 linux/x86_64 Up /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.4.74:9090 prometheus 10.90.4.74 9090/12020 linux/x86_64 Up /tidb-data/prometheus-9090 /tidb-deploy/prometheus-9090 10.90.1.247:4000 tidb 10.90.1.247 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.2.33:4000 tidb 10.90.2.33 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.1.122:20160 tikv 10.90.1.122 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.2.5:20160 tikv 10.90.2.5 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.3.14:20160 tikv 10.90.3.14 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 Total nodes: 11 ``` + Ctrl+Cを[ターミナル 2](ssh://monitor1-ssh#2)と[ターミナル 3](ssh://monitor1-ssh#3)で押して、両方のワークロードを停止します。 ## 結論 TiDBの分散アーキテクチャのおかげで、データセンターやアベイラビリティゾーンレベルでの障害はサーバ側のフェイルオーバーをトリガーし、データベースクライアントがフェイルオーバーの完了を待つ必要がありません。代わりに、データベースクライアントは利用可能なTiDBサーバインスタンスにシームレスに接続し、継続的なビジネス運用を保証します。このような災害が発生した場合、アプリケーションはビジネスの要件に従って操作のタイムアウトを設定できます。伝統的なシステムとは異なり、TiDBはサーバ側のフェイルオーバーが完了する前にデータベースクライアントが接続する必要はありません。 ```hbsptform { "ui": { "titleLevel": 3 }, "portalId": "4466002", "formId": "62bfb32a-a60a-4f9d-b2dc-1107a93db568", "region": "na1", "sfdcCampaignId": "701RC00000NdFlAYAV" } ```