Riduzione al minimo dei tempi di inattività in MemoryDB con Multi-AZ - Amazon MemoryDB
Risposte per scenari di errore relativi alla funzione Multi-AZTest del failover automatico

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à.

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 del nodo primario o della 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 venga persa alcuna perdita di 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:

  1. Il nodo primario non riuscito viene portato offline.

  2. Una up-to-date replica diventa automaticamente principale.

    Le scritture possono riprendere non appena il processo di failover è completo, in genere solo pochi secondi.

  3. 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.

  4. La replica si sincronizza con il registro delle transazioni.

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:

  1. Il nodo primario e le repliche non riuscite vengono messi offline.

  2. Una replica disponibile diventerà il nodo principale.

    Le scritture possono riprendere non appena il failover è completo, in genere solo pochi secondi.

  3. 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.

  4. Tutti i nodi si sincronizzano con il registro delle transazioni.

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

 

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.

  2. Viene creato e fornito un nodo primario sostitutivo, sincronizzato con il log delle transazioni.

  3. 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:

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 aFailoverShard, elencati qui in ordine di probabilità:

    1. messaggio del cluster: FailoverShard API called for shard <shard-id>

    2. messaggio del cluster: Failover from primary node <primary-node-id> to replica node <node-id> completed

    3. messaggio del cluster: Recovering nodes <node-id>

    4. messaggio del cluster: Finished recovery for nodes <node-id>

    Per ulteriori informazioni, consulta gli argomenti seguenti:

  • 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.

Test del failover automatico utilizzando il AWS Management Console

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

  1. Accedere AWS Management Console e aprire la console MemoryDB all'indirizzo https://console.aws.amazon.com/memorydb/.

  2. Scegli il pulsante di opzione a sinistra del cluster che desideri testare. Questo cluster deve avere almeno un nodo di replica.

  3. 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.

  4. Seleziona il nome del cluster.

  5. Nella pagina Shards and nodes, per lo shard su cui desiderate testare il failover, scegliete il nome dello shard.

  6. Per il nodo, scegli Failover Primary.

  7. 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 il AWS CLI

È possibile testare il failover automatico su qualsiasi cluster dotato di Multi-AZ utilizzando l' AWS CLI operazione failover-shard.

Parametri

  • --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:

 

Test del failover automatico utilizzando l'API MemoryDB

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

Esempio 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=<credential>

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

Per ulteriori informazioni, consulta gli argomenti seguenti: