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.

È inoltre possibile utilizzare questo parametro come variabile globale, dove n è il numero di thread di lavoro paralleli:

SET global aurora_binlog_replication_sec_index_parallel_workers=n;

Ottimizzazione della replica binlog (Aurora My 2.10 e versioni successive) SQL

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 regolate il parametro di configurazione su un valore diverso aurora_binlog_replication_max_yield_seconds da zero nelle versioni precedenti di Aurora SQL My, reimpostatelo a zero per SQL Aurora My 2.10 e versioni successive.

Le variabili di stato aurora_binlog_io_cache_read_requests sono disponibili in Aurora My SQL 2.10 aurora_binlog_io_cache_reads e versioni successive. Queste variabili di stato aiutano a 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.

Ottimizzazione della replica binlog (Aurora My SQL dalla versione 2 alla 2.09)

Per ottimizzare la replica dei log binari per Aurora SQL My, si modificano i seguenti parametri di ottimizzazione a livello di cluster. Questi parametri consentono di specificare il giusto equilibrio tra latenza nell'istanza di origine dei log binari e ritardo di replica.

Panoramica delle ottimizzazioni del buffer di lettura di grandi dimensioni e di max-yield

È possibile che si verifichi una riduzione delle prestazioni di replica dei log binari quando il thread di dump dei log binari accede al volume del cluster Aurora mentre il cluster elabora un numero elevato di transazioni. È possibile utilizzare i parametri aurora_binlog_use_large_read_buffer, aurora_binlog_replication_max_yield_seconds e aurora_binlog_read_buffer_size per ridurre al minimo questo tipo di conflitto.

Supponi di avere una situazione in cui aurora_binlog_replication_max_yield_seconds è impostato su maggiore di 0 e il file binlog corrente del thread di dump è attivo. In questo caso, il thread di dump dei log binari attende fino a un numero specificato di secondi affinché il file binlog corrente venga riempito dalle transazioni. Questo periodo di attesa evita conflitti che possono derivare dalla replica di ciascun evento dei log binari singolarmente. Tuttavia, in questo modo aumenta il ritardo di replica per le repliche dei log binari. Tali repliche possono rimanere indietro rispetto all'origine dello stesso numero di secondi dell'impostazione aurora_binlog_replication_max_yield_seconds.

Il file binlog corrente indica il file binlog che il thread di dump sta attualmente leggendo per eseguire la replica. Consideriamo che un file binlog è attivo quando il file binlog è in aggiornamento o aperto per essere aggiornato dalle transazioni in entrata. Dopo che Aurora My ha SQL riempito il file binlog attivo, My SQL crea e passa a un nuovo file binlog. Il vecchio file binlog diventa inattivo. Non viene più aggiornato dalle transazioni in entrata.

Aurora My SQL riconosce immediatamente qualsiasi modifica al aurora_binlog_replication_max_yield_seconds valore del parametro. Non è necessario riavviare l'istanza database. Tuttavia, quando si attiva questa impostazione, il thread di dump inizia a produrre solo quando il file dei log binari corrente raggiunge la dimensione massima di 128 MB e viene ruotato in un nuovo file.

Parametri correlati

Utilizza i seguenti parametri del cluster di database per attivare l'ottimizzazione binlog.

Attivazione del meccanismo max-yield di replica dei log binari

È possibile attivare l'ottimizzazione max-yield di replica dei log binari come descritto di seguito. In questo modo si riduce al minimo la latenza per le transazioni sull'istanza di origine binlog. Tuttavia, è possibile che si verifichi un ritardo di replica più elevato.

Disattivare l'ottimizzazione max-yield di replica dei log binari

È possibile disattivare l'ottimizzazione max-yield di replica dei log binari come descritto di seguito. In questo modo si riduce al minimo il ritardo di replica. Tuttavia, è possibile che si verifichi una latenza maggiore per le transazioni sull'istanza di origine binlog.

Disattivazione del buffer di lettura di grandi dimensioni

È possibile disattivare l'intera funzionalità di buffer di lettura di grandi dimensioni come di seguito.