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 di 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 di log binari multithread è supportata in Aurora MySQL versione 3 e in Aurora MySQL versione 2.12.1 e successive. Affinché una replica multithread elabori in modo efficiente gli eventi binlog in parallelo, è necessario configurare l'origine per la replica multithread del log binario e l'origine deve utilizzare una versione che includa le informazioni sul parallelismo nei suoi file di log binari.

Quando un'istanza DB Aurora MySQL è configurata per utilizzare la replica binaria dei log, per impostazione predefinita l'istanza di replica utilizza la replica a thread singolo per le versioni di Aurora MySQL precedenti alla 3.04. Per abilitare la replica multithread, si aggiorna il parametro a un valore maggiore rispetto al gruppo di parametri personalizzato. replica_parallel_workers 1

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

Per aumentare la resilienza del database in caso di arresti imprevisti, si consiglia di abilitare la replica GTID sull'origine e di GTIDs consentirla sulla replica. Per consentire la replica GTID, imposta gtid_mode su sia sull'origine che sulla replica. ON_PERMISSIVE Per ulteriori informazioni sulla replica basata su GTID, consultare Utilizzo della replica GTID basata.

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 a fondo tutte le modifiche a questi parametri di configurazione prima di applicare nuove impostazioni dei parametri a un'istanza di produzione:

Lo schema e le caratteristiche del carico di lavoro sono fattori che influiscono sulla replica in parallelo. I fattori più comuni sono i seguenti.

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

Ottimizzazione della replica binlog

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 avevi regolato il parametro di configurazione aurora_binlog_replication_max_yield_seconds su un valore diverso da zero nelle versioni precedenti di Aurora MySQL, reimpostalo su zero per le versioni attualmente disponibili.

Le variabili aurora_binlog_io_cache_reads di stato aurora_binlog_io_cache_read_requests consentono di monitorare la frequenza con cui i dati vengono letti dalla cache I/O binlog.

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.