Replica con Amazon Aurora MySQL - Amazon Aurora
Repliche di AuroraOpzioni di replicaPrestazioni di replicaZero-downtime restart (ZDR)Configurazione dei filtri di replicaMonitoraggio della replica .

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.

Argomenti

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.

Importante

Le repliche Aurora per Aurora MySQL utilizzano sempre il livello di isolamento della transazione predefinita REPEATABLE READ per operazioni nelle tabelle InnoDB. Puoi utilizzare il comando SET TRANSACTION ISOLATION LEVEL per modificare il livello di transazione solo per l'istanza primaria di un cluster database Aurora MySQL. Questa restrizione evita blocchi a livello di utente nelle repliche Aurora e permette alle repliche Aurora di dimensionarsi per supportare migliaia di connessioni utente attive mantenendo il ritardo di replica al minimo.

Nota

Le istruzioni DDL che vengono eseguite sull'istanza primaria possono interrompere le connessioni di database sulle repliche Aurora associate. Se una connessione di replica Aurora sta utilizzando attivamente un oggetto di database, come una tabella e quell'oggetto è modificato nell'istanza primaria utilizzando un'istruzione DDL, la connessione di replica Aurora viene interrotta.

Nota

La regione Cina (Ningxia) non supporta le repliche di lettura fra regioni.

Opzioni di replica per Amazon Aurora MySQL

Puoi impostare repliche tra qualsiasi delle seguenti opzioni:

Nota

Il riavvio dell'istanza primaria di un cluster database Amazon Aurora riavvia automaticamente anche le repliche Aurora per il cluster database, per ristabilire un punto di ingresso che garantisce coerenza di lettura/scrittura nel cluster database.

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.

Zero-downtime restart (ZDR) per Amazon Aurora MySQL

La funzione ZDR (zero-downtime restart) può conservare alcune o tutte le connessioni attive alle istanze DB durante alcuni tipi di riavvio. ZDR si applica ai riavvii che Aurora esegue automaticamente per risolvere condizioni di errore, ad esempio quando una replica inizia a rimanere troppo indietro rispetto all'origine.

Importante

Il meccanismo ZDR funziona in modo ottimale. Le versioni Aurora MySQL, le classi di istanza, le condizioni di errore, le operazioni SQL compatibili e altri fattori che determinano dove si applica ZDR sono soggetti a modifica in qualsiasi momento.

ZDR per Aurora MySQL 2.x richiede la versione 2.10 e successive. ZDR è disponibile in tutte le versioni minori di Aurora MySQL 3.x. In Aurora MySQL versioni 2 e 3, il meccanismo ZDR è attivato per impostazione predefinita e Aurora non utilizza il parametro aurora_enable_zdr.

Aurora riporta sulla pagina Eventi le attività relative al riavvio con tempi di inattività pari a zero. Aurora registra un evento quando prova un riavvio utilizzando il meccanismo ZDR. Questo evento indica perché Aurora esegue il riavvio. Quindi Aurora registra un altro evento al termine del riavvio. Questo evento finale esegue un report su quanto tempo è durato il processo e quante connessioni sono state conservate o interrotte durante il riavvio. È possibile consultare il registro degli errori del database per visualizzare ulteriori dettagli su ciò che è successo durante il riavvio.

Sebbene le connessioni rimangano intatte a seguito di un'operazione ZDR riuscita, alcune variabili e funzionalità vengono reinizializzate. I seguenti tipi di informazioni non vengono conservati tramite un riavvio causato da zero-downtime restart:

  • Variabili globali. Aurora ripristina le variabili di sessione, ma non ripristina le variabili globali dopo il riavvio.

  • Variabili di stato. In particolare, il valore di attività riportato dallo stato del motore viene ripristinato.

  • LAST_INSERT_ID.

  • Stato auto_increment in memoria per le tabelle. Lo stato di incremento automatico in memoria viene reinizializzato. Per ulteriori informazioni sui valori di incremento automatico, consulta il Manuale di riferimento di MySQL.

  • Informazioni diagnostiche dalle tabelle INFORMATION_SCHEMA e PERFORMANCE_SCHEMA. Queste informazioni diagnostiche vengono visualizzate anche nell'output di comandi come SHOW PROFILE e SHOW PROFILES.

La tabella seguente mostra le versioni, i ruoli delle istanze e altre circostanze che determinano se Aurora può utilizzare il meccanismo ZDR per il riavvio delle istanze DB nel cluster.

Versione Aurora MySQL ZDR si applica allo scrittore? ZDR si applica ai lettori? ZDR è sempre abilitato? Note

2.x, inferiore a 2.10.0

No

No

N/D

ZDR non è disponibile per queste versioni.

2.10.0—2.11.0

Sì

Sì

Sì

Aurora ripristina le transazioni in corso sulle connessioni attive. La tua domanda deve riprovare le transazioni.

Aurora annulla tutte le connessioni che utilizzano TLS/SSL, tabelle temporanee, blocchi di tabella o blocchi utente.

2.11.1 e versioni successive

Sì

Sì

Sì

Aurora ripristina le transazioni in corso sulle connessioni attive. La tua domanda deve riprovare le transazioni.

Aurora annulla tutte le connessioni che utilizzano tabelle temporanee, blocchi tabella o blocchi utente.

3,01—3,03

Sì

Sì

Sì

Aurora ripristina le transazioni in corso sulle connessioni attive. La tua domanda deve riprovare le transazioni.

Aurora annulla tutte le connessioni che utilizzano TLS/SSL, tabelle temporanee, blocchi di tabella o blocchi utente.

3.04 e versioni successive

Sì

Sì

Sì

Aurora ripristina le transazioni in corso sulle connessioni attive. La tua domanda deve riprovare le transazioni.

Aurora annulla tutte le connessioni che utilizzano tabelle temporanee, blocchi tabella o blocchi utente.

Configurazione dei filtri di replica con Aurora MySQL

Puoi utilizzare i filtri di replica per specificare quali database e tabelle vengono replicati con una replica di lettura. I filtri di replica possono includere database e tabelle nella replica o escluderli dalla replica.

Di seguito sono riportati alcuni casi d'uso per i filtri di replica:

  • Per ridurre le dimensioni di una replica di lettura. Con il filtro di replica è possibile escludere i database e le tabelle che non sono necessari nella replica di lettura.

  • Per escludere database e tabelle dalle repliche di lettura per motivi di sicurezza.

  • Per replicare database e tabelle diversi per casi d'uso specifici in repliche di lettura diverse. Ad esempio, è possibile utilizzare repliche di lettura specifiche per l'analisi o la condivisione.

  • Per un cluster di database che dispone di repliche di lettura in più Regioni AWS, per replicare database o tabelle diversi in differenti Regioni AWS.

  • Per specificare quali database e tabelle vengono replicati con un cluster di database Aurora MySQL configurato come replica in una topologia di replica in entrata. Per ulteriori informazioni su questa configurazione, consulta Replica tra Aurora e MySQL o tra Aurora e un altro cluster di database Aurora (replica dei log binari).

Impostazione dei parametri dei filtri di replica per Aurora MySQL

Per configurare i filtri di replica, imposta i seguenti parametri:

  • binlog-do-db – Replica le modifiche ai log binari specificati. Quando impostate questo parametro per un cluster di origine binlog, vengono replicati solo i log binari specificati nel parametro.

  • binlog-ignore-db – Non replicare le modifiche ai log binari specificati. Quando il binlog-do-db parametro è impostato per un cluster di origine binlog, questo parametro non viene valutato.

  • replicate-do-db – Replicare le modifiche ai database specificati. Quando si imposta questo parametro per un cluster di replica binlog, vengono replicati solo i database specificati nel parametro.

  • replicate-ignore-db – Non replicare le modifiche ai database specificati. Quando il replicate-do-db parametro è impostato per un cluster di replica binlog, questo parametro non viene valutato.

  • replicate-do-table – Replicare le modifiche alle tabelle specificate. Quando si imposta questo parametro per una replica di lettura, vengono replicate solo le tabelle specificate nel parametro. Inoltre, quando il replicate-ignore-db parametro replicate-do-db or è impostato, assicuratevi di includere il database che include le tabelle specificate nella replica con il cluster di replica binlog.

  • replicate-ignore-table – Non replicare le modifiche alle tabelle specificate. Quando il replicate-do-table parametro è impostato per un cluster di replica binlog, questo parametro non viene valutato.

  • replicate-wild-do-table – Replicare le tabelle in base ai modelli di nome del database e della tabella specificati. I caratteri jolly % e _ sono supportati. Quando il replicate-ignore-db parametro replicate-do-db or è impostato, assicuratevi di includere il database che include le tabelle specificate nella replica con il cluster di replica binlog.

  • replicate-wild-ignore-table – Non replicare le tabelle in base ai modelli di nomi di database e tabella specificati. I caratteri jolly % e _ sono supportati. Quando il replicate-wild-do-table parametro replicate-do-table or è impostato per un cluster di replica binlog, questo parametro non viene valutato.

I parametri vengono valutati nell'ordine in cui sono elencati. Per ulteriori informazioni sul funzionamento di questi parametri, consulta la documentazione di MySQL:

Per impostazione predefinita, ognuno di questi parametri ha un valore vuoto. In ogni cluster binlog, è possibile utilizzare questi parametri per impostare, modificare ed eliminare i filtri di replica. Quando viene impostato uno di questi parametri, è necessario separare ogni filtro dagli altri con una virgola.

È possibile utilizzare i caratteri jolly % e _ nei parametri replicate-wild-do-table e replicate-wild-ignore-table. Il carattere jolly % corrisponde a un numero qualsiasi di caratteri e il carattere jolly _ corrisponde a un solo carattere.

Il formato di registrazione binaria dell'istanza database di origine è importante per la replica perché determina il record delle modifiche ai dati. L'impostazione del parametro binlog_format determina se la replica è basata su righe o basata su dichiarazione. Per ulteriori informazioni, consulta Configurazione del log binario di Aurora MySQL.

Nota

Tutte le istruzioni DDL (Data Definition Language) vengono replicate come istruzioni, indipendentemente dall'impostazione binlog_format dell'istanza database di origine.

Limitazioni dei filtri di replica per Aurora MySQL

Le seguenti limitazioni si applicano ai filtri di replica per Aurora MySQL:

  • I filtri di replica sono supportati solo per Aurora MySQL versione 3.

  • Ogni parametro di filtro della replica ha un limite di 2.000 caratteri.

  • Le virgole non sono supportate nei filtri di replica.

  • Il filtro delle repliche non supporta le transazioni XA.

    Per ulteriori informazioni, consulta Restrizioni sulle transazioni XA nella documentazione di MySQL.

Esempi di filtri di replica per Aurora MySQL

Per configurare il filtro per una replica di lettura, modifica i parametri di filtro replica nel gruppo di parametri del cluster di database associato alla replica di lettura.

Nota

Non è consentito modificare un gruppo di parametri del cluster di database predefinito. Se la replica di lettura usa un gruppo di parametri predefinito, creare un nuovo gruppo di parametri e associarlo alla replica di lettura. Per ulteriori informazioni sui gruppi di parametri del cluster di database, consulta Utilizzo di gruppi di parametri.

È possibile impostare parametri in un gruppo di parametri del cluster di database utilizzando la AWS Management Console, la AWS CLI o l'API RDS. Per informazioni sull'estensione dei parametri consulta Modifica di parametri in un gruppo di parametri del database. Quando si impostano parametri in un gruppo di parametri del cluster di database, tutti i cluster di database associati al gruppo di parametri utilizzano le impostazioni dei parametri. Se imposti i parametri di filtro replica in un gruppo di parametri del cluster di database, assicurati che il gruppo di parametri sia associato solo alle repliche di lettura. Lasciare vuoti i parametri di filtro di replica per le istanze database di origine.

Negli esempi seguenti vengono impostati i parametri utilizzando AWS CLI. In questi esempi si imposta ApplyMethod su immediate in modo che le modifiche ai parametri avvengano immediatamente dopo il completamento del comando della CLI. Se si desidera applicare una modifica in sospeso dopo il riavvio della replica di lettura, impostare ApplyMethod su pending-reboot.

Gli esempi seguenti impostano i filtri di replica:

Esempio Inclusione dei database nella replica

Nell'esempio seguente sono inclusi i database mydb1 e mydb2 nella replica.

PerLinux, omacOS: Unix

aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name myparametergroup \
  --parameters "ParameterName=replicate-do-db,ParameterValue='mydb1,mydb2',ApplyMethod=immediate"

Per Windows:

aws rds modify-db-cluster-parameter-group ^
  --db-cluster-parameter-group-name myparametergroup ^
  --parameters "ParameterName=replicate-do-db,ParameterValue='mydb1,mydb2',ApplyMethod=immediate"
Esempio Inclusione delle tabelle nella replica

Nell'esempio seguente sono incluse le tabelle table1 e table2 nel database mydb1 nella replica.

Per LinuxmacOS, oUnix:

aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name myparametergroup \
  --parameters "ParameterName=replicate-do-table,ParameterValue='mydb1.table1,mydb1.table2',ApplyMethod=immediate"

Per Windows:

aws rds modify-db-cluster-parameter-group ^
  --db-cluster-parameter-group-name myparametergroup ^
  --parameters "ParameterName=replicate-do-table,ParameterValue='mydb1.table1,mydb1.table2',ApplyMethod=immediate"
Esempio Inclusione di tabelle nella replica utilizzando caratteri jolly

Nell'esempio seguente sono incluse tabelle con nomi che iniziano con order e return nel database mydb nella replica.

Per LinuxmacOS, oUnix:

aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name myparametergroup \
  --parameters "ParameterName=replicate-wild-do-table,ParameterValue='mydb.order%,mydb.return%',ApplyMethod=immediate"

Per Windows:

aws rds modify-db-cluster-parameter-group ^
  --db-cluster-parameter-group-name myparametergroup ^
  --parameters "ParameterName=replicate-wild-do-table,ParameterValue='mydb.order%,mydb.return%',ApplyMethod=immediate"
Esempio Esclusione di database dalla replica

Nell'esempio seguente vengono esclusi i database mydb5 e mydb6 dalla replica.

Per LinuxmacOS, oUnix:

aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name myparametergroup \
  --parameters "ParameterName=replicate-ignore-db,ParameterValue='mydb5,mydb6',ApplyMethod=immediate"

Per Windows:

aws rds modify-db-cluster-parameter-group ^
  --db-cluster-parameter-group-name myparametergroup ^
  --parameters "ParameterName=replicate-ignore-db,ParameterValue='mydb5,mydb6,ApplyMethod=immediate"
Esempio Esclusione di tabelle dalla replica

Nell'esempio seguente vengono escluse dalla replica le tabelle table1 nel database mydb5 e table2 nel database mydb6.

Per LinuxmacOS, oUnix:

aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name myparametergroup \
  --parameters "ParameterName=replicate-ignore-table,ParameterValue='mydb5.table1,mydb6.table2',ApplyMethod=immediate"

Per Windows:

aws rds modify-db-cluster-parameter-group ^
  --db-cluster-parameter-group-name myparametergroup ^
  --parameters "ParameterName=replicate-ignore-table,ParameterValue='mydb5.table1,mydb6.table2',ApplyMethod=immediate"
Esempio Esclusione di tabelle dalla replica utilizzando caratteri jolly

Nell'esempio seguente vengono escluse le tabelle con nomi che iniziano con order e return nel database mydb7 dalla replica.

Per LinuxmacOS, oUnix:

aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name myparametergroup \
  --parameters "ParameterName=replicate-wild-ignore-table,ParameterValue='mydb7.order%,mydb7.return%',ApplyMethod=immediate"

Per Windows:

aws rds modify-db-cluster-parameter-group ^
  --db-cluster-parameter-group-name myparametergroup ^
  --parameters "ParameterName=replicate-wild-ignore-table,ParameterValue='mydb7.order%,mydb7.return%',ApplyMethod=immediate"

Visualizzazione dei filtri di replica per una replica di lettura

È possibile visualizzare i filtri di replica per una replica di lettura nei seguenti modi:

  • Controllare le impostazioni dei parametri di filtro replica nel gruppo di parametri associato alla replica di lettura.

    Per istruzioni, consulta Visualizzazione dei valori dei parametri per un gruppo di parametri del database.

  • In un client MySQL, connettersi alla replica di lettura ed eseguire l'istruzione SHOW REPLICA STATUS.

    Nell'output, i campi seguenti mostrano i filtri di replica per la replica di lettura:

    • Binlog_Do_DB

    • Binlog_Ignore_DB

    • Replicate_Do_DB

    • Replicate_Ignore_DB

    • Replicate_Do_Table

    • Replicate_Ignore_Table

    • Replicate_Wild_Do_Table

    • Replicate_Wild_Ignore_Table

    Per ulteriori informazioni su questi campi, consulta Verifica dello stato della replica nella documentazione di MariaDB.

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