マルチ AZ による ElastiCache for Redis のダウンタイムの最小化

ElastiCache for Redis がプライマリノードを置き換える必要があるインスタンスが多数あります。これには、特定のタイプの計画されたメンテナンスや、プライマリノードまたはアベイラビリティーゾーンの予期できない障害などが含まれます。

この置き換えにより、クラスターのダウンタイムが発生しますが、マルチ AZ が有効になっている場合、ダウンタイムは最小限に抑えられます。プライマリノードのロールは、いずれかのリードレプリカに自動的にフェイルオーバーされます。ElastiCache ではこれを透過的に処理するため、新しいプライマリノードを作成してプロビジョニングする必要はありません。このフェイルオーバーとレプリカの昇格により、昇格が完了したらすぐに新しいプライマリへの書き込みを再開できます。

また、ElastiCache は昇格されたレプリカのドメイン名サービス (DNS) 名を伝達します。これを行うのは、アプリケーションがプライマリエンドポイントに書き込みを行う場合、アプリケーションでエンドポイントの変更が必要なくなるためです。個別のエンドポイントから読み取りを行う場合は、プライマリに昇格されたレプリカの読み取りエンドポイントを新しいレプリカのエンドポイントに変更してください。

メンテナンス更新やセルフサービス更新に伴って開始された計画的なノード置換の場合:

• ElastiCache for Redis クラスターでは、クラスターが着信した書き込みリクエストを処理している間に、計画されたノードの置換が完了します。

• Redis クラスターモードが無効で、マルチ AZ が有効になっているクラスターが 5.0.6 以降のエンジンで実行されている場合、クラスターが着信した書き込みリクエストを処理している間に、計画されたノード置換が完了します。

• Redis クラスターモードが無効で、マルチ AZ が有効になっているクラスターでが 4.0.10 以前のエンジンで実行されている場合、DNS の更新に伴って短い書き込みの中断が発生することがあります。この中断は数秒続く場合があります。このプロセスは、新しいプライマリを再作成してプロビジョニングする (マルチ AZ を有効にしない場合に発生すること) よりもはるかに高速です。

マルチ AZ を有効にするには、ElastiCache マネジメントコンソール、AWS CLI、または ElastiCache API を使用できます。

Redis クラスターで ElastiCache のマルチ AZ を有効にすると (API、CLI、レプリケーショングループ内)、耐障害性が向上します。これは特に、クラスターの読み取り/書き込みプライマリクラスタノードが到達できなくなった場合、または何らかの理由で障害が発生した場合に当てはまります。マルチ AZ は、各シャードに複数のノードがある Redis クラスターでのみサポートされます。

マルチ AZ の有効化

クラスターの作成時または変更時にマルチ AZ を有効にするには (API、CLI、レプリケーショングループ内)、ElastiCache コンソール、AWS CLI、または ElastiCache API を使用できます。

マルチ AZ は、使用可能なリードレプリカが少なくとも 1 つある Redis (クラスターモードが無効) クラスターでのみ有効にすることができます。リードレプリカのないクラスターでは、高可用性や耐障害性は提供されません。レプリケーションが有効なクラスターの作成については、「Redis レプリケーショングループの作成」を参照してください。レプリケーションが有効なクラスターへのリードレプリカの追加については、「Redis (クラスターモードが無効) レプリケーショングループのリードレプリカの追加」を参照してください。

トピック

• マルチ AZ の有効化 (コンソール)
• マルチ AZ の有効化 (AWS CLI)
• マルチ AZ の有効化 (ElastiCache API)

マルチ AZ の有効化 (コンソール)

ElastiCache コンソールを使用して、新しい Redis クラスターの作成時や、レプリケーションが有効になっている既存の Redis クラスターの変更時に、マルチ AZ を有効にすることができます。

マルチ AZ は、Redis (クラスターモードが有効) クラスターでデフォルトで有効になります。

重要

ElastiCache は、クラスターにすべてのシャードのプライマリとは異なるアベイラビリティーゾーンに少なくとも 1 つのレプリカが含まれている場合にのみ、マルチ AZ を自動的に有効にします。

ElastiCache コンソールを使用したクラスター作成時のマルチ AZ の有効化

このプロセスの詳細については、「Redis (クラスターモードが無効) クラスターの作成 (コンソール)」を参照してください。必ず 1 つ以上のレプリカを用意して、マルチ AZ を有効にしてください。

既存のクラスターでのマルチ AZ の有効化 (コンソール)

このプロセスの詳細については、「AWS Management Console を使用する場合」でクラスターの変更に関する説明を参照してください。

マルチ AZ の有効化 (AWS CLI)

次のコード例では、AWS CLI を使用して、レプリケーショングループ redis12 のマルチ AZ を有効にします。

重要

レプリケーショングループ redis12 が既に存在しており、少なくとも 1 個の利用可能なリードレプリカが必要となります。

Linux、macOS、Unix の場合:

aws elasticache modify-replication-group \
    --replication-group-id redis12 \
    --automatic-failover-enabled \
    --multi-az-enabled \
    --apply-immediately

Windows の場合:

aws elasticache modify-replication-group ^
    --replication-group-id redis12 ^
    --automatic-failover-enabled ^
    --multi-az-enabled ^
    --apply-immediately

このコマンドの JSON 出力は次のようになります。

{
    "ReplicationGroup": {
        "Status": "modifying", 
        "Description": "One shard, two nodes", 
        "NodeGroups": [
            {
                "Status": "modifying", 
                "NodeGroupMembers": [
                    {
                        "CurrentRole": "primary", 
                        "PreferredAvailabilityZone": "us-west-2b", 
                        "CacheNodeId": "0001", 
                        "ReadEndpoint": {
                            "Port": 6379, 
                            "Address": "redis12-001.v5r9dc.0001.usw2.cache.amazonaws.com"
                        }, 
                        "CacheClusterId": "redis12-001"
                    }, 
                    {
                        "CurrentRole": "replica", 
                        "PreferredAvailabilityZone": "us-west-2a", 
                        "CacheNodeId": "0001", 
                        "ReadEndpoint": {
                            "Port": 6379, 
                            "Address": "redis12-002.v5r9dc.0001.usw2.cache.amazonaws.com"
                        }, 
                        "CacheClusterId": "redis12-002"
                    }
                ], 
                "NodeGroupId": "0001", 
                "PrimaryEndpoint": {
                    "Port": 6379, 
                    "Address": "redis12.v5r9dc.ng.0001.usw2.cache.amazonaws.com"
                }
            }
        ], 
        "ReplicationGroupId": "redis12", 
        "SnapshotRetentionLimit": 1, 
        "AutomaticFailover": "enabling", 
        "MultiAZ": "enabled", 
        "SnapshotWindow": "07:00-08:00", 
        "SnapshottingClusterId": "redis12-002", 
        "MemberClusters": [
            "redis12-001", 
            "redis12-002"
        ], 
        "PendingModifiedValues": {}
    }
}

詳細については、AWS CLI コマンドリファレンスの以下のトピックを参照してください。

• create-cache-cluster

• create-replication-group

• AWS CLI コマンドリファレンスの modify-replication-group。

マルチ AZ の有効化 (ElastiCache API)

次のコード例では、ElastiCache API を使用して、レプリケーショングループ redis12 のマルチ AZ を有効にします。

注記

この例を使用するには、レプリケーショングループ redis12 が既に存在していて、少なくとも 1 個の利用可能なリードレプリカがある必要があります。

https://elasticache.us-west-2.amazonaws.com/
    ?Action=ModifyReplicationGroup
    &ApplyImmediately=true
    &AutoFailover=true
    &MultiAZEnabled=true
    &ReplicationGroupId=redis12
    &Version=2015-02-02
    &SignatureVersion=4
    &SignatureMethod=HmacSHA256
    &Timestamp=20140401T192317Z
    &X-Amz-Credential=<credential>

詳細については、ElastiCache API リファレンスの以下のトピックを参照してください。

• CreateCacheCluster

• CreateReplicationGroup

• ModifyReplicationGroup

障害シナリオとマルチ AZ のレスポンス

マルチ AZ の導入前は、ElastiCache でクラスターの失敗したノードを検出し、失敗したノードを再作成およびプロビジョニングすることで置き換えました。マルチ AZ を有効にすると、失敗したプライマリノードはレプリケーションの遅延が最も小さいレプリカにフェイルオーバーされます。選択されたレプリカは自動的にプライマリに昇格されます。このプロセスは、新しいプライマリノードを作成して再プロビジョニングするよりも大幅に高速です。通常は数秒で、クラスターへの書き込みが再び可能になります。

マルチ AZ を有効にすると、ElastiCache はプライマリノードの状態を継続的にモニタリングします。プライマリノードが失敗すると、失敗のタイプに応じて次のいずれかのアクションが実行されます。

トピック

• プライマリノードのみが失敗した場合の障害シナリオ
• プライマリノードと複数のリードレプリカが失敗した場合の障害シナリオ
• クラスター全体が失敗した場合の障害シナリオ

プライマリノードのみが失敗した場合の障害シナリオ

プライマリノードのみが失敗した場合、レプリケーションの遅延が最も小さいリードレプリカがプライマリに昇格されます。次に、失敗したプライマリと同じアベイラビリティーゾーンに置換リードレプリカが作成されてプロビジョニングされます。

プライマリノードのみが失敗した場合、ElastiCache のマルチ AZ は次の処理を行います。

1. 失敗したプライマリノードがオフラインになります。

2. レプリケーションの遅延が最短のリードレプリカがプライマリに昇格されます。

   書き込みは、昇格プロセスが完了するとすぐに (通常は数秒) 再開できます。アプリケーションからプライマリエンドポイントに書き込む場合、書き込み用または読み取り用のエンドポイントを変更する必要はありません。ElastiCache は、昇格されたレプリカの DNS 名を伝達します。

3. 置き換えられたリードレプリカが起動し、プロビジョニングされます。

   ノードのディストリビューションが維持されるように、障害が発生したプライマリノードがあったアベイラビリティーゾーンで置き換えリードレプリカが起動されます。

4. レプリカが新しいプライマリノードと同期されます。

新しいレプリカが使用可能になった後は、次の影響に注意してください。

• [プライマリエンドポイント] – 新しいプライマリノードの DNS 名がプライマリエンドポイントに伝達されるため、アプリケーションに変更は加えません。

• [読み取りエンドポイント] – 読み取りエンドポイントは、新しいレプリカノードを指すように自動的に更新されます。

クラスターのエンドポイントの検索については、以下のトピックを参照してください。

• Redis (クラスターモードが無効) クラスターのエンドポイント (コンソール)

• レプリケーショングループのエンドポイントの検索 (AWS CLI)

• レプリケーショングループのエンドポイントの検索 (ElastiCache API)

 

プライマリノードと複数のリードレプリカが失敗した場合の障害シナリオ

プライマリおよび少なくとも 1 つのリードレプリカで障害が発生した場合、利用可能でレプリケーションの遅延が最も少ないレプリカが、プライマリクラスターに昇格されます。また、障害が発生したノードおよびプライマリに昇格されたレプリカと同じアベイラビリティーゾーンで、新しいリードレプリカが作成およびプロビジョニングされます。

プライマリノードと複数のリードレプリカが失敗すると、ElastiCache のマルチ AZ は次の処理を行います。

1. 障害が発生したプライマリノードとリードレプリカがオフラインになります。

2. レプリケーションの遅延が最短の使用可能なレプリカがプライマリノードに昇格されます。

   書き込みは、昇格プロセスが完了するとすぐに (通常は数秒) 再開できます。アプリケーションがプライマリエンドポイントに書き込む場合、書き込み用のエンドポイントを変更する必要はありません。ElastiCache は、昇格されたレプリカの DNS 名を伝達します。

3. 複数の置き換えレプリカを作成してプロビジョニングします。

   ノードのディストリビューションが維持されるように、障害が発生したノードのアベイラビリティーゾーンで置き換えレプリカが作成されます。

4. すべてのクラスターが新しいプライマリノードと同期されます。

新しいノードが使用可能になったら、アプリケーションに以下の変更を行います。

• [プライマリエンドポイント] – アプリケーションは変更しないでください。新しいプライマリノードの DNS 名がプライマリエンドポイントに伝達されます。

• [読み取りエンドポイント] – 読み取りエンドポイントは、新しいレプリカノードを指すように自動的に更新されます。

レプリケーショングループのエンドポイントの検索については、次のトピックを参照してください:

• Redis (クラスターモードが無効) クラスターのエンドポイント (コンソール)

• レプリケーショングループのエンドポイントの検索 (AWS CLI)

• レプリケーショングループのエンドポイントの検索 (ElastiCache API)

 

クラスター全体が失敗した場合の障害シナリオ

すべてに障害が発生した場合、すべてのノードは、元のノードと同じアベイラビリティーゾーンで再作成され、プロビジョニングされます。

このシナリオでは、クラスター内のすべてのデータがクラスター内のすべてのノードの障害のために失われます。これはまれにしか発生しません。

クラスター全体が失敗すると、ElastiCache のマルチ AZ は次の処理を行います。

1. 障害が発生したプライマリノードとリードレプリカがオフラインになります。

2. 置き換えプライマリノードが作成され、プロビジョニングされます。

3. 複数の置き換えレプリカを作成してプロビジョニングします。

   ノードのディストリビューションが維持されるように、障害が発生したノードのアベイラビリティーゾーンで置き換えレプリカが作成されます。

   クラスター全体に障害が発生したため、データが失われ、すべての新しいノードがコールド起動されます。

置換先の各ノードと置換元のノードはエンドポイントが同じであるため、アプリケーションでエンドポイントを変更する必要はありません。

レプリケーショングループのエンドポイントの検索については、次のトピックを参照してください:

• Redis (クラスターモードが無効) クラスターのエンドポイント (コンソール)

• レプリケーショングループのエンドポイントの検索 (AWS CLI)

• レプリケーショングループのエンドポイントの検索 (ElastiCache API)

耐障害性レベルを上げるために、プライマリノードとリードレプリカは別々のアベイラビリティーゾーンに作成することをお勧めします。

自動フェイルオーバーのテスト

自動フェイルオーバーを有効にしたら、ElastiCache コンソール、AWS CLI、または ElastiCache API を使用してテストできます。

テストを行う場合、以下の点に注意してください。

• このオペレーションを使用して、任意のローリング期間の 24 時間あたり、最大 5 つのシャード (ElastiCache API および AWS CLI ではノードグループと呼ばれます) で自動フェイルオーバーをテストできます。

• 別のクラスターのシャード (API および CLI ではレプリケーショングループと呼ばれます) でこのオペレーションを呼び出す場合、同時に呼び出しを行うことができます。

• 場合によっては、同じ Redis (クラスターモードが有効) レプリケーショングループの複数の異なるシャードに対して、このオペレーションを複数回呼び出すことがあります。このような場合、後続の呼び出しを行う前に、最初のノードの置換が完了する必要があります。

• ノードの置換が完了しているかどうか調べるには、Amazon ElastiCache コンソール、AWS CLI、または ElastiCache API を使用してイベントを確認します。自動フェイルオーバーに関連する次のイベントを検索します。ここでは、発生すると思われる順番にイベントを示します。

  1. レプリケーショングループメッセージ: Test Failover API called for node group <node-group-id>

  2. キャッシュクラスターメッセージ: Failover from primary node <primary-node-id> to replica node <node-id> completed

  3. レプリケーショングループメッセージ: Failover from primary node <primary-node-id> to replica node <node-id> completed

  4. キャッシュクラスターメッセージ: Recovering cache nodes <node-id>

  5. キャッシュクラスターメッセージ: Finished recovery for cache nodes <node-id>

  詳細については、次を参照してください。

  • ElastiCache ユーザーガイドの ElastiCache イベントの表示

  • ElastiCache API リファレンスの DescribeEvents

  • AWS CLI コマンドリファレンスの describe-events。

• この API は、ElastiCache でフェイルオーバーが発生した場合のアプリケーションの動作をテストするために設計されています。クラスターの問題に対処するためにフェイルオーバーを開始するための運用ツールとしては設計されていません。さらに、大規模な運用イベントなどの特定の条件下では、AWS がこの API をブロックする可能性があります。

トピック

• AWS Management Console を使用した自動フェイルオーバーのテスト
• AWS CLI を使用した自動フェイルオーバーのテスト
• ElastiCache API を使用した自動フェイルオーバーのテスト

AWS Management Console を使用した自動フェイルオーバーのテスト

コンソールで自動フェイルオーバーをテストするには、次の手順に従います。

自動フェイルオーバーをテストするには

1. AWS Management Console にサインインして、ElastiCache コンソール (https://console.aws.amazon.com/elasticache/) を開きます。

2. ナビゲーションペインで [Redis] を選択します。

3. Redis クラスターの一覧で、テストするクラスターの名前の左にあるチェックボックスをオンにします。このクラスターには、少なくとも 1 つのリードレプリカノードが必要です。

4. [Details] エリアで、このクラスターでマルチ AZ が有効になっていることを確認します。クラスターでマルチ AZ が有効になっていない場合は、別のクラスターを選択するか、このクラスターを変更してマルチ AZ を有効にします。詳細については、「AWS Management Console を使用する場合」を参照してください。

   

5. Redis (クラスターモードが無効) の場合は、クラスターの名前を選択します。

   Redis (クラスターモードが有効) の場合、次の手順を実行します。

   1. クラスターの名前を選択します。

   2. [Shards] ページで、フェイルオーバーをテストするシャード (API および CLI ではノードグループと呼ばれます) のシャード名を選択します。

6. [Nodes] ページで [Failover Primary] を選択します。

7. [Continue] を選択してプライマリをフェイルオーバーするか、[Cancel] を選択してプライマリノードへのフェイルオーバーをキャンセルします。

   フェイルオーバープロセス中は、コンソールでノードのステータスが [available] と継続して表示されます。フェイルオーバーテストの進捗状況を追跡するには、コンソールのナビゲーションペインから [Events] を選択します。[Events] タブで、フェイルオーバーの開始 (Test Failover API called) と完了 (Recovery completed) を示すイベントを監視します。

 

AWS CLI を使用した自動フェイルオーバーのテスト

マルチ AZ が有効になっているクラスターで自動フェイルオーバーをテストするには、AWS CLI オペレーションの test-failover を使用できます。

パラメータ

• --replication-group-id – 必須。テストするレプリケーショングループ (コンソールではクラスター)。

• --node-group-id – 必須。自動フェイルオーバーをテストするノードグループの名前。ローリング期間の 24 時間あたり、最大 5 つのノードグループをテストできます。

次の例では、AWS CLI を使用して、Redis (クラスターモードが有効) クラスター redis00 のノードグループ redis00-0003 で自動フェイルオーバーをテストします。

例 自動フェイルオーバーをテストする

Linux、macOS、Unix の場合:

aws elasticache test-failover \
   --replication-group-id redis00 \
   --node-group-id redis00-0003

Windows の場合:

aws elasticache test-failover ^
   --replication-group-id redis00 ^
   --node-group-id redis00-0003

上のコマンドによる出力は次のようになります。

{
    "ReplicationGroup": {
        "Status": "available", 
        "Description": "1 shard, 3 nodes (1 + 2 replicas)", 
        "NodeGroups": [
            {
                "Status": "available", 
                "NodeGroupMembers": [
                    {
                        "CurrentRole": "primary", 
                        "PreferredAvailabilityZone": "us-west-2c", 
                        "CacheNodeId": "0001", 
                        "ReadEndpoint": {
                            "Port": 6379, 
                            "Address": "redis1x3-001.7ekv3t.0001.usw2.cache.amazonaws.com"
                        }, 
                        "CacheClusterId": "redis1x3-001"
                    }, 
                    {
                        "CurrentRole": "replica", 
                        "PreferredAvailabilityZone": "us-west-2a", 
                        "CacheNodeId": "0001", 
                        "ReadEndpoint": {
                            "Port": 6379, 
                            "Address": "redis1x3-002.7ekv3t.0001.usw2.cache.amazonaws.com"
                        }, 
                        "CacheClusterId": "redis1x3-002"
                    }, 
                    {
                        "CurrentRole": "replica", 
                        "PreferredAvailabilityZone": "us-west-2b", 
                        "CacheNodeId": "0001", 
                        "ReadEndpoint": {
                            "Port": 6379, 
                            "Address": "redis1x3-003.7ekv3t.0001.usw2.cache.amazonaws.com"
                        }, 
                        "CacheClusterId": "redis1x3-003"
                    }
                ], 
                "NodeGroupId": "0001", 
                "PrimaryEndpoint": {
                    "Port": 6379, 
                    "Address": "redis1x3.7ekv3t.ng.0001.usw2.cache.amazonaws.com"
                }
            }
        ], 
        "ClusterEnabled": false, 
        "ReplicationGroupId": "redis1x3", 
        "SnapshotRetentionLimit": 1, 
        "AutomaticFailover": "enabled", 
        "MultiAZ": "enabled",
        "SnapshotWindow": "11:30-12:30", 
        "SnapshottingClusterId": "redis1x3-002", 
        "MemberClusters": [
            "redis1x3-001", 
            "redis1x3-002", 
            "redis1x3-003"
        ], 
        "CacheNodeType": "cache.m3.medium", 
        "DataTiering": "disabled",
        "PendingModifiedValues": {}
    }
}

フェイルオーバーの進行状況を追跡するには、AWS CLI describe-events オペレーションを使用します。

詳細については、次を参照してください。

• AWS CLI コマンドリファレンスの test-failover。

• AWS CLI コマンドリファレンスの describe-events。

 

ElastiCache API を使用した自動フェイルオーバーのテスト

マルチ AZ が有効になっている任意のクラスターで自動フェイルオーバーをテストするには、ElastiCache API オペレーションの TestFailover を使用できます。

パラメータ

• ReplicationGroupId – 必須。テスト対象のレプリケーショングループ (コンソールではクラスター)。

• NodeGroupId – 必須。自動フェイルオーバーをテストする対象のノードグループの名前。ローリング期間の 24 時間あたり、最大 5 つのノードグループをテストできます。

次の例では、レプリケーショングループ (コンソールではクラスター) redis00 のノードグループ redis00-0003 で、自動フェイルオーバーをテストします。

例 自動フェイルオーバーのテスト

https://elasticache.us-west-2.amazonaws.com/
    ?Action=TestFailover
    &NodeGroupId=redis00-0003
    &ReplicationGroupId=redis00
    &Version=2015-02-02
    &SignatureVersion=4
    &SignatureMethod=HmacSHA256
    &Timestamp=20140401T192317Z
    &X-Amz-Credential=<credential>

フェイルオーバーの進行状況を追跡するには、ElastiCache の DescribeEvents API オペレーションを使用します。

詳細については、次を参照してください。

• ElastiCache API リファレンスの TestFailoverの

• ElastiCache API リファレンスの DescribeEvents

 

Redis のマルチ AZ の制限事項

Redis のマルチ AZ に関する次の制限事項に注意してください。

• マルチ AZ は、Redis バージョン 2.8.6 以降でサポートされます。

• Redis のマルチ AZ は、T1 ノードタイプではサポートされません。

• Redis レプリケーションは非同期で行われます。そのため、プライマリノードがレプリカにフェイルオーバーすると、レプリケーションの遅延のために少量のデータが失われる可能性があります。

  プライマリに昇格させるレプリカを選択する際には、ElastiCache for Redis はレプリケーションの遅延が最短のレプリカを選択します。言い換えると、最新のレプリカを選択します。これにより、失われるデータ量が最小限に抑えられます。レプリケーションの遅延が最短のレプリカは、障害が発生したプライマリノードと同じ、または異なるアベイラビリティーゾーンに存在できます。

• マルチ AZ と自動フェイルオーバーが無効なときにのみ、Redis (クラスターモードが無効) でリードレプリカを手動でプライマリに昇格させることができます。リードレプリカをプライマリに昇格させるには、以下のステップを実行します。

  1. クラスターでマルチ AZ を無効にします。

  2. クラスターで自動フェイルオーバーを無効にします。これを行うには、Redis コンソールを使用して、レプリケーショングループの [自動フェイルオーバー] チェックボックスをクリアします。これを行うには、AWS CLI を使用して、ModifyReplicationGroup オペレーションを呼び出す際に AutomaticFailoverEnabled プロパティを false に設定します。

  3. リードレプリカをプライマリに昇格させます。

  4. マルチ AZ を再度有効にします。

• ElastiCache for Redis のマルチ AZ および AOF (Append-Only File) は、相互に排他的です。一方を有効にすると、他方を有効にすることはできません。

• アベイラビリティーゾーン全体の障害というまれなイベントにより、ノードの障害が発生することがあります。この場合、障害の発生したプライマリを置き換えるレプリカは、アベイラビリティーゾーンがバックアップされているときのみ作成されます。たとえば、AZ-a のプライマリおよび AZ-b および AZ-c のレプリカを持つレプリケーショングループを考えてみます。プライマリに障害が発生した場合、レプリケーションの遅延が最も小さい利用可能なレプリカをプライマリクラスターに昇格します。その後、AZ-a がバックアップとなっていて使用可能な場合にのみ、ElastiCache は AZ-a 内 (障害が発生したプライマリがあった場所) に新しいレプリカを作成します。

• プライマリの再起動をお客様が開始した場合、自動フェイルオーバーはトリガーされません。他の再起動と障害は、自動フェイルオーバーをトリガーします。

• プライマリが再起動すると、オンラインに戻ったときにデータがクリアされます。リードレプリカがクリアされたプライマリクラスターを検出すると、データのコピーがクリアされるため、データ損失が発生します。

• リードレプリカが昇格されると、他のレプリカは新しいプライマリと同期されます。最初の同期後に、レプリカのコンテンツは削除され、新しいプライマリからデータが同期されます。この同期プロセスに伴って一時的に中断が発生し、その間はレプリカにアクセスできなくなります。また、この同期プロセスに伴ってレプリカとの同期中にプライマリで一時的にロードが増えます。この動作は、Redis にネイティブであり、ElastiCache のマルチ AZ に特有ではありません。Redis の当該動作の詳細については、Redis ウェブサイトの「のレプリケーション」を参照してください。

重要

Redis バージョン 2.8.22 以降では、外部レプリカを作成できません。

2.8.22 より前のバージョンの Redis では、マルチ AZ が有効になっている ElastiCache for Redis クラスターに、Redis の外部レプリカを接続しないようお勧めします。このサポートされていない設定により、問題が発生し、ElastiCache がフェイルオーバーや復旧を正しく実行できなくなる場合があります。Redis の外部レプリカを ElastiCache クラスターに接続する場合は、接続する前にマルチ AZ が有効になっていないことを確認してください。