# TiDB デュアルデータセンター展開ソリューション: DR Auto-Sync ## 概要 金融業界では、デュアルデータセンターアーキテクチャは特にコアビジネスシステムにおいて一般的な展開モデルです。銀行や金融機関は、データの可用性と災害復旧機能に高い価値を置いています。TiDBのDRオートシンクソリューションは、そのような環境のために特別に設計されており、デュアルデータセンターインフラストラクチャ上での強力なデータ保護を提供しつつ、RPO（回復時点目標）を0、RTO（回復時間目標）を分単位で保証します。具体的には、このソリューションは次の機能を提供します： + RPO = 0：データセンターの障害が発生した場合でもデータ損失を防ぎます。 + 分単位のRTO：障害後、数分以内にサービスの復旧を可能にします。 + アクティブ・アクティブサービス：両方のデータセンターが同時に高可用性データサービスを提供します。 この演習では、DRオートシンクのデュアルデータセンターシナリオでの展開をシミュレートし、1つのデータセンターが利用できない場合やネットワーク遅延が発生した場合にデータの一貫性と高可用性をどのように達成するかを示します。 ### 所要時間 + この演習は約 100 分程度かかります。 ### DR オートシンクソリューションの紹介 デフォルト展開の課題 + デフォルトでは、すべてのデータベースレプリカ（3つのレプリカ）がRaftグループを形成し、任意の2つのレプリカがデータベースの可用性とデータの永続性を保証します。各データ書き込みは、Raftグループ内の任意の2つのTiKVでコミットされる限り、クライアントは成功レスポンスを受け取ります。しかし、データセンター1が最新の2つのデータレプリカを保持し、完全に停止した場合、これらの2つのレプリカは失われ、Raftグループはデータセンター2への最新データのレプリケーションを保証できません。 ![60%](https://lab-static.pingcap.com/quick-demo/demo-303-1-en.png) DR オートシンクソリューション + このソリューションでは、Raftアルゴリズムにコミットグループの概念を導入します。データをコミットするには、過半数ルールを満たすだけでなく、少なくとも2つのコミットグループに存在する必要があります。これにより、両方のデータセンターが最新のデータコピーを保持し、データの安全性を確保します。 ![60%](https://lab-static.pingcap.com/quick-demo/demo-303-2-en.png) また、このソリューションにはDC2にエクストララーナーノードが含まれており、投票には参加せず、DC2が唯一の生存データセンターである場合にのみTiDBクラスタを復元するために使用されます。 DR オートシンクによる高可用性シナリオ + DRオートシンクソリューションは、TiKVデータ同期モードを識別するために3つの異なる状態を使用します。クラスタのレプリケーションモードは、自動的かつ適応的に3つのステータス間を切り替えることができます。 ![60%](https://lab-static.pingcap.com/quick-demo/demo-303-3-en.png) + 同期モード：TiDBはデフォルトで同期レプリケーションモードで動作します。このモードでは、災害復旧データセンターの少なくとも1つのレプリカがプライマリデータセンターと同期します。Raftアルゴリズムは、すべてのデータが災害復旧データセンターにレプリケートされることを保証します。この状態では、どのデータセンターの全体的な障害も、TiDBクラスタがRPO=0を達成することを保証します。 + 非同期モード：1つのデータセンター全体で障害が発生した場合、TiDBは非同期レプリケーションモードに切り替えます。このモードでは、2つのデータセンターのデータは完全に同期されません。Raftアルゴリズムは、過半数クオーラムプロトコルのみに従って劣化し、生存データセンター内でデータレプリケーションを完了します。障害がすでに発生しているため、2回目の障害が発生する場合、TiDBクラスタはRPO=0を保証できません。クラスタは、初期障害が解決された後にのみ、RPO=0の高可用性機能を再び得ることができます。 + 同期復旧モード：データセンターの障害が解決され、2つのデータセンター間のデータ同期が進行中です。TiDBは同期復旧モードに切り替わります。このモードでは、2つのデータセンターは完全に同期されていません。データ同期が完了すると、TiDBは再び同期モードに戻ります。その後、TiDBクラスタはRPO=0 HA機能を再び得ます。 ### タスク + モジュール 1: デモンストレーション1: TiDBクラスタをセットアップし、DR Auto-syncデプロイメントを構成して、高可用性モードの正しい設定を確認します。 + モジュール 2: 災害復旧データセンターの障害またはネットワーク分離をシミュレートし、クラスタの自動切替と復旧メカニズムを観察します。 + モジュール 3: プライマリデータセンターの障害をシミュレートし、クラスタのフェイルオーバー動作と迅速な復旧能力を確認します。 ### 目的 2つのデータセンターシナリオをシミュレートすることにより、この演習はTiDBのDR Auto-Syncソリューションがデータセンター間でどのように高可用性と強い整合性を実現するかを示します。このソリューションは、従来の2つのデータセンターアーキテクチャにおける潜在的な障害やデータ喪失の問題を解決するだけでなく、動的同期モード切り替えによりTiDBの柔軟性と災害復旧能力を向上させます。 DR Auto-Syncは、高い信頼性とデータ喪失ゼロを要求する支払いシステム、クリアリングシステム、アカウント管理システムなどの金融業界の主要なビジネスシナリオに特に適しています。この演習は、二重データセンターアーキテクチャにおけるTiDBのユニークな利点と実用的な能力を直感的に理解する機会を提供します。 ### 前提条件 + **macOS** ユーザー: + 秘密キーファイル[pe-class-key-oregon.pem](/api/labs/demo_001/vm_key?region_name=oregon)をクリックしてダウンロードしてください。このファイルは、このハンズオン演習でリモートLinuxにログインするために必要です。 + 秘密キーファイルを`~/.ssh/`フォルダに保存し、プライベートキーの権限を`400`に設定する必要があります。 + 以下のコマンドを使用して権限を設定し、ファイルが存在するか確認してください。 ```bash chmod 400 ~/.ssh/pe-class-key-oregon.pem ls -lF ~/.ssh/pe-class-key-oregon.pem ``` ```output ... -r--------@ 1 username staff 1674 Jun 21 2023 /Users/username/.ssh/pe-class-key-oregon.pem ``` + **Windows 10** ユーザー: + 秘密キーファイル[pe-class-key-oregon.pem](/api/labs/demo_001/vm_key?region_name=oregon)をクリックしてダウンロードしてください。このファイルは、このハンズオン演習でリモートLinuxにログインするために必要です。 + 秘密キーファイルを`%userprofile%\.ssh`フォルダに保存する必要があります。 + ファイルが存在するかどうかを確認するには、以下のコマンドを使用してください。コマンドプロンプトを使用し、Powershellは使用しないでください。 ```cmd dir %userprofile%\.ssh\pe-class-key-oregon.pem ``` ```output ... 2024/11/14 10:22 1,674 pe-class-key-oregon.pem 1 Files(s) 1,674 bytes ... ``` + **Windows 8** またはそれ以前のユーザー: + 秘密キーファイル[pe-class-key-oregon.ppk](/api/labs/demo_001/vm_key?region_name=oregon&key_type=ppk)をクリックしてダウンロードしてください。このファイルは、このハンズオン演習でリモートLinuxにログインするために必要です。 + [PuTTY](https://www.putty.org/)をダウンロードしてインストールします。 ## モジュール 1: DR 自動同期構成で TiDB クラスタをセットアップ この演習では、DR自動同期構成を有効にしたクラスターを設定します。次のノードが2つのデータセンターに分散しています: + DC1はプライマリデータセンターで、AWSのAZ1に位置しています: `pd*2, tidb*1, tikv*2, tiup(monitor)*1` + DC2は災害復旧データセンターで、AWSのAZ2に位置しています: `pd*1(さらに予備の1ノード待機), tidb*1, tikv*2, tiup(monitor)*1` + Sysbenchはアプリケーションとして機能し、各データセンターにデプロイされています（下の図の`client`に対応）。注: テストはロードバランシングサービスを簡略化し、DC1のsysbenchはDC1のTiDBサーバーに直接接続し、DC2のsysbenchも同様です。 ![60%](https://lab-static.pingcap.com/quick-demo/demo-303-4-en.png) ### 手順 1. 最初のデータセンターでモニターノードに接続する + ローカルターミナル（ターミナル1）を開き、モニター1サーバーに接続してTiDBクラスタをデプロイします。リモートのバスチョンLinuxに接続してください。接続の資格情報を持っていない場合は、`前提条件`セクションを確認してください。メッセージが表示されたら`yes`と答えてください。 + **macOS** ユーザー: ```bash ssh -i ~/.ssh/pe-class-key-oregon.pem ec2-user@az1monitor1_address ``` + **Windows 10** ユーザー: ```cmd ssh -i %userprofile%\.ssh\pe-class-key-oregon.pem ec2-user@az1monitor1_address ``` + **Windows 8** またはそれ以前のユーザー: + PuTTYを実行し、`Session` -> `Host Name` に `ec2-user@monitor1_address`と入力します。 + In `Connection` -> `SSH` -> `Auth` -> `Credentials` -> `Private key file for authentication`で、キーファイルの場所を探して指定します。 + これでリモートLinuxに接続できるようになりますので。 + ログイン後に表示されるバナーは次のようになります。 ```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 クラスタトポロジ構成を確認する + プロビジョニングされたクラスタトポロジーのYAMLを確認します。 ```bash cat dr-auto-sync.yaml ``` ```output global: user: "ec2-user" ssh_port: 22 deploy_dir: "/tidb-deploy" data_dir: "/tidb-data" arch: "amd64" monitored: node_exporter_port: 9100 blackbox_exporter_port: 9115 deploy_dir: "/tidb-deploy/monitored-9100" data_dir: "/tidb-data/monitor_9115" log_dir: "/tidb-deploy/monitor-9100/log" server_configs: pd: replication.location-labels: ["dc","logic","rack","host"] tidb_servers: - host: 10.90.1.163 port: 4000 status_port: 10080 deploy_dir: "/tidb-deploy/tidb-4000" log_dir: "/tidb-deploy/tidb-4000/log" - host: 10.90.2.111 port: 4000 status_port: 10080 deploy_dir: "/tidb-deploy/tidb-4000" log_dir: "/tidb-deploy/tidb-4000/log" tikv_servers: - host: 10.90.1.80 port: 20160 status_port: 20180 deploy_dir: "/tidb-deploy/tikv-20160" data_dir: "/tidb-data/tikv_data" config: server.labels: { dc: "dc1",logic: "logic1",rack: "r1",host: "10.90.1.80" } - host: 10.90.1.45 port: 20160 status_port: 20180 deploy_dir: "/tidb-deploy/tikv-20160" data_dir: "/tidb-data/tikv_data" config: server.labels: { dc: "dc1",logic: "logic2",rack: "r1",host: "10.90.1.45" } - host: 10.90.2.33 port: 20160 status_port: 20180 deploy_dir: "/tidb-deploy/tikv-20160" data_dir: "/tidb-data/tikv_data" config: server.labels: { dc: "dc2",logic: "logic3",rack: "r1",host: "10.90.2.33" } - host: 10.90.2.113 port: 20160 status_port: 20180 deploy_dir: "/tidb-deploy/tikv-20160" data_dir: "/tidb-data/tikv_data" config: server.labels: { dc: "dc2",logic: "logic4",rack: "r1",host: "10.90.2.113" } pd_servers: - host: 10.90.1.19 client_port: 2379 peer_port: 2380 deploy_dir: "/tidb-deploy/pd-2379" data_dir: "/tidb-data/pd_data" advertise_client_addr: "http://35.88.184.77:2379" - host: 10.90.1.44 client_port: 2379 peer_port: 2380 deploy_dir: "/tidb-deploy/pd-2379" data_dir: "/tidb-data/pd_data" advertise_client_addr: "http://34.219.233.52:2379" - host: 10.90.2.108 client_port: 2379 peer_port: 2380 deploy_dir: "/tidb-deploy/pd-2379" data_dir: "/tidb-data/pd_data" advertise_client_addr: "http://18.236.155.129:2379" monitoring_servers: - host: 10.90.1.147 port: 10090 deploy_dir: "/tidb-deploy/prometheus-10090" data_dir: "/tidb-data/prometheus_data" - host: 10.90.2.82 port: 10090 deploy_dir: "/tidb-deploy/prometheus-10090" data_dir: "/tidb-data/prometheus_data" grafana_servers: - host: 10.90.1.147 port: 3000 deploy_dir: "/tidb-deploy/grafana-3000" - host: 10.90.2.82 port: 3000 deploy_dir: "/tidb-deploy/grafana-3000" ``` ### 手順 3. TiUP のミラーを設定して `precheck` コマンドを実行します ```bash tiup mirror set tidb-community-server-tidb_version-linux-amd64 tiup cluster check dr-auto-sync.yaml \ --user ec2-user \ -i /home/ec2-user/.ssh/pe-class-key-oregon.pem \ --apply ``` ```output ... + Try to apply changes to fix failed checks + Try to apply changes to fix failed checks + Try to apply changes to fix failed checks + Try to apply changes to fix failed checks + Try to apply changes to fix failed checks + Try to apply changes to fix failed checks + Try to apply changes to fix failed checks - Applying changes on 10.90.2.33 ... Done - Applying changes on 10.90.2.113 ... Done - Applying changes on 10.90.1.163 ... Done - Applying changes on 10.90.2.111 ... Done - Applying changes on 10.90.1.147 ... Done - Applying changes on 10.90.1.44 ... Done - Applying changes on 10.90.2.108 ... Done - Applying changes on 10.90.1.45 ... Done - Applying changes on 10.90.2.82 ... Done - Applying changes on 10.90.1.19 ... Done - Applying changes on 10.90.1.80 ... Done ``` ### 手順 4. TiDB クラスタをデプロイします ```bash tiup cluster deploy tidb-demo vtidb_version ./dr-auto-sync.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` ``` ### 手順 5. TiDB クラスタを開始します ```bash tiup cluster start tidb-demo ``` ```output ... Started cluster `tidb-demo` successfully ``` ### 手順 6. TiDB クラスタのステータスを確認します + クラスタのステータスを取得します。主要なクラスタコンポーネントは2つのサブネット（10.90.1.0/24 for DC1, 10.90.2.0/24 for DC2）に分布しており、2つのアベイラビリティゾーンに位置しています。各データセンターには2つのPDサーバー（DC2には待機中のpdノードが1つ含まれています）、2つのTiKVサーバー、および1つのTiDBサーバーがあります。したがって、このデプロイメントを使用して、2データセンター環境をシミュレートすることができます。 ```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://54.188.60.25:2379/dashboard Grafana URL: http://10.90.1.114:3000,http://10.90.2.122:3000 ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.90.1.114:3000 grafana 10.90.1.114 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000 10.90.2.122:3000 grafana 10.90.2.122 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000 10.90.1.106:2379 pd 10.90.1.106 2379/2380 linux/x86_64 Up /tidb-data/pd_data /tidb-deploy/pd-2379 10.90.1.19:2379 pd 10.90.1.19 2379/2380 linux/x86_64 Up /tidb-data/pd_data /tidb-deploy/pd-2379 10.90.2.162:2379 pd 10.90.2.162 2379/2380 linux/x86_64 Up|L /tidb-data/pd_data /tidb-deploy/pd-2379 10.90.1.114:10090 prometheus 10.90.1.114 10090/12020 linux/x86_64 Up /tidb-data/prometheus_data /tidb-deploy/prometheus-10090 10.90.2.122:10090 prometheus 10.90.2.122 10090/12020 linux/x86_64 Up /tidb-data/prometheus_data /tidb-deploy/prometheus-10090 10.90.1.81:4000 tidb 10.90.1.81 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.2.207:4000 tidb 10.90.2.207 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.1.163:20160 tikv 10.90.1.163 20160/20180 linux/x86_64 Up /tidb-data/tikv_data /tidb-deploy/tikv-20160 10.90.1.83:20160 tikv 10.90.1.83 20160/20180 linux/x86_64 Up /tidb-data/tikv_data /tidb-deploy/tikv-20160 10.90.2.17:20160 tikv 10.90.2.17 20160/20180 linux/x86_64 Up /tidb-data/tikv_data /tidb-deploy/tikv-20160 10.90.2.19:20160 tikv 10.90.2.19 20160/20180 linux/x86_64 Up /tidb-data/tikv_data /tidb-deploy/tikv-20160 Total nodes: 13 ``` ### 手順 7. プレースメントドライバーのリーダーがDC1にあることを確認します + プレースメントドライバー（PD）リーダーがDC1にない場合（IPが10.90.1.0/24サブネットに属しない場合）、リーダーをDC1に移行します。 ```output ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.90.1.106:2379 pd 10.90.1.106 2379/2380 linux/x86_64 Up /tidb-data/pd_data /tidb-deploy/pd-2379 10.90.1.19:2379 pd 10.90.1.19 2379/2380 linux/x86_64 Up /tidb-data/pd_data /tidb-deploy/pd-2379 10.90.2.162:2379 pd 10.90.2.162 2379/2380 linux/x86_64 Up|L /tidb-data/pd_data /tidb-deploy/pd-2379 ``` + 前のステップの結果にかかわらず、リーダーをDC1に移行するためにこのコマンドを実行できます。 ```bash tiup ctl:vtidb_version pd -u ${HOST_AZ1PD1_PRIVATE_IP}:2379 member leader transfer "pd-${HOST_AZ1PD1_PRIVATE_IP}-2379" ``` ```output The component `ctl` version vtidb_version is not installed; downloading from repository. Starting component ctl: /home/ec2-user/.tiup/components/ctl/vtidb_version/ctl pd -u 10.90.1.19:2379 member leader transfer pd-10.90.1.106-2379 Success! ``` + PDリーダーの場所を確認し、DC1に移行していることを確認します。 ```bash tiup cluster display tidb-demo ``` ```output ... ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- ... 10.90.1.106:2379 pd 10.90.1.106 2379/2380 linux/x86_64 Up|L /tidb-data/pd_data /tidb-deploy/pd-2379 10.90.1.19:2379 pd 10.90.1.19 2379/2380 linux/x86_64 Up /tidb-data/pd_data /tidb-deploy/pd-2379 10.90.2.162:2379 pd 10.90.2.162 2379/2380 linux/x86_64 Up /tidb-data/pd_data /tidb-deploy/pd-2379 ... ``` ### 手順 8. DC2 にピアリング TiUP モニターを作成します + TiUPのクラスタメタファイルをモニター2（Tiupディレクトリ）にコピーします。これは災害復旧データセンター（DC2）にあります。メッセージが表示されたら`yes`と答えてください。 ```bash scp -i ~/.ssh/pe-class-key-oregon.pem -r .tiup/storage/ ec2-user@az2monitor1_address:/home/ec2-user/.tiup/ ``` ```output ... run_blackbox_exporter_10.90.1.163.sh 100% 519 356.8KB/s 00:00 run_blackbox_exporter_10.90.2.82.sh 100% 519 414.9KB/s 00:00 meta.yaml 100% 4481 3.2MB/s 00:00 ``` + 新しいターミナルを開きます（ターミナル2）。モニター2にログインして、TiUPメタファイルが正常に機能していることを確認します。 + monitor2にログインします。 ```bash ssh -i ~/.ssh/pe-class-key-oregon.pem ec2-user@az2monitor1_address ``` ```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の`tiup`が正常に機能していることを確認します。 ```bash tiup cluster display tidb-demo ``` ```output Checking updates for component cluster... A new version of cluster is available: v1.15.1 -> v1.16.1 To update this component: tiup update cluster To update all components: tiup update --all Cluster type: tidb Cluster name: tidb-demo Cluster version: vtidb_version Deploy user: ec2-user SSH type: builtin Dashboard URL: http://35.88.184.77:2379/dashboard Grafana URL: http://10.90.1.147:3000,http://10.90.2.82:3000 ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.90.1.147:3000 grafana 10.90.1.147 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000 10.90.2.82:3000 grafana 10.90.2.82 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000 10.90.1.19:2379 pd 10.90.1.19 2379/2380 linux/x86_64 Up|L /tidb-data/pd_data /tidb-deploy/pd-2379 10.90.1.44:2379 pd 10.90.1.44 2379/2380 linux/x86_64 Up /tidb-data/pd_data /tidb-deploy/pd-2379 10.90.2.108:2379 pd 10.90.2.108 2379/2380 linux/x86_64 Up /tidb-data/pd_data /tidb-deploy/pd-2379 10.90.1.147:10090 prometheus 10.90.1.147 10090/12020 linux/x86_64 Up /tidb-data/prometheus_data /tidb-deploy/prometheus-10090 10.90.2.82:10090 prometheus 10.90.2.82 10090/12020 linux/x86_64 Up /tidb-data/prometheus_data /tidb-deploy/prometheus-10090 10.90.1.163:4000 tidb 10.90.1.163 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.2.111:4000 tidb 10.90.2.111 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.1.45:20160 tikv 10.90.1.45 20160/20180 linux/x86_64 Up /tidb-data/tikv_data /tidb-deploy/tikv-20160 10.90.1.80:20160 tikv 10.90.1.80 20160/20180 linux/x86_64 Up /tidb-data/tikv_data /tidb-deploy/tikv-20160 10.90.2.113:20160 tikv 10.90.2.113 20160/20180 linux/x86_64 Up /tidb-data/tikv_data /tidb-deploy/tikv-20160 10.90.2.33:20160 tikv 10.90.2.33 20160/20180 linux/x86_64 Up /tidb-data/tikv_data /tidb-deploy/tikv-20160 Total nodes: 13 ``` ### 手順 9. TiDB クラスタで DR Auto-Sync を有効にします + ターミナル1に戻ります。 ```bash exit ``` + 現在のクラスタデータのレプリケーションモードを確認します。デフォルトでは`過半数`でのはずです。注: 結果が`"acid_consistent": false`である場合、プライマリデータセンターと災害復旧データセンター間のデータレプリケーションが`同期`モードではないことを意味します。したがって、プライマリデータセンターが完全に障害を起こした場合、トランザクションの`ACID`特性は絶対的に保証されません。 ```bash curl ${HOST_AZ1PD1_PRIVATE_IP}:2379/pd/api/v1/replication_mode/status ``` ```output { "mode": "majority", "dr-auto-sync": { "label_key": "", "state": "", "acid_consistent": false } } ``` + DR自動同期構成用に準備したプレースメントルールファイルを確認します。データセンターが2つあり、投票者ロールはDC1に限定されています。DC2にはフォロワーとラーナーロールがあります。 ```bash cat dr-anto-sync-rules.json ``` ```output [ { "group_id": "pd", "group_index": 0, "group_override": false, "rules": [ { "group_id": "pd", "id": "dc1", "start_key": "", "end_key": "", "role": "voter", "count": 2, "location_labels": ["dc", "logic", "rack", "host"], "label_constraints": [{"key": "dc", "op": "in", "values": ["dc1"]}] }, { "group_id": "pd", "id": "logic3", "start_key": "", "end_key": "", "role": "follower", "count": 1, "location_labels": ["dc", "logic", "rack", "host"], "label_constraints": [{"key": "logic", "op": "in", "values": ["logic3"]}] }, { "group_id": "pd", "id": "logic4", "start_key": "", "end_key": "", "role": "learner", "count": 1, "location_labels": ["dc", "logic", "rack", "host"], "label_constraints": [{"key": "logic", "op": "in", "values": ["logic4"]}] } ] } ] ``` ![60%](https://lab-static.pingcap.com/quick-demo/demo-303-41-en.png) + 上記のプレースメントルールをインポートすることで、PDは異なるノードの分配設計を認識することができます（Learnerに関する詳細：[PD Scheduling Best Practices - クラスタトポロジーの認識](https://docs.pingcap.com/tidb/stable/pd-scheduling-best-practices#cluster-topology-awareness)）。これにより、クラスタ内のリージョンのレプリカが可能な限り分散されるようになります。PDはlocation-labelsの設定に基づいてスケジュールを作成します。設定の["dc", "logic", "rack", "host"]は4レベルのトポロジー構造を定義しています: + クラスタは複数のdc（データセンター）に分割されています。 + 各dcは複数のlogic（論理ゾーン）を含んでいます。 + 各logicは複数のrackユニットを含んでいます。 + 各rackは複数のhostユニットを含んでいます。 + スケジューリング時にPDは: + リージョンのピアを異なるdcに優先的に配置します。 + これが不可能な場合（例えば、3つのレプリカが構成されているが、利用可能なデータセンターが2つしかない場合）、PDは異なる論理ゾーンに配置を保証します。 + 論理ゾーンの数も分離を保証するには不十分な場合、ラックレベルでの隔離を試みます。 + ラックユニットの数も不十分である場合、ホストレベルでの隔離を試みます。 + プレースメントルール構成をロードします。`ctl`ツールは自動的にダウンロードおよびインストールされます。 ```bash tiup ctl:vtidb_version pd config placement-rules rule-bundle -u ${HOST_AZ1PD1_PRIVATE_IP}:2379 save --in="/home/ec2-user/dr-anto-sync-rules.json" ``` ```output The component `ctl` version vtidb_version is not installed; downloading from repository. download https://tiup-mirrors.pingcap.com/ctl-vtidb_version-linux-amd64.tar.gz 408.65 MiB / 408.65 MiB 100.00% 103.24 MiB/s Starting component ctl: /home/ec2-user/.tiup/components/ctl/vtidb_version/ctl pd config placement-rules rule-bundle -u http://10.90.2.162:2379 save --in=/home/ec2-user/dr-anto-sync-rules.json "Update rules and groups successfully." ``` + プレースメントルール構成がロードされているか確認します。 ```bash tiup ctl:vtidb_version pd config placement-rules show -u ${HOST_AZ1PD1_PRIVATE_IP}:2379 ``` ```output Starting component ctl: /home/ec2-user/.tiup/components/ctl/vtidb_version/ctl pd config placement-rules show -u http://10.90.2.162:2379 [ { "group_id": "pd", "id": "dc1", "start_key": "", "end_key": "", "role": "voter", "is_witness": false, "count": 2, "label_constraints": [ { "key": "dc", "op": "in", "values": [ "dc1" ] } ], "location_labels": [ "dc", "logic", "rack", "host" ], "version": 2, "create_timestamp": 1733292613 }, { "group_id": "pd", "id": "logic3", "start_key": "", "end_key": "", "role": "voter", "is_witness": false, "count": 1, "label_constraints": [ { "key": "logic", "op": "in", "values": [ "logic3" ] } ], "location_labels": [ "dc", "logic", "rack", "host" ], "version": 2, "create_timestamp": 1733292613 }, { "group_id": "pd", "id": "logic4", "start_key": "", "end_key": "", "role": "learner", "is_witness": false, "count": 1, "label_constraints": [ { "key": "logic", "op": "in", "values": [ "logic4" ] } ], "location_labels": [ "dc", "logic", "rack", "host" ], "version": 2, "create_timestamp": 1733292613 } ] ``` + `jq`ツールをインストールします。 ```bash sudo yum install jq -y ``` ```output ... Installed: jq.x86_64 0:1.5-1.amzn2.0. 2 Dependency Installed: oniguruma.x86_64 0:5.9.6-1.amzn2.0. 7 Complete! ``` + `Leaner`ピアがないTiKVリージョンがないかを確認します。`Leaner`ピアのないリージョンがないことを確認し、投票者と`Leaner`の役割を持つ間でデータが同期されていることを保証します。このステップは、高可用性とフェイルオーバーの準備を維持するために重要なデータの整合性のある複製を保証します。 ```bash tiup ctl:vtidb_version pd -u ${HOST_AZ1PD1_PRIVATE_IP}:2379 region --jq='.regions[] | select(.peers | any(.role_name=="Learner") | not) | {id: .id, peers: [.peers]}' ``` ```output Starting component ctl: /home/ec2-user/.tiup/components/ctl/vtidb_version/ctl pd -u http://34.215.73.186:2379 region --jq=.regions[] | select(.peers | any(.role_name=="Learner") | not) | {id: .id, peers: [.peers]} ``` + DR自動同期構成を有効にします。 ```bash tiup ctl:vtidb_version pd -u ${HOST_AZ1PD1_PRIVATE_IP}:2379 config set replication-mode dr-auto-sync tiup ctl:vtidb_version pd -u ${HOST_AZ1PD1_PRIVATE_IP}:2379 config set replication-mode dr-auto-sync label-key dc tiup ctl:vtidb_version pd -u ${HOST_AZ1PD1_PRIVATE_IP}:2379 config set replication-mode dr-auto-sync primary dc1 tiup ctl:vtidb_version pd -u ${HOST_AZ1PD1_PRIVATE_IP}:2379 config set replication-mode dr-auto-sync dr dc2 tiup ctl:vtidb_version pd -u ${HOST_AZ1PD1_PRIVATE_IP}:2379 config set replication-mode dr-auto-sync primary-replicas 2 tiup ctl:vtidb_version pd -u ${HOST_AZ1PD1_PRIVATE_IP}:2379 config set replication-mode dr-auto-sync dr-replicas 1 ``` ```output Starting component ctl: /home/ec2-user/.tiup/components/ctl/vtidb_version/ctl pd -u http://10.90.2.162:2379 config set replication-mode dr-auto-sync Success! The replication mode config is updated." Starting component ctl: /home/ec2-user/.tiup/components/ctl/vtidb_version/ctl pd -u http://10.90.2.162:2379 config set replication-mode dr-auto-sync label-key dc Success! The replication mode config is updated." Starting component ctl: /home/ec2-user/.tiup/components/ctl/vtidb_version/ctl pd -u http://10.90.2.162:2379 config set replication-mode dr-auto-sync primary dc1 Success! The replication mode config is updated." Starting component ctl: /home/ec2-user/.tiup/components/ctl/vtidb_version/ctl pd -u http://10.90.2.162:2379 config set replication-mode dr-auto-sync dr dc2 Success! The replication mode config is updated." Starting component ctl: /home/ec2-user/.tiup/components/ctl/vtidb_version/ctl pd -u http://10.90.2.162:2379 config set replication-mode dr-auto-sync primary-replicas 2 Success! The replication mode config is updated." Starting component ctl: /home/ec2-user/.tiup/components/ctl/vtidb_version/ctl pd -u http://10.90.2.162:2379 config set replication-mode dr-auto-sync dr-replicas 1 Success! The replication mode config is updated." ``` + これらのパラメータの設定により、クラスタはデータセンターの位置を認識し、データの分配を制御することができます。 + set replication-mode dr-auto-sync: TiDBのレプリケーションモードをdr-auto-syncに設定します。 + set replication-mode dr-auto-sync label-key dc: PDがノードが属するデータセンターをdcラベルに基づいて識別できるようにし、データ分布の制御を達成します。 + set replication-mode dr-auto-sync primary dc1: DC1をプライマリデータセンターに設定し、運用時にTiDBクラスタの主要な書き込みノードにします。すべてのデータ更新はプライマリデータセンターへの書き込みが優先されます。 + set replication-mode dr-auto-sync dr dc2: DC2を災害復旧データセンターに設定し、TiKVノードが`Leaner`ロールで存在します。 + set replication-mode dr-auto-sync primary-replicas 2: プライマリデータセンター（DC1）のレプリカ数を2に設定します。 + set replication-mode dr-auto-sync dr-replicas 1: 災害復旧データセンター（DC2）のレプリカ数を1に設定します（`Leaner`ロールは含まれません）。 + 構成が有効であるかどうかを確認します。 ```bash tiup ctl:vtidb_version pd -u ${HOST_AZ1PD1_PRIVATE_IP}:2379 config show replication-mode ``` ```output Starting component ctl: /home/ec2-user/.tiup/components/ctl/vtidb_version/ctl pd -u http://10.90.2.162:2379:2379 config show replication-mode { "replication-mode": "dr-auto-sync", "dr-auto-sync": { "label-key": "dc", "primary": "dc1", "dr": "dc2", "primary-replicas": 2, "dr-replicas": 1, "wait-store-timeout": "1m0s", "wait-recover-timeout": "0s", "pause-region-split": "false" } } ``` + 現在のクラスタのレプリケーション状態をチェックします。操作が速かった場合、状態が`sync`モードになる前に`sync_recover`モードと`recover_progress`を確認できます。 ```bash curl ${HOST_AZ1PD1_PRIVATE_IP}:2379/pd/api/v1/replication_mode/status ``` ```output { "mode": "dr-auto-sync", "dr-auto-sync": { "label_key": "dc", "state": "sync_recover", "state_id": 2003, "acid_consistent": false, "total_regions": 60, "synced_regions": 37, "recover_progress": 0.98333335 } } ``` + 最後に、TiDBの`sync`状態を取得します。 ```output { "mode": "dr-auto-sync", "dr-auto-sync": { "label_key": "dc", "state": "sync", "state_id": 378, "acid_consistent": true } } ``` + 初期化の状態として、クラスタは同期レプリケーションモードにあります。PDはステータス情報をTiKVに送信し、二つのデータセンター（二コミットグループ）は厳密に同期レプリケーションモードに従って動作します。 ### 手順 10. `sysbench` データベースを作成します + TiDBにログインします。 ```bash mysql -h ${HOST_AZ1DB1_PRIVATE_IP} -P 4000 -u root --connect-expired-password ``` ```output mysql> ``` + `sysbench`用のデータベースを作成します。 ```sql CREATE DATABASE sbtest; EXIT; ``` ```output Query OK, 0 rows affected (0.13 sec) Bye ``` + DC1用の`sysbench`構成を設定します。 ```bash cat << EOF > sysbench_config mysql-host=${HOST_AZ1DB1_PRIVATE_IP} mysql-port=4000 mysql-user=root mysql-password= mysql-db=sbtest time=3600 threads=6 report-interval=1 EOF cat sysbench_config ``` ```output mysql-host=10.90.1.125 mysql-port=4000 mysql-user=root mysql-password= mysql-db=sbtest time=3600 threads=16 report-interval=1 ``` + 次のモジュールのために`sysbench`データを準備します。 ```bash sysbench --config-file=sysbench_config oltp_point_select --tables=6 --table-size=100 prepare ``` ```output sysbench 1.0.17 (using bundled LuaJIT 2.1.0-beta2) Initializing worker threads... Creating table 'sbtest3'... Creating table 'sbtest1'... Creating table 'sbtest5'... Creating table 'sbtest6'... Creating table 'sbtest4'... Creating table 'sbtest2'... Inserting 100 records into 'sbtest3' Creating a secondary index on 'sbtest3'... Inserting 100 records into 'sbtest1' Creating a secondary index on 'sbtest1'... Inserting 100 records into 'sbtest4' Creating a secondary index on 'sbtest4'... Inserting 100 records into 'sbtest6' Creating a secondary index on 'sbtest6'... Inserting 100 records into 'sbtest2' Creating a secondary index on 'sbtest2'... Inserting 100 records into 'sbtest5' Creating a secondary index on 'sbtest5'... ``` ### モジュール 1のまとめ + ここまでで、次のことを完了しました: + TiDBクラスタの作成。 + TiDBクラスタのDR自動同期デプロイメント計画を有効にし、そのステータスを確認しました。 + アプリケーションの動作をシミュレートするためにsysbenchの設定を準備しました。 ## モジュール 2: DC2 のネットワークアクセスを遮断してセカンダリ DC の故障をシミュレートする この演習の目的は、データセンター2を完全に利用できない状態にシミュレートし、TiDBクラスタの状態を観察し、それを復元することです。 ![60%](https://lab-static.pingcap.com/quick-demo/demo-303-5-en.png) データセンター2の障害をシミュレートする方法は、データセンター1とデータセンター2間のネットワーク通信を切断することです。これにより、データセンター2のサーバーが外部からの要求を受信したり応答したりするのを防ぎ、データセンター1から見るとデータセンター2が完全に故障したかのように見えます。 ### 手順 1. DC1 のモニターサーバーに接続します + ローカルターミナル（Terminal 1）を開き、モニターサーバー1に接続します。 + **macOS**ユーザーの場合： ```bash ssh -i ~/.ssh/pe-class-key-oregon.pem ec2-user@az1monitor1_address ``` + **Windows 10**ユーザーの場合： ```cmd ssh -i %userprofile%\.ssh\pe-class-key-oregon.pem ec2-user@az1monitor1_address ``` ```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. ワークロードを開始します + `sysbench`を開始してアプリケーションとして動作させます。開始後、次のステップに進みます。 ```bash sysbench --config-file=sysbench_config oltp_read_write --tables=6 --mysql-ignore-errors=all run ``` ```output sysbench 1.0.17 (using bundled LuaJIT 2.1.0-beta2) Running the test with following options: Number of threads: 1 Report intermediate results every 1 second(s) Initializing random number generator from current time Initializing worker threads... Threads started! [ 1s ] thds: 1 tps: 61.90 qps: 1240.90 (r/w/o: 868.53/247.58/124.79) lat (ms,95%): 18.28 err/s: 0.00 reconn/s: 0.00 [ 2s ] thds: 1 tps: 58.02 qps: 1176.46 (r/w/o: 824.32/236.09/116.04) lat (ms,95%): 18.28 err/s: 0.00 reconn/s: 0.00 ... ``` ### 手順 3. レプリケーション状態が同期していることを確認します + 新しいターミナル（Terminal 2）を開きます。DC1のモニター1にログインして、データレプリケーションの状態が`sync`モードであることを確認します。 ```bash ssh -i ~/.ssh/pe-class-key-oregon.pem ec2-user@az1monitor1_address ``` ```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/ ``` + データレプリケーションの状態を確認します。 ```bash curl ${HOST_AZ1PD1_PRIVATE_IP}:2379/pd/api/v1/replication_mode/status ``` ```output { "mode": "dr-auto-sync", "dr-auto-sync": { "label_key": "dc", "state": "sync", "state_id": 1006, "acid_consistent": true } } ``` ### 手順 4. DC2（アベイラビリティゾーン2）へのネットワークアクセスをブロックします + スクリプトを実行して、サブネット`demo-subnet-2`（AZ2内のサブネット10.90.2.0/24）をブロックすることによって完全なアベイラビリティゾーンの故障をシミュレートします。 ```bash VPC_ID=`aws ec2 describe-vpcs --filters "Name=tag:Name,Values=trainer_name" --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-2" --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" } ``` ### 手順 5. アプリケーションと TiDB の状態を観察します + SysbenchはTiDBクラスタへのアクセスが約70秒間ブロックされます。これは、ブロックウィンドウ設定（デフォルト設定は60秒）よりも少し長いです。理由は、TiDBクラスタがネットワーク状態を収集し、TiDBクラスタの状態を処理し、各TiKVノードに状態を同期するための時間が必要だからです。 ```output ... [ 493s ] thds: 6 tps: 278.00 qps: 5525.08 (r/w/o: 3866.05/1082.02/577.01) lat (ms,95%): 26.68 err/s: 0.00 reconn/s: 0.00 [ 494s ] thds: 6 tps: 274.99 qps: 5505.84 (r/w/o: 3853.89/1079.97/571.98) lat (ms,95%): 27.17 err/s: 0.00 reconn/s: 0.00 [ 495s ] thds: 6 tps: 271.99 qps: 5447.84 (r/w/o: 3814.89/1065.97/566.98) lat (ms,95%): 28.67 err/s: 0.00 reconn/s: 0.00 [ 496s ] thds: 6 tps: 70.00 qps: 1406.04 (r/w/o: 985.03/278.01/143.00) lat (ms,95%): 28.16 err/s: 0.00 reconn/s: 0.00 [ 497s ] thds: 6 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s: 0.00 reconn/s: 0.00 [ 498s ] thds: 6 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s: 0.00 reconn/s: 0.00 ... [ 544s ] thds: 6 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s: 0.00 reconn/s: 0.00 [ 545s ] thds: 6 tps: 0.00 qps: 29.00 (r/w/o: 26.00/0.00/3.00) lat (ms,95%): 0.00 err/s: 3.00 reconn/s: 0.00 [ 546s ] thds: 6 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s: 0.00 reconn/s: 0.00 ... [ 566s ] thds: 6 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s: 0.00 reconn/s: 0.00 [ 567s ] thds: 6 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s: 0.00 reconn/s: 0.00 [ 568s ] thds: 6 tps: 98.00 qps: 1968.01 (r/w/o: 1376.00/388.00/204.00) lat (ms,95%): 25.74 err/s: 0.00 reconn/s: 0.00 ... [ 569s ] thds: 6 tps: 244.00 qps: 4883.91 (r/w/o: 3418.93/950.98/513.99) lat (ms,95%): 24.38 err/s: 0.00 reconn/s: 0.00 [ 570s ] thds: 6 tps: 237.00 qps: 4734.95 (r/w/o: 3313.96/924.99/495.99) lat (ms,95%): 26.68 err/s: 0.00 reconn/s: 0.00 [ 571s ] thds: 6 tps: 264.02 qps: 5279.31 (r/w/o: 3693.21/1039.06/547.03) lat (ms,95%): 30.26 err/s: 0.00 reconn/s: 0.00 ... ``` + TiDBクラスタ内のノードの状態を観察します。dc2に配置されているノードはすべてダウンしています。 ```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://18.236.254.103:2379/dashboard Grafana URL: http://10.90.1.90:3000,http://10.90.2.17:3000 ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.90.1.90:3000 grafana 10.90.1.90 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000 10.90.2.17:3000 grafana 10.90.2.17 3000 linux/x86_64 Down - /tidb-deploy/grafana-3000 10.90.1.176:2379 pd 10.90.1.176 2379/2380 linux/x86_64 Up|L /tidb-data/pd_data /tidb-deploy/pd-2379 10.90.1.73:2379 pd 10.90.1.73 2379/2380 linux/x86_64 Up /tidb-data/pd_data /tidb-deploy/pd-2379 10.90.2.198:2379 pd 10.90.2.198 2379/2380 linux/x86_64 Down /tidb-data/pd_data /tidb-deploy/pd-2379 10.90.1.90:10090 prometheus 10.90.1.90 10090/12020 linux/x86_64 Up /tidb-data/prometheus_data /tidb-deploy/prometheus-10090 10.90.2.17:10090 prometheus 10.90.2.17 10090/12020 linux/x86_64 Down /tidb-data/prometheus_data /tidb-deploy/prometheus-10090 10.90.1.106:4000 tidb 10.90.1.106 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.2.61:4000 tidb 10.90.2.61 4000/10080 linux/x86_64 Down - /tidb-deploy/tidb-4000 10.90.1.245:20160 tikv 10.90.1.245 20160/20180 linux/x86_64 Up /tidb-data/tikv_data /tidb-deploy/tikv-20160 10.90.1.45:20160 tikv 10.90.1.45 20160/20180 linux/x86_64 Up /tidb-data/tikv_data /tidb-deploy/tikv-20160 10.90.2.125:20160 tikv 10.90.2.125 20160/20180 linux/x86_64 Disconnected /tidb-data/tikv_data /tidb-deploy/tikv-20160 10.90.2.96:20160 tikv 10.90.2.96 20160/20180 linux/x86_64 Disconnected /tidb-data/tikv_data /tidb-deploy/tikv-20160 Total nodes: 13 ``` + TiDBの同期モードが、`sync`から`async_wait`、そして`async`というように変化するのを観察します。`async_wait`の期間中、pdはすべてのtikvノードにモード切り替え指示を送信します。このプロセスが完了すると、同期モードは`async`に移行します。 ```bash curl ${HOST_AZ1PD1_PRIVATE_IP}:2379/pd/api/v1/replication_mode/status ``` ```output { "mode": "dr-auto-sync", "dr-auto-sync": { "label_key": "dc", "state": "sync", "state_id": 1006, "acid_consistent": true } } ``` ```bash curl ${HOST_AZ1PD1_PRIVATE_IP}:2379/pd/api/v1/replication_mode/status ``` ```output { "mode": "dr-auto-sync", "dr-auto-sync": { "label_key": "dc", "state": "async_wait", "state_id": 1001, "acid_consistent": true } } ``` ```bash curl ${HOST_AZ1PD1_PRIVATE_IP}:2379/pd/api/v1/replication_mode/status ``` ```output { "mode": "dr-auto-sync", "dr-auto-sync": { "label_key": "dc", "state": "async", "state_id": 483, "acid_consistent": true } } ``` ### 手順 6. DC2 のネットワークアクセスを復旧します + ネットワークを復旧します。以前失われたノードは再びTiDBクラスタに参加します。 ```bash VPC_ID=`aws ec2 describe-vpcs --filters "Name=tag:Name,Values=trainer_name" --query "Vpcs[0].VpcId" --output text --region us-west-2` echo $VPC_ID SUBNET_ID=`aws ec2 describe-subnets --filters "Name=vpc-id,Values=${VPC_ID}" "Name=tag:Name,Values=demo-subnet-2" --query "Subnets[0].SubnetId" --output text --region us-west-2` echo $SUBNET_ID 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` echo $DEFAULT_NACL_ID 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}'` echo $ASSOC_ID aws ec2 replace-network-acl-association --association-id ${ASSOC_ID} --network-acl-id ${DEFAULT_NACL_ID} --region us-west-2 ``` ```output { "NewAssociationId": "aclassoc-0df1e05cfc70356a8" } ``` + アプリケーションとTiDBクラスタの状態を観察します。`sysbench`は安定して動作しています。 ```output [ 1039s ] thds: 6 tps: 268.99 qps: 5409.79 (r/w/o: 3787.85/1067.96/553.98) lat (ms,95%): 27.17 err/s: 0.00 reconn/s: 0.00 [ 1040s ] thds: 6 tps: 273.01 qps: 5455.15 (r/w/o: 3814.11/1083.03/558.02) lat (ms,95%): 28.16 err/s: 0.00 reconn/s: 0.00 [ 1041s ] thds: 6 tps: 265.00 qps: 5282.95 (r/w/o: 3702.96/1043.99/535.99) lat (ms,95%): 30.26 err/s: 0.00 reconn/s: 0.00 ... [ 1105s ] thds: 6 tps: 260.00 qps: 5244.02 (r/w/o: 3669.02/1043.00/532.00) lat (ms,95%): 29.72 err/s: 0.00 reconn/s: 0.00 [ 1106s ] thds: 6 tps: 267.99 qps: 5339.86 (r/w/o: 3740.90/1052.97/545.99) lat (ms,95%): 27.17 err/s: 0.00 reconn/s: 0.00 ``` + TiDBクラスタの状態を確認します。DC2内のすべてのノードは再びオンラインになります。手順を迅速に進行すると、いくつかのTiKVノードの状態が`Disconnected`から`Up`に徐々に変わるのを観察するかもしれません。 ```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.92.147.161:2379/dashboard Grafana URL: http://10.90.1.212:3000,http://10.90.2.99:3000 ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.90.1.212:3000 grafana 10.90.1.212 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000 10.90.2.99:3000 grafana 10.90.2.99 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000 10.90.1.156:2379 pd 10.90.1.156 2379/2380 linux/x86_64 Up /tidb-data/pd_data /tidb-deploy/pd-2379 10.90.1.232:2379 pd 10.90.1.232 2379/2380 linux/x86_64 Up|L /tidb-data/pd_data /tidb-deploy/pd-2379 10.90.2.104:2379 pd 10.90.2.104 2379/2380 linux/x86_64 Up /tidb-data/pd_data /tidb-deploy/pd-2379 10.90.1.212:10090 prometheus 10.90.1.212 10090/12020 linux/x86_64 Up /tidb-data/prometheus_data /tidb-deploy/prometheus-10090 10.90.2.99:10090 prometheus 10.90.2.99 10090/12020 linux/x86_64 Up /tidb-data/prometheus_data /tidb-deploy/prometheus-10090 10.90.1.23:4000 tidb 10.90.1.23 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.2.122:4000 tidb 10.90.2.122 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.1.178:20160 tikv 10.90.1.178 20160/20180 linux/x86_64 Up /tidb-data/tikv_data /tidb-deploy/tikv-20160 10.90.1.6:20160 tikv 10.90.1.6 20160/20180 linux/x86_64 Up /tidb-data/tikv_data /tidb-deploy/tikv-20160 10.90.2.250:20160 tikv 10.90.2.250 20160/20180 linux/x86_64 Disconnected /tidb-data/tikv_data /tidb-deploy/tikv-20160 10.90.2.90:20160 tikv 10.90.2.90 20160/20180 linux/x86_64 Up /tidb-data/tikv_data /tidb-deploy/tikv-20160 Total nodes: 13 ``` ```output ... ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.90.2.250:20160 tikv 10.90.2.250 20160/20180 linux/x86_64 Up /tidb-data/tikv_data /tidb-deploy/tikv-20160 ... ``` + 現在のTiDBクラスタのレプリケーション状態を確認します。わずか数秒で状態が`sync_recover`から`sync`に切り替わります。 ![60%](https://lab-static.pingcap.com/quick-demo/demo-303-6-en.png) + `sync_recover`モード。 ```bash curl ${HOST_AZ1PD1_PRIVATE_IP}:2379/pd/api/v1/replication_mode/status ``` ```output { "mode": "dr-auto-sync", "dr-auto-sync": { "label_key": "dc", "state": "sync_recover", "state_id": 1009, "acid_consistent": false, "total_regions": 78, "recover_progress": 0.08974359 } } ``` + `sync`モード。 ```bash curl ${HOST_AZ1PD1_PRIVATE_IP}:2379/pd/api/v1/replication_mode/status ``` ```output { "mode": "dr-auto-sync", "dr-auto-sync": { "label_key": "dc", "state": "sync", "state_id": 1010, "acid_consistent": true } } ``` ![60%](https://lab-static.pingcap.com/quick-demo/demo-303-61-en.png) + この時点で、TiDBは2つのデータセンター間のデータ同期をSYNC状態に復元し、データセンター故障に対するRPO=0の高い耐障害性を達成します。 ### 手順 7. `sysbench` ワークロードを停止します + ターミナル1とターミナル2に切り替え、sysbenchスレッドを終了してターミナルを閉じます。 ### モジュール 2のまとめ + 上記の手順を通じて、TiDBが完全なDC2の故障とその高可用性への復旧を処理する過程全体をシミュレーションしました。 + DC2が利用不可になると、TiDBは故障を確認するためにブロッキングウィンドウに入ります。このブロッキングウィンドウ中、データベースへのアプリケーションの読み書き操作は影響を受けます。 + ブロッキングウィンドウを超えると、TiDBはDC1内のノードのみを使用して動作し、`async`状態に移行します。この時点で、アプリケーションの読み書き操作は正常に戻ります。 + DC2が障害から復旧すると、TiDBは`sync_recover`状態に入り、DC1内のノードからDC2内のノードにデータを同期します。このプロセスは、アプリケーションアクセスのためのデータベースの可用性には影響しません。 + データ同期が完了すると、TiDBクラスタは`sync`モードに戻ります。 ## モジュール 3: DC1 の全ノードを停止してプライマリ DC の障害をシミュレートする この演習の目的は、プライマリデータセンターの完全な利用不可をシミュレートし、その可用性をどのように回復するかを確認することです。 DC1 が完全に障害を起こした時、DC2 はフォロワーの TiKV インスタンスに最新のデータを保持しています。バックアップ用のラーナー TiKV インスタンスと共に、2つのレプリカクラスタがすぐに復元され、サービスを再開することができます。 ![60%](https://lab-static.pingcap.com/quick-demo/demo-303-7-en.png) 災害復旧データセンターの Placement Driver を通じて新しい TiDB クラスタを開始する必要があります（データは保持されるが、新しい クラスタID を持ちます）。さらに、PD ノードをスケールアウトし（事前に予約されたスタンバイの PD ノード）、災害復旧データセンターのラーナー TiKV ノードを投票権を持つ TiKV に変換し、他の TiKV ノードと共に機能的な Raft グループを形成する必要があります。 ### 手順 1. DC1 のモニターサーバーに接続します + ローカルのターミナル（ターミナル1）を開き、モニターサーバー1に接続します。 + **macOS** ユーザー： ```bash ssh -i ~/.ssh/pe-class-key-oregon.pem ec2-user@az1monitor1_address ``` + **Windows 10** ユーザー： ```cmd ssh -i %userprofile%\.ssh\pe-class-key-oregon.pem ec2-user@az1monitor1_address ``` ```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. ワークロードを開始します + DC1 および DC2 の両方で `sysbench` を起動し、アプリケーションの実行として機能させます。このタスクは 60 分間動作します。 + DC1 で `sysbench` ワークロードを開始します。 ```bash sysbench --config-file=sysbench_config oltp_read_write --tables=6 --mysql-ignore-errors=all run ``` ```output sysbench 1.0.17 (using bundled LuaJIT 2.1.0-beta2) Running the test with following options: Number of threads: 1 Report intermediate results every 1 second(s) Initializing random number generator from current time Initializing worker threads... Threads started! [ 1s ] thds: 1 tps: 61.90 qps: 1240.90 (r/w/o: 868.53/247.58/124.79) lat (ms,95%): 18.28 err/s: 0.00 reconn/s: 0.00 [ 2s ] thds: 1 tps: 58.02 qps: 1176.46 (r/w/o: 824.32/236.09/116.04) lat (ms,95%): 18.28 err/s: 0.00 reconn/s: 0.00 ... ``` + 新しいローカルターミナル（ターミナル2）を開いて、モニターサーバー2に接続します。DC2で `sysbench` ワークロードを開始します。 ```bash ssh -i ~/.ssh/pe-class-key-oregon.pem ec2-user@az2monitor1_address ``` ```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/ ``` + DC2 の `sysbench` 設定をセットアップします。 ```bash cat << EOF > sysbench_config mysql-host=${HOST_AZ2DB1_PRIVATE_IP} mysql-port=4000 mysql-user=root mysql-password= mysql-db=sbtest time=3600 threads=6 report-interval=1 EOF cat sysbench_config ``` ```output mysql-host=10.90.2.125 mysql-port=4000 mysql-user=root mysql-password= mysql-db=sbtest time=3600 threads=16 report-interval=1 ``` + DC2 で `sysbench` ワークロードを開始します。 ```bash sysbench --config-file=sysbench_config oltp_read_write --tables=6 --mysql-ignore-errors=all run ``` ```output Threads started! [ 1s ] thds: 6 tps: 316.47 qps: 6401.24 (r/w/o: 4486.46/1158.05/756.73) lat (ms,95%): 23.10 err/s: 0.00 reconn/s: 0.00 [ 2s ] thds: 6 tps: 330.09 qps: 6611.89 (r/w/o: 4631.33/1171.34/809.23) lat (ms,95%): 22.69 err/s: 0.00 reconn/s: 0.00 ... ``` ### 手順 3. レプリケーション状態が同期していることを確認します 新しいターミナル（ターミナル3）を開きます。DC2のモニターサーバー2にログインして、データレプリケーションの状態が `sync` モードであることを確認します。 + モニター2にログイン。 ```bash ssh -i ~/.ssh/pe-class-key-oregon.pem ec2-user@az2monitor1_address ``` ```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/ ``` + データのレプリケーション状態を確認します。 ```bash curl ${HOST_AZ1PD1_PRIVATE_IP}:2379/pd/api/v1/replication_mode/status ``` ```output { "mode": "dr-auto-sync", "dr-auto-sync": { "label_key": "dc", "state": "sync", "state_id": 1006, "acid_consistent": true } } ``` ### 手順 4. プライマリデータセンターの完全な障害をシミュレーションします + TiDB クラスタのノード上のすべての TiDB プロセスを停止することで、プライマリデータセンターの完全な障害をシミュレーションします。注意: アプリケーションは生きたままにして、TiDB クラスタのアクセス可能性を観察します。 + DC1 にある各 TiDB、TiKV、および PD ノードのプロセスを終了し、データディレクトリを削除します。プロンプトが表示された場合は `yes` で応答します。 ```bash ssh -i ~/.ssh/pe-class-key-oregon.pem ec2-user@${HOST_AZ1DB1_PRIVATE_IP} "sudo systemctl stop tidb-4000.service; sudo systemctl stop node_exporter-9100.service; sudo systemctl stop blackbox_exporter-9115.service; sudo rm -rf /tidb-deploy/; sudo rm -rf /tidb-data;" ``` ```bash ssh -i ~/.ssh/pe-class-key-oregon.pem ec2-user@${HOST_AZ1KV1_PRIVATE_IP} "sudo systemctl stop tikv-20160.service; sudo systemctl stop node_exporter-9100.service; sudo systemctl stop blackbox_exporter-9115.service; sudo rm -rf /tidb-deploy/; sudo rm -rf /tidb-data;" ``` ```bash ssh -i ~/.ssh/pe-class-key-oregon.pem ec2-user@${HOST_AZ1KV2_PRIVATE_IP} "sudo systemctl stop tikv-20160.service; sudo systemctl stop node_exporter-9100.service; sudo systemctl stop blackbox_exporter-9115.service; sudo rm -rf /tidb-deploy/; sudo rm -rf /tidb-data;" ``` ```bash ssh -i ~/.ssh/pe-class-key-oregon.pem ec2-user@${HOST_AZ1PD1_PRIVATE_IP} "sudo systemctl stop pd-2379.service; sudo systemctl stop node_exporter-9100.service; sudo systemctl stop blackbox_exporter-9115.service; sudo rm -rf /tidb-deploy/; sudo rm -rf /tidb-data;" ``` ```bash ssh -i ~/.ssh/pe-class-key-oregon.pem ec2-user@${HOST_AZ1PD2_PRIVATE_IP} "sudo systemctl stop pd-2379.service; sudo systemctl stop node_exporter-9100.service; sudo systemctl stop blackbox_exporter-9115.service; sudo rm -rf /tidb-deploy/; sudo rm -rf /tidb-data;" ``` + 監視のプロセスを終了し、データディレクトリを削除します。 ```bash ssh -i ~/.ssh/pe-class-key-oregon.pem ec2-user@${HOST_AZ1MONITOR1_PRIVATE_IP} "sudo systemctl stop prometheus-10090.service; sudo systemctl stop grafana-3000.service; sudo systemctl stop node_exporter-9100.service; sudo systemctl stop blackbox_exporter-9115.service; sudo rm -rf /tidb-deploy/; sudo rm -rf /tidb-data;" ``` ### 手順 5. アプリケーションと TiDB のステータスを観察します + TiDB クラスタ内のノードのステータスを観察します。すべての PD サーバーのステータスは `Down`、すべての TiKV サーバーは `N/A`、そして TiDB サーバーの1つは `Down` です。DC2 に配置されている TiDB サーバーのみが稼働しています。 ```bash tiup cluster display tidb-demo ``` ```output A new version of cluster is available: v1.15.1 -> v1.16.1 To update this component: tiup update cluster To update all components: tiup update --all Cluster type: tidb Cluster name: tidb-demo Cluster version: vtidb_version Deploy user: ec2-user SSH type: builtin Grafana URL: http://10.90.1.182:3000,http://10.90.2.252:3000 ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.90.1.182:3000 grafana 10.90.1.182 3000 linux/x86_64 Down - /tidb-deploy/grafana-3000 10.90.2.252:3000 grafana 10.90.2.252 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000 10.90.1.213:2379 pd 10.90.1.213 2379/2380 linux/x86_64 Down /tidb-data/pd_data /tidb-deploy/pd-2379 10.90.1.90:2379 pd 10.90.1.90 2379/2380 linux/x86_64 Down /tidb-data/pd_data /tidb-deploy/pd-2379 10.90.2.65:2379 pd 10.90.2.65 2379/2380 linux/x86_64 Down /tidb-data/pd_data /tidb-deploy/pd-2379 10.90.1.182:10090 prometheus 10.90.1.182 10090/12020 linux/x86_64 Down /tidb-data/prometheus_data /tidb-deploy/prometheus-10090 10.90.2.252:10090 prometheus 10.90.2.252 10090/12020 linux/x86_64 Up /tidb-data/prometheus_data /tidb-deploy/prometheus-10090 10.90.1.196:4000 tidb 10.90.1.196 4000/10080 linux/x86_64 Down - /tidb-deploy/tidb-4000 10.90.2.226:4000 tidb 10.90.2.226 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.1.228:20160 tikv 10.90.1.228 20160/20180 linux/x86_64 N/A /tidb-data/tikv_data /tidb-deploy/tikv-20160 10.90.1.91:20160 tikv 10.90.1.91 20160/20180 linux/x86_64 N/A /tidb-data/tikv_data /tidb-deploy/tikv-20160 10.90.2.202:20160 tikv 10.90.2.202 20160/20180 linux/x86_64 N/A /tidb-data/tikv_data /tidb-deploy/tikv-20160 10.90.2.206:20160 tikv 10.90.2.206 20160/20180 linux/x86_64 N/A /tidb-data/tikv_data /tidb-deploy/tikv-20160 Total nodes: 13 ``` + TiDB の同期モードを観察します。DC1 にある PD リーダーにアクセスできないため、DC2 にあるフォロアー PD にアクセスする必要があります。しかし、リーダーへのリダイレクトができないため、操作はタイムアウトします。 ```bash curl ${HOST_AZ2PD1_PRIVATE_IP}:2379/pd/api/v1/replication_mode/status ``` ```output [PD:apiutil:ErrRedirectNoLeader]redirect finds no leader ``` + ターミナル1に切り替えます。TiDB クラスタが利用不可になったため、QPS が 0 になったことが確認できます。 ```output ... [ 57s ] thds: 6 tps: 193.99 qps: 3834.86 (r/w/o: 2679.90/665.98/488.98) lat (ms,95%): 28.67 err/s: 0.00 reconn/s: 0.00 [ 58s ] thds: 6 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s: 0.00 reconn/s: 0.00 [ 59s ] thds: 6 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s: 0.00 reconn/s: 0.00 ... ``` + ターミナル2に切り替えます。TiDB クラスタが利用不可になったため、QPS が 0 になったことが確認できます。 ```output ... [ 34s ] thds: 6 tps: 116.00 qps: 2313.99 (r/w/o: 1624.99/385.00/304.00) lat (ms,95%): 28.67 err/s: 0.00 reconn/s: 0.00 [ 35s ] thds: 6 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s: 0.00 reconn/s: 0.00 [ 36s ] thds: 6 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s: 0.00 reconn/s: 0.00 ... ``` ### 手順 6. 生存しているノードのみを使用して TiDB クラスタを再形成します + ターミナル3に切り替えて、用意されたメタファイルを使用して `tiup` のメタファイルを上書きします。このメタファイルにはデータセンター2（AZ2）のノードのみが含まれています。 + 上書きする前にメタファイルをバックアップします。 ```bash cp /home/ec2-user/.tiup/storage/cluster/clusters/tidb-demo/meta.yaml /home/ec2-user/.tiup/storage/cluster/clusters/tidb-demo/meta.yaml.backup ``` + yamlファイル `majority-DC2.yaml` をチェックします。 ```bash cat majority-DC2.yaml ``` ```output user: ec2-user tidb_version: vtidb_version topology: global: user: "ec2-user" ssh_port: 22 deploy_dir: "/tidb-deploy" data_dir: "/tidb-data" arch: "amd64" monitored: node_exporter_port: 9100 blackbox_exporter_port: 9115 deploy_dir: "/tidb-deploy/monitored-9100" data_dir: "/tidb-data/monitor_9115" log_dir: "/tidb-deploy/monitor-9100/log" server_configs: pd: replication.location-labels: ["dc","logic","rack","host"] tidb_servers: - host: 10.90.2.210 port: 4000 status_port: 10080 deploy_dir: "/tidb-deploy/tidb-4000" log_dir: "/tidb-deploy/tidb-4000/log" tikv_servers: - host: 10.90.2.111 port: 20160 status_port: 20180 deploy_dir: "/tidb-deploy/tikv-20160" data_dir: "/tidb-data/tikv_data" config: server.labels: { dc: "dc2",logic: "logic3",rack: "r1",host: "10.90.2.111" } - host: 10.90.2.91 port: 20160 status_port: 20180 deploy_dir: "/tidb-deploy/tikv-20160" data_dir: "/tidb-data/tikv_data" config: server.labels: { dc: "dc2",logic: "logic4",rack: "r1",host: "10.90.2.91" } pd_servers: - host: 10.90.2.83 client_port: 2379 peer_port: 2380 deploy_dir: "/tidb-deploy/pd-2379" data_dir: "/tidb-data/pd_data" advertise_client_addr: "http://54.212.25.205:2379" monitoring_servers: - host: 10.90.2.107 port: 10090 deploy_dir: "/tidb-deploy/prometheus-10090" data_dir: "/tidb-data/prometheus_data" grafana_servers: - host: 10.90.2.107 port: 3000 deploy_dir: "/tidb-deploy/grafana-3000" ``` + プロビジョンファイルを使用してメタファイルを置き換えます。 ```bash cp -rf majority-DC2.yaml /home/ec2-user/.tiup/storage/cluster/clusters/tidb-demo/meta.yaml ``` ### 手順 7. TiDB クラスタを停止する + TiDBクラスタのステータスを確認します。 ```bash tiup cluster display tidb-demo ``` ```output ... ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.90.2.14:3000 grafana 10.90.2.14 3000 / Up - /tidb-deploy/grafana-3000 10.90.2.53:2379 pd 10.90.2.53 2379/2380 / Down /tidb-data/pd_data /tidb-deploy/pd-2379 10.90.2.14:10090 prometheus 10.90.2.14 10090 / Up /tidb-data/prometheus_data /tidb-deploy/prometheus-10090 10.90.2.97:4000 tidb 10.90.2.97 4000/10080 / Up - /tidb-deploy/tidb-4000 10.90.2.170:20160 tikv 10.90.2.170 20160/20180 / N/A /tidb-data/tikv_data /tidb-deploy/tikv-20160 10.90.2.78:20160 tikv 10.90.2.78 20160/20180 / N/A /tidb-data/tikv_data /tidb-deploy/tikv-20160 Total nodes: 6 ``` + TiDBクラスタのノードを停止します。 ```bash tiup cluster stop tidb-demo -y ``` ```output ... Stopping component grafana Stopping instance 10.90.2.14 Stop grafana 10.90.2.14:3000 success Stopping component prometheus Stopping instance 10.90.2.14 Stop prometheus 10.90.2.14:10090 success Stopping component tidb Stopping instance 10.90.2.97 Stop tidb 10.90.2.97:4000 success Stopping component tikv Stopping instance 10.90.2.170 Stopping instance 10.90.2.78 Stop tikv 10.90.2.170:20160 success Stop tikv 10.90.2.78:20160 success Stopping component pd Stopping instance 10.90.2.53 Stop pd 10.90.2.53:2379 success Stopping component node_exporter Stopping instance 10.90.2.170 Stopping instance 10.90.2.14 Stopping instance 10.90.2.53 Stopping instance 10.90.2.97 Stopping instance 10.90.2.78 Stop 10.90.2.170 success Stop 10.90.2.78 success Stop 10.90.2.53 success Stop 10.90.2.97 success Stop 10.90.2.14 success Stopping component blackbox_exporter Stopping instance 10.90.2.170 Stopping instance 10.90.2.14 Stopping instance 10.90.2.97 Stopping instance 10.90.2.78 Stopping instance 10.90.2.53 Stop 10.90.2.78 success Stop 10.90.2.170 success Stop 10.90.2.97 success Stop 10.90.2.53 success Stop 10.90.2.14 success Stopped cluster `tidb-demo` successfully ``` + TiDBノードのステータスを確認し、すべてのpd, tidb, tikv, およびprometheusがダウンしていることを確認します。 ```bash tiup cluster display tidb-demo ``` ```output ... ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.90.2.82:3000 grafana 10.90.2.82 3000 linux/x86_64 Down - /tidb-deploy/grafana-3000 10.90.2.125:2379 pd 10.90.2.125 2379/2380 linux/x86_64 Down /tidb-data/pd_data /tidb-deploy/pd-2379 10.90.2.82:10090 prometheus 10.90.2.82 10090/12020 linux/x86_64 Down /tidb-data/prometheus_data /tidb-deploy/prometheus-10090 10.90.2.173:4000 tidb 10.90.2.173 4000/10080 linux/x86_64 Down - /tidb-deploy/tidb-4000 10.90.2.129:20160 tikv 10.90.2.129 20160/20180 linux/x86_64 N/A /tidb-data/tikv_data /tidb-deploy/tikv-20160 10.90.2.216:20160 tikv 10.90.2.216 20160/20180 linux/x86_64 N/A /tidb-data/tikv_data /tidb-deploy/tikv-20160 Total nodes: 6 ``` ### 手順 8. Placement Driver を復元する + pd-recover ツールをインストールします。 ```bash tiup install pd-recover:vtidb_version ``` ```output download https://tiup-mirrors.pingcap.com/pd-recover-vtidb_version-darwin-arm64.tar.gz 13.88 MiB / 13.88 MiB 100.00% 6.99 MiB/s ``` + 配置ドライバーサーバーにSSHでアクセスし、DC2に配置されている新しい配置ドライバークラスタを強制的に開始します。 + PD にログインします。プロンプトが表示されたら、`yes`と入力します。 ```bash ssh -i ~/.ssh/pe-class-key-oregon.pem ec2-user@${HOST_AZ2PD1_PRIVATE_IP} ``` ```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/ ``` + DC1が失われる前のTiDBクラスタの同期モードであるpdのステータスを確認し、現在のTiDBのデータ一貫性を示します。 ```bash cat /tidb-data/pd_data/DR_STATE ``` ```output {"state":"sync","state_id":1947} ``` + pdの初期スクリプトを修正し、`--force-new-cluster`パラメータを追加します。このパラメータはpdの新しいetcdクラスタを開始するために使用されます。 ```bash sed -i '/pd-server/ s#pd-server#pd-server --force-new-cluster#' /tidb-deploy/pd-2379/scripts/run_pd.sh ``` + モニターOSからログアウトします。 ```bash exit ``` ```output logout Connection to 10.90.2.26 closed. ``` + PD ノードを開始してクラスタを始動します。 ```bash tiup cluster start tidb-demo -N ${HOST_AZ2PD1_PRIVATE_IP}:2379 -y ``` ```output ... Starting cluster tidb-demo... + [ Serial ] - SSHKeySet: privateKey=/home/ec2-user/.tiup/storage/cluster/clusters/tidb-demo/ssh/id_rsa, publicKey=/home/ec2-user/.tiup/storage/cluster/clusters/tidb-demo/ssh/id_rsa.pub + [Parallel] - UserSSH: user=ec2-user, host=10.90.2.38 + [Parallel] - UserSSH: user=ec2-user, host=10.90.2.26 + [Parallel] - UserSSH: user=ec2-user, host=10.90.2.38 + [Parallel] - UserSSH: user=ec2-user, host=10.90.2.254 + [Parallel] - UserSSH: user=ec2-user, host=10.90.2.182 + [Parallel] - UserSSH: user=ec2-user, host=10.90.2.49 + [ Serial ] - StartCluster Starting component pd Starting instance 10.90.2.26:2379 Start instance 10.90.2.26:2379 success Starting component node_exporter Starting instance 10.90.2.26 Start 10.90.2.26 success Starting component blackbox_exporter Starting instance 10.90.2.26 Start 10.90.2.26 success + [ Serial ] - UpdateTopology: cluster=tidb-demo Started cluster `tidb-demo` successfully ``` + PD が起動していることを確認します。 ```bash tiup cluster display tidb-demo ``` ```output A new version of cluster is available: v1.15.1 -> v1.16.1 To update this component: tiup update cluster To update all components: tiup update --all Cluster type: tidb Cluster name: tidb-demo Cluster version: vtidb_version Deploy user: ec2-user SSH type: builtin Dashboard URL: http://35.94.179.113:2379/dashboard Grafana URL: http://10.90.2.82:3000 ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.90.2.107:3000 grafana 10.90.2.107 3000 / Down - /tidb-deploy/grafana-3000 10.90.2.83:2379 pd 10.90.2.83 2379/2380 / Up|L /tidb-data/pd_data /tidb-deploy/pd-2379 10.90.2.107:10090 prometheus 10.90.2.107 10090 / Down /tidb-data/prometheus_data /tidb-deploy/prometheus-10090 10.90.2.210:4000 tidb 10.90.2.210 4000/10080 / Down - /tidb-deploy/tidb-4000 10.90.2.111:20160 tikv 10.90.2.111 20160/20180 / Disconnected /tidb-data/tikv_data /tidb-deploy/tikv-20160 10.90.2.91:20160 tikv 10.90.2.91 20160/20180 / Disconnected /tidb-data/tikv_data /tidb-deploy/tikv-20160 Total nodes: 6 ``` + PD のメタデータを修正します。このステップの後、ストレージの`alloc_id`は自動的に`100000000`の安全な値まで増加します。 ```bash tiup pd-recover:vtidb_version --from-old-member --endpoints=http://${HOST_AZ2PD1_PRIVATE_IP}:2379 ``` ```output download https://tiup-mirrors.pingcap.com/pd-recover-vtidb_version-linux-amd64.tar.gz 15.87 MiB / 15.87 MiB 100.00% 3.78 MiB/s Checking updates for component pd-recover... Starting component pd-recover: /home/ec2-user/.tiup/components/pd-recover/v8.5.0/pd-recover --from-old-member --endpoints=http://10.90.2.31:2379 recover success! please restart the PD cluster ``` ### 手順 9. 新しい Placement Driver サーバーを1つスケールアウトする + yamlファイルを確認します。 ```bash cat scale-out-pd.yaml ``` ```output pd_servers: - host: 10.90.2.102 client_port: 2379 peer_port: 2380 deploy_dir: "/tidb-deploy/pd-2379" data_dir: "/tidb-data/pd_data" advertise_client_addr: "http://35.161.129.28:2379" ``` + PD ノードをスケールアウトします。 ```bash tiup cluster scale-out tidb-demo scale-out-pd.yaml --user ec2-user -i ~/.ssh/pe-class-key-oregon.pem -y ``` ```output ... Starting component pd Starting instance 10.90.2.102:2379 Start instance 10.90.2.102:2379 success Starting component node_exporter Starting instance 10.90.2.102 Start 10.90.2.102 success Starting component blackbox_exporter Starting instance 10.90.2.102 Start 10.90.2.102 success + Refresh components conifgs - Generate config pd -> 10.90.2.26:2379 ... Done - Generate config pd -> 10.90.2.102:2379 ... Done - Generate config tikv -> 10.90.2.254:20160 ... Done - Generate config tikv -> 10.90.2.182:20160 ... Done - Generate config tidb -> 10.90.2.49:4000 ... Done - Generate config prometheus -> 10.90.2.38:10090 ... Done - Generate config grafana -> 10.90.2.38:3000 ... Done + Reload prometheus and grafana - Reload prometheus -> 10.90.2.38:10090 ... Done - Reload grafana -> 10.90.2.38:3000 ... Done + [ Serial ] - UpdateTopology: cluster=tidb-demo Scaled cluster `tidb-demo` out successfully ``` + DC2の2つのpdノードがすべて起動していることを確認します。 ```bash tiup cluster display tidb-demo ``` ```output A new version of cluster is available: v1.15.1 -> v1.16.1 To update this component: tiup update cluster To update all components: tiup update --all Cluster type: tidb Cluster name: tidb-demo Cluster version: vtidb_version Deploy user: ec2-user SSH type: builtin Dashboard URL: http://35.94.179.113:2379/dashboard Grafana URL: http://10.90.2.82:3000 ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.90.2.107:3000 grafana 10.90.2.107 3000 / Up - /tidb-deploy/grafana-3000 10.90.2.83:2379 pd 10.90.2.83 2379/2380 / Up|L /tidb-data/pd_data /tidb-deploy/pd-2379 10.90.2.96:2379 pd 10.90.2.96 2379/2380 linux/x86_64 Up /tidb-data/pd_data /tidb-deploy/pd-2379 10.90.2.107:10090 prometheus 10.90.2.107 10090 / Down /tidb-data/prometheus_data /tidb-deploy/prometheus-10090 10.90.2.210:4000 tidb 10.90.2.210 4000/10080 / Down - /tidb-deploy/tidb-4000 10.90.2.111:20160 tikv 10.90.2.111 20160/20180 / Disconnected /tidb-data/tikv_data /tidb-deploy/tikv-20160 10.90.2.91:20160 tikv 10.90.2.91 20160/20180 / Disconnected /tidb-data/tikv_data /tidb-deploy/tikv-20160 Total nodes: 7 ``` ### 手順 10. クラスタを `majority` モードに設定する + クラスタが依然として`dr-auto-sync`レプリケーションモードにあることを確認します。 ```bash tiup ctl:vtidb_version pd -u ${HOST_AZ2PD1_PRIVATE_IP}:2379 config show replication-mode ``` ```output The component `ctl` version vtidb_version is not installed; downloading from repository. download https://tiup-mirrors.pingcap.com/ctl-vtidb_version-linux-amd64.tar.gz 408.65 MiB / 408.65 MiB 100.00% 97.75 MiB/s Starting component ctl: /home/ec2-user/.tiup/components/ctl/vtidb_version/ctl pd -u 10.90.2.83:2379 config show replication-mode { "replication-mode": "dr-auto-sync", "dr-auto-sync": { "label-key": "dc", "primary": "dc1", "dr": "dc2", "primary-replicas": 2, "dr-replicas": 1, "wait-store-timeout": "1m0s", "wait-recover-timeout": "0s", "pause-region-split": "false" } } ``` + `majority`ルールファイルを確認します。 ```bash cat majority-rules.json ``` ```output [ { "group_id": "pd", "group_index": 0, "group_override": false, "rules": [ { "group_id": "pd", "id": "voters", "start_key": "", "end_key": "", "role": "voter", "count": 3, "location_labels": ["dc","logic","rack", "host"] } ] } ] ``` + `majority`配置ルール構成をロードします。 ```bash tiup ctl:vtidb_version pd config placement-rules rule-bundle -u ${HOST_AZ2PD1_PRIVATE_IP}:2379 save --in="/home/ec2-user/majority-rules.json" ``` ```output Starting component ctl: /home/ec2-user/.tiup/components/ctl/vtidb_version/ctl pd config placement-rules rule-bundle -u http://10.90.2.162:2379 save --in=/home/ec2-user/majority-rules.json "Update rules and groups successfully." ``` + 配置ルールがロードされていることを確認します。 ```bash tiup ctl:vtidb_version pd config placement-rules show -u ${HOST_AZ2PD1_PRIVATE_IP}:2379 ``` ```output Starting component ctl: /home/ec2-user/.tiup/components/ctl/vtidb_version/ctl pd config placement-rules show -u 10.90.2.125:2379 [ { "group_id": "pd", "id": "voters", "start_key": "", "end_key": "", "role": "voter", "is_witness": false, "count": 3, "location_labels": [ "dc", "logic", "rack", "host" ], "create_timestamp": 1734071450 } ] ``` + `majority`設定を有効にします。 ```bash tiup ctl:vtidb_version pd -u ${HOST_AZ2PD1_PRIVATE_IP}:2379 config set replication-mode majority tiup ctl:vtidb_version pd -u ${HOST_AZ2PD1_PRIVATE_IP}:2379 config set max-replicas 3 ``` ```output Starting component ctl: /home/ec2-user/.tiup/components/ctl/vtidb_version/ctl pd -u 10.90.2.125:2379 config set replication-mode majority Success! The replication mode config is updated." Starting component ctl: /home/ec2-user/.tiup/components/ctl/vtidb_version/ctl pd -u 10.90.2.125:2379 config set max-replicas 3 Success! ``` + クラスタの`majority`レプリケーションモードが有効であることを確認します。 ```bash tiup ctl:vtidb_version pd -u ${HOST_AZ2PD1_PRIVATE_IP}:2379 config show replication-mode ``` ```output Starting component ctl: /home/ec2-user/.tiup/components/ctl/vtidb_version/ctl pd -u 10.90.2.125:2379 config show replication-mode { "replication-mode": "majority", "dr-auto-sync": { "label-key": "dc", "primary": "dc1", "dr": "dc2", "primary-replicas": 2, "dr-replicas": 1, "wait-store-timeout": "1m0s", "wait-recover-timeout": "0s", "pause-region-split": "false" } } ``` ### 手順 11. 利用不可の TiKV ノードを削除します + TiKVノードを開始します。 ```bash tiup cluster start tidb-demo -R tikv -y ``` ```output ... Starting component tikv Starting instance 10.90.2.129:20160 Starting instance 10.90.2.216:20160 Start instance 10.90.2.216:20160 success Start instance 10.90.2.129:20160 success Starting component node_exporter Starting instance 10.90.2.129 Starting instance 10.90.2.216 Start 10.90.2.216 success Start 10.90.2.129 success Starting component blackbox_exporter Starting instance 10.90.2.129 Starting instance 10.90.2.216 Start 10.90.2.216 success Start 10.90.2.129 success + [ Serial ] - UpdateTopology: cluster=tidb-demo Started cluster `tidb-demo` successfully ... ``` + 2つのTiKVノードが起動するのを待ちます。 ```bash tiup cluster display tidb-demo ``` ```output ... ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.90.2.82:3000 grafana 10.90.2.82 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000 10.90.2.125:2379 pd 10.90.2.125 2379/2380 linux/x86_64 Up|L /tidb-data/pd_data /tidb-deploy/pd-2379 10.90.2.135:2379 pd 10.90.2.135 2379/2380 linux/x86_64 Up /tidb-data/pd_data /tidb-deploy/pd-2379 10.90.2.82:10090 prometheus 10.90.2.82 10090/12020 linux/x86_64 Down /tidb-data/prometheus_data /tidb-deploy/prometheus-10090 10.90.2.173:4000 tidb 10.90.2.173 4000/10080 linux/x86_64 Down - /tidb-deploy/tidb-4000 10.90.2.129:20160 tikv 10.90.2.129 20160/20180 linux/x86_64 Up /tidb-data/tikv_data /tidb-deploy/tikv-20160 10.90.2.216:20160 tikv 10.90.2.216 20160/20180 linux/x86_64 Up /tidb-data/tikv_data /tidb-deploy/tikv-20160 Total nodes: 7 ``` + DC1（AZ1）にあるTiKVストアのIDを取得します。ダウンまたは切断された状態のストアを2つ見つけます。次のステップのためにIDを記録します。 ```bash tiup ctl:vtidb_version pd -u ${HOST_AZ2PD1_PRIVATE_IP}:2379 store ``` ```output Starting component ctl: /home/ec2-user/.tiup/components/ctl/vtidb_version/ctl pd -u 10.90.2.125:2379 store { "count": 4, "stores": [ { "store": { "id": 16, ... "state_name": "Up" }, "status": { ... } }, { "store": { "id": 1, ... "state_name": "Up" }, "status": { ... } }, { "store": { "id": 2, ... "state_name": "Down" }, "status": { ... } }, { "store": { "id": 15, ... "state_name": "Down" }, "status": { ... } } ] } ``` + `state_name` が `Down` の場合、利用不可の TiKV ノードを削除します。コマンド内の n1 と n2 を、前のステップで記録したストア ID に置き換えてください。 ```bash tiup ctl:vtidb_version pd -u ${HOST_AZ2PD1_PRIVATE_IP}:2379 unsafe remove-failed-stores n1,n2 ``` ```output Starting component ctl: /home/ec2-user/.tiup/components/ctl/vtidb_version/ctl pd -u 10.90.2.125:2379 unsafe remove-failed-stores 2,15 Success! Request has been accepted. ``` + 削除操作の状態を表示します。しばらく後、次の説明を確認することでプロセスが完了したことを確認できます: "info": "Unsafe recovery Finished" コマンド結果の最後に表示されます。 ```bash tiup ctl:vtidb_version pd -u ${HOST_AZ2PD1_PRIVATE_IP}:2379 unsafe remove-failed-stores show ``` ```output Starting component ctl: /home/ec2-user/.tiup/components/ctl/vtidb_version/ctl pd -u 10.90.2.125:2379 unsafe remove-failed-stores show [ { "info": "Unsafe recovery enters collect report stage", "time": "2024-12-13 07:01:51.714", "details": [ "Failed stores 2, 15" ] }, { "info": "Unsafe recovery enters force leader stage", "time": "2024-12-13 07:01:54.000", "actions": { "store 1": [ "force leader on regions: 7, 9, 39, 41, 43, 45, 47, 49, 51, 53, 55, 57, 59, 61, 63, 65, 67, 69, 71, 101, 104, 107, 110, 113, 116, 119, 122, 125, 128, 131, 134, 137, 140, 143, 146, 149, 152, 155, 158, 209, 213, 217, 221, 225, 229, 233, 237, 241, 245, 249, 253, 1978, 2013, 2018, 1993, 2043, 2048, 1983, 2023, 2028, 1988, 2033, 2038, 1998, 2063, 2068, 2008, 2053, 2058, 35, 31, 27, 23, 19, 17, 11, 13, 3" ], "store 16": [ "force leader on regions: " ] } }, { "info": "Unsafe recovery enters demote Failed voter stage", "time": "2024-12-13 07:02:04.586", "actions": { "store 1": [ "region 7 demotes peers { id:75 store_id:2 }, { id:170 store_id:15 }", ... "region 3 demotes peers { id:77 store_id:2 }, { id:208 store_id:15 }" ] } }, { "info": "Unsafe recovery Finished", "time": "2024-12-13 07:02:14.002", "details": [ "affected table ids: 74, 94, 110, 24, 58, 78, 92, 107, 281474976710649, 56, 82, 84, 106, 108, 109, 281474976710652, 281474976710654, 52, 111, 50, 66, 281474976710653, 48, 98, 54, 38, 42, 46, 62, 72, 76, 6, 281474976710651, 86, 28, 30, 40, 68, 96, 20, 60, 4, 18, 34, 80, 12, 10, 32, 70, 8, 64, 22, 36, 88, 90, 102, 14, 26, 44, 281474976710650, 16", "no newly created empty regions" ] } ] ``` ### 手順 12. 回復した TiDB クラスタを起動します + TiDBとPrometheusインスタンスを開始します。 ```bash tiup cluster start tidb-demo -R tidb,prometheus -y ``` ```output Starting component tidb Starting instance 10.90.2.49:4000 Start instance 10.90.2.49:4000 success Starting component prometheus Starting instance 10.90.2.38:10090 Start instance 10.90.2.38:10090 success Starting component node_exporter Starting instance 10.90.2.38 Starting instance 10.90.2.49 Start 10.90.2.49 success Start 10.90.2.38 success Starting component blackbox_exporter Starting instance 10.90.2.38 Starting instance 10.90.2.49 Start 10.90.2.49 success Start 10.90.2.38 success + [ Serial ] - UpdateTopology: cluster=tidb-demo Started cluster `tidb-demo` successfully ``` + TiDBクラスタの状態を確認します。DC2内のすべてのノードの状態が「Up」であることを確認します。 ```bash tiup cluster display tidb-demo ``` ```output A new version of cluster is available: v1.15.1 -> v1.16.1 To update this component: tiup update cluster To update all components: tiup update --all Cluster type: tidb Cluster name: tidb-demo Cluster version: vtidb_version Deploy user: ec2-user SSH type: builtin Dashboard URL: http://35.94.179.113:2379/dashboard Grafana URL: http://10.90.2.82:3000 ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.90.2.82:3000 grafana 10.90.2.82 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000 10.90.2.125:2379 pd 10.90.2.125 2379/2380 linux/x86_64 Up|L /tidb-data/pd_data /tidb-deploy/pd-2379 10.90.2.135:2379 pd 10.90.2.135 2379/2380 linux/x86_64 Up /tidb-data/pd_data /tidb-deploy/pd-2379 10.90.2.82:10090 prometheus 10.90.2.82 10090/12020 linux/x86_64 Up /tidb-data/prometheus_data /tidb-deploy/prometheus-10090 10.90.2.173:4000 tidb 10.90.2.173 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.2.129:20160 tikv 10.90.2.129 20160/20180 linux/x86_64 Up /tidb-data/tikv_data /tidb-deploy/tikv-20160 10.90.2.216:20160 tikv 10.90.2.216 20160/20180 linux/x86_64 Up /tidb-data/tikv_data /tidb-deploy/tikv-20160 Total nodes: 7 ``` + TiDBクラスタのレプリケーションモードを確認します。 ```bash curl ${HOST_AZ2PD1_PRIVATE_IP}:2379/pd/api/v1/replication_mode/status ``` ```output { "mode": "majority", "dr-auto-sync": { "label_key": "", "state": "", "acid_consistent": false } } ``` ### 手順 13. `sysbench` ワークロードが回復していることを確認します + ターミナル1に切り替え、sysbenchワークロードのQPSが依然として0であることを確認します。これは、DC1にあるTiDBサーバーが利用不可であるためです。 ```output ... [ 1697s ] thds: 6 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s: 0.00 reconn/s: 0.00 [ 1698s ] thds: 6 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s: 0.00 reconn/s: 0.00 [ 1699s ] thds: 6 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s: 0.00 reconn/s: 0.00 ``` + ターミナル2に切り替え、sysbenchワークロードのQPSが正常に戻ったことを確認します。 ```output ... [ 1618s ] thds: 6 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s: 0.00 reconn/s: 0.00 [ 1619s ] thds: 6 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s: 0.00 reconn/s: 6.00 [ 1620s ] thds: 6 tps: 321.06 qps: 6505.17 (r/w/o: 4564.82/1103.20/837.15) lat (ms,95%): 23.10 err/s: 0.00 reconn/s: 0.00 [ 1621s ] thds: 6 tps: 313.95 qps: 6261.93 (r/w/o: 4378.25/1098.81/784.87) lat (ms,95%): 26.68 err/s: 0.00 reconn/s: 0.00 ``` ### 手順 14. 再度 DR Auto-Sync を有効にします + DC1が回復した後、TiDBクラスタをDR Auto-syncデプロイメントに戻す必要があります。 + 失われたノードを再びTiDBクラスタに参加させます。yamlファイルを確認してください。 ```bash cat scale-out-DC1.yaml ``` ```output tidb_servers: - host: 10.90.1.58 port: 4000 status_port: 10080 deploy_dir: "/tidb-deploy/tidb-4000" log_dir: "/tidb-deploy/tidb-4000/log" tikv_servers: - host: 10.90.1.219 port: 20160 status_port: 20180 deploy_dir: "/tidb-deploy/tikv-20160" data_dir: "/tidb-data/tikv_data" config: server.labels: { dc: "dc1",logic: "logic1",rack: "r1",host: "10.90.1.219" } - host: 10.90.1.71 port: 20160 status_port: 20180 deploy_dir: "/tidb-deploy/tikv-20160" data_dir: "/tidb-data/tikv_data" config: server.labels: { dc: "dc1",logic: "logic2",rack: "r1",host: "10.90.1.71" } pd_servers: - host: 10.90.1.95 client_port: 2379 peer_port: 2380 deploy_dir: "/tidb-deploy/pd-2379" data_dir: "/tidb-data/pd_data" advertise_client_addr: "http://34.214.79.226:2379" - host: 10.90.1.55 client_port: 2379 peer_port: 2380 deploy_dir: "/tidb-deploy/pd-2379" data_dir: "/tidb-data/pd_data" advertise_client_addr: "http://54.202.186.157:2379" monitoring_servers: - host: 10.90.1.221 port: 10090 deploy_dir: "/tidb-deploy/prometheus-10090" data_dir: "/tidb-data/prometheus_data" grafana_servers: - host: 10.90.1.221 port: 3000 deploy_dir: "/tidb-deploy/grafana-3000" ``` + DC1のノードをスケールアウトします。 ```bash tiup cluster scale-out tidb-demo scale-out-DC1.yaml --user ec2-user -i ~/.ssh/pe-class-key-oregon.pem -y ``` ```output ... Starting component pd Starting instance 10.90.1.95:2379 Start instance 10.90.1.95:2379 success Starting instance 10.90.1.55:2379 Start instance 10.90.1.55:2379 success Starting component tikv Starting instance 10.90.1.71:20160 Starting instance 10.90.1.219:20160 Start instance 10.90.1.71:20160 success Start instance 10.90.1.219:20160 success Starting component tidb Starting instance 10.90.1.58:4000 Start instance 10.90.1.58:4000 success Starting component prometheus Starting instance 10.90.1.221:10090 Start instance 10.90.1.221:10090 success Starting component grafana Starting instance 10.90.1.221:3000 Start instance 10.90.1.221:3000 success Starting component node_exporter Starting instance 10.90.1.55 Starting instance 10.90.1.58 Starting instance 10.90.1.221 Starting instance 10.90.1.95 Starting instance 10.90.1.219 Starting instance 10.90.1.71 Start 10.90.1.71 success Start 10.90.1.95 success Start 10.90.1.219 success Start 10.90.1.55 success Start 10.90.1.221 success Start 10.90.1.58 success Starting component blackbox_exporter Starting instance 10.90.1.55 Starting instance 10.90.1.58 Starting instance 10.90.1.221 Starting instance 10.90.1.95 Starting instance 10.90.1.219 Starting instance 10.90.1.71 Start 10.90.1.219 success Start 10.90.1.95 success Start 10.90.1.71 success Start 10.90.1.55 success Start 10.90.1.221 success Start 10.90.1.58 success + Refresh components conifgs - Generate config pd -> 10.90.2.83:2379 ... Done - Generate config pd -> 10.90.2.96:2379 ... Done - Generate config pd -> 10.90.1.95:2379 ... Done - Generate config pd -> 10.90.1.55:2379 ... Done - Generate config tikv -> 10.90.2.111:20160 ... Done - Generate config tikv -> 10.90.2.91:20160 ... Done - Generate config tikv -> 10.90.1.219:20160 ... Done - Generate config tikv -> 10.90.1.71:20160 ... Done - Generate config tidb -> 10.90.2.210:4000 ... Done - Generate config tidb -> 10.90.1.58:4000 ... Done - Generate config prometheus -> 10.90.2.107:10090 ... Done - Generate config prometheus -> 10.90.1.221:10090 ... Done - Generate config grafana -> 10.90.2.107:3000 ... Done - Generate config grafana -> 10.90.1.221:3000 ... Done + Reload prometheus and grafana - Reload prometheus -> 10.90.2.107:10090 ... Done - Reload grafana -> 10.90.2.107:3000 ... Done + [ Serial ] - UpdateTopology: cluster=tidb-demo Scaled cluster `tidb-demo` out successfully ``` + TiDBクラスタの状態を確認し、すべてのノードが回復していることを確認します。 ```bash tiup cluster display tidb-demo ``` ```output ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.90.1.221:3000 grafana 10.90.1.221 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000 10.90.2.107:3000 grafana 10.90.2.107 3000 / Up - /tidb-deploy/grafana-3000 10.90.1.55:2379 pd 10.90.1.55 2379/2380 linux/x86_64 Up /tidb-data/pd_data /tidb-deploy/pd-2379 10.90.1.95:2379 pd 10.90.1.95 2379/2380 linux/x86_64 Up /tidb-data/pd_data /tidb-deploy/pd-2379 10.90.2.83:2379 pd 10.90.2.83 2379/2380 / Up|L /tidb-data/pd_data /tidb-deploy/pd-2379 10.90.2.96:2379 pd 10.90.2.96 2379/2380 linux/x86_64 Up /tidb-data/pd_data /tidb-deploy/pd-2379 10.90.1.221:10090 prometheus 10.90.1.221 10090/12020 linux/x86_64 Up /tidb-data/prometheus_data /tidb-deploy/prometheus-10090 10.90.2.107:10090 prometheus 10.90.2.107 10090 / Up /tidb-data/prometheus_data /tidb-deploy/prometheus-10090 10.90.1.58:4000 tidb 10.90.1.58 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.2.210:4000 tidb 10.90.2.210 4000/10080 / Up - /tidb-deploy/tidb-4000 10.90.1.219:20160 tikv 10.90.1.219 20160/20180 linux/x86_64 Up /tidb-data/tikv_data /tidb-deploy/tikv-20160 10.90.1.71:20160 tikv 10.90.1.71 20160/20180 linux/x86_64 Up /tidb-data/tikv_data /tidb-deploy/tikv-20160 10.90.2.111:20160 tikv 10.90.2.111 20160/20180 / Up /tidb-data/tikv_data /tidb-deploy/tikv-20160 10.90.2.91:20160 tikv 10.90.2.91 20160/20180 / Up /tidb-data/tikv_data /tidb-deploy/tikv-20160 Total nodes: 14 ``` + DR Auto-Sync配置ルール設定をロードします。 ```bash tiup ctl:vtidb_version pd config placement-rules rule-bundle -u ${HOST_AZ2PD1_PRIVATE_IP}:2379 save --in="/home/ec2-user/dr-anto-sync-rules.json" ``` ```output The component `ctl` version vtidb_version is not installed; downloading from repository. download https://tiup-mirrors.pingcap.com/ctl-vtidb_version-linux-amd64.tar.gz 408.65 MiB / 408.65 MiB 100.00% 103.24 MiB/s Starting component ctl: /home/ec2-user/.tiup/components/ctl/vtidb_version/ctl pd config placement-rules rule-bundle -u http://10.90.2.162:2379 save --in=/home/ec2-user/dr-anto-sync-rules.json "Update rules and groups successfully." ``` + `jq`ツールをインストールします。 ```bash sudo yum install epel-release sudo yum install jq -y ``` ```output ... Installed: jq.x86_64 0:1.5-1.amzn2.0. 2 Dependency Installed: oniguruma.x86_64 0:5.9.6-1.amzn2.0. 7 Complete! ``` + Learner PeersのないTiKVリージョンを確認します。リージョンにLearner Peersがいないことを確認することで、各役割間のデータ同期が確保され、データが一貫してクラスター内で複製されていることを確認します。これは高可用性とフェイルオーバー準備を維持するために重要です。 ```bash tiup ctl:vtidb_version pd -u ${HOST_AZ2PD1_PRIVATE_IP}:2379 region --jq='.regions[] | select(.peers | any(.role_name=="Learner") | not) | {id: .id, peers: [.peers]}' ``` ```output Starting component ctl: /home/ec2-user/.tiup/components/ctl/vtidb_version/ctl pd -u http://34.215.73.186:2379 region --jq=.regions[] | select(.peers | any(.role_name=="Learner") | not) | {id: .id, peers: [.peers]} ``` + Learner Peersの役割変換を促進します（任意の操作）。Learner Peersに変換されていないリージョンがある場合、次のコマンドを使用してリージョンをLearnerリージョンに昇格させます。最初の数字はRegion IDで、2番目の数字はStore IDです。注意：前のステップで結果が返されなかった場合、このステップをスキップしてください。 ```bash operator add remove-peer 6066 6 ``` + DR Auto-Syncの設定を有効にします。 ```bash tiup ctl:vtidb_version pd -u ${HOST_AZ2PD1_PRIVATE_IP}:2379 config set replication-mode dr-auto-sync tiup ctl:vtidb_version pd -u ${HOST_AZ2PD1_PRIVATE_IP}:2379 config set replication-mode dr-auto-sync label-key dc tiup ctl:vtidb_version pd -u ${HOST_AZ2PD1_PRIVATE_IP}:2379 config set replication-mode dr-auto-sync primary dc1 tiup ctl:vtidb_version pd -u ${HOST_AZ2PD1_PRIVATE_IP}:2379 config set replication-mode dr-auto-sync dr dc2 tiup ctl:vtidb_version pd -u ${HOST_AZ2PD1_PRIVATE_IP}:2379 config set replication-mode dr-auto-sync primary-replicas 2 tiup ctl:vtidb_version pd -u ${HOST_AZ2PD1_PRIVATE_IP}:2379 config set replication-mode dr-auto-sync dr-replicas 1 ``` ```output Starting component ctl: /home/ec2-user/.tiup/components/ctl/vtidb_version/ctl pd -u http://10.90.2.162:2379 config set replication-mode dr-auto-sync Success! The replication mode config is updated." Starting component ctl: /home/ec2-user/.tiup/components/ctl/vtidb_version/ctl pd -u http://10.90.2.162:2379 config set replication-mode dr-auto-sync label-key dc Success! The replication mode config is updated." Starting component ctl: /home/ec2-user/.tiup/components/ctl/vtidb_version/ctl pd -u http://10.90.2.162:2379 config set replication-mode dr-auto-sync primary dc1 Success! The replication mode config is updated." Starting component ctl: /home/ec2-user/.tiup/components/ctl/vtidb_version/ctl pd -u http://10.90.2.162:2379 config set replication-mode dr-auto-sync dr dc2 Success! The replication mode config is updated." Starting component ctl: /home/ec2-user/.tiup/components/ctl/vtidb_version/ctl pd -u http://10.90.2.162:2379 config set replication-mode dr-auto-sync primary-replicas 2 Success! The replication mode config is updated." Starting component ctl: /home/ec2-user/.tiup/components/ctl/vtidb_version/ctl pd -u http://10.90.2.162:2379 config set replication-mode dr-auto-sync dr-replicas 1 Success! The replication mode config is updated." ``` + 設定が有効であることを確認します。 ```bash tiup ctl:vtidb_version pd -u ${HOST_AZ2PD1_PRIVATE_IP}:2379 config show replication-mode ``` ```output Starting component ctl: /home/ec2-user/.tiup/components/ctl/vtidb_version/ctl pd -u http://10.90.2.162:2379:2379 config show replication-mode { "replication-mode": "dr-auto-sync", "dr-auto-sync": { "label-key": "dc", "primary": "dc1", "dr": "dc2", "primary-replicas": 2, "dr-replicas": 1, "wait-store-timeout": "1m0s", "wait-recover-timeout": "0s", "pause-region-split": "false" } } ``` ### 手順 15. レプリケーション状態が `sync` に戻っていることを確認します + クラスタの現在のレプリケーション状態を確認します。状態が`sync`モードになるまで、一時的に`sync_recover`モードまたは`recover_progress`の状態が表示されることがあります。 ```bash curl ${HOST_AZ2PD1_PRIVATE_IP}:2379/pd/api/v1/replication_mode/status ``` ```output { "mode": "dr-auto-sync", "dr-auto-sync": { "label_key": "dc", "state": "sync_recover", "state_id": 2003, "acid_consistent": false, "total_regions": 60, "synced_regions": 37, "recover_progress": 0.98333335 } } ``` + 最後に`sync`状態を取得します。 ```output { "mode": "dr-auto-sync", "dr-auto-sync": { "label_key": "dc", "state": "sync", "state_id": 378, "acid_consistent": true } } ``` + ターミナル1に切り替え、sysbenchワークロードのQPSが回復したことを確認します。 ```output ... [ 2309s ] thds: 6 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s: 0.00 reconn/s: 0.00 [ 2310s ] thds: 6 tps: 0.00 qps: 0.00 (r/w/o: 0.00/0.00/0.00) lat (ms,95%): 0.00 err/s: 0.00 reconn/s: 0.00 [ 2311s ] thds: 6 tps: 105.01 qps: 2170.15 (r/w/o: 1530.11/416.03/224.02) lat (ms,95%): 100000.00 err/s: 0.00 reconn/s: 6.00 [ 2312s ] thds: 6 tps: 193.97 qps: 3869.44 (r/w/o: 2705.61/763.89/399.94) lat (ms,95%): 34.33 err/s: 0.00 reconn/s: 0.00 ``` ### 手順 16. Placement Driver と TiKV のリーダーを DC1 に転送します + DC2の2番目のPlacement Driverノードをスケールインします。 ```bash tiup cluster scale-in tidb-demo -N "${HOST_AZ2PD2_PRIVATE_IP}:2379" -y ``` ```output The component `ctl` version vtidb_version is not installed; downloading from repository. Starting component ctl: /home/ec2-user/.tiup/components/ctl/vtidb_version/ctl pd -u 10.90.1.19:2379 member leader transfer pd-10.90.1.106-2379 Success! ``` + 前の手順の結果に関係なく、このコマンドを実行してPDリーダーをDC1に転送しようとします。 ```bash tiup ctl:vtidb_version pd -u ${HOST_AZ1PD1_PRIVATE_IP}:2379 member leader transfer "pd-${HOST_AZ1PD1_PRIVATE_IP}-2379" ``` ```output The component `ctl` version vtidb_version is not installed; downloading from repository. Starting component ctl: /home/ec2-user/.tiup/components/ctl/vtidb_version/ctl pd -u 10.90.1.19:2379 member leader transfer pd-10.90.1.106-2379 Success! ``` + TiDBクラスタの状態を確認します。PDのリーダーがDC1に配置され、PDノードの数が3であることを確認します。 ```bash tiup cluster display tidb-demo ``` ```output ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.90.1.221:3000 grafana 10.90.1.221 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000 10.90.2.107:3000 grafana 10.90.2.107 3000 / Up - /tidb-deploy/grafana-3000 10.90.1.55:2379 pd 10.90.1.55 2379/2380 linux/x86_64 Up /tidb-data/pd_data /tidb-deploy/pd-2379 10.90.1.95:2379 pd 10.90.1.95 2379/2380 linux/x86_64 Up|L /tidb-data/pd_data /tidb-deploy/pd-2379 10.90.2.83:2379 pd 10.90.2.83 2379/2380 / Up /tidb-data/pd_data /tidb-deploy/pd-2379 10.90.1.221:10090 prometheus 10.90.1.221 10090/12020 linux/x86_64 Up /tidb-data/prometheus_data /tidb-deploy/prometheus-10090 10.90.2.107:10090 prometheus 10.90.2.107 10090 / Up /tidb-data/prometheus_data /tidb-deploy/prometheus-10090 10.90.1.58:4000 tidb 10.90.1.58 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.2.210:4000 tidb 10.90.2.210 4000/10080 / Up - /tidb-deploy/tidb-4000 10.90.1.219:20160 tikv 10.90.1.219 20160/20180 linux/x86_64 Up /tidb-data/tikv_data /tidb-deploy/tikv-20160 10.90.1.71:20160 tikv 10.90.1.71 20160/20180 linux/x86_64 Up /tidb-data/tikv_data /tidb-deploy/tikv-20160 10.90.2.111:20160 tikv 10.90.2.111 20160/20180 / Up /tidb-data/tikv_data /tidb-deploy/tikv-20160 10.90.2.91:20160 tikv 10.90.2.91 20160/20180 / Up /tidb-data/tikv_data /tidb-deploy/tikv-20160 Total nodes: 13 ``` + 各役割のリージョン配分を調べることで、DR Auto-sync設定がTiKVノードにうまく適用されていることを確認できます。 ```bash tiup ctl:vtidb_version pd -u ${HOST_AZ1PD1_PRIVATE_IP}:2379 store ``` ```output Starting component ctl: /home/ec2-user/.tiup/components/ctl/vtidb_version/ctl pd -u 10.90.2.83:2379 store { "count": 4, "stores": [ { "store": { "id": 1, "address": "10.90.2.111:20160", ... }, "status": { "leader_count": 0, "region_count": 79, ... } }, { "store": { "id": 14, "address": "10.90.2.91:20160", ... }, "status": { "leader_count": 0, "region_count": 79, "learner_count": 79, ... } }, { "store": { "id": 2001, "address": "10.90.1.219:20160", ... }, "status": { "leader_count": 42, "region_count": 79, ... } }, { "store": { "id": 2002, "address": "10.90.1.71:20160", ... }, "status": { "leader_count": 37, "region_count": 79, ... } } ] } ``` + 上記の情報から、各TiKVノードの役割をリージョン分布から特定できます（ストアIDは例とは異なるかもしれません）。 + ストア1は「フォロワー」: "leader_count": 0, "region_count": 79 + ストア14は「ラーナー」: "leader_count": 0, "region_count": 79, "learner_count": 79 + ストア2001は「投票者」: "leader_count": 42, "region_count": 79 + ストア2002は「投票者」: "leader_count": 37, "region_count": 79 ### モジュール 3のまとめ + このモジュールを通じて、プライマリデータセンターが完全に故障した場合でも、TiDBクラスタを正常に復元し、RPO=0を保証できることを観察しました。おおまかに言うと、復旧操作には以下のステップが含まれます: + DC2で唯一残っているPDを回復させ、新しいクラスタを作成します。 + DC2に新しいPDをスケールアウトし、新しいRaftグループを形成します。 + クラスタモードを過半数モードに変更します。 + DC1にある利用不可のTiKVノードを削除します。 + すべてのクラスタノードを再起動し、2つの生き残ったTiKVノードで運用します。アプリケーションの読み書き操作の回復を観察します。 + 故障を修正します。 + DC1内のノードを初期化し、TiDBクラスタに再統合します。 + クラスタ設定を変更してDR Auto-syncモードに戻します。 ## 結論 上記の3つの実践を通じて、TiDB DR Auto-syncデプロイメントソリューションの高可用性を検証し、データセンターレベルの故障が発生してもデータの損失がないことを確認しました。 特にFSI（金融サービス業界）では、多くのクライアントが高可用性のために2つのデータセンター環境で運用しており、このニーズを満たすためにTiDBはDR Auto-Sync（Data Replication Auto Synchronous）メカニズムを導入し、データセンター間のデプロイメント上の課題を解決し、データの整合性を保証し、システムの可用性を向上させます。 ```hbsptform { "ui": { "titleLevel": 3 }, "portalId": "4466002", "formId": "62bfb32a-a60a-4f9d-b2dc-1107a93db568", "region": "na1", "sfdcCampaignId": "701RC00000NdFlAYAV" } ```