Come posso risolvere i problemi più comuni quando utilizzo le repliche di lettura in Aurora?

Soluzione

Promozione di una replica di lettura di Aurora

Per promuovere un'altra istanza di replica di lettura come istanza di scrittura, esegui un failover manuale.

Completa i seguenti passaggi:

1. Apri la console Amazon Relational Database Service (Amazon RDS).
2. Nel pannello di navigazione, scegli Database.
3. Scegli l'istanza di scrittura del cluster Aurora DB.
4. Seleziona Azioni, quindi seleziona Failover.

Se l’istanza di scrittura diventa indisponibile, Aurora esegue automaticamente il failover su un'istanza di replica di lettura. Un'istanza di scrittura potrebbe essere indisponibile per diversi motivi, ad esempio un conflitto di risorse e un'attività di manutenzione.

In caso di più lettori, è possibile specificare un livello di priorità di promozione a ciascuna istanza del cluster. Quando l'istanza di scrittura fallisce, Aurora promuove la replica con la massima priorità come nuovo scrittore.

È anche possibile 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 appena promosso funziona come un cluster di database indipendente e gestisce operazioni di lettura e scrittura.

Misurazione del ritardo di replica

Poiché tutte le istanze di database Aurora in un singolo cluster di database condividono un volume di dati comune, il ritardo di replica è minimo. Tuttavia, in alcuni scenari, potrebbe verificarsi un leggero aumento del ritardo dei lettori.

Nota: le repliche tra regioni utilizzano la replica logica. La modifica e l'applicazione delle tariffe e dei ritardi nelle comunicazioni di rete tra le regioni selezionate possono influire sulle repliche tra regioni. Le repliche tra regioni che utilizzano i database Aurora hanno un ritardo tipico inferiore a un secondo.

Il ritardo di replica può essere misurato utilizzando i seguenti parametri di Amazon CloudWatch:

• AuroraReplicaLag misura il ritardo di replica tra il nodo scrittore e lettore in millisecondi nella stessa regione.
• AuroraBinlogReplicaLag misura il ritardo di replica tra i cluster di database Aurora che utilizzano log binari.

Miglioramento delle prestazioni di replica

Per migliorare il ritardo di replica, adotta le seguenti azioni:

• Se l'istanza di lettura è più piccola dell'istanza di scrittura, il volume delle modifiche potrebbe essere eccessivo perché il lettore possa recuperare il ritardo. Per evitare carichi di lavoro elevati sulle istanze di lettura, è consigliabile rendere tutte le istanze di un cluster della stessa dimensione.
  Nota: se il carico di lavoro sull’istanza di scrittura è elevato, è possibile che ci sia un ritardo temporaneo nella replica di lettura. Il ritardo si riduce dopo che l'istanza di lettura raggiunge l'istanza di scrittura.
• Se sono in corso transazioni di lunga durata, potrebbe verificarsi un ritardo di replica nei lettori. Per evitare ritardi nella replica, esegui le transazioni in batch più piccoli ed esegui i commit più frequentemente.

Per informazioni su come utilizzare la replica MySQL nativa basata su binlog per risolvere i problemi relativi al ritardo di replica, consulta Overview of backing up and restoring an Aurora DB cluster.

Risoluzione dei problemi relativi all'elevato ritardo di replica

Puoi verificare l'elevato ritardo di replica nella metrica AuroraReplicaLag di CloudWatch. Un ritardo di replica elevato può causare il riavvio di un'istanza di lettura. Per evitare un frequente riavvio dell'istanza di lettura a causa di un ritardo di replica elevato, consulta Perché la mia replica di lettura di Amazon Aurora è rimasta indietro e si è riavviata?

Configurazione della replica basata su GTID

Aurora non usa la replica binlog nativa per replicare i dati per leggere le istanze di replica. Non puoi utilizzare gli identificatori di transazione globali (GTID) per replicare i dati tra istanze nello stesso cluster. Tuttavia, è possibile configurare la replica basata su GTID in determinati scenari. Per ulteriori informazioni su come utilizzare la replica basata su GTID in Aurora compatibile con MySQL, consulta Amazon Aurora for MySQL compatibility now supports global transaction identifiers (GTIDs) replication.

Nota: puoi configurare una replica basata su GTID tra Amazon RDS MySQL e un cluster Aurora e tra cluster Aurora. L’origine deve essere un master esterno. Assicurati di abilitare binlog sull’origine prima di avviare il processo di replica.

Per ulteriori informazioni su GTID, consulta GTID format and storage sul sito Web MySQL.

Informazioni correlate

Replicating Amazon Aurora MySQL DB clusters across AWS Regions

Replication with Amazon Aurora