View a markdown version of this page

Disponibilità e replica elevate di Amazon DocumentDB - Amazon DocumentDB

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

Disponibilità e replica elevate di Amazon DocumentDB

È possibile ottenere un'elevata disponibilità e scalabilità della lettura in Amazon DocumentDB (con compatibilità 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 per l'istanza primaria e per le 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 in 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 mantenere 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 sottorete (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 sottorete per bilanciare il cluster. Questa azione impedisce inoltre che tutte le istanze si trovino nella stessa zona di disponibilità.

Esempio

Per illustrare meglio questo punto, supponi di creare un cluster che abbia un gruppo di sottorete con tre zone di disponibilità: AZ1, AZ2 e AZ3.

Una volta creata, la prima istanza all'interno del cluster si trova in una delle zone di disponibilità. In questo esempio, si trova nella zona AZ1. La seconda istanza creata è un'istanza di replica e si trova in una delle altre due zone di disponibilità, ad esempio AZ2. La terza istanza creata è un'istanza di replica e si trova nella zona di disponibilità restante, 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 primaria (AZ1), viene attivato un failover e una delle repliche esistenti viene promossa a primaria. Quando la vecchia istanza primaria viene ripristinata, diventa una replica nella stessa zona di disponibilità in cui è stata assegnata (AZ1). Quando esegui il provisioning di un cluster a tre istanze, Amazon DocumentDB continua a preservare 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 ripristinata 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à.

Puoi specificare le repliche di Amazon DocumentDB come destinazioni di failover. In altre parole, se l'istanza primaria ha esito negativo, la replica o la replica di Amazon DocumentDB specificata da un livello viene promossa all'istanza primaria. 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 primaria ha esito negativo, viene ricreata. La promozione di una replica di Amazon DocumentDB è molto più veloce rispetto alla ricreazione dell'istanza primaria.

Per una disponibilità elevata, crea una o più repliche Amazon DocumentDB della stessa classe di istanza dell'istanza principale in diverse zone di disponibilità.

Per ulteriori informazioni, consulta gli argomenti seguenti:

Nelle versioni 5.0 e 8.0 di Amazon DocumentDB, le istanze di replica non si riavviano al riavvio dell'istanza primaria. Continuano a fornire richieste di lettura durante i riavvii dell'istanza primaria, mantenendo una maggiore disponibilità.

Alta disponibilità con cluster globali

Per un'elevata disponibilità su più livelli Regioni AWS, puoi configurare cluster globali di Amazon DocumentDB. Ogni cluster globale si estende su più regioni, consentendo letture globali a bassa latenza e il disaster recovery in caso di interruzioni tra regioni. 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 primaria.

Quando si crea un cluster utilizzando il Console di gestione AWS, 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 il cluster, è necessario creare in modo esplicito le istanze primarie e di replica. Per ulteriori informazioni, consulta la sezione «Utilizzo del AWS CLI" nei seguenti argomenti:

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 primario che fa sì che le repliche di lettura rimangano indietro rispetto a quelle primarie.

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

  • Numero molto elevato di interrogazioni simultanee sulle repliche lette.

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

  • Se hai una velocità di scrittura elevata o un elevato utilizzo della CPU, aumenta la scalabilità delle istanze nel cluster.

  • Se sono presenti query di lunga durata sulle repliche di lettura e aggiornamenti molto frequenti ai documenti oggetto di interrogazione, valuta la possibilità di modificare le query di lunga durata o di eseguirle sulla primary/write replica per evitare conflitti sulle repliche lette.

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

  • Poiché il ritardo di replica deriva da un elevato throughput di scrittura e da query di lunga durata, risolvi i problemi del ritardo di replica utilizzando la metrica in combinazione con lo slow query logger e le metriche/. DBClusterReplicaLagMaximum CloudWatch WriteThroughput WriteIOPS

Assicurati che tutte le repliche siano dello stesso tipo di istanza in modo che un failover del cluster non causi un peggioramento delle prestazioni.

Se scegli tra lo scaling up e lo scaling out (ad esempio, sei istanze più piccole contro tre istanze più grandi), in genere consigliamo di provare a scalare prima (istanze più grandi) prima di eseguire lo scaling out, poiché otterrai una cache di buffer più grande per istanza DB.

In modo proattivo, dovresti impostare un allarme di ritardo di replica e impostarne la soglia su un valore che ritieni sia il limite superiore del ritardo (o «obsoleto») dei tuoi 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 di creare un allarme, a causa di carichi di lavoro transitori.

Nota

Imposta un altro allarme per i ritardi di replica che superano i 10 secondi. Se superi questa soglia per più punti dati, aumenta la scalabilità delle istanze o riduci il throughput di scrittura sull'istanza principale.