

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# MemoryDB レプリケーションを理解する
<a name="replication"></a>

MemoryDBは、最大500のシャードに分割されたデータでレプリケーションを実装しています。

クラスター内の各シャードには、単一の読み取り/書き込みプライマリノードと、最大 5 個の読み取り専用レプリカノードがあります。各プライマリノードは最大 100 MB/秒を維持できます。シャードの数が多くレプリカの数が少ないクラスターを作成できます。クラスターあたり最大 500 ノードです。このクラスター設定は、シャード 500 個およびレプリカ 0 個からシャード 100 個およびレプリカ 4 個 (許容されるレプリカの最大数) までです。

# 整合性
<a name="consistency"></a>

MemoryDBでは、プライマリノードは強い一貫性を持っています。成功した書き込み操作は、クライアントに返される前に、分散されたマルチ AZ トランザクションログに永続的に保存されます。プライマリでの読み取り操作では、それまでに成功したすべての書き込み操作の影響を反映した最新のデータが常に返されます。このような強固な一貫性は、プライマリのフェイルオーバー後も維持されます。

MemoryDB では、レプリカノードは結果整合性です。レプリカからの読み取り操作 (`READONLY` コマンドを使用) は、遅延メトリクスが CloudWatch に発行したため、直近に成功した書き込み操作の影響を常に反映するとは限りません。ただし、1 つのレプリカからの読み取りオペレーションはシーケンシャルに一貫性があります。書き込み操作が成功すると、プライマリで実行されたのと同じ順序で各レプリカで有効になります。

## クラスター内のレプリケーション
<a name="replication.redis.groups.cluster"></a>

 シャード内の各リードレプリカは、シャードのプライマリノードからのデータのコピーを維持します。トランザクションログを使用した非同期レプリケーション機能は、リードレプリカとプライマリの同期を維持するのに使用されます。アプリケーションは、クラスター内のどのノードからでも読み取ることができます。アプリケーションは、そのプライマリノードにのみ書き込むことができます。リードレプリカは読み取りのスケーラビリティを高めます。MemoryDB はデータを耐久性のあるトランザクションログに保存するので、データが失われるリスクはありません。データは MemoryDB クラスター内のシャード間で分割されます。

アプリケーションは、MemoryDB クラスターのクラスターエンドポイントを使用してクラスターのノードに接続します。詳細については、「[接続エンドポイントの検索](endpoints.md)」を参照してください。

MemoryDB クラスターはリージョナルで、1 つのリージョンのノードのみを含めることができます。耐障害性を向上させるために、そのリージョン内の複数のアベイラビリティーゾーンにプライマリとリードレプリカの両方をプロビジョニングできます。

マルチ AZ を提供するレプリケーションの使用は、すべての MemoryDB クラスターで強く推奨されます。詳細については、「[マルチ AZ による MemoryDB のダウンタイムの最小化](autofailover.md)」を参照してください。

# マルチ AZ による MemoryDB のダウンタイムの最小化
<a name="autofailover"></a>

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

ノード障害への対応は、どのノードに障害が発生したかによって異なります。ただし、いずれの場合も、MemoryDB はノードの交換やフェイルオーバー中にデータが失われないようにします。例えば、レプリカに障害が発生した場合、障害が発生したノードは交換され、データがトランザクションログから同期されます。プライマリノードに障害が発生すると、整合性のとれたレプリカへのフェイルオーバーがトリガーされ、フェイルオーバー中にデータが失われることはありません。これで、書き込みは新しいプライマリノードから処理されます。その後、古いプライマリノードが置き換えられ、トランザクションログから同期されます。

1 つのノードシャード (レプリカなし) でプライマリノードに障害が発生した場合、MemoryDB は、プライマリノードが交換されてトランザクションログと同期されるまで、書き込みを受け付けなくなります。

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

メンテナンス更新またはサービス更新により計画されたノード置換が開始された場合、クラスターが着信した書き込みリクエストを処理している間に、計画されたノード置換が完了することに注意してください。

MemoryDB クラスターのマルチ AZ を使用すると、耐障害性が向上します。これは特に、クラスターのプライマリノードが到達できなくなった場合、または何らかの理由で障害が発生した場合に当てはまります。MemoryDB クラスターのマルチ AZ では、各シャードに複数のノードが必要で、自動的に有効になります。

**Topics**
+ [障害シナリオとマルチ AZ のレスポンス](#autofailover.scenarios)
+ [自動フェイルオーバーのテスト](#auto-failover-test)

## 障害シナリオとマルチ AZ のレスポンス
<a name="autofailover.scenarios"></a>

マルチ AZ がアクティブな場合、障害が発生したプライマリノードは使用可能なレプリカにフェイルオーバーします。レプリカは自動的にトランザクションログと同期され、プライマリノードになります。これは、新しいプライマリノードを作成して再プロビジョニングするよりもはるかに高速です。通常は数秒で、クラスターへの書き込みが再び可能になります。

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

**Topics**
+ [プライマリノードのみが失敗した場合の障害シナリオ](#autofailover.scenarios.primaryonly)
+ [プライマリノードと一部のリードレプリカが失敗した場合の障害シナリオ](#autofailover.scenarios.primaryandeplicas)
+ [クラスター全体が失敗した場合の障害シナリオ](#autofailover.scenarios.allfail)

### プライマリノードのみが失敗した場合の障害シナリオ
<a name="autofailover.scenarios.primaryonly"></a>

プライマリノードのみが失敗した場合、レプリカは自動的にプライマリノードになります。次に、障害の発生したプライマリと同じアベイラビリティーゾーンに代替のリードレプリカが作成されてプロビジョニングされます。

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

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

1. 最新のレプリカが自動的にプライマリになります。

   書き込みは、フェイルオーバープロセスが完了すると通常は数秒で再開できます。

1. 代替のリードレプリカが起動され、プロビジョニングされます。

   代替のレプリカは、障害が発生したプライマリノードが属していたアベイラビリティーゾーンで起動され、ノードの分散が維持されます。

1. レプリカはトランザクションログと同期します。

クラスターのエンドポイントの検索については、以下のトピックを参照してください。
+ [MemoryDB クラスターのエンドポイントを検索する (MemoryDB API)](endpoints.md#endpoints.find.api.clusters)

 

### プライマリノードと一部のリードレプリカが失敗した場合の障害シナリオ
<a name="autofailover.scenarios.primaryandeplicas"></a>

プライマリと 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)

 

### クラスター全体が失敗した場合の障害シナリオ
<a name="autofailover.scenarios.allfail"></a>

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

このシナリオでは、データはトランザクションログに保持されているため、データが失われることはありません。

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

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

1. 代わりのプライマリノードが作成され、トランザクションログと同期してプロビジョニングされます。

1. 代替レプリカはトランザクションログと同期して作成され、プロビジョニングされます。

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

クラスターのエンドポイントの検索については、以下のトピックを参照してください。
+ [(AWS CLI) MemoryDB クラスターのエンドポイントの検索](endpoints.md#endpoints.find.cli)
+ [MemoryDB クラスターのエンドポイントを検索する (MemoryDB API)](endpoints.md#endpoints.find.api.clusters)

## 自動フェイルオーバーのテスト
<a name="auto-failover-test"></a>

MemoryDB コンソール、 AWS CLI、および MemoryDB API を使用して自動フェイルオーバーをテストできます。

テストを行う場合、以下の点に注意してください。
+ この操作は、24 時間に最大 5 回まで使用できます。
+ 別のクラスターのシャードでこのオペレーションを呼び出す場合、同時に呼び出しを行うことができます。
+ 場合によっては、同じ MemoryDBクラスター内の異なるシャードに対して、このオペレーションを複数回呼び出すことがあります。このような場合、後続の呼び出しを行う前に、最初のノードの置換が完了する必要があります。
+ ノードの交換が完了したかどうかを判断するには、MemoryDB コンソール、、 AWS CLIまたは MemoryDB API を使用してイベントを確認します。`FailoverShard`‬に関連する以下のイベントは、発生すると思われる順に一覧表示されます。‬

  1. クラスターメッセージ: `FailoverShard API called for shard <shard-id>`

  1. クラスターメッセージ: `Failover from primary node <primary-node-id> to replica node <node-id> completed`

  1. クラスターメッセージ: `Recovering nodes <node-id>`

  1. クラスターメッセージ: `Finished recovery for nodes <node-id>`

  詳細については次を参照してください:
  + 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 マネジメントコンソール
<a name="auto-failover-test-con"></a>

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

****

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
<a name="auto-failover-test-cli"></a>

 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 を使用した自動フェイルオーバーのテスト
<a name="failovershard-test-api"></a>

次の例では、クラスター `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=<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) 

# レプリカの数の変更
<a name="update-replica-count"></a>

AWS マネジメントコンソール、AWS CLI、または MemoryDB API を使用して、MemoryDB クラスターのリードレプリカ数を動的に増減できます。すべてのシャードのレプリカの数が同じである必要があります。

## クラスターのレプリカの数を増やす
<a name="increase-replica-count"></a>

MemoryDB クラスター内のレプリカの数は、シャードごとに最大 5 個まで増やすことができます。AWS マネジメントコンソール、AWS CLI、または MemoryDB API を使用して行うことができます。

**Topics**
+ [の使用AWS マネジメントコンソール](#increase-replica-count-con)
+ [の使用AWS CLI](#increase-replica-count-cli)
+ [MemoryDB API の使用](#increase-replica-count-api)

### の使用AWS マネジメントコンソール
<a name="increase-replica-count-con"></a>

MemoryDB クラスター (コンソール) 内のレプリカの数を増やすには、「[クラスターからのノードの追加/削除](clusters.deletenode.md)」を参照してください。

### の使用AWS CLI
<a name="increase-replica-count-cli"></a>

MemoryDB クラスターのレプリカ数を増やすには、以下のパラメータを指定して`update-cluster`コマンドを使用します：
+ `--cluster-name` – 必須。レプリカの数を増やすクラスターを指定します。
+ `--replica-configuration` – 必須。レプリカの数を設定できます。レプリカの数を増やすには、このオペレーションの終了後にこのシャードに必要なレプリカの数を `ReplicaCount` プロパティに設定します。

**Example**  
次の例では、クラスター ‭`my-cluster`‬ 内のレプリカの数を 2 個に増やします。  
Linux、macOS、Unix の場合:  

```
aws memorydb update-cluster \
    --cluster-name my-cluster \
    --replica-configuration \
        ReplicaCount=2
```
Windows の場合:  

```
aws memorydb update-cluster ^
    --cluster-name my-cluster ^
    --replica-configuration ^
        ReplicaCount=2
```

以下の JSON コードを返します。

```
{
    "Cluster": {
        "Name": "my-cluster",
        "Status": "updating",
        "NumberOfShards": 1,
        "ClusterEndpoint": {
            "Address": "clustercfg.my-cluster.xxxxx.memorydb.us-east-1.amazonaws.com",
            "Port": 6379
        },
        "NodeType": "db.r6g.large",
        "EngineVersion": "6.2",
        "EnginePatchVersion": "6.2.6",
        "ParameterGroupName": "default.memorydb-redis6",
        "ParameterGroupStatus": "in-sync",
        "SubnetGroupName": "my-sg",
        "TLSEnabled": true,
        "ARN": "arn:aws:memorydb:us-east-1:xxxxxxexamplearn:cluster/my-cluster",
        "SnapshotRetentionLimit": 0,
        "MaintenanceWindow": "wed:03:00-wed:04:00",
        "SnapshotWindow": "04:30-05:30",
        "DataTiering": "false",
        "AutoMinorVersionUpgrade": true
    }
}
```

クラスターのステータスが*更新中*から*利用可能*に変わったら、更新されたクラスターの詳細を表示するには、次のコマンドを使用します。

Linux、macOS、Unix の場合:

```
aws memorydb describe-clusters \
    --cluster-name my-cluster
    --show-shard-details
```

Windows の場合:

```
aws memorydb describe-clusters ^
    --cluster-name my-cluster
    --show-shard-details
```

以下のようなJSONレスポンスが返される：

```
{
    "Clusters": [
        {
            "Name": "my-cluster",
            "Status": "available",
            "NumberOfShards": 1,
            "Shards": [
                {
                    "Name": "0001",
                    "Status": "available",
                    "Slots": "0-16383",
                    "Nodes": [
                        {
                            "Name": "my-cluster-0001-001",
                            "Status": "available",
                            "AvailabilityZone": "us-east-1a",
                            "CreateTime": "2021-08-21T20:22:12.405000-07:00",
                            "Endpoint": {
                                "Address": "clustercfg.my-cluster.xxxxxx.memorydb.us-east-1.amazonaws.com",
                                "Port": 6379
                            }
                        },
                        {
                            "Name": "my-cluster-0001-002",
                            "Status": "available",
                            "AvailabilityZone": "us-east-1b",
                            "CreateTime": "2021-08-21T20:22:12.405000-07:00",
                            "Endpoint": {
                                "Address": "clustercfg.my-cluster.xxxxxx.memorydb.us-east-1.amazonaws.com",
                                "Port": 6379
                            }
                        },
                        {
                            "Name": "my-cluster-0001-003",
                            "Status": "available",
                            "AvailabilityZone": "us-east-1a",
                            "CreateTime": "2021-08-22T12:59:31.844000-07:00",
                            "Endpoint": {
                                "Address": "clustercfg.my-cluster.xxxxxx.memorydb.us-east-1.amazonaws.com",
                                "Port": 6379
                            }
                        }
                    ],
                    "NumberOfNodes": 3
                }
            ],
            "ClusterEndpoint": {
                "Address": "clustercfg.my-cluster.xxxxxx.memorydb.us-east-1.amazonaws.com",
                "Port": 6379
            },
            "NodeType": "db.r6g.large",
            "EngineVersion": "6.2",
            "EnginePatchVersion": "6.2.6",
            "ParameterGroupName": "default.memorydb-redis6",
            "ParameterGroupStatus": "in-sync",
            "SubnetGroupName": "my-sg",
            "TLSEnabled": true,
            "ARN": "arn:aws:memorydb:us-east-1:xxxxxxexamplearn:cluster/my-cluster",
            "SnapshotRetentionLimit": 0,
            "MaintenanceWindow": "wed:03:00-wed:04:00",
            "SnapshotWindow": "04:30-05:30",
            "ACLName": "my-acl",
            "DataTiering": "false",
            "AutoMinorVersionUpgrade": true
        }
    ]
}
```

CLI を使用してレプリカの数を増やす方法の詳細については、「AWS CLI コマンドリファレンス」の「[クラスターの更新](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html)」を参照してください。

### MemoryDB API の使用
<a name="increase-replica-count-api"></a>

MemoryDB シャードでレプリカの数を増やすには、以下のパラメータを設定して `UpdateCluster` アクションを使用します。
+ `ClusterName` – 必須。レプリカの数を増やすクラスターを指定します。
+ `ReplicaConfiguration` – 必須。レプリカの数を設定できます。レプリカの数を増やすには、このオペレーションの終了後にこのシャードに必要なレプリカの数を `ReplicaCount` プロパティに設定します。

**Example**  
次の例では、クラスター ‭`sample-cluster`‬ 内のレプリカの数を 3 個に増やします。この例が終了すると、各シャードのレプリカは 3 個になります。この数は、単一のシャードを持つ MemoryDB クラスターでも、複数のシャードを持つ MemoryDB クラスターでも適用されます。  

```
https://memory-db.us-east-1.amazonaws.com/
      ?Action=UpdateCluster      
      &ReplicaConfiguration.ReplicaCount=3
      &ClusterName=sample-cluster
      &Version=2021-01-01
      &SignatureVersion=4
      &SignatureMethod=HmacSHA256
      &Timestamp=20210802T192317Z
      &X-Amz-Credential=<credential>
```

API を使用したレプリカの数を増やす詳細については、「[クラスターの更新](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html)」を参照してください。

## クラスターのレプリカの数を減らす
<a name="decrease-replica-count"></a>

MemoryDB のクラスター内のレプリカの数を減らせます。レプリカの数をゼロまで減らすことはできますが、プライマリノードに障害が発生した場合にレプリカにフェイルオーバーすることはできません。

AWS マネジメントコンソール、AWS CLI、または MemoryDB API を使用して、クラスター内のレプリカの数を減らせます。

**Topics**
+ [の使用AWS マネジメントコンソール](#decrease-replica-count-con)
+ [の使用AWS CLI](#decrease-replica-count-cli)
+ [MemoryDB API の使用](#decrease-replica-count-api)

### の使用AWS マネジメントコンソール
<a name="decrease-replica-count-con"></a>

MemoryDB クラスター (コンソール) 内のレプリカの数を減らすには、「[クラスターからのノードの追加/削除](clusters.deletenode.md)」を参照してください。

### の使用AWS CLI
<a name="decrease-replica-count-cli"></a>

MemoryDB クラスターでレプリカの数を減らすには、以下のパラメータを設定して `update-cluster` コマンドを使用します。
+ `--cluster-name` – 必須。レプリカの数を減らすクラスターを指定します。
+ `--replica-configuration` – 必須。

  `ReplicaCount` – レプリカノードの数を指定するには、このプロパティを設定します。

**Example**  
次の例では、‭`--replica-configuration` を使用して、‭クラスター `my-cluster`‬ 内のレプリカの数を、指定された値まで減らします。‬‬‬‬‬‬   
Linux、macOS、Unix の場合:  

```
aws memorydb update-cluster \
    --cluster-name my-cluster \
    --replica-configuration \
        ReplicaCount=1
```
Windows の場合:  

```
aws memorydb update-cluster ^
    --cluster-name my-cluster ^
    --replica-configuration ^
        ReplicaCount=1 ^
```

以下のようなJSONレスポンスが返される：

```
{
    "Cluster": {
        "Name": "my-cluster",
        "Status": "updating",
        "NumberOfShards": 1,
        "ClusterEndpoint": {
            "Address": "clustercfg.my-cluster.xxxxxx.memorydb.us-east-1.amazonaws.com",
            "Port": 6379
        },
        "NodeType": "db.r6g.large",
        "EngineVersion": "6.2",
        "EnginePatchVersion": "6.2.6",
        "ParameterGroupName": "default.memorydb-redis6",
        "ParameterGroupStatus": "in-sync",
        "SubnetGroupName": "my-sg",
        "TLSEnabled": true,
        "ARN": "arn:aws:memorydb:us-east-1:xxxxxxexamplearn:cluster/my-cluster",
        "SnapshotRetentionLimit": 0,
        "MaintenanceWindow": "wed:03:00-wed:04:00",
        "SnapshotWindow": "04:30-05:30",
        "DataTiering": "false",
        "AutoMinorVersionUpgrade": true
    }
}
```

クラスターのステータスが更新中から利用可能に変わったら、更新されたクラスターの詳細を表示するには、次のコマンドを使用します：

Linux、macOS、Unix の場合:

```
aws memorydb describe-clusters \
    --cluster-name my-cluster
    --show-shard-details
```

Windows の場合:

```
aws memorydb describe-clusters ^
    --cluster-name my-cluster
    --show-shard-details
```

以下のようなJSONレスポンスが返される：

```
{
    "Clusters": [
        {
            "Name": "my-cluster",
            "Status": "available",
            "NumberOfShards": 1,
            "Shards": [
                {
                    "Name": "0001",
                    "Status": "available",
                    "Slots": "0-16383",
                    "Nodes": [
                        {
                            "Name": "my-cluster-0001-001",
                            "Status": "available",
                            "AvailabilityZone": "us-east-1a",
                            "CreateTime": "2021-08-21T20:22:12.405000-07:00",
                            "Endpoint": {
                                "Address": "clustercfg.my-cluster.xxxxxx.memorydb.us-east-1.amazonaws.com",
                                "Port": 6379
                            }
                        },
                        {
                            "Name": "my-cluster-0001-002",
                            "Status": "available",
                            "AvailabilityZone": "us-east-1b",
                            "CreateTime": "2021-08-21T20:22:12.405000-07:00",
                            "Endpoint": {
                                "Address": "clustercfg.my-cluster.xxxxxx.memorydb.us-east-1.amazonaws.com",
                                "Port": 6379
                            }
                        }
                    ],
                    "NumberOfNodes": 2
                }
            ],
            "ClusterEndpoint": {
                "Address": "clustercfg.my-cluster.xxxxxx.memorydb.us-east-1.amazonaws.com",
                "Port": 6379
            },
            "NodeType": "db.r6g.large",
            "EngineVersion": "6.2",
            "EnginePatchVersion": "6.2.6",
            "ParameterGroupName": "default.memorydb-redis6",
            "ParameterGroupStatus": "in-sync",
            "SubnetGroupName": "my-sg",
            "TLSEnabled": true,
            "ARN": "arn:aws:memorydb:us-east-1:xxxxxxexamplearn:cluster/my-cluster",
            "SnapshotRetentionLimit": 0,
            "MaintenanceWindow": "wed:03:00-wed:04:00",
            "SnapshotWindow": "04:30-05:30",
            "ACLName": "my-acl",
            "DataTiering": "false",
            "AutoMinorVersionUpgrade": true
        }
    ]
}
```

CLI を使用してレプリカの数を減らす方法の詳細については、「AWS CLI コマンドリファレンス」の「[クラスターの更新](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-cluster.html)」を参照してください。

### MemoryDB API の使用
<a name="decrease-replica-count-api"></a>

MemoryDB クラスターでレプリカの数を減らすには、以下のパラメータを設定して `UpdateCluster` アクションを使用します。
+ `ClusterName` – 必須。レプリカの数を減らすクラスターを指定します。
+ `ReplicaConfiguration` – 必須。レプリカの数を設定できます。

  `ReplicaCount` – レプリカノードの数を指定するには、このプロパティを設定します。

**Example**  
次の例では、‭`ReplicaCount` を使用して、‭クラスター `sample-cluster`‬内のレプリカの数を 1 個に減らします。‬‬‬‬‬‬ この例が終了すると、各シャードのレプリカは 1 個になります。この数は、単一のシャードを持つ MemoryDB クラスターでも、複数のシャードを持つ MemoryDB クラスターでも適用されます。  

```
https://memory-db.us-east-1.amazonaws.com/
      ?Action=UpdateCluster    
      &ReplicaConfiguration.ReplicaCount=1
      &ClusterName=sample-cluster
      &Version=2021-01-01
      &SignatureVersion=4
      &SignatureMethod=HmacSHA256
      &Timestamp=20210802T192317Z
      &X-Amz-Credential=<credential>
```

API を使用したレプリカの数を減らす詳細については、「[クラスターの更新](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html)」を参照してください。