重要
このページは英語版のページを機械翻訳しています。原文はこちらからご覧ください。

デプロイを導入して使用する

このドキュメントでは、バックアップと復元(BR)の推奨される展開と、BRを使用してデータをバックアップおよび復元する方法について説明します。

BRをデプロイ

BRを展開する際の推奨プラクティス:

  • 実稼働環境では、少なくとも8コアのCPUと16GBのメモリを備えたノードにBRをデプロイします。 LinuxOSのバージョン要件に従って、適切なOSバージョンを選択します。

  • バックアップデータをAmazonS3、GCS、またはAzureBlobStorageに保存します。

  • バックアップと復元に十分なリソースを割り当てます。

    • BR、TiKVノード、およびバックアップストレージシステムは、バックアップ速度よりも速いネットワーク帯域幅を提供する必要があります。ターゲットクラスタが特に大きい場合、バックアップと復元の速度のしきい値は、バックアップネットワークの帯域幅によって制限されます。
    • バックアップストレージシステムは、十分な書き込み/読み取りパフォーマンス(IOPS)も提供する必要があります。そうしないと、バックアップまたは復元中にIOPSがパフォーマンスのボトルネックになる可能性があります。
    • TiKVノードには、バックアップ用に少なくとも2つの追加のCPUコアと高性能ディスクが必要です。そうしないと、バックアップがクラスタで実行されているサービスに影響を与える可能性があります。

  • ネットワークファイルシステム(NFS)がBRまたはTiKVノードにマウントされていない場合、またはAmazon S3、GCS、またはAzure Blob Storageプロトコルをサポートする外部ストレージを使用している場合、BRによってバックアップされるデータは各TiKVノードで生成されます。 BRはリーダーレプリカのみをバックアップするため、リーダーのサイズに基づいて各ノードで予約されているスペースを見積もる必要があります。 TiDBはデフォルトで負荷分散にリーダー数を使用するため、リーダーのサイズは大きく異なる可能性があります。これにより、バックアップデータが各ノードに不均一に分散されるという問題が発生する可能性があります。
  • バックアップデータは各ノードのローカルファイルシステムに分散しているため、これはBRを展開するための推奨される方法ではないことに注意してください。バックアップデータを収集すると、データの冗長性と運用および保守の問題が発生する可能性があります。一方、バックアップデータを収集する直前にデータを復元すると、 SST file not foundエラーが発生します。

BRを使用する

現在、BRツールを実行するために次のメソッドがサポートされています。

SQLステートメントを使用する

TiDBは、 BACKUPつとRESTOREのSQLステートメントの両方をサポートします。ステートメントSHOW BACKUPS|RESTORESを使用して、これらの操作の進行状況を監視できます。

コマンドラインツールを使用する

詳細については、 バックアップと復元にBRコマンドラインを使用するを参照してください。

Kubernetes環境でBRを使用する

Kubernetes環境では、 TiDB Operatorを使用してTiDBクラスタデータをAmazonS3、GCS、または永続ボリュームにバックアップし、そのようなシステムのバックアップデータからデータを復元できます。詳細については、 TiDB Operatorを使用したデータのバックアップと復元を参照してください。