TiDB 災害復旧ソリューションの概要

このドキュメントでは、TiDB が提供する災害復旧 (DR) ソリューションを紹介します。このドキュメントの構成は次のとおりです。

  • DR の基本的な概念について説明します。
  • TiDB、TiCDC、およびバックアップと復元 ( BR ) のアーキテクチャを紹介します。
  • TiDB が提供する DR ソリューションについて説明します。
  • これらの DR ソリューションを比較します。

基本概念

  • RTO (目標復旧時間): システムが災害から復旧するのに必要な時間。
  • RPO (目標復旧ポイント): 災害時に企業が許容できるデータ損失の最大量。

次の図は、これら 2 つの概念を示しています。

RTO and RPO

  • エラー許容目標: 災害はさまざまな地域に影響を及ぼす可能性があるためです。このドキュメントでは、エラー許容目標という用語は、システムが許容できる災害の最大範囲を表すために使用されます。
  • リージョン: このドキュメントは地域 DR に焦点を当てており、ここで言及されている「地域」は地理的なエリアまたは都市を指します。

コンポーネントアーキテクチャ

具体的な DR ソリューションを紹介する前に、このセクションでは、TiDB、TiCDC、 BRなどの TiDB コンポーネントのアーキテクチャをDR の観点から紹介します。

ティビ

TiDB architecture

TiDB は、コンピューティングとstorageを分離したアーキテクチャで設計されています。

  • TiDB はシステムの SQL コンピューティングレイヤーです。
  • TiKV はシステムのstorageレイヤーであり、行ベースのstorageエンジンです。1 リージョン TiKV でデータをスケジュールするための基本単位です。リージョンは、ソートされたデータ行のコレクションです。リージョン内のデータは少なくとも 3 つのレプリカに保存され、データの変更はRaftプロトコルを通じてログレイヤーに複製されます。
  • オプションコンポーネントTiFlash は、分析クエリを高速化するために使用できる列型storageエンジンです。データは、 Raftグループの学習者ロールを通じて TiKV からTiFlashに複製されます。

TiDB は 3 つの完全なデータ レプリカを保存します。そのため、複数のレプリカに基づく DR が当然可能です。同時に、TiDB はRaftログを使用してトランザクション ログを複製するため、トランザクション ログの複製に基づく DR も提供できます。

ティCDC

TiCDC architecture

TiDB の増分データ レプリケーション ツールである TiCDC は、PD の etcd を通じて高い可用性を実現します。TiCDC は、複数のキャプチャ プロセスを通じて TiKV ノードからデータ変更を取得し、内部でデータ変更をソートしてマージします。その後、TiCDC は複数のレプリケーション タスクを使用して、データを複数のダウンストリーム システムに複製します。上記のアーキテクチャ図では、次のようになっています。

  • TiKVサーバー: アップストリームのデータ変更を TiCDC ノードに送信します。TiCDC ノードは、変更ログが連続していないと判断すると、TiKVサーバーに変更ログの提供を積極的に要求します。
  • TiCDC: 複数のキャプチャ プロセスを実行します。各キャプチャ プロセスは KV 変更ログの一部を取得し、取得したデータを並べ替えてから、変更をさまざまな下流システムに複製します。

前述のアーキテクチャ図から、TiCDC のアーキテクチャはトランザクション ログ レプリケーション システムのアーキテクチャに似ていますが、スケーラビリティが優れており、論理データ レプリケーションのメリットがあることがわかります。したがって、TiCDC は DR シナリオにおいて TiDB の優れた補完となります。

BR

BR architecture

TiDB のバックアップおよび復元ツールとして、 BR は特定の時点に基づく完全なスナップショット バックアップと TiDB クラスターの継続的なログ バックアップを実行できます。TiDB クラスターが完全に使用できなくなった場合は、新しいクラスターでバックアップ ファイルを復元できます。BRは通常、データ セキュリティの最後の手段と見なされます。

ソリューション紹介

プライマリおよびセカンダリ クラスタに基づく DR ソリューション

Primary-secondary cluster DR

上記のアーキテクチャには 2 つの TiDB クラスターが含まれており、クラスター 1 はリージョン 1 で実行され、読み取りおよび書き込み要求を処理します。クラスタ2 はリージョン 2 で実行され、セカンダリ クラスターとして機能します。クラスター 1 で災害が発生すると、クラスター 2 がサービスを引き継ぎます。データの変更は、TiCDC を使用して 2 つのクラスター間で複製されます。このアーキテクチャは、「1:1」DR ソリューションとも呼ばれます。

このアーキテクチャはシンプルで可用性が高く、リージョン レベルのエラー許容目標、スケーラブルな書き込み機能、秒レベルの RPO、分レベルの RTO またはそれ以下を備えています。本番システムで RPO をゼロにする必要がない場合は、この DR ソリューションが推奨されます。このソリューションの詳細については、 プライマリおよびセカンダリ クラスタに基づく DR ソリューション参照してください。

単一クラスタ内の複数のレプリカに基づく DR ソリューション

Multi-replica cluster DR

前述のアーキテクチャでは、各リージョンに、異なる使用可能ゾーン (AZ) に配置された 2 つの完全なデータ レプリカがあります。クラスター全体は 3 つのリージョンにまたがっています。リージョン1 は、読み取りおよび書き込み要求を処理するプライマリ リージョンです。リージョン 1 が災害により完全に使用できなくなった場合は、リージョン 2 を DR リージョンとして使用できます。リージョン3 は、多数決プロトコルを満たすために使用されるレプリカです。このアーキテクチャは、「2-2-1」ソリューションとも呼ばれます。

このソリューションは、リージョン レベルのエラー許容度、スケーラブルな書き込み機能、ゼロ RPO、分単位またはそれ以下の RTO を提供します。本番システムでゼロ RPO が必要な場合は、この DR ソリューションを使用することをお勧めします。このソリューションの詳細については、 単一クラスタ内の複数のレプリカに基づく DR ソリューション参照してください。

TiCDCと複数のレプリカに基づくDRソリューション

前述の 2 つのソリューションは、地域 DR を提供します。ただし、複数の地域が同時に利用できない場合は機能しません。システムが非常に重要で、複数の地域をカバーするためにエラー許容目標が必要な場合は、これら 2 つのソリューションを組み合わせる必要があります。

TiCDC-based multi-replica cluster DR

前述のアーキテクチャには、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ソリューション

BR-based cluster 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 を受け入れる生産システム

このページは役に立ちましたか?