翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# マルチ AZ による MemoryDB のダウンタイムの最小化
MemoryDB がプライマリノードを置き換える必要があるインスタンスが多数あります。これには、特定のタイプの計画されたメンテナンスや、プライマリノードまたはアベイラビリティーゾーンの予期できない障害などが含まれます。
ノード障害への対応は、どのノードに障害が発生したかによって異なります。ただし、いずれの場合も、MemoryDB はノードの交換やフェイルオーバー中にデータが失われないようにします。例えば、レプリカに障害が発生した場合、障害が発生したノードは交換され、データがトランザクションログから同期されます。プライマリノードに障害が発生すると、整合性のとれたレプリカへのフェイルオーバーがトリガーされ、フェイルオーバー中にデータが失われることはありません。これで、書き込みは新しいプライマリノードから処理されます。その後、古いプライマリノードが置き換えられ、トランザクションログから同期されます。
1 つのノードシャード (レプリカなし) でプライマリノードに障害が発生した場合、MemoryDB は、プライマリノードが交換されてトランザクションログと同期されるまで、書き込みを受け付けなくなります。
ノードの交換により、クラスターのダウンタイムが発生しますが、マルチ AZ が有効になっている場合、ダウンタイムは最小限に抑えられます。プライマリノードのロールは、リードレプリカの 1 つに自動的にフェイルオーバーされます。MemoryDB ではこれを透過的に処理するため、新しいプライマリノードを作成してプロビジョニングする必要はありません。このフェイルオーバーとレプリカの昇格により、昇格が完了したらすぐに新しいプライマリへの書き込みを再開できます。
メンテナンス更新またはサービス更新により計画されたノード置換が開始された場合、クラスターが着信した書き込みリクエストを処理している間に、計画されたノード置換が完了することに注意してください。
MemoryDB クラスターのマルチ AZ を使用すると、耐障害性が向上します。これは特に、クラスターのプライマリノードが到達できなくなった場合、または何らかの理由で障害が発生した場合に当てはまります。MemoryDB クラスターのマルチ AZ では、各シャードに複数のノードが必要で、自動的に有効になります。
**Topics**
+ [障害シナリオとマルチ AZ のレスポンス](#autofailover.scenarios)
+ [自動フェイルオーバーのテスト](#auto-failover-test)
## 障害シナリオとマルチ AZ のレスポンス
マルチ AZ がアクティブな場合、障害が発生したプライマリノードは使用可能なレプリカにフェイルオーバーします。レプリカは自動的にトランザクションログと同期され、プライマリノードになります。これは、新しいプライマリノードを作成して再プロビジョニングするよりもはるかに高速です。通常は数秒で、クラスターへの書き込みが再び可能になります。
マルチ AZ を有効にすると、MemoryDB はプライマリノードの状態を継続的にモニタリングします。プライマリノードが失敗すると、失敗のタイプに応じて次のいずれかのアクションが実行されます。
**Topics**
+ [プライマリノードのみが失敗した場合の障害シナリオ](#autofailover.scenarios.primaryonly)
+ [プライマリノードと一部のリードレプリカが失敗した場合の障害シナリオ](#autofailover.scenarios.primaryandeplicas)
+ [クラスター全体が失敗した場合の障害シナリオ](#autofailover.scenarios.allfail)
### プライマリノードのみが失敗した場合の障害シナリオ
プライマリノードのみが失敗した場合、レプリカは自動的にプライマリノードになります。次に、障害の発生したプライマリと同じアベイラビリティーゾーンに代替のリードレプリカが作成されてプロビジョニングされます。
プライマリノードのみが失敗した場合、MemoryDB のマルチ AZ は次の処理を行います。
1. 失敗したプライマリノードがオフラインになります。
1. 最新のレプリカが自動的にプライマリになります。
書き込みは、フェイルオーバープロセスが完了すると通常は数秒で再開できます。
1. 代替のリードレプリカが起動され、プロビジョニングされます。
代替のレプリカは、障害が発生したプライマリノードが属していたアベイラビリティーゾーンで起動され、ノードの分散が維持されます。
1. レプリカはトランザクションログと同期します。
クラスターのエンドポイントの検索については、以下のトピックを参照してください。
+ [MemoryDB クラスターのエンドポイントを検索する (MemoryDB API)](endpoints.md#endpoints.find.api.clusters)
### プライマリノードと一部のリードレプリカが失敗した場合の障害シナリオ
プライマリと 1 つ以上のレプリカに障害が発生すると、最新のレプリカがプライマリクラスターに昇格されます。新しいレプリカも作成され、障害が発生したノードと同じアベイラビリティーゾーンにプロビジョニングされます。
プライマリノードと一部のリードレプリカが失敗すると、MemoryDB Multi-AZは次の処理を行います。
1. 障害が発生したプライマリノードと故障したレプリカがオフラインになります。
1. 使用可能なレプリカがプライマリノードになります。
フェイルオーバーが完了すると、書き込みは、通常は数秒で 再開できます。
1. 複数の置き換えレプリカを作成してプロビジョニングします。
ノードのディストリビューションが維持されるように、障害が発生したノードのアベイラビリティーゾーンで置き換えレプリカが作成されます。
1. すべてのノードがトランザクションログと同期します。
クラスターのエンドポイントの検索については、以下のトピックを参照してください。
+ [(AWS CLI) MemoryDB クラスターのエンドポイントの検索](endpoints.md#endpoints.find.cli)
+ [MemoryDB クラスターのエンドポイントを検索する (MemoryDB API)](endpoints.md#endpoints.find.api.clusters)
### クラスター全体が失敗した場合の障害シナリオ
すべてに障害が発生した場合、すべてのノードは、元のノードと同じアベイラビリティーゾーンで再作成され、プロビジョニングされます。
このシナリオでは、データはトランザクションログに保持されているため、データが失われることはありません。
クラスター全体が失敗すると、MemoryDB のマルチ AZ は次の処理を行います。
1. 障害が発生したプライマリノードとレプリカがオフラインになります。
1. 代わりのプライマリノードが作成され、トランザクションログと同期してプロビジョニングされます。
1. 代替レプリカはトランザクションログと同期して作成され、プロビジョニングされます。
ノードのディストリビューションが維持されるように、障害が発生したノードのアベイラビリティーゾーンで置き換えレプリカが作成されます。
クラスターのエンドポイントの検索については、以下のトピックを参照してください。
+ [(AWS CLI) MemoryDB クラスターのエンドポイントの検索](endpoints.md#endpoints.find.cli)
+ [MemoryDB クラスターのエンドポイントを検索する (MemoryDB API)](endpoints.md#endpoints.find.api.clusters)
## 自動フェイルオーバーのテスト
MemoryDB コンソール、 AWS CLI、および MemoryDB API を使用して自動フェイルオーバーをテストできます。
テストを行う場合、以下の点に注意してください。
+ この操作は、24 時間に最大 5 回まで使用できます。
+ 別のクラスターのシャードでこのオペレーションを呼び出す場合、同時に呼び出しを行うことができます。
+ 場合によっては、同じ MemoryDBクラスター内の異なるシャードに対して、このオペレーションを複数回呼び出すことがあります。このような場合、後続の呼び出しを行う前に、最初のノードの置換が完了する必要があります。
+ ノードの交換が完了したかどうかを判断するには、MemoryDB コンソール、、 AWS CLIまたは MemoryDB API を使用してイベントを確認します。`FailoverShard`に関連する以下のイベントは、発生すると思われる順に一覧表示されます。
1. クラスターメッセージ: `FailoverShard API called for shard `
1. クラスターメッセージ: `Failover from primary node to replica node completed`
1. クラスターメッセージ: `Recovering nodes `
1. クラスターメッセージ: `Finished recovery for nodes `
詳細については次を参照してください:
+ MemoryDB API リファレンスの [DescribeEvents](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEvents.html)
+ この API は、MemoryDB でフェイルオーバーが発生した場合のアプリケーションの動作をテストするために設計されています。クラスターの問題に対処するためにフェイルオーバーを開始するための運用ツールとしては設計されていません。さらに、大規模な運用イベントなどの特定の条件下で AWS は、 がこの API をブロックすることがあります。
**Topics**
+ [を使用した自動フェイルオーバーのテスト AWS マネジメントコンソール](#auto-failover-test-con)
+ [を使用した自動フェイルオーバーのテスト AWS CLI](#auto-failover-test-cli)
+ [MemoryDB API を使用した自動フェイルオーバーのテスト](#failovershard-test-api)
### を使用した自動フェイルオーバーのテスト AWS マネジメントコンソール
コンソールで自動フェイルオーバーをテストするには、次の手順に従います。
****
1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/) で MemoryDB コンソールを開きます。
1. テストしたいクラスターの左側にあるラジオボタンを選択します。このクラスターには、少なくとも 1 つのレプリカノードが必要です。
1. **Details** エリアで、このクラスターでマルチ AZ が有効になっていることを確認します。クラスターでマルチ AZ が有効になっていない場合は、別のクラスターを選択するか、このクラスターを変更してマルチ AZ を有効にします。詳細については、「[MemoryDB クラスターの変更](clusters.modify.md)」を参照してください。
1. クラスターの名前を選択します。
1. **[シャードとノード]** ページで、フェイルオーバーをテストするシャード (API および CLI ではノードグループと呼ばれます) のシャード名を選択します。
1. ノード ページで **[フェイルオーバープライマリ]** を選択します。
1. **Continue** を選択してプライマリをフェイルオーバーするか、**Cancel** を選択してプライマリノードへのフェイルオーバーをキャンセルします。
フェイルオーバープロセス中は、コンソールでノードのステータスが 使用可能** と継続して表示されます。フェイルオーバーテストの進捗状況を追跡するには、コンソールのナビゲーションペインから **Events** を選択します。**Events** タブで、フェイルオーバーの開始`FailoverShard API called`と完了`Recovery completed`を示すイベントを監視します。
### を使用した自動フェイルオーバーのテスト AWS CLI
AWS CLI オペレーションのフェイルオーバー[シャードを使用して、マルチ AZ 対応クラスターで自動フェイルオーバー](https://docs.aws.amazon.com/cli/latest/reference/memorydb/failover-shard.html)をテストできます。
**パラメータ**
+ `--cluster-name` – 必須。テスト対象のクラスター。
+ `--shard-name` – 必須。自動フェイルオーバーをテストするシャードの名前。24 時間以内に、最大 5 つのシャードをテストできます。
次の例では AWS CLI 、 を使用して MemoryDB クラスター のシャード `failover-shard` で `0001`を呼び出します`my-cluster`。
Linux、macOS、Unix の場合:
```
aws memorydb failover-shard \
--cluster-name my-cluster \
--shard-name 0001
```
Windows の場合:
```
aws memorydb failover-shard ^
--cluster-name my-cluster ^
--shard-name 0001
```
フェイルオーバーの進行状況を追跡するには、 AWS CLI `describe-events`オペレーションを使用します。
以下のようなJSONレスポンスが返される：
```
{
"Events": [
{
"SourceName": "my-cluster",
"SourceType": "cluster",
"Message": "Failover to replica node my-cluster-0001-002 completed",
"Date": "2021-08-22T12:39:37.568000-07:00"
},
{
"SourceName": "my-cluster",
"SourceType": "cluster",
"Message": "Starting failover for shard 0001",
"Date": "2021-08-22T12:39:10.173000-07:00"
}
]
}
```
詳細については次を参照してください:
+ 「[フェイルオーバーシャード](https://docs.aws.amazon.com/cli/latest/reference/memorydb/failover-shard.html)」
+ [describe-events](https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-events.html)
### MemoryDB API を使用した自動フェイルオーバーのテスト
次の例では、クラスター `memorydb00` 内のシャード `0003` で `FailoverShard` を呼び出します。
**Example 自動フェイルオーバーのテスト**
```
https://memory-db.us-east-1.amazonaws.com/
?Action=FailoverShard
&ShardName=0003
&ClusterName=memorydb00
&Version=2021-01-01
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&Timestamp=20210801T192317Z
&X-Amz-Credential=
```
フェイルオーバーの進行状況を追跡するには、MemoryDB `DescribeEvents` API オペレーションを使用します。
詳細については次を参照してください:
+ 「[フェイルオーバーシャード](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_FailoverShard.html)」
+ [DescribeEvents](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEvents.html)