Come posso risolvere problematiche comuni quando si utilizzano le repliche di lettura in Amazon Aurora?

Breve descrizione

Amazon Aurora MySQL supporta Read Leggi Repliche che condividono un volume sottostante comune con un'istanza DB di writer nella stessa regione AWS. Se modifichi l'istanza database di writer, gli aggiornamenti sono visibili alle istanze di replica nel cluster di database. Puoi anche creare repliche di lettura MySQLinterregionali. Queste sono implementate utilizzando il motore di replica MySQL basato su binlog.

Si consiglia di utilizzare le repliche Aurora durante il ridimensionamento delle operazioni di lettura. A tale scopo, è possibile ridurre il carico di lavoro di lettura dello scrittore. Quindi, aumenta la disponibilità per gestire eventi che rallentano o bloccano la scalabilità.

Risoluzione

Come posso promuovere una replica di lettura di Aurora?

Failover manuale - esegui un failover manuale per promuovere un'altra istanza di replica di lettura come istanza di scrittura seguendo questi passaggi:

1. Accedi alla console Amazon Relational Database Service (Amazon RDS).
2. Dal pannello di navigazione, seleziona Database.
3. Scegli l'istanza di scrittura per il tuo cluster Aurora DB.
4. Seleziona Azioni, quindi seleziona Failover.

Failover automatico: Aurora esegue automaticamente il failover su un'istanza di replica di lettura se l'istanza di scrittura non è più disponibile. Ciò può accadere per vari motivi, tra cui contese di risorse e attività di manutenzione. Se hai più lettori, puoi assegnare un livello di priorità di promozione a ciascuna istanza del tuo cluster. Quando l'istanza di scrittura fallisce, Aurora promuove la replica con la massima priorità come nuova scrittrice.

Puoi anche promuovere una replica Aurora interregionale come cluster DB autonomo. La replica interregionale si interrompe dopo aver avviato il processo di promozione. Il cluster appena promosso funziona come un cluster DB indipendente e gestisce operazioni di lettura e scrittura.

Come si misura il ritardo di replica?

Poiché tutte le istanze Aurora DB in un singolo cluster di database condividono un volume di dati comune, il ritardo di replica è minimo. Di solito, i tempi di latenza sono nell'ordine di 10 di millisecondo. Tuttavia, potresti osservare un leggero aumento del ritardo nei lettori in alcune circostanze specifiche.

**Nota:**Le repliche interregionali utilizzano la replica logica e sono influenzate dalla frequenza di modifica/applicazione e dai ritardi nella comunicazione di rete tra le regioni specifiche selezionate. Le repliche interregionali che utilizzano i database Aurora hanno un ritardo tipico inferiore a un secondo.

Puoi misurare il ritardo di replica utilizzando i seguenti parametri di Amazon CloudWatch:

• Usa AuroraReplicaLag per misurare il ritardo di replica tra il nodo writer e lettore in millisecondi (stessa regione).
• Usa AuroraBinLogReplicalAg per misurare il ritardo di replica tra i cluster Aurora DB utilizzando log binari.

Come posso aumentare le prestazioni di replica?

Segui questi consigli per migliorare il ritardo di replica:

• Se l'istanza reader è più piccola dell'istanza writer, il volume delle modifiche potrebbe essere eccessivo perché il lettore possa recuperare il ritardo. È consigliabile che tutte le istanze in un cluster abbiano le stesse dimensioni per evitare un sovraccarico di lavoro sulle istanze di lettura.
• Se il masterizzatore presenta un carico di lavoro elevato, è possibile che ci sia un ritardo temporaneo nella replica della lettura. Il ritardo si riduce dopo che l'istanza del lettore raggiunge l'istanza di scrittura.
• Se sono in corso transazioni a lungo termine, potrebbe verificarsi un ritardo di replica sui lettori. Per evitare ritardi nella replica, esegui le transazioni in batch più piccoli ed esegui i commit più frequentemente.

Per ulteriori informazioni sulla risoluzione dei problemi di ritardo di replica elevati utilizzando la replica MySQL nativa basata su binlog, vedi Panoramica del backup e del ripristino di un cluster Aurora DB.

Posso usare un identificatore di transazione globale (GTID)?

Un identificatore di transazione globale è una stringa univoca associata a una transazione nel relativo Commit. Un GTID è unico per tutti i server e le modifiche vengono applicate all'obiettivo, in base al valore GTID. Per ulteriori informazioni, consulta la documentazione di MySQL per i concetti relativi a GTID.

Aurora non usa la replica binlog nativa per replicare i dati per leggere le istanze di replica. Non è possibile utilizzare GTID per replicare i dati tra istanze nello stesso cluster. Tuttavia, è possibile configurare la replica basata su GTID in determinati scenari. Per ulteriori informazioni sull'utilizzo della replica basata su GTID in Aurora MySQL, consulta il blog AWS su GTID.

**Nota:**Puoi configurare una replica basata su GTID tra un cluster Amazon RDS MySQL e un cluster Aurora e tra cluster Aurora (se l'origine è un master esterno). Assicurati di abilitare binlog sulla sorgente prima di avviare il processo di replica.

---

Informazioni correlate

Replica con Amazon Aurora

Cos'è Amazon Aurora?