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.

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.

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:

Per informazioni sull'individuazione degli endpoint di un cluster, consulta i seguenti argomenti:

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:

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:

Per informazioni sull'individuazione degli endpoint di un cluster, consulta i seguenti argomenti:

Test del failover automatico

È possibile testare il failover automatico utilizzando la console MemoryDB, il e MemoryDB. AWS CLI API

Durante il test, tieni presente quanto segue:

Test del failover automatico utilizzando AWS Management Console

Utilizza la procedura seguente per testare il failover automatico con la console.

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.

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 JSON risposta:

{
    "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:

Test del failover automatico utilizzando MemoryDB API

L'esempio seguente richiama FailoverShard lo shard 0003 nel cluster. memorydb00

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>

Per tenere traccia dell'avanzamento del failover, utilizzate l'operazione DescribeEvents API MemoryDB.

Per ulteriori informazioni, consulta gli argomenti seguenti: