Come posso risolvere i problemi che riscontro quando utilizzo repliche in lettura nella mia istanza database Aurora compatibile con MySQL?

Risoluzione

Promuovi una replica in lettura di Aurora compatibile con MySQL

Se l'istanza di scrittura richiede un riavvio o una manutenzione, esegui un failover manuale per promuovere una replica in lettura come istanza di scrittura.

Per eseguire un failover manuale, completa i seguenti passaggi:

1. Apri la console Amazon RDS.
2. Nel pannello di navigazione, scegli Database.
3. Scegli l'istanza di scrittura del cluster Aurora DB.
4. Scegli Operazioni, quindi Failover.

Se l'istanza di scrittura non è disponibile, Aurora compatibile con MySQL esegue automaticamente il failover su un'istanza di replica in lettura. Un'istanza di scrittura può diventare non disponibile per diversi motivi, ad esempio un conflitto di risorse o un'attività di manutenzione.

In caso di più istanze di lettura, specifica un livello di priorità di promozione per ciascuna istanza del cluster. Quando l'istanza di scrittura ha esito negativo, Aurora compatibile con MySQL promuove la replica con la massima priorità come nuova istanza di scrittura.

Puoi anche promuovere una replica Aurora tra Regioni AWS come cluster di database autonomo. La replica tra Regioni si interrompe dopo avere avviato il processo di promozione. Il cluster promosso funziona come un cluster di database autonomo e gestisce sia le operazioni di lettura che quelle di scrittura.

Misura il ritardo di replica

Poiché tutte le istanze database Aurora in un singolo cluster di database condividono un volume di dati comune, il ritardo di replica è minimo. Tuttavia, in alcune situazioni, potresti riscontrare un ritardo leggermente maggiore delle istanze di lettura.

Nota: le repliche tra Regioni utilizzano la replica dei log binari. I tempi di modifica e applicazione e i ritardi nella comunicazione di rete tra le Regioni selezionate possono influire sulle repliche tra Regioni. Le repliche tra Regioni che utilizzano database Aurora MySQL hanno un ritardo tipico inferiore a 1 secondo.

Per misurare il ritardo di replica, utilizza le seguenti metriche di Amazon CloudWatch:

• La metrica AuroraReplicaLag misura il ritardo di replica tra il nodo di scrittura e di lettura in millisecondi nella stessa Regione.
• La metrica AuroraBinLogReplicaLag misura il ritardo di replica tra i cluster di database Aurora che utilizzano log binari.

Per ulteriori informazioni sulle metriche precedenti, consulta Metriche a livello di istanza per Amazon Aurora.

Migliora le prestazioni di replica

Esegui queste azioni:

• Per evitare carichi di lavoro elevati sulle istanze di lettura, è consigliabile rendere tutte le istanze di un cluster della stessa dimensione. Quando l'istanza di lettura è più piccola dell'istanza scrittura, il volume delle modifiche è troppo elevato per l'istanza di lettura.
  Nota: se il carico di lavoro sull’istanza di scrittura è elevato, potresti riscontrare un ritardo temporaneo nella replica in lettura. Il ritardo si riduce dopo che l'istanza di lettura corrisponde all'istanza di scrittura.
• Per evitare ritardi nella replica quando sono in corso transazioni di lunga durata, effettua le transazioni in batch più piccoli ed esegui spesso commit.

Per informazioni su come utilizzare la replica MySQL nativa basata su log binari per risolvere i problemi di ritardo di replica, consulta Problemi di replica relativi a Amazon Aurora MySQL.

Risolvi i problemi relativi al ritardo di replica elevato

Utilizza la metrica AuroraReplicaLag di CloudWatch per controllare se il ritardo di replica è elevato. Un ritardo di replica elevato può causare il riavvio di un'istanza di lettura. Per risolvere il problema, consulta Perché la mia replica di lettura di Amazon Aurora è rimasta indietro e si è riavviata?

Configura una replica basata su GTID

Aurora non utilizza la replica binlog nativa per leggere le istanze di replica replicando i dati. Non puoi utilizzare un identificatore di transazione globale (GTID) per replicare i dati tra istanze nello stesso cluster. Tuttavia, in alcune situazioni, puoi configurare una replica basata su GTID. Per ulteriori informazioni sull'utilizzo della replica basata su GTID in Aurora compatibile con MySQL, consulta Amazon Aurora for MySQL compatibility now supports global transaction identifiers (GTIDs) replication (Amazon Aurora compatibile con MySQL ora supporta la replica degli identificatori di transazione globali (GTID)).

Per impostazione predefinita, nelle versioni 3.04 e successive di Aurora compatibile con MySQL, la replica dei log binari multi-thread è attivata e il parametro replica_parallel_workers è impostato su 4. Poiché è attivata la replica dei log binari multi-thread, devi aumentare la resilienza del database in caso di arresto imprevisto. È consigliabile attivare la replica GTID sull'origine e autorizzare i GTID sulla replica.

Nota: puoi configurare la replica basata su GTID tra Amazon Relational Database Service (Amazon RDS) per MySQL e un cluster Aurora e tra cluster Aurora. L'origine deve essere un server principale esterno. Prima di iniziare il processo di replica, assicurati di attivare la registrazione binaria sull'origine.

Per ulteriori informazioni sui GTID, consulta GTID format and storage (Formato e archiviazione dei GTID) sul sito web MySQL.

Informazioni correlate

Replicating Amazon Aurora MySQL DB clusters across AWS Regions

Replication with Amazon Aurora