TiDB Cloud Serverless の高可用性

TiDB Cloud Serverless は、デフォルトで高可用性とデータ耐久性を維持するための堅牢なメカニズムを備えて設計されており、単一障害点を防ぎ、中断が発生した場合でも継続的なサービスを保証します。実戦でテストされた TiDB オープンソース製品に基づく完全マネージド サービスとして、TiDB のコアとなる高可用性 (HA) 機能を継承し、追加のクラウド ネイティブ機能で強化されています。

概要

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

TiDB Cloud Serverless は、さまざまな運用要件を満たすために、次の 2 種類の高可用性でこれらの機能を拡張します。

• ゾーン高可用性 (デフォルト) : このオプションでは、すべてのノードが単一の可用性ゾーン内に配置され、ネットワークレイテンシーが短縮されます。ゾーン間でアプリケーション レベルの冗長性を必要とせずに高可用性が確保されるため、単一ゾーン内での低レイテンシーを優先するアプリケーションに適しています。ゾーン高可用性は、 TiDB Cloud Serverless をサポートするすべてのリージョンで利用できます。詳細については、 ゾーン高可用性アーキテクチャ参照してください。

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

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

注記：

ゾーン高可用性はデフォルトのオプションであり、 TiDB Cloud Serverless をサポートするすべての AWS リージョンで利用できます。

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

ゾーン高可用性アーキテクチャの場合:

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

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

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

• 障害が発生したレプリカを置き換えるために新しいレプリカが作成されます。

• storageサービスを提供するサーバーは、Amazon S3 上の永続データからローカル キャッシュを回復し、システムをレプリカとの一貫性のある状態に復元します。

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

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

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

リージョン高可用性のクラスターを作成すると、PD や TiKV などの重要な OLTP (オンライン トランザクション処理) ワークロード コンポーネントが複数のアベイラビリティ ゾーンにデプロイされ、冗長レプリケーションが確保され、可用性が最大化されます。通常の操作中は、ゲートウェイ、TiDB、 TiFlashコンピューティング/書き込みノードなどのコンポーネントは、プライマリ アベイラビリティ ゾーンでホストされます。データ プレーンのこれらのコンポーネントは、仮想マシン プールを通じてインフラストラクチャの冗長性を提供し、コロケーションによるフェイルオーバー時間とネットワークレイテンシーを最小限に抑えます。

注記：

• リージョン高可用性は現在ベータ版であり、AWS 東京 ( ap-northeast-1 ) リージョンでのみ利用可能です。
• リージョン高可用性を有効にできるのは、クラスターの作成時のみです。

地域高可用性アーキテクチャの場合:

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

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

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

TiDB Cloud Serverless は、次のアクションを実行することで、プライマリ ゾーンの障害時にサービスの中断を最小限に抑え、ビジネスの継続性を確保します。

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

TiKV レプリケーションによる高可用性の提供に加えて、TiKV インスタンスは、各データ レプリカを異なるアベイラビリティ ゾーンに配置するようにデプロイおよび構成されます。2 つのアベイラビリティ ゾーンが正常に動作している限り、システムは引き続き利用可能です。高い耐久性を実現するために、データを S3 に定期的にバックアップすることでデータの永続性が確保されます。2 つのゾーンで障害が発生しても、S3 に保存されているデータは引き続きアクセス可能で、回復可能です。

アプリケーションは、プライマリ以外のゾーンの障害の影響を受けず、そのようなイベントを認識しません。プライマリ ゾーンの障害時には、ワークロードを処理するために、スタンバイ アベイラビリティ ゾーンで Gateway と TiDB が起動されます。アプリケーションに再試行ロジックを実装して、新しいリクエストをスタンバイ アベイラビリティ ゾーンのアクティブ サーバーにリダイレクトするようにしてください。

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

データベースのバックアップは、ビジネスの継続性と災害復旧に不可欠であり、データの破損や誤った削除からデータを保護するのに役立ちます。バックアップを使用すると、保持期間内の特定の時点にデータベースを復元できるため、データの損失とダウンタイムを最小限に抑えることができます。

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

• 毎日の完全バックアップ: データベースの完全なバックアップが 1 日に 1 回作成され、データベース全体の状態がキャプチャされます。
• 継続的なトランザクション ログのバックアップ:トランザクションログは約 5 分ごとに継続的にバックアップされますが、正確な頻度はデータベースのアクティビティによって異なります。

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

注記：

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

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

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

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

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

RTO と RPO

ビジネス継続計画を作成するときは、次の 2 つの主要な指標を考慮してください。

• 回復時間目標 (RTO): 中断イベント後にアプリケーションが完全に回復するまでにかかる最大許容時間。
• リカバリポイント目標 (RPO): 計画外の中断イベントからのリカバリ中にアプリケーションが失うことを許容できる最新のデータ更新の最大許容時間間隔。

次の表は、各高可用性オプションの RTO と RPO を比較したものです。