TiDBでのディザスタリカバリ (DR) の仕組み

※このブログは2023年3月6日に公開された英語ブログ「How Disaster Recovery (DR) Works in TiDB」の拙訳です。

前回のブログでは、データベースのディザスタリカバリテクノロジーの進化を紹介しました。今回は、TiDBのディザスタリカバリ (DR) ソリューションに焦点を当てます。また、これらのソリューションの長所と短所、および最適な展開オプションについても分析します。

TiDBのストレージアーキテクチャ

TiDBのDRソリューションを深く掘り下げる前に、TiDBとは何か、そしてTiDBがどのようにデータを処理および保存するかを調べてみましょう。

TiDB は、水平方向のスケーラビリティ、オンラインのトランザクションおよび分析処理、および高可用性を備えたオープンソースの分散SQLデータベースです。また、MySQLと高い互換性があり、強力な一貫性を備えています。

TiDB は、次の主要コンポーネントで構成されています。

• Placement Driver (PD): メタデータを保存および管理し、データスケジューリングコマンドをTiKVに送信するTiDBシステム全体の頭脳
• TiDB サーバー：計算、SQL分析、およびTiKVまたはTiFlashへのリクエストの送信に使用されるステートレスSQLレイヤー
• TiKV サーバー：行ストア
• TiFlash サーバー：カラム型ストア

図1.TiDBのアーキテクチャ

TiDBは、Raftコンセンサスプロトコルを採用しています。データの複数のコピー (デフォルトでは3つのコピー) を異なるTiKVノードに均等に配布して保存します。TiKVノードに保存されているデータの最小セグメントは、TiDBリージョンと呼ばれます。

TiDBのDRソリューション

さまざまな顧客のニーズを満たすために、TiDBは次のDRソリューションを提供しています。

• 1:1アーキテクチャのTiCDC DR
• 2-2-1アーキテクチャのマルチレプリカDR
• 2-2-1:1アーキテクチャのTiCDC DR

これらのソリューションはどういうものでしょうか？データベースのフェイルオーバーをどのように実現しますか？どのシナリオに最適ですか？次のセクションでは、それぞれについて説明します。

1:1アーキテクチャのTiCDC DR

TiCDCはTiDBの変更データキャプチャツールです。TiDBの増分データを複製します。このアーキテクチャでは、2つの別々のリージョンにデプロイされた2つのTiDBクラスタがあります。(注：”リージョン”は地理的領域を表します)

• リージョン1にデプロイされたクラスタ1には3つのデータレプリカがあり、読み取りと書き込みを行います
• リージョン2にデプロイされたクラスタ2にも3つのデータレプリカがあります。DRクラスタとして機能し、わずかな遅延で読み取り専用サービスを処理することもできます。TiCDCは、2つのクラスタ間でデータ変更を同期します

• TiFlashサーバー：カラムナーストア。

• 2つのクラスタ間でデータ変更を同期します

図2. 1:1アーキテクチャのTiCDC DR

これはTiDBにおいて最も推奨されるDRソリューションです。利用しやすくて信頼性があります。秒レベルの目標復旧時点 (RPO) と”分”もしくはそれ以下のレベルの目標復旧時間 (RTO) により、単一リージョンにおけるフォールトトレランスを実現できます。お客様の要件が単一リージョンのフォールトトレランスとデータ損失が許容されるRPOである場合、このアーキテクチャは間違いなくコスト効率が高くなります。また、ディザスタリカバリに加えて、読み取りと書き込みのスケーラビリティも実現します。

2-2-1アーキテクチャのマルチレプリカDR

次の図は2-2-1アーキテクチャを示しています。その中で、TiDBクラスタ全体が3つのリージョンにまたがっています。リージョン1と2の両方に2つのデータのコピーが含まれ、リージョン3には1つ含まれています。これらのデータレプリカは、異なるアベイラビリティーゾーン (AZ) に別々に保存されます。通常、AZ間のネットワークは高速で安定しています。

図3. 2-2-1アーキテクチャのマルチレプリカDR

このアーキテクチャでは、次のようになります。

• リージョン1は読み取り要求と書き込み要求を処理します
• リージョン2はリージョン1で障害が発生した後のフェイルオーバーに使用されます。また、レイテンシーを気にしないで良い一部の読み取り処理もカバーできます
• リージョン3はリージョン1がダウンしている場合でもRaftベースのコンセンサスプロトコルが維持できることを保証するクォーラムレプリカに似ています

このアーキテクチャは、データ損失が許容されないRPOかつ分またはそれより短いレベルのRTOでのリージョンレベルのフォールトトレランス向けです。RPO=0が必要な場合は、このDRソリューションをお勧めします。

このソリューションの最大の欠点は、データベースの応答時間がリージョン1とリージョン2の間のネットワーク遅延の影響を受けることです。これは、データ変更があった場合にリージョン2のTiKVノードに反映された後ではないとトランザクションを返すことができないためです。

2-2-1:1アーキテクチャのTiCDC DR

このアーキテクチャでは2つのTiDBクラスタがあります。クラスタ1には5つのデータレプリカが含まれ、3つのリージョンにまたがっています。

• リージョン1には書き込みワークロードを処理する2つのデータレプリカが含まれています
• リージョン2にはリージョン1がダウンした場合に備えてDR用のレプリカが2つあります。また、レイテンシーを気にしないで良い読み取り要求にも対応できます
• リージョン3にはRaftの投票に使用される最後のデータレプリカが格納されます。

図4. 2-2-1:1アーキテクチャのTiCDC DR

クラスタ2は、リージョン1および2のDRクラスタです。3つのデータレプリカが含まれ、リージョン3で実行されます。データの変更は、TiCDCを介して2つのクラスタ間で同期されます。

この構成は複雑に見えます。しかしながら、フォールトトレランスのターゲットを複数のリージョンに引き上げることができ、秒レベルのRPOと分レベルのRTOを使用できます。システムでマルチリージョンのフォールトトレランスを実現し、データ損失が許容されないRPOを必要としない場合はこのソリューションが最適です。

TiDBの主要なDRソリューションのまとめ

次の表は各ソリューションの利点と欠点をまとめたものです。

TiDBのDRソリューション	利点	欠点
1:1アーキテクチャのTiCDC DR	単一リージョンのフォールトトレランス 秒レベルのRPO 分またはそれ以下のレベルのRTO 2-1-1アーキテクチャ よりも回復力が高い 読み取りと書き込みのスケーラビリティ 費用対効果が高い	複数リージョンの障害に耐えられない
2-2-1アーキテクチャのマルチレプリカDR	単一リージョンのフォールトトレランス データ損失が許容されないRPO 分またはそれ以下のレベルのRTO 費用対効果が高い	データベース応答時間の増加 複数リージョンの障害に耐え られない
2-2-1:1アーキテクチャのTiCDC DR	複数リージョンのフォールトトレランス 秒レベルのRPO 分レベルのRTO	複雑なアーキテクチャ コストがかかる

表1. TiDBのDRソリューションの利点と欠点

これらのDRソリューションに加えて、TiDBはDR自動同期と呼ばれるデュアルサイトDRソリューションを提供します。これは、RaftログのLearnerレプリカと、TiDB Cloud上のバックアップと復元 (BR) ベースのデュアルドメインバックアップ冗長ソリューションに基づいています。これら2つのDRソリューションとその障害シナリオの詳細については、それぞれのオンラインドキュメントを参照してください。

結論

今後の記事では、TiDBのDRソリューションを他の分散SQLデータベースと比較します。また、コンセンサスプロトコルの観点から分散SQLデータベースがDRにもたらしたもの、TiDBの独自のアプローチ、およびTiDBのDR開発の将来の計画についても説明します。乞うご期待！

TiDBまたはそのDRソリューションについて質問やフィードバックがある場合は、Twitter、LinkedIn、またはSlackチャンネルを通じてお気軽にお問い合わせください。TiDBを体験するには、コミュニティエディションまたはTiDB Cloud無料トライアルをお試しください。日本語ドキュメントのTiDBクイックスタートガイド、またはTiDB Cloudワークショップガイドのご利用をお勧めします。ご不明な点などございましたら、お問い合わせフォームよりご連絡ください。

こちらも併せてお読みください。

Technical Paths to HTAP: GreenPlum and TiDB as Examples

HTAPシステムとしてのTiDBの実力は？HATtrickベンチマーク

クラウドストレージサービスでデータベースの地理的冗長性バックアップを簡素化する

Disaster Recovery for Databases: How it Evolves Over Years