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

Ottimizzazione della replica dei log binari per Aurora MySQL

Di seguito, è possibile imparare a ottimizzare le prestazioni di replica dei log binari e risolvere i problemi correlati in Aurora MySQL.

Replica dei log binari multithread

Con la replica del log binario multithread, un thread SQL legge gli eventi dal log di inoltro e li mette in coda per l'applicazione dei thread SQL worker. I thread di lavoro SQL sono gestiti dal thread coordinatore. Gli eventi di log binari vengono applicati in parallelo quando possibile. Il livello di parallelismo dipende da fattori quali versione, parametri, progettazione dello schema e caratteristiche del carico di lavoro.

La replica dei log binari multithread è supportata in Aurora MySQL versione 3 e Aurora MySQL 2.12.1 e versioni successive. Affinché una replica multithread elabori in modo efficiente gli eventi dei log binari in parallelo, è necessario configurare l’origine per la replica dei log binari multithread, la quale dovrà utilizzare una versione che includa le informazioni sul parallelismo nei file di log binari.

Quando un’istanza database Aurora MySQL è configurata per l’utilizzo della replica dei log binari, per impostazione predefinita l’istanza di replica utilizza la replica a thread singolo per le versioni precedenti alla 3.04 di Aurora MySQL. Per abilitare la replica multithread, si aggiorna il parametro replica_parallel_workers a un valore maggiore di 1 nel gruppo di parametri personalizzati.

Per Aurora MySQL 3.04 e versioni successive, la replica è multithread per impostazione predefinita, con replica_parallel_workers impostato su 4. È possibile modificare questo parametro nel gruppo di parametri personalizzato.

Per aumentare la resilienza del database in caso di arresti imprevisti, è consigliabile abilitare la replica GTID sull’origine e consentire i GTID sulla replica. Per consentire la replica GTID, si imposta gtid_mode su ON_PERMISSIVE sia sull’origine sia sulla replica. Per ulteriori informazioni sulla replica basata su GTID, consultare Utilizzo della replica basata su GTID.

Le opzioni di configurazione seguenti consentono di ottimizzare la replica multithread. Per informazioni sull'utilizzo, consulta Opzioni e variabili di replica e registrazione binaria nel Manuale di riferimento MySQL. Per ulteriori informazioni sulla replica multithread, consulta il blog MySQL Improving the Parallel Applier with Writeset-based Dependency Tracking.

I valori ottimali dei parametri dipendono da diversi fattori. Ad esempio, le prestazioni per la replica dei log binari sono influenzate dalle caratteristiche del carico di lavoro del database e dalla classe di istanza database su cui è in esecuzione la replica. Pertanto, si consiglia di testare con attenzione tutte le modifiche apportate a questi parametri di configurazione prima di applicare nuove impostazioni di parametro a un’istanza di produzione:

Le caratteristiche dello schema e del carico di lavoro sono fattori che influiscono sulla replica in parallelo. Di seguito sono riportati i fattori più comuni.

In Aurora MySQL 3.06 e versioni successive, è possibile migliorare le prestazioni delle repliche di log binari durante la replica delle transazioni per tabelle di grandi dimensioni con più di un indice secondario. Questa funzionalità introduce un pool di thread per applicare le modifiche dell’indice secondario in parallelo su una replica di log binari. La funzionalità è controllata dal parametro del cluster di database aurora_binlog_replication_sec_index_parallel_workers, che controlla il numero totale di thread paralleli disponibili per applicare le modifiche dell’indice secondario. Per impostazione predefinita, il parametro è impostato su 0 (disabilitato). L’abilitazione di questa funzionalità non richiede il riavvio dell’istanza. Per abilitare questa funzionalità, arrestare la replica in corso, impostare il numero desiderato di thread di lavoro paralleli e quindi riavviare la replica.

Ottimizzazione della replica dei log binari

In Aurora MySQL 2.10 e versioni successive, Aurora applica automaticamente un'ottimizzazione nota come cache I/O binlog alla replica del log binario. Inserendo nella cache gli eventi binlog più recenti, questa ottimizzazione è progettata per migliorare le prestazioni del thread di dump di binlog limitando al contempo l'impatto sulle transazioni in primo piano sull'istanza di origine binlog.

Non è necessario regolare alcun parametro di configurazione per attivare questa ottimizzazione. In particolare, se il parametro di configurazione aurora_binlog_replication_max_yield_seconds è stato impostato su un valore diverso da zero nelle versioni precedenti di Aurora MySQL, impostarlo su zero per le versioni attualmente disponibili.

Queste variabili di stato aurora_binlog_io_cache_reads e aurora_binlog_io_cache_read_requests consentono di monitorare la frequenza con cui i dati vengono letti dalla cache I/O dei log binari.

La seguente query SQL calcola la percentuale di richieste di lettura binlog che sfruttano le informazioni memorizzate nella cache. In questo caso, più il rapporto è vicino a 100, migliore è.

mysql> SELECT
  (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS
    WHERE VARIABLE_NAME='aurora_binlog_io_cache_reads')
  / (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS
    WHERE VARIABLE_NAME='aurora_binlog_io_cache_read_requests')
  * 100
  as binlog_io_cache_hit_ratio;
+---------------------------+
| binlog_io_cache_hit_ratio |
+---------------------------+
|         99.99847949080622 |
+---------------------------+

La funzione di cache I/O binlog include anche nuovi parametri relativi ai thread di dump di binlog. I thread di dump sono i thread creati quando le nuove repliche di binlog sono collegate all'istanza fonte binlog.

I parametri del thread di dump vengono stampati nel log del database ogni 60 secondi con il prefisso [Dump thread metrics]. I parametri includono informazioni per ogni replica binlog, ad esempio Secondary_id, Secondary_uuid, il nome del file binlog e la posizione in cui ogni replica sta leggendo. I parametri includono anche Bytes_behind_primary che rappresenta la distanza in byte tra l'origine della replica e la replica. Questo parametro misura il ritardo del thread I/O di replica. Tale cifra è diversa dal ritardo del thread dell'applicatore SQL della replica, rappresentato dal parametro seconds_behind_master sulla replica binlog. È possibile determinare se le repliche di binlog stiano recuperando l'origine o rimangano indietro controllando se la distanza diminuisce o aumenta.

Log di inoltro in memoria

In Aurora MySQL versione 3.10 e versioni successive, Aurora introduce un’ottimizzazione nota come log di inoltro in memoria per migliorare il throughput della replica. Questa ottimizzazione migliora le prestazioni di I/O del log di inoltro memorizzando nella cache tutto il contenuto del log di inoltro intermedio presente in memoria. Di conseguenza, diminuisce la latenza di commit riducendo al minimo le operazioni di I/O di archiviazione, poiché il contenuto del log di inoltro rimane facilmente accessibile in memoria.

Per impostazione predefinita, la funzionalità di log di inoltro in memoria è abilitata automaticamente per gli scenari di replica gestiti da Aurora (incluse implementazioni blu/verdi, replica Aurora-Aurora e repliche tra Regioni) quando la replica soddisfa una di queste configurazioni:

La funzionalità di log di inoltro in memoria è supportata su classi di istanza più grandi di t3.large, ma non è disponibile sulle istanze Aurora Serverless. Il buffer circolare del log di inoltro ha una dimensione fissa di 128 MB. Per monitorare il consumo di memoria di questa funzionalità, è possibile eseguire la seguente query:

SELECT event_name, current_alloc FROM sys.memory_global_by_current_bytes WHERE event_name = 'memory/sql/relaylog_io_cache';

La funzionalità di log di inoltro in memoria è controllata dal parametro aurora_in_memory_relaylog, che può essere impostato a livello di istanza o di cluster di database. È possibile abilitare o disabilitare questa funzionalità in modo dinamico senza riavviare l’istanza:

Esempio:

CALL mysql.rds_stop_replication;
set aurora_in_memory_relaylog to ON to enable or OFF to disable in cluster parameter group
CALL mysql.rds_start_replication;

Anche quando aurora_in_memory_relaylog è impostato su ON, la funzionalità di log di inoltro in memoria potrebbe comunque essere disabilitata in determinate condizioni. Per verificare lo stato corrente della funzionalità, è possibile utilizzare il seguente comando:

SHOW GLOBAL STATUS LIKE 'Aurora_in_memory_relaylog_status';

Se la funzionalità viene disabilitata in modo imprevisto, è possibile identificarne il motivo eseguendo il seguente comando:

SHOW GLOBAL STATUS LIKE 'Aurora_in_memory_relaylog_disabled_reason';

Questo comando restituisce un messaggio che spiega perché la funzionalità è attualmente disabilitata.