PD Recover ユーザーガイド

PD Recover は、正常に起動またはサービスを提供できない PD クラスターを復旧するために使用される PD の災害復旧ツールです。

ソースコードからコンパイルする

• Go モジュールが使用されるため、 行く 1.21 以降が必要です。
• PDプロジェクトのルート ディレクトリで、 make pd-recoverコマンドを使用してbin/pd-recoverコンパイルして生成します。

注記：

通常、 PD Controlツールはリリースされたバイナリまたは Docker にすでに存在するため、ソース コードをコンパイルする必要はありません。ただし、開発者ユーザーは、上記の手順を参照してソース コードをコンパイルできます。

TiDB Toolkitをダウンロード

PD Recover インストール パッケージはTiDB Toolkitに含まれています。TiDB TiDB Toolkitをダウンロードするには、 TiDBツールをダウンロード参照してください。

次のセクションでは、PD クラスターを回復するための 2 つの方法 (存続している PD ノードから回復する方法と、PD クラスター全体を再構築する方法) を紹介します。

方法1: 残存PDノードを使用してPDクラスターを回復する

クラスター内の PD ノードの過半数で回復不能なエラーが発生すると、クラスターはサービスを提供できなくなります。残っている PD ノードがある場合は、残っている PD ノードを選択し、 Raftグループのメンバーを強制的に変更することでサービスを回復できます。手順は次のとおりです。

ステップ1: すべてのノードを停止する

リカバリ プロセス中に PD パラメータとのやり取りによって発生するデータ破損やその他の回復不能なエラーを防ぐには、クラスター内の TiDB、TiKV、およびTiFlashプロセスを停止します。

ステップ2: 生き残ったPDノードを起動する

--force-new-cluster起動パラメータを使用して、生き残った PD ノードを起動します。次に例を示します。

./bin/pd-server --force-new-cluster --name=pd-127.0.0.10-2379 --client-urls=http://0.0.0.0:2379 --advertise-client-urls=http://127.0.0.1:2379 --peer-urls=http://0.0.0.0:2380 --advertise-peer-urls=http://127.0.0.1:2380 --config=conf/pd.toml

ステップ3: pd-recoverを使用してメタデータを修復する

この方法では、少数の PD ノードを使用してサービスを回復するため、ノードに古いデータが含まれている可能性があります。1 とtsoデータがロールバックされると、クラスター データが破損したり、使用できなくなったりする可能alloc_idがあります。これを防ぐには、 pd-recover使用してメタデータを変更し、ノードが正しい割り当て ID と TSO サービスを提供できるようにする必要があります。次に例を示します。

./bin/pd-recover --from-old-member --endpoints=http://127.0.0.1:2379 # Specify the corresponding PD address

注記：

このステップでは、storage内のalloc_id安全な値である100000000だけ自動的に増加します。その結果、後続のクラスターではより大きな ID が割り当てられます。

また、 pd-recover TSO を変更しません。したがって、この手順を実行する前に、ローカル時間が障害発生時刻よりも後であることを確認し、障害発生前に PD コンポーネント間で NTP クロック同期サービスが有効になっていることを確認します。有効になっていない場合は、TSO がロールバックしないように、ローカル クロックを将来の時刻に調整する必要があります。

ステップ4: PDノードを再起動する

プロンプトメッセージrecovery is successfulが表示されたら、PD ノードを再起動します。

ステップ5: PDをスケールアウトしてクラスターを起動する

デプロイメント ツールを使用して PD クラスターをスケールアウトし、クラスター内の他のコンポーネントを起動します。この時点で、PD サービスは利用可能になります。

方法2: PDクラスターを完全に再構築する

この方法は、PD データはすべて失われたが、TiDB、TiKV、 TiFlashなどの他のコンポーネントのデータがまだ存在するシナリオに適用できます。

ステップ1: クラスターIDを取得する

クラスター ID は、PD、TiKV、または TiDB のログから取得できます。クラスター ID を取得するには、サーバー上で直接ログを表示します。

PD ログからクラスター ID を取得する (推奨)

PD ログからクラスター ID を取得するには、次のコマンドを実行します。

cat {{/path/to}}/pd.log | grep "init cluster id"

[2019/10/14 10:35:38.880 +00:00] [INFO] [server.go:212] ["init cluster id"] [cluster-id=6747551640615446306]
...

TiDBログからクラスタIDを取得する

TiDB ログからクラスター ID を取得するには、次のコマンドを実行します。

cat {{/path/to}}/tidb.log | grep "init cluster id"

2019/10/14 19:23:04.688 client.go:161: [info] [pd] init cluster id 6747551640615446306
...

TiKVログからクラスターIDを取得する

TiKV ログからクラスター ID を取得するには、次のコマンドを実行します。

cat {{/path/to}}/tikv.log | grep "connect to PD cluster"

[2019/10/14 07:06:35.278 +00:00] [INFO] [tikv-server.rs:464] ["connect to PD cluster 6747551640615446306"]
...

ステップ2: 割り当てられたIDを取得する

指定する割り当て ID 値は、現在割り当てられている最大の ID 値よりも大きくする必要があります。割り当て ID を取得するには、モニターから取得するか、サーバー上で直接ログを表示します。

モニターから割り当てられたIDを取得する（推奨）

モニターから割り当てられた ID を取得するには、表示しているメトリックが最後の PD リーダーのメトリックであることを確認する必要があります。また、PD ダッシュボードの現在の ID 割り当てパネルから最大の割り当て ID を取得できます。

PDログから割り当てられたIDを取得する

PD ログから割り当てられた ID を取得するには、表示しているログが最後の PD リーダーのログであることを確認する必要があります。次のコマンドを実行すると、割り当てられた最大の ID を取得できます。

cat {{/path/to}}/pd*.log | grep "idAllocator allocates a new id" |  awk -F'=' '{print $2}' | awk -F']' '{print $1}' | sort -r -n | head -n 1

4000
...

または、すべての PD サーバーで上記のコマンドを実行して、最大のサーバーを見つけることもできます。

ステップ3: 新しいPDクラスターをデプロイ

新しい PD クラスターをデプロイする前に、既存の PD クラスターを停止し、以前のデータ ディレクトリを削除するか、 --data-dirを使用して新しいデータ ディレクトリを指定する必要があります。

ステップ4: pd-recoverを使用する

1 つの PD ノードでpd-recoverだけ実行する必要があります。

./pd-recover -endpoints http://10.0.1.13:2379 -cluster-id 6747551640615446306 -alloc-id 10000

ステップ5: クラスター全体を再起動する

リカバリが成功したことを示すプロンプト情報が表示されたら、クラスター全体を再起動します。

FAQ

クラスタIDを取得する際に複数のクラスタIDが見つかりました

PD クラスターが作成されると、新しいクラスター ID が生成されます。ログを表示することで、古いクラスターのクラスター ID を確認できます。

pd-recoverを実行すると、エラーdial tcp 10.0.1.13:2379: connect: connection refusedが返されます。

PD リカバリを使用する前に、 pd-recover . PD クラスターをデプロイ起動するを実行する場合は、PD サービスが必要です。