Amazon DocumentDB Disponibilità e replica elevate

Puoi ottenere disponibilità elevata e scalabilità di lettura in Amazon DocumentDB (con compatibilità con MongoDB) utilizzando istanze di replica. Un singolo cluster Amazon DocumentDB supporta una singola istanza primaria e fino a 15 istanze di replica. Queste istanze possono essere distribuite tra le zone di disponibilità all'interno della regione del cluster. L'istanza primaria accetta il traffico in lettura e in scrittura, mentre le istanze di replica accettano solo richieste di lettura.

Il volume cluster si compone di più copie dei dati per il cluster. Tuttavia, i dati nel volume del cluster sono rappresentati come un unico volume logico nell'istanza principale e nelle repliche di Amazon DocumentDB nel cluster. Le istanze di replica sono consistenti finali. Restituiscono risultati di query con un ritardo di replica minimo, generalmente inferiore a 100 millisecondi dopo che l'istanza primaria ha scritto un aggiornamento. Il ritardo di replica varia in base alla velocità di modifica del database. In altre parole, nei periodi in cui si verificano numerose operazioni di scrittura nel database, potresti riscontrare un aumento del ritardo di replica.

Dimensionamento della lettura

Le repliche di Amazon DocumentDB funzionano bene per il ridimensionamento della lettura perché sono completamente dedicate alle operazioni di lettura sul volume del cluster. Le operazioni di lettura sono gestite dall'istanza primaria. Il volume del cluster è condiviso tra tutte le istanze del cluster. Pertanto, non è necessario replicare e conservare una copia dei dati per ogni replica di Amazon DocumentDB.

Elevata disponibilità

Quando crei un cluster Amazon DocumentDB, a seconda del numero di zone di disponibilità nel gruppo di sottoreti (devono essercene almeno due), Amazon DocumentDB effettua il provisioning delle istanze nelle zone di disponibilità. Quando crei istanze nel cluster, Amazon DocumentDB le distribuisce automaticamente tra le zone di disponibilità in un gruppo di sottoreti per bilanciare il cluster. Questa azione impedisce inoltre che tutte le istanze si trovino nella stessa zona di disponibilità.

Esempio

Per illustrare il punto, considera un esempio in cui crei un cluster con un gruppo di sottoreti con tre zone di disponibilità:, e. AZ1AZ2AZ3

Una volta creata, la prima istanza all'interno del cluster si trova in una delle zone di disponibilità. In questo esempio, è in. AZ1 La seconda istanza creata è un'istanza di replica e si trova, ad esempio AZ2, in una delle altre due zone di disponibilità. La terza istanza creata è un'istanza di replica e si trova nella zona di disponibilità rimanente,. AZ3 Se crei più istanze, queste sono distribuite tra le zone di disponibilità in modo da ottenere il bilanciamento del cluster.

Se si verifica un errore nell'istanza principale (AZ1), viene attivato un failover e una delle repliche esistenti viene promossa a principale. Quando la vecchia unità primaria viene ripristinata, diventa una replica nella stessa zona di disponibilità in cui era stata fornita (). AZ1 Quando effettui il provisioning di un cluster a tre istanze, Amazon DocumentDB continua a conservare quel cluster a tre istanze. Amazon DocumentDB gestisce automaticamente il rilevamento, il failover e il ripristino degli errori delle istanze senza alcun intervento manuale.

Quando Amazon DocumentDB esegue un failover e ripristina un'istanza, l'istanza recuperata rimane nella zona di disponibilità in cui era stata originariamente fornita. Tuttavia, il ruolo dell'istanza potrebbe cambiare da primaria a replica. Questa operazione viene eseguita per evitare lo scenario in cui una serie di failover provoca il posizionamento di tutte le istanze nella stessa zona di disponibilità.

È possibile specificare le repliche di Amazon DocumentDB come destinazioni di failover. In altre parole, se l'istanza primaria fallisce, la replica Amazon DocumentDB specificata o la replica di un livello viene promossa all'istanza principale. Si verifica una breve interruzione durante la quale le richieste di lettura e scrittura inviate all'istanza primaria falliscono con un'eccezione. Se il tuo cluster Amazon DocumentDB non include alcuna replica di Amazon DocumentDB, quando l'istanza principale si guasta, viene ricreata. La promozione di una replica di Amazon DocumentDB è molto più rapida rispetto alla ricreazione dell'istanza principale.

Per scenari ad alta disponibilità, consigliamo di creare una o più repliche di Amazon DocumentDB. Queste repliche devono appartenere alla stessa classe di istanza dell'istanza principale e in zone di disponibilità diverse per il cluster Amazon DocumentDB.

Per ulteriori informazioni, consulta gli argomenti seguenti:

• Comprendere la tolleranza agli errori del cluster Amazon DocumentDB

• Failover di Amazon DocumentDB

  • Controllo della destinazione del failover

Alta disponibilità con cluster globali

Per un'elevata disponibilità su più piattaforme Regioni AWS, puoi configurare cluster globali di Amazon DocumentDB. Ogni cluster globale si estende su più regioni, consentendo letture globali a bassa latenza e disaster recovery in caso di interruzioni su un. Regione AWS Amazon DocumentDB gestisce automaticamente la replica di tutti i dati e gli aggiornamenti dalla regione principale a ciascuna delle regioni secondarie.

Aggiunta di repliche di

L'istanza primaria è la prima istanza aggiunta al cluster. Ogni istanza aggiunta dopo la prima è un'istanza di replica. Un cluster può avere fino a 15 istanze di replica oltre a quella principale.

Quando si crea un cluster utilizzando il AWS Management Console, contemporaneamente viene creata automaticamente un'istanza primaria. Per creare una replica nello stesso momento in cui viene creato il cluster e l'istanza primaria, scegli Create replica in different zone (Crea replica in una zona diversa). Per ulteriori informazioni, consulta la fase 4.d in Creazione di un cluster Amazon DocumentDB. Per aggiungere altre repliche a un cluster Amazon DocumentDB, consulta. Aggiungere un'istanza Amazon DocumentDB a un cluster

Quando si utilizza il AWS CLI per creare un cluster, è necessario creare in modo esplicito le istanze primarie e di replica. Per ulteriori informazioni, consulta la sezione «Utilizzo di AWS CLI" nei seguenti argomenti:

• Creazione di un cluster Amazon DocumentDB

• Aggiungere un'istanza Amazon DocumentDB a un cluster

Ritardo di replica

Il ritardo di replica è in genere pari o inferiore a 50 ms. I motivi più comuni dell'aumento del ritardo di replica sono:

• Una velocità di scrittura elevata sul sistema primario che fa sì che le repliche di lettura rimangano inferiori rispetto a quelle primarie.

• Conflitto sulle repliche di lettura tra query a esecuzione prolungata (ad esempio, scansioni sequenziali di grandi dimensioni, query di aggregazione) e replica di scrittura in entrata.

• Numero molto elevato di query simultanee sulle repliche di lettura.

Per ridurre al minimo il ritardo nella replica, prova queste tecniche di risoluzione dei problemi:

• Se hai una velocità di scrittura o un CPU utilizzo elevato, ti consigliamo di scalare le istanze del cluster.

• Se sono presenti query di lunga durata sulle repliche di lettura e aggiornamenti molto frequenti dei documenti interrogati, valuta la possibilità di modificare le query di lunga durata o di eseguirle sulla replica primaria/di scrittura per evitare conflitti sulle repliche di lettura.

• Se è presente un numero molto elevato di query simultanee o un CPU utilizzo elevato solo sulle repliche di lettura, un'altra opzione è quella di ridimensionare il numero di repliche di lettura per distribuire il carico di lavoro.

• Poiché il ritardo di replica è il risultato di un'elevata velocità di scrittura e di query a esecuzione prolungata, si consiglia di risolvere il problema del ritardo di replica utilizzando la metrica CW in combinazione con lo slow query logger e/metrics. DBClusterReplicaLagMaximum WriteThroughput WriteIOPS

In generale, è consigliabile che tutte le repliche siano dello stesso tipo di istanza, in modo che un failover del cluster non provochi un peggioramento delle prestazioni.

Se si sceglie tra la scalabilità verticale e quella orizzontale (ad esempio sei istanze più piccole anziché tre istanze più grandi), in genere consigliamo di provare a scalare prima (istanze più grandi) prima di eseguire la scalabilità orizzontale, in quanto si otterrà una cache di buffer più grande per istanza DB.

In modo proattivo, dovresti impostare un allarme di ritardo nella replica e impostarne la soglia su un valore che ritieni sia il limite superiore per indicare il ritardo (o «obsoleto») dei dati sulle istanze di replica prima che inizino a influire sulla funzionalità dell'applicazione. In generale, consigliamo di superare la soglia di ritardo di replica per diversi punti dati prima dell'invio di allarmi, a causa di carichi di lavoro transitori.

Nota

Inoltre, si consiglia di impostare un altro allarme per i ritardi di replica superiori a 10 secondi. Se superi questa soglia per più punti dati, ti consigliamo di scalare le istanze o ridurre il throughput di scrittura sull'istanza principale.