Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Grundlegendes zur MemoryDB-Replikation
MemoryDB implementiert die Replikation mit Daten, die auf bis zu 500 Shards partitioniert sind.
Jeder Shard in einem Cluster hat einen einzelnen read/write primären Knoten und bis zu 5 schreibgeschützte Replikatknoten. Jeder Primärknoten kann bis zu 100 MB/s unterstützen. Sie können einen Cluster mit einer höheren Anzahl von Shards und einer geringeren Anzahl von Replikaten mit insgesamt bis zu 500 Knoten pro Cluster erstellen. Diese Clusterkonfiguration kann von 500 Shards und 0 Replikaten bis hin zu 100 Shards und 4 Replikaten reichen, was der maximal zulässigen Anzahl von Replikaten entspricht.
# Konsistenz
In MemoryDB sind die Primärknoten stark konsistent. Erfolgreiche Schreibvorgänge werden dauerhaft in verteilten Multi-AZ-Transaktionsprotokollen gespeichert, bevor sie an die Clients zurückgegeben werden. Lesevorgänge auf Primärdaten geben immer die meisten up-to-date Daten zurück, die die Auswirkungen aller vorherigen erfolgreichen Schreibvorgänge widerspiegeln. Diese starke Konsistenz bleibt bei allen primären Failovers erhalten.
In MemoryDB sind die Replikatknoten letztendlich konsistent. Lesevorgänge von Replikaten (mithilfe eines `READONLY` Befehls) spiegeln möglicherweise nicht immer die Auswirkungen der letzten erfolgreichen Schreibvorgänge wider. Lag-Metriken werden unter veröffentlicht. CloudWatch Lesevorgänge aus einem einzelnen Replikat sind jedoch sequenziell konsistent. Erfolgreiche Schreibvorgänge werden für jedes Replikat in derselben Reihenfolge wirksam, in der sie auf dem Primärreplikat ausgeführt wurden.
## Replikation in einem Cluster
Jedes Lesereplikat in einem Shard verwaltet eine Kopie der Daten vom Primärknoten des Shards. Asynchrone Replikationsmechanismen, die die Transaktionsprotokolle verwenden, werden verwendet, um die Lesereplikate mit dem Primärserver zu synchronisieren. Anwendungen können aus jedem Knoten im Cluster lesen. Anwendungen können nur in die primären Knoten schreiben. Read Replicas verbessern die Leseskalierbarkeit. Da MemoryDB die Daten in dauerhaften Transaktionsprotokollen speichert, besteht kein Risiko, dass Daten verloren gehen. Die Daten werden auf die Shards in einem MemoryDB-Cluster aufgeteilt.
Anwendungen verwenden den *Cluster-Endpunkt des MemoryDB-Clusters, um eine Verbindung mit den Knoten im Cluster* herzustellen. Weitere Informationen finden Sie unter [Ermitteln von Verbindungsendpunkten](endpoints.md).
MemoryDB-Cluster sind regional und können nur Knoten aus einer Region enthalten. Um die Fehlertoleranz zu verbessern, müssen Sie Primärdaten und Read Replicas in mehreren Availability Zones innerhalb dieser Region bereitstellen.
Die Verwendung der Replikation, die Ihnen Multi-AZ bietet, wird für alle MemoryDB-Cluster dringend empfohlen. Weitere Informationen finden Sie unter [Minimierung von Ausfallzeiten in MemoryDB mit Multi-AZ](autofailover.md).
# Minimierung von Ausfallzeiten in MemoryDB mit Multi-AZ
Es gibt eine Reihe von Fällen, in denen MemoryDB möglicherweise einen Primärknoten austauschen muss. Dazu gehören bestimmte Arten von geplanten Wartungsarbeiten und der unwahrscheinliche Fall eines Ausfalls des Primärknotens oder der Availability Zone.
Die Reaktion auf einen Knotenausfall hängt davon ab, welcher Knoten ausgefallen ist. In allen Fällen stellt MemoryDB jedoch sicher, dass beim Austausch von Knoten oder beim Failover keine Daten verloren gehen. Wenn beispielsweise ein Replikat ausfällt, wird der ausgefallene Knoten ersetzt und Daten aus dem Transaktionslog synchronisiert. Wenn der primäre Knoten ausfällt, wird ein Failover auf ein konsistentes Replikat ausgelöst, wodurch sichergestellt wird, dass beim Failover keine Daten verloren gehen. Die Schreibvorgänge werden jetzt vom neuen Primärknoten aus bedient. Der alte Primärknoten wird dann ersetzt und anhand des Transaktionsprotokolls synchronisiert.
Wenn ein primärer Knoten auf einem einzelnen Knoten-Shard (keine Replikate) ausfällt, akzeptiert MemoryDB keine Schreibvorgänge mehr, bis der primäre Knoten ersetzt und mit dem Transaktionslog synchronisiert wird.
Der Austausch eines Knotens kann zu einigen Ausfallzeiten für den Cluster führen, aber wenn Multi-AZ aktiv ist, werden die Ausfallzeiten minimiert. Die Rolle des primären Knotens wird automatisch auf eines der Replikate übertragen. Es ist nicht erforderlich, einen neuen Primärknoten zu erstellen und bereitzustellen, da MemoryDB dies transparent handhabt. Dieser Failover und die Replikatheraufstufung stellen sicher, dass Sie weiter in den neuen primären Knoten schreiben können, sobald die Heraufstufung abgeschlossen wurde.
Bei geplanten Knotenersetzungen, die aufgrund von Wartungsupdates oder Service-Updates initiiert werden, sollten Sie sich bewusst sein, dass der geplante Knotenaustausch abgeschlossen ist, während der Cluster eingehende Schreibanforderungen bearbeitet.
Multi-AZ auf Ihren MemoryDB-Clustern verbessert Ihre Fehlertoleranz. Dies gilt insbesondere in Fällen, in denen die primären Knoten Ihres Clusters nicht mehr erreichbar sind oder aus irgendeinem Grund ausfallen. Multi-AZ auf MemoryDB-Clustern erfordert, dass jeder Shard mehr als einen Knoten hat, und wird automatisch aktiviert.
**Topics**
+ [Fehlerszenarien mit Multi-AZ-Antworten](#autofailover.scenarios)
+ [Testen des automatischen Failovers](#auto-failover-test)
## Fehlerszenarien mit Multi-AZ-Antworten
Wenn Multi-AZ aktiv ist, erfolgt ein Failover eines ausgefallenen Primärknotens auf ein verfügbares Replikat. Das Replikat wird automatisch mit dem Transaktionslog synchronisiert und wird primär, was viel schneller ist als die Erstellung und erneute Bereitstellung eines neuen Primärknotens. Bei diesem Vorgang dauert gewöhnlich nur wenige Sekunden, bis Sie wieder in den Cluster schreiben können.
Wenn Multi-AZ aktiv ist, überwacht MemoryDB kontinuierlich den Status des Primärknotens. Sollte der primäre Knoten ausfallen, wird abhängig von der Art des Ausfalls eine der folgenden Aktionen durchgeführt.
**Topics**
+ [Fehlerszenarien, wenn nur der Primärknoten ausfällt](#autofailover.scenarios.primaryonly)
+ [Ausfallszenarien, wenn der Primärknoten und einige Replikate ausfallen](#autofailover.scenarios.primaryandeplicas)
+ [Fehlerszenarien, wenn der gesamte Cluster ausfällt](#autofailover.scenarios.allfail)
### Fehlerszenarien, wenn nur der Primärknoten ausfällt
Wenn nur der Primärknoten ausfällt, wird ein Replikat automatisch zum primären Knoten. Anschließend wird ein Ersatzreplikat erstellt und in derselben Availability Zone wie das ausgefallene Primärreplikat bereitgestellt.
Wenn nur der Primärknoten ausfällt, geht MemoryDB Multi-AZ wie folgt vor:
1. Der ausgefallene primäre Knoten wird in den Offline-Zustand versetzt.
1. Ein up-to-date Replikat wird automatisch primär.
Schreibvorgänge können wieder aufgenommen werden, sobald der Failover-Vorgang abgeschlossen ist, normalerweise nur ein paar Sekunden.
1. Ein Ersatzreplikat wird gestartet und bereitgestellt.
Das Ersatzreplikat wird in der Availability Zone gestartet, in der sich der ausgefallene Primärknoten befand, sodass die Verteilung der Knoten beibehalten wird.
1. Das Replikat wird mit dem Transaktionslog synchronisiert.
Weitere Informationen zum Suchen der Endpunkte eines Clusters finden Sie in den folgenden Themen:
+ [Den Endpunkt für einen MemoryDB-Cluster finden (MemoryDB-API)](endpoints.md#endpoints.find.api.clusters)
### Ausfallszenarien, wenn der Primärknoten und einige Replikate ausfallen
Wenn das primäre Replikat und mindestens ein Replikat ausfallen, wird ein up-to-date Replikat zum primären Cluster heraufgestuft. Neue Replikate werden außerdem in denselben Availability Zones wie die ausgefallenen Knoten erstellt und bereitgestellt.
Wenn der Primärknoten und einige Replikate ausfallen, geht MemoryDB Multi-AZ wie folgt vor:
1. Der ausgefallene Primärknoten und die ausgefallenen Replikate werden offline geschaltet.
1. Ein verfügbares Replikat wird zum primären Knoten.
Schreibvorgänge können fortgesetzt werden, sobald der Failover abgeschlossen ist, normalerweise nur ein paar Sekunden.
1. Ersatzreplikate werden erstellt und bereitgestellt.
Die Ersatzreplikate werden in den Availability Zones der ausgefallenen Knoten erstellt, sodass die Verteilung der Knoten erhalten bleibt.
1. Alle Knoten werden mit dem Transaktionslog synchronisiert.
Weitere Informationen zum Suchen der Endpunkte eines Clusters finden Sie in den folgenden Themen:
+ [Den Endpunkt für einen MemoryDB-Cluster (AWS CLI) finden](endpoints.md#endpoints.find.cli)
+ [Den Endpunkt für einen MemoryDB-Cluster finden (MemoryDB-API)](endpoints.md#endpoints.find.api.clusters)
### Fehlerszenarien, wenn der gesamte Cluster ausfällt
Bei einem umfassenden Ausfall werden in denselben Availability Zones, der sich die Originalknoten befanden, alle Knoten neu erstellt und bereitgestellt.
In diesem Szenario gibt es keinen Datenverlust, da die Daten im Transaktionslog dauerhaft gespeichert wurden.
Wenn der gesamte Cluster ausfällt, geht MemoryDB Multi-AZ wie folgt vor:
1. Der ausgefallene Primärknoten und die Replikate werden offline geschaltet.
1. Ein Ersatz-Primärknoten wird erstellt und bereitgestellt, der mit dem Transaktionsprotokoll synchronisiert wird.
1. Ersatzreplikate werden erstellt und bereitgestellt und mit dem Transaktionslog synchronisiert.
Die Ersetzungen werden in den Availability Zones der ausgefallenen Knoten erstellt, sodass die Verteilung der Knoten erhalten bleibt.
Weitere Informationen zum Suchen der Endpunkte eines Clusters finden Sie in den folgenden Themen:
+ [Den Endpunkt für einen MemoryDB-Cluster (AWS CLI) finden](endpoints.md#endpoints.find.cli)
+ [Den Endpunkt für einen MemoryDB-Cluster finden (MemoryDB-API)](endpoints.md#endpoints.find.api.clusters)
## Testen des automatischen Failovers
Sie können den automatischen Failover mithilfe der MemoryDB-Konsole, der und der MemoryDB-API testen. AWS CLI
Beim Testen ist Folgendes zu beachten:
+ Sie können diesen Vorgang innerhalb von 24 Stunden bis zu fünf Mal ausführen.
+ Wenn Sie diesen Vorgang für Shards in verschiedenen Clustern aufrufen, können Sie die Aufrufe gleichzeitig tätigen.
+ In einigen Fällen können Sie diesen Vorgang mehrmals auf verschiedenen Shards im selben MemoryDB-Cluster aufrufen. In solchen Fällen muss die erste Knotenersetzung abgeschlossen werden, bevor ein nachfolgender Aufruf ausgeführt werden kann.
+ Um festzustellen, ob der Knotenaustausch abgeschlossen ist, überprüfen Sie Ereignisse mithilfe der MemoryDB-Konsole, der oder der AWS CLI MemoryDB-API. Suchen Sie nach den folgenden Ereignissen im Zusammenhang mit`FailoverShard`, die hier in der Reihenfolge ihres wahrscheinlichen Auftretens aufgeführt sind:
1. Cluster-Meldung: `FailoverShard API called for shard `
1. Cluster-Nachricht: `Failover from primary node to replica node completed`
1. Cluster-Nachricht: `Recovering nodes `
1. Cluster-Nachricht: `Finished recovery for nodes `
Weitere Informationen finden Sie hier:
+ [DescribeEvents](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEvents.html)in der *MemoryDB-API-Referenz*
+ Diese API wurde entwickelt, um das Verhalten Ihrer Anwendung im Falle eines MemoryDB-Failovers zu testen. Sie wurde nicht als Betriebstool zum Einleiten eines Failovers konzipiert, um ein Problem mit dem Cluster zu beheben. Darüber hinaus AWS kann diese API unter bestimmten Bedingungen, z. B. bei großen Betriebsereignissen, blockiert werden.
**Topics**
+ [Testen des automatischen Failovers mit dem AWS-Managementkonsole](#auto-failover-test-con)
+ [Testen des automatischen Failovers mit dem AWS CLI](#auto-failover-test-cli)
+ [Testen des automatischen Failovers mithilfe der MemoryDB-API](#failovershard-test-api)
### Testen des automatischen Failovers mit dem AWS-Managementkonsole
Verwenden Sie das folgende Verfahren, um das automatische Failover mit der Konsole zu testen.
****
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die MemoryDB-Konsole unter. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. Wählen Sie das Optionsfeld links neben dem Cluster, den Sie testen möchten. Dieser Cluster muss mindestens einen Replikatknoten haben.
1. Bestätigen Sie im Bereich **Details**, dass dieser Cluster Multi-AZ-fähig ist. Wenn der Cluster nicht Multi-AZ-fähig ist, wählen Sie einen anderen Cluster aus oder bearbeiten Sie diesen Cluster so, dass Multi-AZ aktiviert wird. Weitere Informationen finden Sie unter [Einen MemoryDB-Cluster ändern](clusters.modify.md).
1. Wählen Sie den Cluster-Namen aus.
1. Wählen Sie auf der Seite **Shards and Nodes** für den Shard, auf dem Sie den Failover testen möchten, den Namen des Shards aus.
1. **Wählen Sie für den Knoten Failover Primary aus.**
1. Wählen Sie **Continue**, um ein Failover des primären Knotens auszuführen, oder wählen Sie **Cancel**, um die Operation ohne ein Failover des primären Knotens abzubrechen.
Während des Failover-Vorgangs zeigt die Konsole den Status des Knotens weiterhin als *available* an. Um den Status des Failover-Tests zu verfolgen, wählen Sie im Navigationsbereich der Konsole **Events** aus. Suchen Sie auf der Registerkarte **Events** nach Ereignissen, für die angegeben wird, dass Ihr Failover gestartet (`FailoverShard API called`) und abgeschlossen (`Recovery completed`) wurde.
### Testen des automatischen Failovers mit dem AWS CLI
[Sie können das automatische Failover auf jedem Multi-AZ-fähigen Cluster testen, indem Sie den AWS CLI Vorgang failover-Shard verwenden.](https://docs.aws.amazon.com/cli/latest/reference/memorydb/failover-shard.html)
**Parameters**
+ `--cluster-name` – Erforderlich. Der Cluster, der getestet werden soll.
+ `--shard-name` – Erforderlich. Der Name des Shards, auf dem Sie den automatischen Failover testen möchten. Sie können in einem fortlaufenden Zeitraum von 24 Stunden maximal fünf Shards testen.
Im folgenden Beispiel wird verwendet AWS CLI , um den Shard `0001` im MemoryDB-Cluster aufzurufen`failover-shard`. `my-cluster`
Für Linux, macOS oder Unix:
```
aws memorydb failover-shard \
--cluster-name my-cluster \
--shard-name 0001
```
Für Windows:
```
aws memorydb failover-shard ^
--cluster-name my-cluster ^
--shard-name 0001
```
Verwenden Sie den Vorgang, um den Fortschritt Ihres Failovers zu verfolgen. AWS CLI `describe-events`
Es wird die folgende JSON-Antwort zurückgegeben:
```
{
"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"
}
]
}
```
Weitere Informationen finden Sie hier:
+ [Failover-Shard](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)
### Testen des automatischen Failovers mithilfe der MemoryDB-API
Das folgende Beispiel ruft den Shard `0003` im Cluster `FailoverShard` auf. `memorydb00`
**Example Testen des automatischen Failovers**
```
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=
```
Verwenden Sie den `DescribeEvents` MemoryDB-API-Vorgang, um den Fortschritt Ihres Failovers zu verfolgen.
Weitere Informationen finden Sie hier:
+ [FailoverShard](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_FailoverShard.html)
+ [DescribeEvents](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEvents.html)
# Ändern der Anzahl von Replikaten
Sie können die Anzahl der Read Replicas in Ihrem MemoryDB-Cluster mithilfe der AWS-Managementkonsole, der oder der MemoryDB-API dynamisch erhöhen oder verringern. AWS CLI Alle Shards müssen dieselbe Anzahl von Replikaten haben.
## Erhöhung der Anzahl der Replikate in einem Cluster
Sie können die Anzahl der Replikate in einem MemoryDB-Cluster auf maximal fünf pro Shard erhöhen. Sie können dazu die AWS-Managementkonsole, oder die MemoryDB-API AWS CLI verwenden.
**Topics**
+ [Mit dem AWS-Managementkonsole](#increase-replica-count-con)
+ [Mit dem AWS CLI](#increase-replica-count-cli)
+ [Verwenden der MemoryDB-API](#increase-replica-count-api)
### Mit dem AWS-Managementkonsole
Informationen zum Erhöhen der Anzahl von Replikaten in einem MemoryDB-Cluster (Konsole) finden Sie unter. [Knoten zu einem Cluster hinzufügen/entfernen](clusters.deletenode.md)
### Mit dem AWS CLI
Um die Anzahl der Replikate in einem MemoryDB-Cluster zu erhöhen, verwenden Sie den `update-cluster` Befehl mit den folgenden Parametern:
+ `--cluster-name` – Erforderlich. Identifiziert, in welchem Cluster Sie die Anzahl der Replikate erhöhen möchten.
+ `--replica-configuration` – Erforderlich. Ermöglicht es Ihnen, die Anzahl der Replikate festzulegen. Um die Anzahl der Replikate zu erhöhen, setzen Sie die `ReplicaCount` Eigenschaft auf die Anzahl der Replikate, die am Ende dieses Vorgangs in diesem Shard enthalten sein sollen.
**Example**
Im folgenden Beispiel wird die Anzahl der Replikate im Cluster auf 2 erhöht. `my-cluster`
Für Linux, macOS oder Unix:
```
aws memorydb update-cluster \
--cluster-name my-cluster \
--replica-configuration \
ReplicaCount=2
```
Für Windows:
```
aws memorydb update-cluster ^
--cluster-name my-cluster ^
--replica-configuration ^
ReplicaCount=2
```
Es gibt die folgende JSON-Antwort zurück:
```
{
"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
}
}
```
*Verwenden Sie den folgenden Befehl, um die Details des aktualisierten Clusters anzuzeigen, sobald sich sein Status von aktuell auf *verfügbar* ändert:*
Für Linux, macOS oder Unix:
```
aws memorydb describe-clusters \
--cluster-name my-cluster
--show-shard-details
```
Für Windows:
```
aws memorydb describe-clusters ^
--cluster-name my-cluster
--show-shard-details
```
Es wird die folgende JSON-Antwort zurückgegeben:
```
{
"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
}
]
}
```
*Weitere Informationen zum Erhöhen der Anzahl von Replikaten mithilfe der CLI finden Sie unter [update-cluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html) in der AWS CLI Befehlsreferenz.*
### Verwenden der MemoryDB-API
Um die Anzahl der Replikate in einem MemoryDB-Shard zu erhöhen, verwenden Sie die Aktion mit den `UpdateCluster` folgenden Parametern:
+ `ClusterName` – Erforderlich. Identifiziert, in welchem Cluster Sie die Anzahl der Replikate erhöhen möchten.
+ `ReplicaConfiguration` – Erforderlich. Ermöglicht es Ihnen, die Anzahl der Replikate festzulegen. Um die Anzahl der Replikate zu erhöhen, setzen Sie die `ReplicaCount` Eigenschaft auf die Anzahl der Replikate, die am Ende dieses Vorgangs in diesem Shard enthalten sein sollen.
**Example**
Im folgenden Beispiel wird die Anzahl der Replikate im Cluster auf drei erhöht. `sample-cluster` Wenn das Beispiel abgeschlossen ist, befinden sich in jedem Shard drei Replikate. Diese Zahl gilt unabhängig davon, ob es sich um einen MemoryDB-Cluster mit einem einzelnen Shard oder um einen MemoryDB-Cluster mit mehreren Shards handelt.
```
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=
```
Weitere Hinweise zur Erhöhung der Anzahl von Replikaten, die die API verwenden, finden Sie unter. [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html)
## Verringerung der Anzahl der Replikate in einem Cluster
Sie können die Anzahl der Replikate in einem Cluster für MemoryDB verringern. Sie können die Anzahl der Replikate auf Null reduzieren, aber Sie können kein Failover auf ein Replikat durchführen, wenn Ihr primärer Knoten ausfällt.
Sie können die AWS-Managementkonsole, AWS CLI oder die MemoryDB-API verwenden, um die Anzahl der Replikate in einem Cluster zu verringern.
**Topics**
+ [Mit dem AWS-Managementkonsole](#decrease-replica-count-con)
+ [Mit dem AWS CLI](#decrease-replica-count-cli)
+ [Verwendung der MemoryDB-API](#decrease-replica-count-api)
### Mit dem AWS-Managementkonsole
Informationen zum Verringern der Anzahl von Replikaten in einem MemoryDB-Cluster (Konsole) finden Sie unter. [Knoten zu einem Cluster hinzufügen/entfernen](clusters.deletenode.md)
### Mit dem AWS CLI
Um die Anzahl der Replikate in einem MemoryDB-Cluster zu verringern, verwenden Sie den `update-cluster` Befehl mit den folgenden Parametern:
+ `--cluster-name` – Erforderlich. Identifiziert, in welchem Cluster Sie die Anzahl der Replikate verringern möchten.
+ `--replica-configuration` – Erforderlich.
`ReplicaCount`— Legen Sie diese Eigenschaft fest, um die Anzahl der gewünschten Replikatknoten anzugeben.
**Example**
Im folgenden Beispiel wird `--replica-configuration` die Anzahl der Replikate im Cluster `my-cluster` auf den angegebenen Wert reduziert.
Für Linux, macOS oder Unix:
```
aws memorydb update-cluster \
--cluster-name my-cluster \
--replica-configuration \
ReplicaCount=1
```
Für Windows:
```
aws memorydb update-cluster ^
--cluster-name my-cluster ^
--replica-configuration ^
ReplicaCount=1 ^
```
Es wird die folgende JSON-Antwort zurückgegeben:
```
{
"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
}
}
```
*Verwenden Sie den folgenden Befehl, um die Details des aktualisierten Clusters anzuzeigen, sobald sich sein Status von aktuell auf *verfügbar* ändert:*
Für Linux, macOS oder Unix:
```
aws memorydb describe-clusters \
--cluster-name my-cluster
--show-shard-details
```
Für Windows:
```
aws memorydb describe-clusters ^
--cluster-name my-cluster
--show-shard-details
```
Es wird die folgende JSON-Antwort zurückgegeben:
```
{
"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
}
]
}
```
*Weitere Informationen zum Verringern der Anzahl von Replikaten mithilfe der CLI finden Sie unter [update-cluster](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-cluster.html) in der AWS CLI Befehlsreferenz.*
### Verwendung der MemoryDB-API
Verwenden Sie die `UpdateCluster` Aktion mit den folgenden Parametern, um die Anzahl der Replikate in einem MemoryDB-Cluster zu verringern:
+ `ClusterName` – Erforderlich. Identifiziert, in welchem Cluster Sie die Anzahl der Replikate verringern möchten.
+ `ReplicaConfiguration` – Erforderlich. Ermöglicht es Ihnen, die Anzahl der Replikate festzulegen.
`ReplicaCount`— Legen Sie diese Eigenschaft fest, um die Anzahl der gewünschten Replikatknoten anzugeben.
**Example**
Im folgenden Beispiel wird `ReplicaCount` die Anzahl der Replikate im Cluster `sample-cluster` auf eins reduziert. Wenn das Beispiel abgeschlossen ist, befindet sich in jedem Shard ein Replikat. Diese Zahl gilt unabhängig davon, ob es sich um einen MemoryDB-Cluster mit einem einzelnen Shard oder um einen MemoryDB-Cluster mit mehreren Shards handelt.
```
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=
```
Weitere Hinweise zur Verringerung der Anzahl von Replikaten, die die API verwenden, finden Sie unter. [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html)