BR を使用してクラスタデータをバックアップする

このドキュメントでは、次のシナリオで BR を使用してクラスター データをバックアップする方法について説明します。

バックアップと復元 (BR) に慣れていない場合は、次のドキュメントを読んで、BR の使用原理と方法を完全に理解することをお勧めします。

TiDB クラスターのスナップショットをバックアップする

TiDB クラスターのスナップショットには、特定の時点における最新でトランザクション的に一貫性のあるデータのみが含まれます。 br backup fullコマンドを実行して、TiDB クラスターの最新または指定したスナップショット データをバックアップできます。このコマンドのヘルプを表示するには、 br backup full --helpコマンドを実行します。

例: 2022-01-30 07:42:23で生成されたスナップショットを Amazon S3 のbackup-dataバケットの2022-01-30/ディレクトリにバックアップします。

br backup full \ --pd "${PDIP}:2379" \ --backupts '2022-01-30 07:42:23' \ --storage "s3://backup-data/2022-01-30/" \ --ratelimit 128 \ --log-file backupfull.log

前述のコマンドでは:

  • --backupts : スナップショットの物理時間。このスナップショットのデータがガベージ コレクション (GC) によって処理される場合、 br backupコマンドはエラーで終了します。このパラメーターを指定しない場合、BR はバックアップの開始時刻に対応するスナップショットを選択します。
  • --ratelimit : バックアップ タスクを実行するTiKV ごとの最大速度 (MiB/秒)。
  • --log-file : BR ロギングの対象ファイル。

バックアップ中は、以下に示すように、進行状況バーがターミナルに表示されます。プログレス バーが 100% まで進むと、バックアップは完了です。

br backup full \ --pd "${PDIP}:2379" \ --storage "s3://backup-data/2022-01-30/" \ --ratelimit 128 \ --log-file backupfull.log Full Backup <---------/................................................> 17.12%.

バックアップが完了すると、BR はバックアップ データのチェックサムとクラスタのチェックサムを比較して、データの正確性とセキュリティを確保し管理者チェックサム テーブル

データベースまたはテーブルのバックアップ

BR は、クラスター スナップショットまたは増分データ バックアップから、指定されたデータベースまたはテーブルの部分的なデータのバックアップをサポートします。この機能を使用すると、スナップショット バックアップと増分データ バックアップから不要なデータを除外し、ビジネス クリティカルなデータのみをバックアップできます。

データベースのバックアップ

クラスター内のデータベースをバックアップするには、 br backup dbコマンドを実行します。このコマンドのヘルプを表示するには、 br backup db --helpコマンドを実行します。

例: testデータベースを Amazon S3 のbackup-dataバケットのdb-test/2022-01-30/ディレクトリにバックアップします。

br backup db \ --pd "${PDIP}:2379" \ --db test \ --storage "s3://backup-data/db-test/2022-01-30/" \ --ratelimit 128 \ --log-file backuptable.log

上記のコマンドで、 --dbはデータベース名を指定し、他のパラメーターはTiDB クラスターのスナップショットをバックアップすると同じです。

テーブルをバックアップする

クラスター内のテーブルをバックアップするには、 br backup tableコマンドを実行します。このコマンドのヘルプを表示するには、 br backup table --helpコマンドを実行します。

例: Amazon S3 のbackup-dataバケットのtable-db-usertable/2022-01-30/ディレクトリにtest.usertableをバックアップします。

br backup table \ --pd "${PDIP}:2379" \ --db test \ --table usertable \ --storage "s3://backup-data/table-db-usertable/2022-01-30/" \ --ratelimit 128 \ --log-file backuptable.log

上記のコマンドで、 --db--tableはそれぞれデータベース名とテーブル名を指定し、その他のパラメーターはTiDB クラスターのスナップショットをバックアップすると同じです。

テーブル フィルターを使用して複数のテーブルをバックアップする

複数の基準で複数のテーブルをバックアップするには、 br backup fullコマンドを実行し、 --filterまたは-fテーブル フィルターを指定します。

例: テーブルのdb*.tbl*データを Amazon S3 のbackup-dataバケットのtable-filter/2022-01-30/ディレクトリにバックアップします。

br backup full \ --pd "${PDIP}:2379" \ --filter 'db*.tbl*' \ --storage "s3://backup-data/table-filter/2022-01-30/" \ --ratelimit 128 \ --log-file backupfull.log

データを外部ストレージにバックアップする

BR は、Amazon S3、Google Cloud Storage (GCS)、Azure Blob Storage、NFS、またはその他の S3 互換ファイル ストレージ サービスへのデータのバックアップをサポートしています。詳細については、次のドキュメントを参照してください。

増分データのバックアップ

TiDB クラスターの増分データは、開始点のスナップショットと終了点のスナップショットの差分データです。増分データは、スナップショット データと比較してサイズが小さいため、スナップショット バックアップを補完するものであり、バックアップ データの量を削減します。

増分データをバックアップするには、最後のバックアップ タイムスタンプ--lastbackuptsを指定してbr backupコマンドを実行します。 --lastbackuptsを取得するには、 validateコマンドを実行します。次に例を示します。

LAST_BACKUP_TS=`br validate decode --field="end-version" -s s3://backup-data/2022-01-30/ | tail -n1`

ノート:

  • 増分バックアップ データは、以前のスナップショット バックアップとは別のパスに保存する必要があります。
  • GC セーフポイントはlastbackuptsより前でなければなりません。デフォルトの GC ライフタイムは TiDB で 10 分です。つまり、TiDB は過去 10 分間に生成された増分データのみをバックアップします。以前の増分データをバックアップするには、 TiDB GC ライフタイム設定を調整するを行う必要があります。
br backup full\ --pd ${PDIP}:2379 \ --ratelimit 128 \ --storage "s3://backup-data/2022-01-30/incr" \ --lastbackupts ${LAST_BACKUP_TS}

上記のコマンドは、 (LAST_BACKUP_TS, current PD timestamp]からこの期間中に生成された DDL までの増分データをバックアップします。増分データを復元する場合、BR は最初にすべての DDL を復元し、次にデータを復元します。

バックアップ データの暗号化

BR は、Amazon S3 へのバックアップ時に、バックアップ側とストレージ側でバックアップ データの暗号化をサポートします。必要に応じて、いずれかの暗号化方式を選択できます。

バックアップ終了時にバックアップ データを暗号化する

TiDB v5.3.0 以降、次のパラメータを設定することでバックアップ データを暗号化できます。

  • --crypter.method : 暗号化アルゴリズム。 aes128-ctraes192-ctr 、またはaes256-ctrのいずれかです。デフォルト値はplaintextで、データが暗号化されていないことを示します。
  • --crypter.key : 16 進文字列形式の暗号化キー。これは、アルゴリズム 2 では 128 ビット (16 バイト) の鍵、アルゴリズムaes128-ctrでは 24 バイトの鍵、アルゴリズムaes192-ctrではaes256-ctrバイトの鍵です。
  • --crypter.key-file : 鍵ファイル。 「crypter.key」を渡さずに、キーが格納されているファイル パスをパラメータとして直接渡すことができます。

例: バックアップの最後にバックアップ データを暗号化します。

br backup full\ --pd ${PDIP}:2379 \ --storage "s3://backup-data/2022-01-30/" \ --crypter.method aes128-ctr \ --crypter.key 0123456789abcdef0123456789abcdef

ノート:

  • キーを紛失すると、バックアップ データをクラスタに復元できなくなります。
  • 暗号化機能は、BR ツールおよび TiDB クラスター v5.3.0 以降のバージョンで使用する必要があります。暗号化されたバックアップ データは、v5.3.0 より前のクラスターでは復元できません。

Amazon S3 へのバックアップ時にバックアップ データを暗号化する

BR は、データを S3 にバックアップするときにサーバー側の暗号化 (SSE) をサポートします。このシナリオでは、作成した AWS KMS キーを使用してデータを暗号化できます。詳細については、 BR S3 サーバー側の暗号化を参照してください。

バックアップのパフォーマンスと影響

バックアップ機能は、クラスターのパフォーマンス (トランザクションのレイテンシーと QPS) に影響を与えます。ただし、バックアップ スレッドbackup.num-threadsの数を調整するか、クラスターを追加することで、影響を軽減できます。

バックアップの影響を説明するために、このドキュメントではいくつかのスナップショット バックアップ テストの結果を示します。

  • (5.3.0 以前) TiKV ノード上の BR のバックアップ スレッドがノードの合計 CPU の 75% を占める場合、QPS は元の QPS の 30% 減少します。
  • (5.4.0 以降) TiKV ノードに BR のスレッドが8しかなく、クラスターの合計 CPU 使用率が 80% を超えない場合、クラスターに対する BR タスク (書き込みおよび読み取り) の影響は 20% です。多くの。
  • (5.4.0 以降) TiKV ノードに BR のスレッドが8しかなく、クラスターの合計 CPU 使用率が 75% を超えない場合、クラスターに対する BR タスク (書き込みおよび読み取り) の影響は 10% です。多くの。
  • (5.4.0 以降) TiKV ノードに BR のスレッドが8しかなく、クラスターの合計 CPU 使用率が 60% を超えない場合、BR タスクはクラスター (書き込みと読み取り) にほとんど影響を与えません。

バックアップ スレッドの数を減らすことで、クラスターのパフォーマンスへの影響を軽減できます。ただし、これによりバックアップのパフォーマンスが低下する可能性があります。前述のテスト結果に基づくと、(単一の TiKV ノードで) バックアップ速度はバックアップ スレッドの数に比例します。スレッド数が少ない場合、バックアップ速度は約 20MB/スレッドです。たとえば、5 つのバックアップ スレッドを持つ単一ノードは、100 MB/秒のバックアップ速度を実現できます。

ノート:

バックアップの影響と速度は、クラスタ構成、展開、および実行中のサービスに大きく依存します。多くのシナリオでのシミュレーション テストに基づき、一部の顧客サイトで検証された前述のテストの結論は、参照に値します。ただし、正確な影響とパフォーマンスの上限は、シナリオによって異なる場合があります。したがって、常にテストを実行し、テスト結果を確認する必要があります。

v5.3.0 以降、BR は自動チューニング機能 (デフォルトで有効) を導入して、バックアップ スレッドの数を調整します。バックアップ タスク中にクラスターの CPU 使用率を 80% 未満に維持できます。詳細については、 BR オートチューンを参照してください。