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

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

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

基本概念

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

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

RTO and RPO

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

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

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

TiDB

TiDB architecture

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

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

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

TiCDC

TiCDC architecture

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

  • TiKVサーバー: アップストリームのデータ変更を TiCDC ノードに送信します。 TiCDC ノードは、変更ログが連続していないことを検出すると、TiKVサーバーに変更ログを提供するよう積極的に要求します。
  • TiCDC: 複数のキャプチャ プロセスを実行します。各キャプチャ プロセスは、KV 変更ログの一部を取得し、変更を別のダウンストリーム システムにレプリケートする前に、取得したデータを並べ替えます。

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

BR

BR architecture

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

ソリューションの紹介

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

Primary-secondary cluster DR

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

このアーキテクチャはシンプルで可用性が高く、領域レベルのエラー許容目標、スケーラブルな書き込み機能、第 2 レベルの 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 v6.5.0 の場合、復元速度についてはスナップショット復元のパフォーマンスと影響PITRのパフォーマンスと影響を参照してください。通常、リージョン間のバックアップ機能はデータ セキュリティの最後の手段とみなされ、ほとんどのシステムにとって必須のソリューションでもあります。このソリューションの詳細については、 BRをベースとしたDRソリューションを参照してください。

一方、v6.5.0 以降、 BR はEBS ボリューム スナップショットから TiDB クラスターを復元するをサポートします。クラスターが Kubernetes 上で実行されており、クラスターに影響を与えずにできるだけ早くクラスターを復元したい場合は、この機能を使用してシステムの RTO を短縮できます。

その他の DR ソリューション

前述の DR ソリューションに加えて、同じ都市のデュアルセンター シナリオでゼロ RPO が必須の場合は、DR-AUTO 同期ソリューションを使用することもできます。詳細については、 1 つの地域に展開された 2 つのデータ センターを参照してください。

ソリューションの比較

このセクションでは、このドキュメントで説明されている DR ソリューションを比較します。これに基づいて、ビジネス ニーズを満たす適切な DR ソリューションを選択できます。

DRソリューションTCOエラー許容範囲の目標RPORTOネットワークレイテンシー要件ターゲットシステム
単一クラスター内の複数のレプリカに基づく DR ソリューション (2-2-1)高い単一領域0分レベルリージョン間は 30 ミリ秒未満DR と対応に関して特定の要件がある運用システム (RPO = 0)
プライマリ クラスタとセカンダリ クラスタ (1:1) に基づく DR ソリューション中くらい単一領域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 を受け入れる実稼働システム

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

Playground
登録なしで TiDB の機能をワンストップでインタラクティブに体験できます。
製品
TiDB Cloud
TiDB
価格
PoC お問い合わせ
エコシステム
TiKV
TiFlash
OSS Insight
© 2024 PingCAP. All Rights Reserved.
Privacy Policy.