高可用性サービスは、検出、修復、および通知モジュールを含むいくつかのモジュールから構成されています。組み合わせでは、これらのモジュールは、データリンクサービスの可用性を保証し、任意の内部データベースの例外を処理します。

また、 RDS は、複数のゾーンをサポートするリージョンに移行することにより、適切な高可用性ポリシーを採用することにより、その高可用性サービスの性能を向上させることができます。

検出

DBエンジンのマスターとスレーブノードは、通常、それらのサービスを提供するかどうかを検出モジュールをチェックします。 HA(ご利用可能)ノードがマスターノードの健康状態をチェックするために、8〜10 秒の間隔で取得し、心拍情報を使用しています。他の HA ノードからスレーブノードと心拍情報の健康状態と組み合わされ、この情報は、そのようなネットワーク・ジッタ等の例外に起因する誤判定の危険性を排除するための検出モジュールを可能にし、例外の切り替えは 30 秒以内に完了することができることを可能にします。

修復

修復モジュールは、DB エンジンのマスターとスレーブノードとの間のレプリケーション関係を維持します。また、いずれかのノード上で発生する可能性のあるエラーを修復することができます。

例えば:

  • 断線した場合のマスター/スレーブレプリケーションの自動回復
  • マスタまたはスレーブノードに対してテーブル・レベルの損傷の自動修復
  • マスターまたはスレーブノードのクラッシュであればオンサ​​イト保存と自動修理

通知

お知らせモジュールは、あなたが正しいノードにアクセスし続けることができることを保証するために、マスタとスレーブノードにステータス変更の SLB またはプロキシに通知します。

例えば、検出モジュールは、マスタノードは例外があり、それを修正する修復モジュールに指示することを発見します。修復モジュールは、問題を解決するために失敗した場合は、トラフィックのスイッチングを開始することを通知モジュールに指示します。通知モジュールは、スイッチング転送リクエストスレーブノードへのすべてのトラフィックをリダイレクトし始める SLB またはプロキシに。同時に、修復モジュールは、別の物理サーバ上の新たなスレーブノードを作成し、バック検出モジュールにこの変更を同期させます。検出モジュールは、この新しい情報を取り入れて、インスタンスの健康状態を再確認するために開始します。

マルチゾーン

マルチゾーンは、同じリージョン内の複数の個々のゾーンを組み合わせることによって形成されている物理リージョンを指します。マルチゾーン RDS インスタンスは、シングルゾーンインスタンスよりも高いレベルの災害に耐えることができます。マルチゾーン RDS インスタンスは、データセンター全体の障害などの状況に耐えることができるが、例えば、単一ゾーン RDS インスタンスは、サーバーラックの障害に耐えることができます。

現在、マルチゾーン RDS インスタンスには追加料金が発生しません。マルチゾーンが有効になっているリージョンでユーザが直接マルチゾーン RDS インスタンスを購入するか、ゾーン間の移行を使用して、マルチゾーン RDS インスタンスに単一ゾーン RDS インスタンスを変換することができます。

注意
複数のゾーンは、ネットワーク遅延の一定量を有することができます。マルチゾーン RDS インスタンスが準同期データ複製ソリューションを使用する場合、結果として、任意の個々の更新に対する応答時間が長く、単一ゾーンのインスタンスよりもあってもよいです。この場合、全体のスループットを改善するための最良の方法は、同時実行性を高めることです。

高可用性ポリシー

高可用性のポリシーは、ビジネスニーズを満たすために、サービスの優先順位やデータレプリケーションモードの組み合わせを使用します。

次のようにサービスの優先順位は以下のとおりです。

  • RTO(目標復旧時間)優先順位:データベースは指定した時間枠内で可能な限り早くサービスを復元する必要があります。これは、中断のないオンラインサービスを提供するために、自分のデータベースを必要とするユーザーに最適です。
  • RPO(目標復旧時点)優先順位:データベースは、データの信頼性を保証しなければならない、それは可能な限り小さなデータ損失として、です。これは、その最も優先度の高いデータの一貫性あるユーザーに最適です。

3 つのデータ・レプリケーションの方法があります。

  • 非同期レプリケーション(非同期):

    このモードでは、マスタノードは、直ちにスレーブノードにデータを同期しません。アプリケーションがアップデートを開始するとリクエスト 、マスターノードは、直ちに運転を完了した後、アプリケーションに応答しますが、必ずしもすぐにスレーブノードにそのデータを複製していない、追加、削除、または変更操作含むことができます。これは、スレーブノードが利用できない場合、プライマリ・データベースの動作は影響を受けないが、マスタノードが利用できない場合、データの不整合が発生する可能性があることを意味します。

  • 強制同期レプリケーション(同期):

    アプリケーションが更新(追加、削除、または変更)を開始するときリクエスト 、プライマリ・データベースが操作を完了した後、スタンバイ・データベースにデータを複製します。スタンバイ・データベースは、データを受信した後、それは、プライマリ・データベースに成功メッセージを戻します。プライマリ・データベースは、アプリケーションに応答する前に、スタンバイ・データベースからのフィードバックを待ちます。これは、スレーブノードが利用できない場合、マスターノードの動作が影響を受けるが、マスタとスレーブノード上のデータが常に一貫していることを意味します。

  • 準同期レプリケーション(セミ同期):

    2 つの先行複製モードのハイブリッドとして機能します。両方のノードが正常に機能している場合、このモードでは、データ複製が強制同期複製モードと同一です。このようなスレーブノードが使用不能になる又はネットワーク例外が 2 つのノード間に発生するように例外がある場合しかし、マスタノードは、スレーブノードにデータを複製し、一定期間のためのアプリケーションへの応答を中断しようとし。レプリケーションモードがタイムアウトした後は、マスターノードは、非同期レプリケーションに低下します。マスタノードが利用できなくなり、アプリケーションがスレーブノードからそのデータを更新する場合は、この時点で、それはマスターノード上のデータと一致しています。2 つのノード間のデータ複製が正常に戻ると、スレーブノードまたはネットワーク接続が回復されているため、強制同期複製が復元されます。ノードが強制同期レプリケーションに復帰するのにかかる時間の量は、半同期レプリケーションモードが実装された方法によって異なります。たとえば、 MySQL 5.5 用 ApsaraDB は、この点での MySQL 5.6 用 ApsaraDB は異なっています。

サービスの優先順位やデータレプリケーションモードのいくつかの組み合わせは、データベースとのビジネスニーズを満たすために利用できます。キーの組み合わせの特性を以下の表に詳述されています。

クラウドデータエンジンサービスの優先順位データレプリケーションモードコンビネーション特性
MySQL 5.1 RPO 非同期
  • マスターノードに障害が発生した場合、スレーブノードは、リレーログをすべて適用した後に切り替わります。
  • スレーブノードに障害が発生した場合、マスターノード上のアプリケーションの操作には影響はありません。スレーブノードが回復した後、マスターノード上のデータが同期されます。
MySQL 5.5 RPO 非同期
  • マスターノードに障害が発生した場合、スレーブノードは、リレーログをすべて適用した後に切り替わります。
  • スレーブノードに障害が発生した場合、マスターノード上のアプリケーションの操作には影響はありません。スレーブノードが回復した後、マスターノード上のデータが同期されます。
MySQL 5.5 RTO セミ同期
  • マスターノードに障害が発生し、データ複製が低下した場合、データの一貫性が保証されているため、RDS は、直ちにスレーブノードへの切り替えとの直接トラフィックをトリガします。
  • スレーブノードに障害が発生した場合、マスターノード時間上のアプリケーション操作がアウト、およびデータ・レプリケーションは、非同期レプリケーションに低下します。スレーブノードが回復し、マスターノード上のデータは、強制同期に完全に、データ複製戻る同期された後。
  • 2 つのノードが非同期複製に一貫性のないデータ及びデータ複製モード degrads を有し、一方、マスタノードに障害が発生した場合、スレーブノードは、中継ログの全てを適用した後切り替えます。
MySQL 5.6 RPO 非同期
  • マスターノードに障害が発生した場合、スレーブノードは、リレーログをすべて適用した後に切り替わります。
  • スレーブノードに障害が発生した場合、マスターノード上のアプリケーションの操作には影響はありません。スレーブノードが回復した後、マスターノード上のデータが同期されます。
MySQL 5.6 RTO セミ同期
  • マスターノードに障害が発生し、データ複製 degrads 場合は、データの一貫性が保証されているため、RDS は、直ちにスレーブノードへの切り替えとの直接トラフィックをトリガします。
  • スレーブノードに障害が発生した場合、マスターノード時間上のアプリケーション操作がアウト、およびデータ・レプリケーションは、非同期レプリケーションに低下します。スレーブノードが回復し、マスターノード上のデータは、強制同期に完全に、データ複製戻る同期された後。
  • 2 つのノードが非同期複製に一貫性のないデータ及びデータ複製モード degrads を有し、一方、マスタノードに障害が発生した場合、スレーブノードは、中継ログの全てを適用した後切り替えます。
MySQL 5.6 RPO セミ同期
  • マスターノードに障害が発生し、データ複製が劣化していない場合は、データの一貫性が保証されているため、RDS は、直ちにスレーブノードへの切り替えと直接トラフィックをトリガします。
  • スレーブノードに障害が発生した場合、マスターノード時間上のアプリケーション操作がアウト、およびデータ・レプリケーションは、非同期レプリケーションに低下します。スレーブノードは、再びマスタノードから情報を取得することができる場合、スレーブノードまたはネットワーク接続が回復したため、データ複製が強制同期に戻ります。
  • 2 つのノードが完全に和解することはできません一貫性のないデータとスレーブノード上のデータの違いを持っている間、マスターノードに障害が発生した場合は、API を介してスレーブノードの時間を得ることができます。次に、スイッチオーバーするタイミングを決定することができますし、データを調整するために使用する予定の方法。
MySQL 5.7 XX現在、このエンジンは、調整をサポートしていません。
SQL Server 2008 R2 XX現在、このエンジンは、調整をサポートしていません。
SQL Server 2012 XX現在、このエンジンは、調整をサポートしていません。
PostgreSQLXX現在、このエンジンは、調整をサポートしていません。
PPAS XX現在、このエンジンは、調整をサポートしていません。