Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Comprendere la replica di MemoryDB
MemoryDB implementa la replica con dati partizionati su un massimo di 500 shard.
Ogni shard in un cluster ha un singolo nodo read/write primario e fino a 5 nodi di replica di sola lettura. Ogni nodo primario può supportare fino a 100 MB/s. È possibile creare un cluster con un numero maggiore di shard e un numero inferiore di repliche, per un totale di fino a 500 nodi per cluster. Questa configurazione del cluster può variare da 500 shard e 0 repliche a 100 shard e 4 repliche, ovvero il numero massimo di repliche consentite.
# Coerenza
In MemoryDB, i nodi primari sono fortemente coerenti. Le operazioni di scrittura riuscite vengono archiviate in modo duraturo in registri transazionali Multi-AZ distribuiti prima di essere restituite ai clienti. Le operazioni di lettura sui file primari restituiscono sempre la maggior parte up-to-date dei dati, riflettendo gli effetti di tutte le precedenti operazioni di scrittura riuscite. Una coerenza così forte viene preservata durante i failover primari.
In MemoryDB, i nodi di replica alla fine sono coerenti. Le operazioni di lettura dalle repliche (utilizzando `READONLY` il comando) potrebbero non riflettere sempre gli effetti delle più recenti operazioni di scrittura riuscite, con metriche di lag pubblicate su. CloudWatch Tuttavia, le operazioni di lettura da una singola replica sono coerenti in sequenza. Le operazioni di scrittura riuscite hanno effetto su ogni replica nello stesso ordine in cui sono state eseguite sulla principale.
## Replica in un cluster
Ogni replica di lettura in uno shard conserva una copia dei dati dal nodo primario dello shard. I meccanismi di replica asincrona che utilizzano i log delle transazioni vengono utilizzati per mantenere le repliche di lettura sincronizzate con quelle primarie. Le applicazioni possono leggere da qualsiasi nodo nel cluster. Le applicazioni possono scrivere solo nei nodi primari. Le repliche di lettura migliorano la scalabilità di lettura. Poiché MemoryDB archivia i dati in registri delle transazioni durevoli, non vi è alcun rischio che i dati vadano persi. I dati vengono partizionati tra gli shard in un cluster MemoryDB.
Le applicazioni utilizzano l'*endpoint del cluster MemoryDB per connettersi con i nodi del cluster*. Per ulteriori informazioni, consulta [Individuazione degli endpoint di connessione](endpoints.md).
I cluster MemoryDB sono regionali e possono contenere nodi di una sola regione. Per migliorare la tolleranza agli errori, è necessario effettuare il provisioning dei file primari e leggere le repliche in più zone di disponibilità all'interno di quella regione.
L'utilizzo della replica, che fornisce Multi-AZ, è fortemente consigliato per tutti i cluster MemoryDB. Per ulteriori informazioni, consulta [Riduzione al minimo dei tempi di inattività in MemoryDB con Multi-AZ](autofailover.md).
# Riduzione al minimo dei tempi di inattività in MemoryDB con Multi-AZ
Esistono diversi casi in cui MemoryDB potrebbe dover sostituire un nodo primario, tra cui alcuni tipi di manutenzione pianificata e l'improbabile eventualità di un guasto di un nodo primario o di una zona di disponibilità.
La risposta all'errore del nodo dipende dal nodo in cui si è verificato l'errore. Tuttavia, in tutti i casi, MemoryDB garantisce che nessun dato venga perso durante la sostituzione dei nodi o il failover. Ad esempio, se una replica fallisce, il nodo guasto viene sostituito e i dati vengono sincronizzati dal registro delle transazioni. Se il nodo primario si guasta, viene attivato un failover su una replica coerente che garantisce che non vengano persi dati durante il failover. Le scritture vengono ora servite dal nuovo nodo primario. Il vecchio nodo primario viene quindi sostituito e sincronizzato dal registro delle transazioni.
Se un nodo primario si guasta su uno shard a nodo singolo (nessuna replica), MemoryDB smette di accettare scritture finché il nodo primario non viene sostituito e sincronizzato dal log delle transazioni.
La sostituzione dei nodi può causare alcuni tempi di inattività per il cluster, ma se Multi-AZ è attivo, il tempo di inattività è ridotto al minimo. Il ruolo del nodo primario eseguirà automaticamente il failover su una delle repliche. Non è necessario creare e fornire un nuovo nodo primario, poiché MemoryDB lo gestirà in modo trasparente. Questo failover e la promozione delle repliche garantiscono la possibilità di ricominciare a scrivere nel nuovo nodo primario non appena la promozione è terminata.
In caso di sostituzioni pianificate dei nodi avviate a causa di aggiornamenti di manutenzione o aggiornamenti del servizio, tenete presente che le sostituzioni pianificate dei nodi vengono completate mentre il cluster soddisfa le richieste di scrittura in entrata.
Multi-AZ sui cluster MemoryDB migliora la tolleranza ai guasti. Ciò è vero in particolare nei casi in cui i nodi primari del cluster diventano irraggiungibili o falliscono per qualsiasi motivo. Multi-AZ sui cluster MemoryDB richiede che ogni shard abbia più di un nodo e viene abilitato automaticamente.
**Topics**
+ [Risposte per scenari di errore relativi alla funzione Multi-AZ](#autofailover.scenarios)
+ [Test del failover automatico](#auto-failover-test)
## Risposte per scenari di errore relativi alla funzione Multi-AZ
Se Multi-AZ è attivo, un nodo primario guasto esegue il failover su una replica disponibile. La replica viene sincronizzata automaticamente con il registro delle transazioni e diventa principale, il che è molto più veloce rispetto alla creazione e al riprovisioning di un nuovo nodo primario. Questo processo richiede in genere pochi secondi prima che sia possibile scrivere nuovamente nel cluster.
Quando Multi-AZ è attivo, MemoryDB monitora continuamente lo stato del nodo primario. Se il nodo primario non riesce, viene eseguita una delle seguenti operazioni a seconda del tipo di errore.
**Topics**
+ [Scenari di errore quando solo il nodo primario non riesce](#autofailover.scenarios.primaryonly)
+ [Scenari di errore in cui il nodo principale e alcune repliche falliscono](#autofailover.scenarios.primaryandeplicas)
+ [Scenari di fallimento quando l'intero cluster non riesce](#autofailover.scenarios.allfail)
### Scenari di errore quando solo il nodo primario non riesce
Se si verifica un errore solo nel nodo primario, una replica diventerà automaticamente principale. Viene quindi creata e fornita una replica sostitutiva nella stessa zona di disponibilità della replica primaria guasta.
Quando si verifica un errore solo nel nodo primario, MemoryDB Multi-AZ esegue le seguenti operazioni:
1. Il nodo primario non riuscito viene portato offline.
1. Una up-to-date replica diventa automaticamente principale.
Le scritture possono riprendere non appena il processo di failover è completo, in genere solo pochi secondi.
1. Viene avviata e fornita una replica sostitutiva.
La replica sostitutiva viene avviata nella zona di disponibilità in cui si trovava il nodo primario guasto, in modo da mantenere la distribuzione dei nodi.
1. La replica si sincronizza con il registro delle transazioni.
Per informazioni sull'individuazione degli endpoint di un cluster, consulta i seguenti argomenti:
+ [Ricerca dell'endpoint per un cluster MemoryDB (API MemoryDB)](endpoints.md#endpoints.find.api.clusters)
### Scenari di errore in cui il nodo principale e alcune repliche falliscono
Se la replica principale e almeno una replica falliscono, una up-to-date replica viene promossa a cluster primario. Vengono inoltre create e fornite nuove repliche nelle stesse zone di disponibilità dei nodi guasti.
Quando il nodo primario e alcune repliche falliscono, MemoryDB Multi-AZ esegue le seguenti operazioni:
1. Il nodo primario e le repliche non riuscite vengono messi offline.
1. Una replica disponibile diventerà il nodo principale.
Le scritture possono riprendere non appena il failover è completo, in genere solo pochi secondi.
1. Repliche sostitutive vengono create e sottoposte a provisioning.
Le repliche sostitutive vengono create nelle zone di disponibilità dei nodi non riusciti, in modo da mantenere la distribuzione dei nodi.
1. Tutti i nodi si sincronizzano con il registro delle transazioni.
Per informazioni sull'individuazione degli endpoint di un cluster, consulta i seguenti argomenti:
+ [Individuazione dell'endpoint per un cluster MemoryDB (CLI)AWS](endpoints.md#endpoints.find.cli)
+ [Ricerca dell'endpoint per un cluster MemoryDB (API MemoryDB)](endpoints.md#endpoints.find.api.clusters)
### Scenari di fallimento quando l'intero cluster non riesce
In caso di errore generale, tutti i nodi vengono ricreati e sottoposti a provisioning nelle stesse zone di disponibilità dei nodi originali.
In questo scenario non si verifica alcuna perdita di dati poiché i dati sono stati mantenuti nel registro delle transazioni.
Quando l'intero cluster fallisce, MemoryDB Multi-AZ esegue le seguenti operazioni:
1. Il nodo primario e le repliche guasti vengono messi offline.
1. Viene creato e fornito un nodo primario sostitutivo, sincronizzato con il log delle transazioni.
1. Le repliche sostitutive vengono create e fornite, sincronizzate con il log delle transazioni.
Le sostituzioni vengono create nelle zone di disponibilità dei nodi non riusciti, in modo da mantenere la distribuzione dei nodi.
Per informazioni sull'individuazione degli endpoint di un cluster, consulta i seguenti argomenti:
+ [Individuazione dell'endpoint per un cluster MemoryDB (CLI)AWS](endpoints.md#endpoints.find.cli)
+ [Ricerca dell'endpoint per un cluster MemoryDB (API MemoryDB)](endpoints.md#endpoints.find.api.clusters)
## Test del failover automatico
È possibile testare il failover automatico utilizzando la console MemoryDB, l'API MemoryDB e l' AWS CLI API MemoryDB.
Durante il test, tieni presente quanto segue:
+ È possibile utilizzare questa operazione fino a cinque volte in un periodo di 24 ore.
+ Se richiami questa operazione su shard in cluster diversi, puoi effettuare le chiamate contemporaneamente.
+ In alcuni casi, è possibile chiamare questa operazione più volte su diversi shard nello stesso cluster MemoryDB. In questi casi, la sostituzione del primo nodo deve essere completata prima di effettuare una chiamata successiva.
+ Per determinare se la sostituzione del nodo è completa, controlla gli eventi utilizzando la console MemoryDB, l'API MemoryDB o l' AWS CLI API MemoryDB. Cerca i seguenti eventi correlati a`FailoverShard`, elencati qui in ordine di probabilità:
1. messaggio del cluster: `FailoverShard API called for shard `
1. messaggio del cluster: `Failover from primary node to replica node completed`
1. messaggio del cluster: `Recovering nodes `
1. messaggio del cluster: `Finished recovery for nodes `
Per ulteriori informazioni, consulta gli argomenti seguenti:
+ [DescribeEvents](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEvents.html)nel riferimento all'API *MemoryDB*
+ Questa API è progettata per testare il comportamento dell'applicazione in caso di failover di MemoryDB. Non è progettato per essere uno strumento operativo per l'avvio di un failover per risolvere un problema con il cluster. Inoltre, in determinate condizioni, come eventi operativi su larga scala, AWS può bloccare questa API.
**Topics**
+ [Test del failover automatico utilizzando Console di gestione AWS](#auto-failover-test-con)
+ [Test del failover automatico utilizzando AWS CLI](#auto-failover-test-cli)
+ [Test del failover automatico utilizzando l'API MemoryDB](#failovershard-test-api)
### Test del failover automatico utilizzando Console di gestione AWS
Utilizza la procedura seguente per testare il failover automatico con la console.
****
1. Accedi Console di gestione AWS e apri la console MemoryDB all'indirizzo. [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/)
1. Scegli il pulsante radio a sinistra del cluster che desideri testare. Questo cluster deve avere almeno un nodo di replica.
1. Nell'area **Dettagli**, conferma che questo cluster è abilitato per Multi-AZ. Se il cluster non è abilitato per la funzione Multi-AZ, scegliere un cluster diverso o modificare questo cluster per abilitare la funzione Multi-AZ. Per ulteriori informazioni, consulta [Modifica di un cluster MemoryDB](clusters.modify.md).
1. Seleziona il nome del cluster.
1. Nella pagina **Shards and nodes**, per lo shard su cui desiderate testare il failover, scegliete il nome dello shard.
1. **Per il nodo, scegli Failover Primary.**
1. Scegli **Continua** per eseguire il failover nel nodo primario o **Annulla** per annullare l'operazione e non eseguire il failover nel nodo primario.
Durante il processo di failover, la console continua a visualizzare lo stato del nodo come *disponibile*. Per monitorare l'avanzamento del test di failover, scegli **Eventi** dal riquadro di navigazione della console. Nella scheda **Eventi**, cerca gli eventi che indicano che il failover è stato avviato (`FailoverShard API called`) e completato (`Recovery completed`).
### Test del failover automatico utilizzando AWS CLI
[È possibile testare il failover automatico su qualsiasi cluster dotato di Multi-AZ utilizzando l' AWS CLI operazione failover-shard.](https://docs.aws.amazon.com/cli/latest/reference/memorydb/failover-shard.html)
**Parameters**
+ `--cluster-name`: obbligatorio Il cluster che deve essere testato.
+ `--shard-name`: obbligatorio Il nome dello shard su cui si desidera testare il failover automatico. È possibile testare un massimo di cinque shard in un periodo continuativo di 24 ore.
L'esempio seguente utilizza la chiamata AWS CLI `failover-shard` allo shard `0001` nel cluster MemoryDB. `my-cluster`
Per Linux, macOS o Unix:
```
aws memorydb failover-shard \
--cluster-name my-cluster \
--shard-name 0001
```
Per Windows:
```
aws memorydb failover-shard ^
--cluster-name my-cluster ^
--shard-name 0001
```
Per tenere traccia dell'avanzamento del failover, utilizzate l'operazione. AWS CLI `describe-events`
Restituirà la seguente risposta 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"
}
]
}
```
Per ulteriori informazioni, consulta gli argomenti seguenti:
+ [frammento di failover](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)
### Test del failover automatico utilizzando l'API MemoryDB
L'esempio seguente chiama `FailoverShard` lo shard `0003` nel cluster. `memorydb00`
**Example Test del failover automatico**
```
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=
```
Per tenere traccia dell'avanzamento del failover, utilizzate l'operazione API MemoryDB`DescribeEvents`.
Per ulteriori informazioni, consulta gli argomenti seguenti:
+ [FailoverShard](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_FailoverShard.html)
+ [DescribeEvents](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEvents.html)
# Modifica del numero di repliche
È possibile aumentare o diminuire dinamicamente il numero di repliche di lettura nel cluster MemoryDB utilizzando l'API MemoryDB o l'API MemoryDB. Console di gestione AWS AWS CLI Tutti gli shard devono avere lo stesso numero di repliche.
## Aumento del numero di repliche in un cluster
È possibile aumentare il numero di repliche in un cluster MemoryDB fino a un massimo di cinque per shard. È possibile farlo utilizzando l' Console di gestione AWS, the o l'API AWS CLI MemoryDB.
**Topics**
+ [Utilizzando il Console di gestione AWS](#increase-replica-count-con)
+ [Utilizzo del AWS CLI](#increase-replica-count-cli)
+ [Utilizzo dell'API MemoryDB](#increase-replica-count-api)
### Utilizzando il Console di gestione AWS
Per aumentare il numero di repliche in un cluster MemoryDB (console), vedere. [Aggiunta/rimozione di nodi da un cluster](clusters.deletenode.md)
### Utilizzo del AWS CLI
Per aumentare il numero di repliche in un cluster MemoryDB, utilizzate il `update-cluster` comando con i seguenti parametri:
+ `--cluster-name`: obbligatorio Identifica in quale cluster si desidera aumentare il numero di repliche.
+ `--replica-configuration`: obbligatorio Consente di impostare il numero di repliche. Per aumentare il numero di repliche, impostate la `ReplicaCount` proprietà sul numero di repliche che desiderate in questo shard al termine di questa operazione.
**Example**
L'esempio seguente aumenta il numero di repliche nel cluster a 2. `my-cluster`
Per Linux, macOS o Unix:
```
aws memorydb update-cluster \
--cluster-name my-cluster \
--replica-configuration \
ReplicaCount=2
```
Per Windows:
```
aws memorydb update-cluster ^
--cluster-name my-cluster ^
--replica-configuration ^
ReplicaCount=2
```
Restituisce la seguente risposta 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
}
}
```
Per visualizzare i dettagli del cluster aggiornato una volta che il suo stato passa da *aggiornamento* a *disponibile*, utilizza il comando seguente:
Per Linux, macOS o Unix:
```
aws memorydb describe-clusters \
--cluster-name my-cluster
--show-shard-details
```
Per Windows:
```
aws memorydb describe-clusters ^
--cluster-name my-cluster
--show-shard-details
```
Restituirà la seguente risposta 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
}
]
}
```
*Per ulteriori informazioni sull'aumento del numero di repliche utilizzando la CLI, [vedere](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html) update-cluster nel Command Reference.AWS CLI *
### Utilizzo dell'API MemoryDB
Per aumentare il numero di repliche in uno shard di MemoryDB, utilizzate l'azione con i `UpdateCluster` seguenti parametri:
+ `ClusterName`: obbligatorio Identifica in quale cluster si desidera aumentare il numero di repliche.
+ `ReplicaConfiguration`: obbligatorio Consente di impostare il numero di repliche. Per aumentare il numero di repliche, impostate la `ReplicaCount` proprietà sul numero di repliche che desiderate in questo shard al termine di questa operazione.
**Example**
L'esempio seguente aumenta a tre il numero di repliche nel cluster. `sample-cluster` Al termine dell'esempio, ci sono tre repliche in ogni shard. Questo numero si applica sia che si tratti di un cluster MemoryDB con un singolo shard o di un cluster MemoryDB con più shard.
```
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=
```
Per ulteriori informazioni sull'aumento del numero di repliche utilizzando l'API, vedere. [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html)
## Riduzione del numero di repliche in un cluster
È possibile ridurre il numero di repliche in un cluster per MemoryDB. È possibile ridurre il numero di repliche a zero, ma non è possibile eseguire il failover su una replica in caso di guasto del nodo primario.
È possibile utilizzare l'API Console di gestione AWS, the AWS CLI o MemoryDB per ridurre il numero di repliche in un cluster.
**Topics**
+ [Utilizzando il Console di gestione AWS](#decrease-replica-count-con)
+ [Utilizzo del AWS CLI](#decrease-replica-count-cli)
+ [Utilizzo dell'API MemoryDB](#decrease-replica-count-api)
### Utilizzando il Console di gestione AWS
Per ridurre il numero di repliche in un cluster MemoryDB (console), vedere. [Aggiunta/rimozione di nodi da un cluster](clusters.deletenode.md)
### Utilizzo del AWS CLI
Per ridurre il numero di repliche in un cluster MemoryDB, utilizzate il `update-cluster` comando con i seguenti parametri:
+ `--cluster-name`: obbligatorio Identifica in quale cluster si desidera ridurre il numero di repliche.
+ `--replica-configuration`: obbligatorio
`ReplicaCount`— Imposta questa proprietà per specificare il numero di nodi di replica che desideri.
**Example**
L'esempio seguente utilizza `--replica-configuration` per ridurre il numero di repliche nel cluster `my-cluster` al valore specificato.
Per Linux, macOS o Unix:
```
aws memorydb update-cluster \
--cluster-name my-cluster \
--replica-configuration \
ReplicaCount=1
```
Per Windows:
```
aws memorydb update-cluster ^
--cluster-name my-cluster ^
--replica-configuration ^
ReplicaCount=1 ^
```
Restituirà la seguente risposta 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
}
}
```
Per visualizzare i dettagli del cluster aggiornato una volta che il suo stato cambia da *aggiornamento* a *disponibile*, usa il comando seguente:
Per Linux, macOS o Unix:
```
aws memorydb describe-clusters \
--cluster-name my-cluster
--show-shard-details
```
Per Windows:
```
aws memorydb describe-clusters ^
--cluster-name my-cluster
--show-shard-details
```
Restituirà la seguente risposta 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
}
]
}
```
*Per ulteriori informazioni sulla riduzione del numero di repliche utilizzando la CLI, vedere [update-cluster](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-cluster.html) nel Command Reference.AWS CLI *
### Utilizzo dell'API MemoryDB
Per ridurre il numero di repliche in un cluster MemoryDB, utilizzate l'`UpdateCluster`azione con i seguenti parametri:
+ `ClusterName`: obbligatorio Identifica in quale cluster si desidera ridurre il numero di repliche.
+ `ReplicaConfiguration`: obbligatorio Consente di impostare il numero di repliche.
`ReplicaCount`— Imposta questa proprietà per specificare il numero di nodi di replica che desideri.
**Example**
L'esempio seguente consente `ReplicaCount` di ridurre a una il numero di repliche nel cluster`sample-cluster`. Al termine dell'esempio, c'è una replica in ogni shard. Questo numero si applica sia che si tratti di un cluster MemoryDB con un singolo shard o di un cluster MemoryDB con più shard.
```
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=
```
Per ulteriori informazioni sulla riduzione del numero di repliche utilizzando l'API, vedere. [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html)