TiDB 災害復旧ソリューションの概要
このドキュメントでは、TiDB が提供する災害復旧 (DR) ソリューションを紹介します。このドキュメントの構成は次のとおりです。
- DR の基本的な概念について説明します。
- TiDB、TiCDC、およびバックアップと復元 ( BR ) のアーキテクチャを紹介します。
- TiDB が提供する DR ソリューションについて説明します。
- これらの DR ソリューションを比較します。
基本概念
- RTO (目標復旧時間): システムが災害から復旧するのに必要な時間。
- RPO (目標復旧ポイント): 災害時に企業が許容できるデータ損失の最大量。
次の図は、これら 2 つの概念を示しています。
- エラー許容目標: 災害はさまざまな地域に影響を及ぼす可能性があるためです。このドキュメントでは、エラー許容目標という用語は、システムが許容できる災害の最大範囲を表すために使用されます。
- リージョン: このドキュメントは地域 DR に焦点を当てており、ここで言及されている「地域」は地理的なエリアまたは都市を指します。
コンポーネントアーキテクチャ
具体的な DR ソリューションを紹介する前に、このセクションでは、TiDB、TiCDC、 BRなどの TiDB コンポーネントのアーキテクチャをDR の観点から紹介します。
ティビ
TiDB は、コンピューティングとstorageを分離したアーキテクチャで設計されています。
- TiDB はシステムの SQL コンピューティングレイヤーです。
- TiKV はシステムのstorageレイヤーであり、行ベースのstorageエンジンです。1 リージョン TiKV でデータをスケジュールするための基本単位です。リージョンは、ソートされたデータ行のコレクションです。リージョン内のデータは少なくとも 3 つのレプリカに保存され、データの変更はRaftプロトコルを通じてログレイヤーに複製されます。
- オプションコンポーネントTiFlash は、分析クエリを高速化するために使用できる列型storageエンジンです。データは、 Raftグループの学習者ロールを通じて TiKV からTiFlashに複製されます。
TiDB は 3 つの完全なデータ レプリカを保存します。そのため、複数のレプリカに基づく DR が当然可能です。同時に、TiDB はRaftログを使用してトランザクション ログを複製するため、トランザクション ログの複製に基づく DR も提供できます。
ティCDC
TiDB の増分データ レプリケーション ツールである TiCDC は、PD の etcd を通じて高い可用性を実現します。TiCDC は、複数のキャプチャ プロセスを通じて TiKV ノードからデータ変更を取得し、内部でデータ変更をソートしてマージします。その後、TiCDC は複数のレプリケーション タスクを使用して、データを複数のダウンストリーム システムに複製します。上記のアーキテクチャ図では、次のようになっています。
- TiKVサーバー: アップストリームのデータ変更を TiCDC ノードに送信します。TiCDC ノードは、変更ログが連続していないと判断すると、TiKVサーバーに変更ログの提供を積極的に要求します。
- TiCDC: 複数のキャプチャ プロセスを実行します。各キャプチャ プロセスは KV 変更ログの一部を取得し、取得したデータを並べ替えてから、変更をさまざまな下流システムに複製します。
前述のアーキテクチャ図から、TiCDC のアーキテクチャはトランザクション ログ レプリケーション システムのアーキテクチャに似ていますが、スケーラビリティが優れており、論理データ レプリケーションのメリットがあることがわかります。したがって、TiCDC は DR シナリオにおいて TiDB の優れた補完となります。
BR
TiDB のバックアップおよび復元ツールとして、 BR は特定の時点に基づく完全なスナップショット バックアップと TiDB クラスターの継続的なログ バックアップを実行できます。TiDB クラスターが完全に使用できなくなった場合は、新しいクラスターでバックアップ ファイルを復元できます。BRは通常、データ セキュリティの最後の手段と見なされます。
ソリューション紹介
プライマリおよびセカンダリ クラスタに基づく DR ソリューション
上記のアーキテクチャには 2 つの TiDB クラスターが含まれており、クラスター 1 はリージョン 1 で実行され、読み取りおよび書き込み要求を処理します。クラスタ2 はリージョン 2 で実行され、セカンダリ クラスターとして機能します。クラスター 1 で災害が発生すると、クラスター 2 がサービスを引き継ぎます。データの変更は、TiCDC を使用して 2 つのクラスター間で複製されます。このアーキテクチャは、「1:1」DR ソリューションとも呼ばれます。
このアーキテクチャはシンプルで可用性が高く、リージョン レベルのエラー許容目標、スケーラブルな書き込み機能、秒レベルの RPO、分レベルの RTO またはそれ以下を備えています。本番システムで RPO をゼロにする必要がない場合は、この DR ソリューションが推奨されます。このソリューションの詳細については、 プライマリおよびセカンダリ クラスタに基づく DR ソリューション参照してください。
単一クラスタ内の複数のレプリカに基づく DR ソリューション
前述のアーキテクチャでは、各リージョンに、異なる使用可能ゾーン (AZ) に配置された 2 つの完全なデータ レプリカがあります。クラスター全体は 3 つのリージョンにまたがっています。リージョン1 は、読み取りおよび書き込み要求を処理するプライマリ リージョンです。リージョン 1 が災害により完全に使用できなくなった場合は、リージョン 2 を DR リージョンとして使用できます。リージョン3 は、多数決プロトコルを満たすために使用されるレプリカです。このアーキテクチャは、「2-2-1」ソリューションとも呼ばれます。
このソリューションは、リージョン レベルのエラー許容度、スケーラブルな書き込み機能、ゼロ RPO、分単位またはそれ以下の RTO を提供します。本番システムでゼロ RPO が必要な場合は、この DR ソリューションを使用することをお勧めします。このソリューションの詳細については、 単一クラスタ内の複数のレプリカに基づく DR ソリューション参照してください。
TiCDCと複数のレプリカに基づくDRソリューション
前述の 2 つのソリューションは、地域 DR を提供します。ただし、複数の地域が同時に利用できない場合は機能しません。システムが非常に重要で、複数の地域をカバーするためにエラー許容目標が必要な場合は、これら 2 つのソリューションを組み合わせる必要があります。
前述のアーキテクチャには、2 つの TiDB クラスターがあります。クラスタ1 には、3 つのリージョンにまたがる 5 つのレプリカがあります。リージョン1 には、プライマリ リージョンとして機能し、書き込み要求を処理する 2 つのレプリカがあります。リージョン2 には、リージョン 1 の DR リージョンとして機能する 2 つのレプリカがあります。このリージョンは、レイテンシーの影響を受けない読み取りサービスを提供します。リージョン3 にある最後のレプリカは、投票に使用されます。
リージョン 1 とリージョン 2 の DR クラスターとして、クラスター 2 はリージョン 3 で実行され、3 つのレプリカを含みます。TiCDC はクラスター 1 からデータを複製します。このアーキテクチャは複雑に見えますが、複数のリージョンに対するエラー許容度目標を高めることができます。複数のリージョンが同時に使用不可になったときに RPO をゼロにする必要がない場合は、このアーキテクチャが適しています。このアーキテクチャは、「2-2-1:1」ソリューションとも呼ばれます。
もちろん、エラー許容度の目標が複数のリージョンであり、RPO をゼロにする必要がある場合は、5 つのリージョンにまたがる少なくとも 9 つのレプリカを持つクラスターを作成することも検討できます。このアーキテクチャは、「2-2-2-2-1」ソリューションとも呼ばれます。
BRに基づくDRソリューション
このアーキテクチャでは、TiDB クラスター 1 がリージョン 1 にデプロイされています。BRはクラスター 1 のデータをリージョン 2 に定期的にバックアップし、このクラスターのデータ変更ログもリージョン 2 に継続的にバックアップします。リージョン 1 で災害が発生し、クラスター 1 を復旧できない場合は、バックアップ データとデータ変更ログを使用して、リージョン 2 に新しいクラスター (クラスター 2) を復元し、サービスを提供できます。
BRベースの DR ソリューションは、5 分未満の RPO と、復元するデータのサイズに応じて変化する RTO を提供します。BR BRの場合、復元速度についてはスナップショット復元のパフォーマンスと影響とPITRのパフォーマンスと影響を参照してください。通常、リージョン間のバックアップ機能は、データ セキュリティの最後の手段と考えられており、ほとんどのシステムに必須のソリューションでもあります。このソリューションの詳細については、 BRに基づくDRソリューション参照してください。
一方、v6.5.0 以降では、 BR はEBS ボリューム スナップショットから TiDB クラスターを復元するサポートします。クラスターが Kubernetes 上で実行されており、クラスターに影響を与えずにできるだけ早くクラスターを復元したい場合は、この機能を使用してシステムの RTO を短縮できます。
その他のDRソリューション
前述の DR ソリューションに加えて、同一都市のデュアル センター シナリオでゼロ RPO が必須である場合は、DR-AUTO 同期ソリューションも使用できます。詳細については、 1 つの地域に展開された 2 つのデータ センター参照してください。
ソリューションの比較
このセクションでは、このドキュメントに記載されている DR ソリューションを比較し、ビジネス ニーズを満たす適切な DR ソリューションを選択できるようにします。
DRソリューション | TCO | エラー許容目標 | RPO | 料金 | ネットワークレイテンシー要件 | 対象システム |
---|---|---|---|---|---|---|
単一クラスタ内の複数のレプリカに基づく DR ソリューション (2-2-1) | 高い | 単一地域 | 0 | 分レベル | 領域間の間隔は30ミリ秒未満 | DR と応答に関する特定の要件がある実稼働システム (RPO = 0) |
プライマリ クラスターとセカンダリ クラスターに基づく DR ソリューション (1:1) | 中くらい | 単一地域 | 10秒未満 | 5分未満 | 領域間の間隔は100ミリ秒未満 | DR と応答に関する特定の要件を持つ実稼働システム (RPO > 0) |
TiCDC と複数のレプリカ (2-2-1:1) に基づく DR ソリューション | 高い | 複数の地域 | 10秒未満 | 5分未満 | DR に複数のレプリカを使用するリージョンでは 30 ミリ秒未満。3 番目のリージョンとその他のリージョンでは 100 ミリ秒未満 | DRとレスポンスに厳しい要件を持つ生産システム |
BRに基づくDRソリューション | 低い | 単一地域 | 5分未満 | 時間レベル | 特別な要件はありません | 5 分未満の RPO と最大 1 時間の RTO を受け入れる生産システム |