翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Valkey および Redis OSS でマルチ AZ を使用して ElastiCache のダウンタイムを最小限に抑える
ElastiCache for Valkey と ElastiCache for Redis OSS では、プライマリノードを置き換える必要がある状況がいくつかあります。これには、特定のタイプの計画的メンテナンスや、プライマリノードまたはアベイラビリティーゾーンの予期しない障害などが含まれます。
この置き換えにより、クラスターのダウンタイムが発生しますが、マルチ AZ が有効になっている場合、ダウンタイムは最小限に抑えられます。プライマリノードのロールは、いずれかのリードレプリカに自動的にフェイルオーバーされます。ElastiCache ではこれを透過的に処理するため、新しいプライマリノードを作成してプロビジョニングする必要はありません。このフェイルオーバーとレプリカの昇格により、昇格が完了したらすぐに新しいプライマリへの書き込みを再開できます。
また、ElastiCache は昇格されたレプリカのドメイン名サービス (DNS) 名を伝達します。これを行うのは、アプリケーションがプライマリエンドポイントに書き込みを行う場合、アプリケーションでエンドポイントの変更が必要なくなるためです。個別のエンドポイントから読み取りを行う場合は、プライマリに昇格されたレプリカの読み取りエンドポイントを新しいレプリカのエンドポイントに変更してください。
メンテナンス更新やセルフサービス更新に伴って開始された計画的なノード置換の場合:
+ Valkey および Redis OSS クラスターでは、クラスターが受信した書き込みリクエストを処理している間に、計画的なノード置換が完了します。
+ Valkey および Redis OSS クラスターモードが無効で、マルチ AZ が有効になっているクラスターが 5.0.6 以降のエンジンで実行されている場合、クラスターが受信した書き込みリクエストを処理している間に、計画的なノード置換が完了します。
+ Valkey および Redis OSS クラスターモードが無効で、マルチ AZ が有効になっているクラスターが 4.0.10 以前のエンジンで実行されている場合、DNS の更新に伴って短い書き込みの中断が発生することがあります。この中断は数秒続く場合があります。このプロセスは、新しいプライマリを再作成してプロビジョニングする (マルチ AZ を有効にしない場合に発生すること) よりもはるかに高速です。
マルチ AZ を有効にするには、ElastiCache マネジメントコンソール、AWS CLI、または ElastiCache API を使用できます。
Valkey または Redis OSS クラスター (API、CLI ではレプリケーショングループ) で ElastiCache のマルチ AZ を有効にすると、耐障害性が向上します。これは特に、クラスターの読み取り/書き込みプライマリクラスタノードが到達できなくなった場合、または何らかの理由で障害が発生した場合に当てはまります。マルチ AZ は、各シャードに複数のノードがある Valkey および Redis OSS クラスターでのみサポートされます。
**Topics**
+ [マルチ AZ の有効化](#AutoFailover.Enable)
+ [障害シナリオとマルチ AZ のレスポンス](#AutoFailover.Scenarios)
+ [自動フェイルオーバーのテスト](#auto-failover-test)
+ [マルチ AZ の制限事項](#AutoFailover.Limitations)
## マルチ AZ の有効化
クラスターの作成時または変更時にマルチ AZ を有効にするには (API、CLI、レプリケーショングループ内)、ElastiCache コンソール、AWS CLI、または ElastiCache API を使用できます。
マルチ AZ は、使用可能なリードレプリカが少なくとも 1 つある Valkey または Redis OSS (クラスターモードが無効) クラスターでのみ有効にすることができます。リードレプリカのないクラスターでは、高可用性や耐障害性は提供されません。レプリケーションが有効なクラスターの作成については、「[Valkey または Redis OSS レプリケーショングループの作成](Replication.CreatingRepGroup.md)」を参照してください。レプリケーションが有効なクラスターへのリードレプリカの追加については、「[Valkey または Redis OSS (クラスターモードが無効) のリードレプリカを追加する](Replication.AddReadReplica.md)」を参照してください。
**Topics**
+ [マルチ AZ の有効化 (コンソール)](#AutoFailover.Enable.Console)
+ [マルチ AZ の有効化 (AWS CLI)](#AutoFailover.Enable.CLI)
+ [マルチ AZ の有効化 (ElastiCache API)](#AutoFailover.Enable.API)
### マルチ AZ の有効化 (コンソール)
ElastiCache コンソールを使用して、新しい Valkey または Redis OSS クラスターの作成時や、レプリケーションが有効になっている既存のクラスターの変更時に、マルチ AZ を有効にすることができます。
マルチ AZ は、Valkey または Redis OSS (クラスターモードが有効) クラスターでデフォルトで有効になります。
**重要**
ElastiCache は、クラスターにすべてのシャードのプライマリとは異なるアベイラビリティーゾーンに少なくとも 1 つのレプリカが含まれている場合にのみ、マルチ AZ を自動的に有効にします。
#### ElastiCache コンソールを使用したクラスター作成時のマルチ AZ の有効化
このプロセスの詳細については、「[Valkey (クラスターモードが無効) クラスターの作成 (コンソール)](SubnetGroups.designing-cluster-pre.valkey.md#Clusters.Create.CON.valkey-gs)」を参照してください。必ず 1 つ以上のレプリカを用意して、マルチ AZ を有効にしてください。
#### 既存のクラスターでのマルチ AZ の有効化 (コンソール)
このプロセスの詳細については、「[ElastiCache AWS マネジメントコンソール の使用](Clusters.Modify.md#Clusters.Modify.CON)」でクラスターの変更に関する説明を参照してください。
### マルチ 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](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-cache-cluster.html)
+ [create-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/create-replication-group.html)
+ *AWS CLI コマンドリファレンス*の [modify-replication-group](https://docs.aws.amazon.com/cli/latest/reference/elasticache/modify-replication-group.html)。
### マルチ 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=
```
詳細については、*ElastiCache API リファレンス*の以下のトピックを参照してください。
+ [CreateCacheCluster](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateCacheCluster.html):
+ [CreateReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_CreateReplicationGroup.html):
+ [ModifyReplicationGroup](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_ModifyReplicationGroup.html)
## 障害シナリオとマルチ AZ のレスポンス
マルチ AZ の導入前は、ElastiCache でクラスターの失敗したノードを検出し、失敗したノードを再作成およびプロビジョニングすることで置き換えました。マルチ AZ を有効にすると、失敗したプライマリノードはレプリケーションの遅延が最も小さいレプリカにフェイルオーバーされます。選択されたレプリカは自動的にプライマリに昇格されます。このプロセスは、新しいプライマリノードを作成して再プロビジョニングするよりも大幅に高速です。通常は数秒で、クラスターへの書き込みが再び可能になります。
マルチ AZ を有効にすると、ElastiCache はプライマリノードの状態を継続的にモニタリングします。プライマリノードが失敗すると、失敗のタイプに応じて次のいずれかのアクションが実行されます。
**Topics**
+ [プライマリノードのみが失敗した場合の障害シナリオ](#AutoFailover.Scenarios.PrimaryOnly)
+ [プライマリノードと複数のリードレプリカが失敗した場合の障害シナリオ](#AutoFailover.Scenarios.PrimaryAndReplicas)
+ [クラスター全体が失敗した場合の障害シナリオ](#AutoFailover.Scenarios.AllFail)
### プライマリノードのみが失敗した場合の障害シナリオ
プライマリノードのみが失敗した場合、レプリケーションの遅延が最も小さいリードレプリカがプライマリに昇格されます。次に、失敗したプライマリと同じアベイラビリティーゾーンに置換リードレプリカが作成されてプロビジョニングされます。
プライマリノードのみが失敗した場合、ElastiCache のマルチ AZ は次の処理を行います。
1. 失敗したプライマリノードがオフラインになります。
1. レプリケーションの遅延が最短のリードレプリカがプライマリに昇格されます。
書き込みは、昇格プロセスが完了するとすぐに (通常は数秒) 再開できます。アプリケーションからプライマリエンドポイントに書き込む場合、書き込み用または読み取り用のエンドポイントを変更する必要はありません。ElastiCache は、昇格されたレプリカの DNS 名を伝達します。
1. 置き換えられたリードレプリカが起動し、プロビジョニングされます。
ノードのディストリビューションが維持されるように、障害が発生したプライマリノードがあったアベイラビリティーゾーンで置き換えリードレプリカが起動されます。
1. レプリカが新しいプライマリノードと同期されます。
新しいレプリカが使用可能になった後は、次の影響に注意してください。
+ [**プライマリエンドポイント**] – 新しいプライマリノードの DNS 名がプライマリエンドポイントに伝達されるため、アプリケーションに変更は加えません。
+ [**読み取りエンドポイント**] – 読み取りエンドポイントは、新しいレプリカノードを指すように自動的に更新されます。
クラスターのエンドポイントの検索については、以下のトピックを参照してください。
+ [Valkey または Redis OSS (クラスターモードが無効) クラスターのエンドポイントを検索する (コンソール)](Endpoints.md#Endpoints.Find.Redis)
+ [Valkey または Redis OSS レプリケーショングループのエンドポイントを検索する (AWS CLI）](Endpoints.md#Endpoints.Find.CLI.ReplGroups)
+ [Valkey または Redis OSS レプリケーショングループのエンドポイントを検索する (ElastiCache API）](Endpoints.md#Endpoints.Find.API.ReplGroups)
### プライマリノードと複数のリードレプリカが失敗した場合の障害シナリオ
プライマリおよび少なくとも 1 つのリードレプリカで障害が発生した場合、利用可能でレプリケーションの遅延が最も少ないレプリカが、プライマリクラスターに昇格されます。また、障害が発生したノードおよびプライマリに昇格されたレプリカと同じアベイラビリティーゾーンで、新しいリードレプリカが作成およびプロビジョニングされます。
プライマリノードと複数のリードレプリカが失敗すると、ElastiCache のマルチ AZ は次の処理を行います。
1. 障害が発生したプライマリノードとリードレプリカがオフラインになります。
1. レプリケーションの遅延が最短の使用可能なレプリカがプライマリノードに昇格されます。
書き込みは、昇格プロセスが完了するとすぐに (通常は数秒) 再開できます。アプリケーションがプライマリエンドポイントに書き込む場合、書き込み用のエンドポイントを変更する必要はありません。ElastiCache は、昇格されたレプリカの DNS 名を伝達します。
1. 複数の置き換えレプリカを作成してプロビジョニングします。
ノードのディストリビューションが維持されるように、障害が発生したノードのアベイラビリティーゾーンで置き換えレプリカが作成されます。
1. すべてのクラスターが新しいプライマリノードと同期されます。
新しいノードが使用可能になったら、アプリケーションに以下の変更を行います。
+ [**プライマリエンドポイント**] – アプリケーションは変更しないでください。新しいプライマリノードの DNS 名がプライマリエンドポイントに伝達されます。
+ [**読み取りエンドポイント**] – 読み取りエンドポイントは、新しいレプリカノードを指すように自動的に更新されます。
レプリケーショングループのエンドポイントの検索については、次のトピックを参照してください:
+ [Valkey または Redis OSS (クラスターモードが無効) クラスターのエンドポイントを検索する (コンソール)](Endpoints.md#Endpoints.Find.Redis)
+ [Valkey または Redis OSS レプリケーショングループのエンドポイントを検索する (AWS CLI）](Endpoints.md#Endpoints.Find.CLI.ReplGroups)
+ [Valkey または Redis OSS レプリケーショングループのエンドポイントを検索する (ElastiCache API）](Endpoints.md#Endpoints.Find.API.ReplGroups)
### クラスター全体が失敗した場合の障害シナリオ
すべてに障害が発生した場合、すべてのノードは、元のノードと同じアベイラビリティーゾーンで再作成され、プロビジョニングされます。
このシナリオでは、クラスター内のすべてのデータがクラスター内のすべてのノードの障害のために失われます。これはまれにしか発生しません。
クラスター全体が失敗すると、ElastiCache のマルチ AZ は次の処理を行います。
1. 障害が発生したプライマリノードとリードレプリカがオフラインになります。
1. 置き換えプライマリノードが作成され、プロビジョニングされます。
1. 複数の置き換えレプリカを作成してプロビジョニングします。
ノードのディストリビューションが維持されるように、障害が発生したノードのアベイラビリティーゾーンで置き換えレプリカが作成されます。
クラスター全体に障害が発生したため、データが失われ、すべての新しいノードがコールド起動されます。
置換先の各ノードと置換元のノードはエンドポイントが同じであるため、アプリケーションでエンドポイントを変更する必要はありません。
レプリケーショングループのエンドポイントの検索については、次のトピックを参照してください:
+ [Valkey または Redis OSS (クラスターモードが無効) クラスターのエンドポイントを検索する (コンソール)](Endpoints.md#Endpoints.Find.Redis)
+ [Valkey または Redis OSS レプリケーショングループのエンドポイントを検索する (AWS CLI）](Endpoints.md#Endpoints.Find.CLI.ReplGroups)
+ [Valkey または Redis OSS レプリケーショングループのエンドポイントを検索する (ElastiCache API）](Endpoints.md#Endpoints.Find.API.ReplGroups)
耐障害性レベルを上げるために、プライマリノードとリードレプリカは別々のアベイラビリティーゾーンに作成することをお勧めします。
## 自動フェイルオーバーのテスト
自動フェイルオーバーを有効にしたら、ElastiCache コンソール、AWS CLI、または ElastiCache API を使用してテストできます。
テストを行う場合、以下の点に注意してください。
+ このオペレーションを使用して、任意の連続 24 時間内で、最大 15 個のシャード (ElastiCache API および AWS CLI ではノードグループと呼ばれます) で自動フェイルオーバーをテストできます。
+ 別のクラスターのシャード (API および CLI ではレプリケーショングループと呼ばれます) でこのオペレーションを呼び出す場合、同時に呼び出しを行うことができます。
+ 場合によっては、同じ Valkey または Redis OSS (クラスターモードが有効) レプリケーショングループの異なるシャードに対して、このオペレーションを複数回呼び出すことがあります。このような場合、後続の呼び出しを行う前に、最初のノードの置換が完了する必要があります。
+ ノードの置換が完了しているかどうか調べるには、Amazon ElastiCache コンソール、AWS CLI、または ElastiCache API を使用してイベントを確認します。自動フェイルオーバーに関連する次のイベントを検索します。ここでは、発生すると思われる順番にイベントを示します。
1. レプリケーショングループメッセージ: `Test Failover API called for node group `
1. キャッシュクラスターメッセージ: `Failover from primary node to replica node completed`
1. レプリケーショングループメッセージ: `Failover from primary node to replica node completed`
1. キャッシュクラスターメッセージ: `Recovering cache nodes `
1. キャッシュクラスターメッセージ: `Finished recovery for cache nodes `
詳細については次を参照してください:
+ *ElastiCache ユーザーガイド*の [ElastiCache イベントの表示](ECEvents.Viewing.md)
+ *ElastiCache API リファレンス*の [DescribeEvents](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeEvents.html)
+ *AWS CLI コマンドリファレンス*の [describe-events](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-events.html)。
+ この API は、ElastiCache でフェイルオーバーが発生した場合のアプリケーションの動作をテストするために設計されています。クラスターの問題に対処するためにフェイルオーバーを開始するための運用ツールとしては設計されていません。さらに、大規模な運用イベントなどの特定の条件下では、AWS がこの API をブロックする可能性があります。
**Topics**
+ [AWS マネジメントコンソール を使用した自動フェイルオーバーのテスト](#auto-failover-test-con)
+ [AWS CLI を使用した自動フェイルオーバーのテスト](#auto-failover-test-cli)
+ [ElastiCache API を使用した自動フェイルオーバーのテスト](#auto-failover-test-api)
### AWS マネジメントコンソール を使用した自動フェイルオーバーのテスト
コンソールで自動フェイルオーバーをテストするには、次の手順に従います。
**自動フェイルオーバーをテストするには**
1. AWS マネジメントコンソール にサインインして、ElastiCache コンソール ([https://console.aws.amazon.com/elasticache/](https://console.aws.amazon.com/elasticache/)) を開きます。
1. ナビゲーションペインで **[Valkey]** または **[Redis OSS]** を選択します。
1. クラスターの一覧で、テストするクラスターの名前の左にあるチェックボックスをオンにします。このクラスターには、少なくとも 1 つのリードレプリカノードが必要です。
1. **Details** エリアで、このクラスターでマルチ AZ が有効になっていることを確認します。クラスターでマルチ AZ が有効になっていない場合は、別のクラスターを選択するか、このクラスターを変更してマルチ AZ を有効にします。詳細については、「[ElastiCache AWS マネジメントコンソール の使用](Clusters.Modify.md#Clusters.Modify.CON)」を参照してください。
![\[イメージ: マルチ AZ が有効なクラスターの [詳細] エリア\]](http://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/dg/images/ElastiCache-AutoFailover-MultiAZ-Enabled.png)
1. Valkey または Redis OSS (クラスターモードが無効) の場合、クラスターの名前を選択します。
Valkey または Redis OSS (クラスターモードが有効) の場合、次の手順を実行します。
1. クラスターの名前を選択します。
1. [**Shards**] ページで、フェイルオーバーをテストするシャード (API および CLI ではノードグループと呼ばれます) のシャード名を選択します。
1. [Nodes] ページで [**Failover Primary**] を選択します。
1. **Continue** を選択してプライマリをフェイルオーバーするか、**Cancel** を選択してプライマリノードへのフェイルオーバーをキャンセルします。
フェイルオーバープロセス中は、コンソールでノードのステータスが 使用可能** と継続して表示されます。フェイルオーバーテストの進捗状況を追跡するには、コンソールのナビゲーションペインから **Events** を選択します。**Events** タブで、フェイルオーバーの開始`Test Failover API called`と完了`Recovery completed`を示すイベントを監視します。
### AWS CLI を使用した自動フェイルオーバーのテスト
マルチ AZ が有効になっているクラスターで自動フェイルオーバーをテストするには、AWS CLI オペレーションの `test-failover` を使用できます。
**パラメータ**
+ `--replication-group-id` – 必須。テストするレプリケーショングループ (コンソールではクラスター)。
+ `--node-group-id` – 必須。自動フェイルオーバーをテストするノードグループの名前。連続 24 時間内で、最大 15 個のノードグループをテストできます。
次の例では、AWS CLI を使用して、Valkey または Redis OSS (クラスターモードが有効) クラスター `redis00` のノードグループ `redis00-0003` で自動フェイルオーバーをテストします。
**Example 自動フェイルオーバーをテストする**
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](https://docs.aws.amazon.com/cli/latest/reference/elasticache/test-failover.html)。
+ *AWS CLI コマンドリファレンス*の [describe-events](https://docs.aws.amazon.com/cli/latest/reference/elasticache/describe-events.html)。
### ElastiCache API を使用した自動フェイルオーバーのテスト
マルチ AZ が有効になっている任意のクラスターで自動フェイルオーバーをテストするには、ElastiCache API オペレーションの `TestFailover` を使用できます。
**パラメータ**
+ `ReplicationGroupId` – 必須。テスト対象のレプリケーショングループ (コンソールではクラスター)。
+ `NodeGroupId` – 必須。自動フェイルオーバーをテストする対象のノードグループの名前。連続 24 時間内で、最大 15 個のノードグループをテストできます。
次の例では、レプリケーショングループ (コンソールではクラスター) `redis00-0003` のノードグループ `redis00` で、自動フェイルオーバーをテストします。
**Example 自動フェイルオーバーのテスト**
```
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=
```
フェイルオーバーの進行状況を追跡するには、ElastiCache の `DescribeEvents` API オペレーションを使用します。
詳細については次を参照してください:
+ *ElastiCache API リファレンス*の [TestFailover](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_TestFailover.html)の
+ *ElastiCache API リファレンス*の [DescribeEvents](https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/API_DescribeEvents.html)
## マルチ AZ の制限事項
マルチ AZ に関する次の制限事項に注意してください。
+ マルチ AZ は Valkey、および Redis OSS バージョン 2.8.6 以降でサポートされます。
+ マルチ AZ は、T1 ノードタイプではサポートされません。
+ Valkey および Redis OSS のレプリケーションは非同期で行われます。そのため、プライマリノードがレプリカにフェイルオーバーすると、レプリケーションの遅延のために少量のデータが失われる可能性があります。
プライマリに昇格させるレプリカを選択する際、ElastiCache はレプリケーションの遅延が最短のレプリカを選択します。言い換えると、最新のレプリカを選択します。これにより、失われるデータ量が最小限に抑えられます。レプリケーションの遅延が最短のレプリカは、障害が発生したプライマリノードと同じ、または異なるアベイラビリティーゾーンに存在できます。
+ マルチ AZ と自動フェイルオーバーが無効なときにのみ、Valkey または Redis OSS クラスター (クラスターモードが無効) でリードレプリカを手動でプライマリに昇格させることができます。リードレプリカをプライマリに昇格させるには、以下のステップを実行します。
1. クラスターでマルチ AZ を無効にします。
1. クラスターで自動フェイルオーバーを無効にします。これを行うには、コンソールで、レプリケーショングループの **[自動フェイルオーバー]** チェックボックスをオフにします。AWS CLI を使用して、`ModifyReplicationGroup` オペレーションを呼び出す際に `AutomaticFailoverEnabled` プロパティを `false` に設定することもできます。
1. リードレプリカをプライマリに昇格させます。
1. マルチ AZ を再度有効にします。
+ ElastiCache for Redis OSS のマルチ AZ および AOF (Append-Only File) は、相互に排他的です。一方を有効にすると、他方を有効にすることはできません。
+ アベイラビリティーゾーン全体の障害というまれなイベントにより、ノードの障害が発生することがあります。この場合、障害の発生したプライマリを置き換えるレプリカは、アベイラビリティーゾーンがバックアップされているときのみ作成されます。たとえば、AZ-a のプライマリおよび AZ-b および AZ-c のレプリカを持つレプリケーショングループを考えてみます。プライマリに障害が発生した場合、レプリケーションの遅延が最も小さい利用可能なレプリカをプライマリクラスターに昇格します。その後、AZ-a がバックアップとなっていて使用可能な場合にのみ、ElastiCache は AZ-a 内 (障害が発生したプライマリがあった場所) に新しいレプリカを作成します。
+ プライマリの再起動をお客様が開始した場合、自動フェイルオーバーはトリガーされません。他の再起動と障害は、自動フェイルオーバーをトリガーします。
+ プライマリが再起動すると、オンラインに戻ったときにデータがクリアされます。リードレプリカがクリアされたプライマリクラスターを検出すると、データのコピーがクリアされるため、データ損失が発生します。
+ リードレプリカが昇格されると、他のレプリカは新しいプライマリと同期されます。最初の同期後に、レプリカのコンテンツは削除され、新しいプライマリからデータが同期されます。この同期プロセスに伴って一時的に中断が発生し、その間はレプリカにアクセスできなくなります。また、この同期プロセスに伴ってレプリカとの同期中にプライマリで一時的にロードが増えます。この動作は、Valkey および Redis OSS にネイティブであり、ElastiCache のマルチ AZ に特有ではありません。この動作の詳細については、Valkey ウェブサイトの「[Replication](http://valkey.io/topics/replication)」を参照してください。
**重要**
Valkey 7.2.6 以降または Redis OSS バージョン 2.8.22 以降では、外部レプリカを作成できません。
2.8.22 より前のバージョンの Redis OSS では、マルチ AZ が有効になっている ElastiCache クラスターに外部レプリカを接続しないことをお勧めします。このサポートされていない設定により、問題が発生し、ElastiCache がフェイルオーバーや復旧を正しく実行できなくなる場合があります。外部レプリカを ElastiCache クラスターに接続する場合は、接続する前にマルチ AZ が有効になっていないことを確認してください。