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

Replica con Amazon Aurora MySQL

Le funzionalità di replica Aurora MySQL sono essenziali per garantire l'elevata disponibilità e le prestazioni avanzate del cluster. Aurora facilita la creazione o il ridimensionamento dei cluster con un massimo di 15 repliche Aurora.

Tutte le repliche utilizzano gli stessi dati sottostanti. Se alcune istanze database passano alla modalità offline, altre rimangono disponibili per continuare a elaborare le query o per essere utilizzate come scrittore, se necessario. Aurora ripartisce automaticamente le connessioni di sola lettura in più istanze database, consentendo a un cluster Aurora di supportare carichi di lavoro che comportano un grande numero di query.

Nei seguenti argomenti vengono fornite informazioni sul funzionamento della replica Aurora MySQL nonché sulla regolazione delle impostazioni di replica per garantire una disponibilità e prestazioni ottimali.

Utilizzo delle repliche di Aurora

Le repliche Aurora sono endpoint indipendenti in un cluster DB Aurora, utilizzati al meglio per operazioni di dimensionamento della lettura e maggiore disponibilità. È possibile distribuire fino a 15 repliche di Aurora nelle zone di disponibilità sulle quali si estende un cluster di database in una Regione AWS. Sebbene il volume cluster database sia fatto di copie multiple di dati per il cluster database, i dati nel volume cluster sono rappresentati come un volume singolo e logico nell'istanza primaria e nelle repliche Aurora nel cluster database. Per ulteriori informazioni sulle repliche di Aurora, consulta Repliche di Aurora.

Le repliche Aurora funzionano bene per il dimensionamento della lettura perché sono dedicate completamente a operazioni di lettura nel volume cluster. Le operazioni di lettura sono gestite dall'istanza primaria. Poiché il volume del cluster viene condiviso tra tutte le istanze database nel tuo cluster database Aurora MySQL, non è necessaria alcuna ulteriore azione per replicare una copia dei dati per ciascuna replica Aurora. Al contrario, le repliche di lettura MySQL devono riprodurre, su un singolo thread, tutte le operazioni di scrittura dall'istanza database master al datastore locale. Questa limitazione può influire sulla capacita delle repliche di lettura MySQL di supportare grandi volumi di traffico in lettura.

Con Aurora MySQL, quando una replica Aurora viene eliminata, l'endpoint dell'istanza viene rimosso immediatamente e la replica Aurora viene rimossa dall'endpoint di lettura. Se vi sono istruzioni in esecuzione nella replica Aurora da eliminare, si ha un periodo di tolleranza di tre minuti. Le istruzioni esistenti possono finire correttamente durante un periodo di tolleranza. Quando finisce il periodo di tolleranza, la replica Aurora viene chiusa ed eliminata.

Opzioni di replica per Amazon Aurora MySQL

Puoi impostare repliche tra qualsiasi delle seguenti opzioni:

Considerazioni sulle prestazioni per la replica Amazon Aurora MySQL

Le funzionalità seguenti consentono di ottimizzare le prestazioni della replica Aurora MySQL.

La funzionalità di compressione dei log di replica riduce automaticamente la larghezza di banda di rete per i messaggi di replica. Poiché ogni messaggio è trasmesso a tutte le repliche Aurora, i vantaggi sono maggiori per i cluster più voluminosi. Questa funzionalità implica un certo overhead della CPU sul nodo scrittore per eseguire la compressione. È sempre abilitato in Aurora MySQL versione 2 e versione 3.

La funzionalità di filtraggio binlog riduce automaticamente la larghezza di banda di rete per i messaggi di replica. Poiché le repliche Aurora non utilizzano informazioni di binlog incluse nei messaggi di replica, quei dati sono omessi dai messaggi inviati a tali nodi.

In Aurora MySQL versione 2, puoi controllare questa funzionalità modificando il parametro aurora_enable_repl_bin_log_filtering. Per impostazione predefinita, questo parametro è abilitato. Poiché questa ottimizzazione è concepita per essere trasparente, puoi disattivare questa impostazione solo durante la diagnosi o la risoluzione dei problemi relativi alla replica. Ad esempio per corrispondere al comportamento di un cluster Aurora MySQL meno recente dove questa funzionalità non era disponibile.

In Aurora MySQL versione 3, il filtraggio dei file binlog è sempre abilitato.

Monitoraggio della replica Amazon Aurora MySQL.

Il dimensionamento di lettura e l'alta disponibilità dipendono da un periodo di ritardo minimo. Puoi monitorare il ritardo di una replica Aurora rispetto all'istanza principale del tuo cluster Aurora MySQL DB monitorando la metrica Amazon. CloudWatch AuroraReplicaLag La metrica AuroraReplicaLag viene registrata in ogni replica Aurora.

L'istanza DB principale registra anche le CloudWatch metriche AuroraReplicaLagMaximum e AuroraReplicaLagMinimum Amazon. La metrica AuroraReplicaLagMaximum registra la quantità massima di ritardo tra l'istanza DB primaria e ogni replica Aurora nel cluster DB. La metrica AuroraReplicaLagMinimum registra la quantità minima di ritardo tra l'istanza DB primaria e ogni replica Aurora nel cluster DB.

Se hai bisogno del valore più recente per il ritardo di Aurora Replica, puoi controllare la metrica AuroraReplicaLag in Amazon. CloudWatch Il ritardo replica di Aurora viene anche registrato su ogni replica Aurora del cluster database Aurora MySQL nella tabella information_schema.replica_host_status. Per ulteriori informazioni su questa tabella, consultare information_schema.replica_host_status.

Per ulteriori informazioni sul monitoraggio delle istanze e dei parametri RDS, consulta. CloudWatch Monitoraggio dei parametri in un cluster di database Amazon Aurora