ApsaraDB for Redis:マスターレプリカ切り替えの実行

原因

• インスタンスホストでの障害

  Alibaba Cloudが、インスタンスの基盤となるホストに障害が発生していることを検出した場合 (インスタンスの高負荷によるプロセスの異常終了やメモリの異常など) 、システムはすぐにマスター-レプリカの切り替えをトリガーします。 この迅速な操作により、インスタンスがタイムリーに復元され、障害による中断の継続時間が最小限に抑えられます。

  このようなイベントは、 次の形式の内部メッセージまたはメール:

  [Alibaba Cloud] 親愛なる ****: ApsaraDB for Redisインスタンスr-bp1zxszhcgatnx **** (名前: ****) で異常が検出されました。 インスタンスの安定した動作を保証するために、HAスイッチオーバーがトリガーされます。 アプリケーションがまだインスタンスに接続されているかどうかを確認し、インスタンスに自動的に再接続するようにアプリケーションを設定することを推奨します。

• インスタンスホストの隠れたリスク

  Alibaba Cloudが、ネットワークのジッターやディスクの異常など、インスタンスの基盤となるホストのリスクを検出した場合、インスタンスの通常動作に将来的に影響を与える可能性があることを示しています。 このような場合、システムはリスクを処理するためにプロアクティブなO&Mタスクを自動的に開始し、メンテナンス期間中にマスターレプリカ切り替えをトリガーしてリスクのあるホストノードを置き換えます。

  ただし、緊急のリスク修復が必要なイベントの場合、システムは問題を解決し、マスター /レプリカの切り替えを開始するために迅速なアクションを実行します。 たとえば、Redisコミュニティで重大なバグが特定された場合、関連するインスタンスはマイナーバージョンの更新を積極的に受けます。 イベント履歴でそのようなアクションのレコードを照会できます。 詳細については、「」「履歴イベントの照会」をご参照ください。 保留中のマスターレプリカ切り替えイベントを管理することもできます。 詳細については、「」「スケジュールイベントの表示と管理」をご参照ください。

影響

インスタンスは自動的に切り替えプロセス全体を完了します。 切り替えが完了すると、インスタンスは期待どおりに実行されます。

ただし、切り替えプロセス中に次の状況が発生する可能性があります。

• 切り替えが実行されるデータノードは数秒間切断され、最大30秒間は読み取り専用のままになります。

• インスタンスが [切り替え] 状態になると、インスタンスを管理できなくなります。 たとえば、インスタンス設定を変更したり、インスタンスを別のゾーンに移行したりすることはできません。 マスター /レプリカの切り替えが完了すると、インスタンスの状態が [実行中] に変わります。

提案事項

• インスタンスに自動的に再接続するか、例外を処理するようにアプリケーションが構成されていることを確認します。 それ以外の場合、切り替え中に次のいずれかのエラーメッセージが返される場合があります。READONLY You can't write against a read only instanceまたはDISABLE You can't write or read against a disable instance。

• インスタンスに対してマスター /レプリカの切り替えがトリガーされると、インスタンスは自動的に切り替えプロセス全体を完了します。これは、レプリカノードを新しいマスターノードに昇格させ、マスターノードとレプリカノード間のデータ同期のために別のレプリカノードを作成するためです。 このプロセス中に操作を実行する必要はありません。

  説明

  デュアルゾーンインスタンスのマスターレプリカ切り替えが完了すると、マスターノードはセカンダリゾーンに存在し、レプリカノードはプライマリゾーンに存在します。 これにより、インスタンスと他のサービス間でクロスゾーンアクセスが発生する可能性があります。 この問題を解決するには、コンソールの サービスの可用性 ページでゾーンを手動で切り替えることができます。

関連ドキュメント

Redisでは、マルチゾーン展開シナリオでディザスタリカバリドリルや近隣の接続のために、マスターレプリカ切り替えを手動でトリガーすることもできます。 詳細については、「マスターノードからレプリカノードへのワークロードの手動切り替え」をご参照ください。

よくある質問

• インスタンス障害によってトリガーされるマスターレプリカ切り替えの原則は何ですか?

  HAシステムは、そのライブネス検出メカニズムに依存して障害を検出する。 次の表に、HAのメカニズムを示します。

  主要イベント	説明
  ヘルスチェック	HAシステムは、マスターノードとレプリカノードが正常かどうかをチェックします。
  マスターノード障害	マスターノードが利用できないと判断された場合、レプリカノードがマスターノードとして機能します。 同時に、レプリカノードの仮想IPアドレス (VIP) が使用されますが、インスタンスのエンドポイントは変更されません。 データ同期を確保するために別のレプリカノードが作成されます。
  レプリカノード障害	レプリカノードが使用できないと判断されると、別のレプリカノードが自動的に作成され、データ同期が保証され、マスター-レプリカアーキテクチャのデータ永続性が維持されます。

  説明

  マスターノードに最近書き込まれた特定のデータは、マスターノードとレプリカノードの間の同期が非同期的に実装されるために失われる可能性があります。

• 読み書き分離インスタンスに対してトリガーされたマスターレプリカスイッチオーバーは、インスタンスでのリードレプリカの使用に影響しますか。

  切り替え中、使用可能なリードレプリカの数は1つ減ります。 切り替えが完了すると、システムは通常に戻ります。

• インスタンスがクラスターマスターレプリカインスタンスの場合、インスタンス内の特定のデータシャードに対してトリガーされたマスターレプリカスイッチオーバーはインスタンス全体に影響しますか。

  インスタンス全体は影響を受けません。 データシャードのみが影響を受けます。