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 My SQL

Di seguito, puoi imparare come ottimizzare le prestazioni della replica dei log binari e risolvere i problemi correlati in Aurora My. SQL

Replica di log binari multithread

Con la replica di log binari multithread, un SQL thread legge gli eventi dal relay log e li mette in coda per l'applicazione dei thread di lavoro. SQL I thread di lavoro sono gestiti da SQL un thread coordinatore. Gli eventi di log binari vengono applicati in parallelo quando possibile.

La replica di log binari multithread è supportata in Aurora My versione 3 e in Aurora My SQL versione 2.12.1 e successive. SQL

Quando un'istanza Aurora My SQL DB è 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 My precedenti alla 3.04. SQL Per abilitare la replica multithread, si aggiorna il parametro replica_parallel_workers a un valore maggiore di zero nel gruppo di parametri personalizzati.

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

Le opzioni di configurazione seguenti consentono di ottimizzare la replica multithread. Per informazioni sull'utilizzo, vedete Opzioni e variabili di replica e registrazione binaria nel My SQL Reference Manual.

La configurazione ottimale dipende 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:

In Aurora My SQL versione 3.06 e successive, è possibile migliorare le prestazioni delle 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 My SQL 2.10 e versioni successive, Aurora applica automaticamente un'ottimizzazione nota come cache I/O binlog alla replica dei log binari. 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 SQL My, 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 SQL query 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. Questa cifra è diversa dal ritardo del thread dell'SQLapplicatore di replica, che è rappresentato dalla metrica sulla seconds_behind_master replica binlog. È possibile determinare se le repliche di binlog stiano recuperando l'origine o rimangano indietro controllando se la distanza diminuisce o aumenta.