TiDB Cloudにおける高可用性

TiDB Cloudは、デフォルトで高い可用性とデータの耐久性を維持する堅牢なメカニズムを備えており、単一障害点を防止し、障害発生時でも継続的なサービスを保証します。実績のあるTiDBオープンソース製品をベースにしたフルマネージドサービスとして、TiDBの中核となる高可用性（HA）機能を継承し、さらにクラウドネイティブな機能を追加しています。

注記：

• このドキュメントは、 TiDB Cloud Starter、 TiDB Cloud Essential、およびTiDB Cloud Premiumにのみ適用されます。
• TiDB Cloud Dedicatedの高可用性については、 TiDB Cloud Dedicatedにおける高可用性参照してください。

概要

TiDBは、 Raftコンセンサスアルゴリズムを用いて高い可用性とデータの耐久性を確保します。このアルゴリズムは、複数のノード間でデータの変更を一貫して複製するため、ノード障害やネットワーク分断が発生した場合でも、TiDBは読み取りおよび書き込み要求を処理できます。このアプローチにより、高いデータの耐久性と耐障害性の両方が実現されます。

TiDB Cloudは、ゾーン別高可用性とリージョン別高可用性によってこれらの機能を拡張し、さまざまな運用要件に対応します。

注記：

• TiDB Cloud Starterインスタンスでは、ゾーン別高可用性のみが有効になっており、設定変更はできません。
• TiDB Cloud Premiumインスタンスでは、リージョンごとの高可用性のみが有効になっており、設定変更はできません。
• AWS 東京 (ap-northeast-1) リージョンまたは Alibaba Cloud のいずれかのリージョンでホストされているTiDB Cloud Essentialインスタンスの場合、リージョンレベルの高可用性がデフォルトで有効になっています。必要に応じて、 TiDB Cloud Essentialインスタンスの作成時にゾーンレベルの高可用性に変更できます。その他のリージョンでホストされているTiDB Cloud Essentialインスタンスの場合、ゾーンレベルの高可用性のみが有効になっており、設定変更はできません。

• ゾーン高可用性：このオプションでは、すべてのノードを単一の可用性ゾーン内に配置することで、ネットワークレイテンシーを低減します。ゾーン間でアプリケーションレベルの冗長性を必要とせずに高可用性を確保するため、単一ゾーン内での低レイテンシーを優先するアプリケーションに適しています。詳細については、ゾーン別高可用性アーキテクチャ参照してください。

• 地域別高可用性 (ベータ版) : このオプションでは、ノードを複数の可用性ゾーンに分散し、インフラストラクチャの分離と冗長性を最大限に高めます。最高レベルの可用性を提供しますが、ゾーン間でアプリケーションレベルの冗長性が必要です。ゾーン内のインフラストラクチャ障害に対する最大限の可用性保護が必要な場合は、このオプションを選択することをお勧めします。レイテンシーが増加し、ゾーン間のデータ転送料金が発生する可能性があることに注意してください。この機能は、3 つ以上の可用性ゾーンを持つリージョンで利用できます。詳細については、「地域地域的な高可用性アーキテクチャ参照してください。

ゾーン別高可用性アーキテクチャ

ゾーン高可用性を備えたTiDB Cloud StarterまたはEssentialインスタンスを作成すると、ゲートウェイ、TiDB、TiKV、 TiFlash の計算/書き込みノードを含むすべてのコンポーネントが同じ可用性ゾーンで実行されます。これらのコンポーネントをデータプレーンに配置することで、仮想マシンプールによるインフラストラクチャの冗長性が確保され、フェイルオーバー時間とコロケーションによるネットワークレイテンシーが最小限に抑えられます。

次の図は、AWSにおけるゾーン別高可用性のアーキテクチャを示しています。

ゾーン型高可用性アーキテクチャでは：

• 配置Driver（PD）は複数の可用性ゾーンに展開され、ゾーン間でデータを冗長に複製することで高可用性を確保します。
• データは、ローカル可用性ゾーン内のTiKVサーバーとTiFlash書き込みノード間で複製されます。
• TiDBサーバーとTiFlash計算ノードは、ストレージレベルのレプリケーションによって保護されているTiKVおよびTiFlash書き込みノードとの間で読み書きを行います。

フェイルオーバープロセス

TiDB Cloudは、アプリケーションの透過的なフェイルオーバープロセスを保証します。フェイルオーバー中は、次のようになります。

• 故障したレプリカの代わりに、新しいレプリカが作成される。

• storageサービスを提供するサーバーは、Amazon S3（クラウドプロバイダーによって異なります）に永続化されたデータからローカルキャッシュを復元し、システムをレプリカと整合性のある状態に復元します。

storageレイヤーでは、永続化されたデータは高い耐久性を確保するために定期的にAmazon S3にプッシュされます。さらに、即時更新は複数のTiKVサーバー間で複製されるだけでなく、各サーバーのEBSにも保存され、データの複製がさらに強化されて耐久性が向上します。TiDBは、バックオフと再試行をミリ秒単位で自動的に実行することで問題を解決し、クライアントアプリケーションのフェイルオーバー処理がシームレスに行われるようにします。

ゲートウェイ層とコンピューティング層はステートレスであるため、フェイルオーバー時には、それらを別の場所で即座に再起動する必要があります。アプリケーションは、接続の再試行ロジックを実装する必要があります。ゾーン構成は高可用性を提供しますが、ゾーン全体の障害には対応できません。ゾーンが利用不能になった場合、ゾーンとその依存サービスが復旧するまでダウンタイムが発生します。

地域的な高可用性アーキテクチャ

TiDB Cloud EssentialまたはTiDB Cloud Premium インスタンスをリージョン高可用性構成で作成すると、PD や TiKV などの重要な OLTP (オンライン トランザクション処理) ワークロード コンポーネントが複数の可用性ゾーンに分散配置され、冗長なレプリケーションと可用性の最大化が確保されます。通常運用時には、Gateway、TiDB、 TiFlash の計算/書き込みノードなどのコンポーネントはプライマリ可用性ゾーンに配置されます。データ プレーン内のこれらのコンポーネントは、仮想マシン プールを介してインフラストラクチャの冗長性を提供し、コロケーションによるフェイルオーバー時間とネットワークレイテンシーを最小限に抑えます。

注記：

地域的な高可用性機能は現在ベータ版です。

次の図は、AWSにおけるリージョン別高可用性のアーキテクチャを示しています。

地域的な高可用性アーキテクチャにおいて：

• 配置Driver（PD）とTiKVは複数の可用性ゾーンに展開され、最高レベルの可用性を確保するために、データは常にゾーン間で冗長的に複製されます。
• データは、プライマリ可用性ゾーン内のTiFlash書き込みノード間で複製されます。
• TiDBサーバーとTiFlash計算ノードは、ストレージレベルのレプリケーションによって保護されているこれらのTiKVおよびTiFlash書き込みノードとの間で読み書きを行います。

フェイルオーバープロセス

自然災害、構成変更、ソフトウェアの問題、ハードウェア障害などによってプライマリゾーンに障害が発生するという稀な事態が発生した場合、ゲートウェイやTiDBを含む重要なOLTPワークロードコンポーネントは、スタンバイ可用性ゾーンで自動的に起動されます。トラフィックは自動的にスタンバイゾーンにリダイレクトされ、迅速なリカバリと事業継続性の維持が確保されます。

TiDB Cloudは、プライマリゾーンの障害発生時に以下の動作を実行することで、サービスの中断を最小限に抑え、事業継続性を確保します。

• スタンバイ可用性ゾーンに、ゲートウェイとTiDBの新しいレプリカを自動的に作成します。
• エラスティックロードバランサーを使用して、スタンバイ可用性ゾーン内のアクティブなゲートウェイレプリカを検出し、障害が発生したプライマリゾーンからOLTPトラフィックをリダイレクトします。

TiKVレプリケーションによる高可用性に加え、TiKVインスタンスは各データレプリカが異なる可用性ゾーンに配置されるようにデプロイおよび構成されます。2つの可用性ゾーンが正常に動作している限り、システムは引き続き利用可能です。高い耐久性を確保するため、データは定期的にS3にバックアップされます。2つのゾーンがダウンした場合でも、S3に保存されたデータはアクセス可能で復旧可能です。

アプリケーションは、プライマリゾーン以外のゾーンで発生した障害の影響を受けず、そのような事象を認識することもありません。プライマリゾーンで障害が発生すると、ゲートウェイとTiDBはスタンバイ可用性ゾーンで起動され、ワー​​クロードを処理します。アプリケーションに再試行ロジックを実装し、新しいリクエストをスタンバイ可用性ゾーンのアクティブサーバーにリダイレクトするようにしてください。

自動バックアップと耐久性

データベースのバックアップは、事業継続とディザスタリカバリに不可欠であり、データの破損や誤削除からデータを保護するのに役立ちます。バックアップがあれば、保存期間内の特定の時点にデータベースを復元できるため、データ損失とダウンタイムを最小限に抑えることができます。

TiDB Cloudは、継続的なデータ保護を保証するために、堅牢な自動バックアップメカニズムを提供します。

• 毎日の完全バックアップ：データベースの完全なバックアップが1日に1回作成され、データベース全体の状態が記録されます。
• トランザクションログの継続的なバックアップ：トランザクションログは、データベースのアクティビティに応じて、約5分ごとに継続的にバックアップされます。

これらの自動バックアップ機能により、データベースをフルバックアップから復元することも、フルバックアップと継続的なトランザクションログを組み合わせることで特定の時点から復元することも可能です。この柔軟性により、インシデント発生直前の正確な時点までデータベースを復旧できます。

注記：

スナップショットベースのバックアップや、ポイントインタイムリカバリ（PITR）のための継続的バックアップを含む自動バックアップは、リージョンレベルで高い耐久性を提供するAmazon S3上で実行されます。

障害発生時のセッションへの影響

障害発生時には、障害が発生したサーバー上で進行中のトランザクションが中断される可能性があります。フェイルオーバーはアプリケーションからは透過的ですが、アクティブなトランザクション中に発生する回復可能な障害を処理するロジックを実装する必要があります。さまざまな障害シナリオは、次のように処理されます。

• TiDBの障害：TiDBノードに障害が発生した場合でも、 TiDB Cloudはゲートウェイ経由でトラフィックを自動的に再ルーティングするため、クライアント接続には影響はありません。障害が発生したTiDBノード上のトランザクションは中断される可能性がありますが、システムはコミット済みのデータが保持されるようにし、新しいトランザクションは別の利用可能なTiDBノードで処理されます。
• ゲートウェイ障害：ゲートウェイに障害が発生すると、クライアント接続が中断されます。しかし、 TiDB Cloudゲートウェイはステートレスであるため、新しいゾーンまたはサーバーで即座に再起動できます。トラフィックは自動的に新しいゲートウェイにリダイレクトされるため、ダウンタイムは最小限に抑えられます。

回復可能な障害を処理するために、アプリケーションにリトライロジックを実装することをお勧めします。実装の詳細については、ドライバまたはORMのドキュメント（例： JDBC ）を参照してください。

RTOとRPO

事業継続計画を作成する際には、次の2つの重要な指標を考慮してください。

• 復旧時間目標（RTO）：障害発生後、アプリケーションが完全に復旧するまでに許容される最大時間。
• リカバリポイント目標 (RPO): アプリケーションが予期せぬ障害発生からのリカバリ中に失っても許容できる、最新のデータ更新の最大許容時間間隔。

以下の表は、各高可用性オプションにおけるRTO（目標復旧時間）とRPO（目標復旧時点）を比較したものです。