Configurazione del file di log binario avanzato per Aurora MySQL

Il file di log binario avanzato riduce il sovraccarico delle prestazioni di elaborazione causato dall'attivazione del file di log binario, che in alcuni casi può arrivare fino al 50%. Con il file di log binario avanzato, questo sovraccarico può essere ridotto a circa il 13%. Per ridurre il sovraccarico, il file di log binario avanzato scrive i log binari e i log delle transazioni nello spazio di archiviazione in parallelo, il che riduce al minimo i dati scritti al momento del commit della transazione.

L'utilizzo del file di log binario avanzato migliora anche i tempi di ripristino del database dopo riavvii e failover fino al 99% rispetto al file di log binario della community MySQL. Il file di log binario avanzato è compatibile con i carichi di lavoro esistenti basati sul file di log binario e viene utilizzato nello stesso modo in cui si utilizza il file di log binario della community MySQL.

Il file di log binario avanzato è disponibile in Aurora MySQL versione 3.03.1 e successive.

Configurazione dei parametri del file di log binario avanzato

È possibile passare dal file di log binario della community MySQL al file di log binario avanzato attivando/disattivando i relativi parametri. Gli utenti esistenti di file di log binario possono continuare a leggere e consumare i file di log binario senza interruzioni nella sequenza di file di log binario.

Per attivare il file di log binario avanzato, imposta i seguenti parametri:

Parametro	Predefinito	Descrizione
binlog_format	–	Impostare il parametro binlog_format sul formato di registrazione binaria desiderato per attivare il file di log binario avanzato. Assicurarsi che binlog_format parameter non sia impostato su OFF. Per ulteriori informazioni, consultare Configurazione del log binario di Aurora MySQL.
aurora_enhanced_binlog	0	Impostare il valore di questo parametro su 1 nel gruppo di parametri del cluster database associato al cluster Aurora MySQL. Quando si modifica il valore di questo parametro, è necessario riavviare l'istanza di scrittura quando il valore di DBClusterParameterGroupStatus viene visualizzato come pending-reboot.
binlog_backup	1	Disattivare questo parametro per attivare il file di log binario avanzato. A tale scopo, impostare il valore di questo parametro su 0.
binlog_replication_globaldb	1	Disattivare questo parametro per attivare il file di log binario avanzato. A tale scopo, impostare il valore di questo parametro su 0.

Importante

È possibile disattivare i parametri binlog_backup e binlog_replication_globaldb  solo in caso di utilizzo del file di log binario avanzato.

Per disattivare il file di log binario avanzato, imposta i seguenti parametri:

Parametro	Descrizione
aurora_enhanced_binlog	Impostare il valore di questo parametro su 0 nel gruppo di parametri del cluster database associato al cluster Aurora MySQL. Ogni volta che si modifica il valore di questo parametro, è necessario riavviare l'istanza di scrittura quando il valore di DBClusterParameterGroupStatus viene visualizzato come pending-reboot.
binlog_backup	Attivare questo parametro quando si disattiva il file di log binario avanzato. A tale scopo, impostare il valore di questo parametro su 1.
binlog_replication_globaldb	Attivare questo parametro quando si disattiva il file di log binario avanzato. A tale scopo, impostare il valore di questo parametro su 1.

Per verificare se il file di log binario avanzato è attivo, usare il seguente comando nel client MySQL:

mysql>show status like 'aurora_enhanced_binlog';
              
+------------------------+--------+
| Variable_name          | Value  |
+------------------------+--------+
| aurora_enhanced_binlog | ACTIVE |
+------------------------+--------+
1 row in set (0.00 sec)
              

Quando il file di log binario avanzato è attivo, l'output mostra ACTIVE per aurora_enhanced_binlog.

Altri parametri correlati

Quando si attiva il file di log binario avanzato, questa operazione interessa i seguenti parametri:

• Il parametro max_binlog_size è visibile ma non modificabile. Il relativo valore predefinito 134217728 viene impostato automaticamente su 268435456 quando il file di log binario avanzato è attivato.

• A differenza file di log binario avanzato della community MySQL, binlog_checksum non agisce come parametro dinamico quando il file di log binario avanzato è attivato. Affinché la modifica a questo parametro abbia effetto, è necessario riavviare manualmente il cluster database anche quando ApplyMethod è immediate.

• Il valore impostato per il parametro binlog_order_commits non ha alcun effetto sull'ordine dei commit quando il file di log binario avanzato è attivato. I commit vengono sempre ordinati senza ulteriori implicazioni in termini di prestazioni.

Differenze tra file di log binario avanzato e file di log binario avanzato della community MySQL

Il file di log binario avanzato interagisce in modo diverso con i cloni, i backup e il database globale Aurora rispetto al file di log binario avanzato di Community MySQL. Si consiglia di analizzare le seguenti differenze prima di utilizzare il file di log binario avanzato.

• I file di log binario avanzati del cluster di database di origine non sono disponibili su un cluster di database clonato.

• I file di log binario avanzati non sono inclusi nei backup di Aurora. Pertanto, i file di log binario avanzati del cluster database di origine non sono disponibili dopo il ripristino di un cluster database nonostante il relativo periodo di conservazione impostato.

• Se utilizzati con un database globale Aurora, i file di log binario avanzati del cluster database primario non vengono replicati nel cluster database nelle regioni secondarie.

Examples (Esempi)

Negli esempi seguenti vengono illustrate le differenze tra file di log binario avanzati e file di log binario della community MySQL.

Su un cluster database ripristinato o clonato

Quando il file di log binario avanzato è attivato, i file di log binario storici non sono disponibili nel cluster database ripristinato o clonato. Dopo un'operazione di ripristino o clonazione, se il file di log binario è attivato, il nuovo cluster database inizia a scrivere la propria sequenza di file di log binario a partire da 1 (mysql-bin-changelog.000001).

Per attivare il file di log binario avanzato dopo un'operazione di ripristino o clonazione, impostare i parametri del cluster database richiesti sul cluster database ripristinato o clonato. Per ulteriori informazioni, consulta Configurazione dei parametri del file di log binario avanzato.

Esempio: operazione di clonazione o ripristino eseguita con il file di log binario avanzato attivato

Cluster database di origine:

mysql> show binary logs;
                      
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        |
| mysql-bin-changelog.000002 |       156 | No        |
| mysql-bin-changelog.000003 |       156 | No        |
| mysql-bin-changelog.000004 |       156 | No        | --> Enhanced Binlog turned on
| mysql-bin-changelog.000005 |       156 | No        | --> Enhanced Binlog turned on
| mysql-bin-changelog.000006 |       156 | No        | --> Enhanced Binlog turned on
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)
                      
                  

In un cluster database ripristinato o clonato, non viene eseguito il backup dei file di log binario quando è attivato il file di log binario avanzato. Per evitare discontinuità nei dati del file di log binario, non sono disponibili nemmeno i file di log binario scritti prima di attivare il file di log binario avanzato.

mysql>show binary logs;
                      
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        | --> New sequence of Binlog files
+----------------------------+-----------+-----------+ 
1 row in set (0.00 sec)
                      
                  

Esempio: operazione di clonazione o ripristino eseguita con il file di log binario avanzato disattivato

Cluster di database di origine:

mysql>show binary logs;
                                                
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        |
| mysql-bin-changelog.000002 |       156 | No        | --> Enhanced Binlog enabled
| mysql-bin-changelog.000003 |       156 | No        | --> Enhanced Binlog enabled
| mysql-bin-changelog.000004 |       156 | No        | 
| mysql-bin-changelog.000005 |       156 | No        | 
| mysql-bin-changelog.000006 |       156 | No        |
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)
                      
                  

Il file di log binario avanzato viene disabilitato dopo mysql-bin-changelog.000003. In un cluster database ripristinato o clonato, sono disponibili file di log binario scritti dopo aver disattivato il file di log binario avanzato.

mysql>show binary logs;
                      
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000004 |       156 | No        | 
| mysql-bin-changelog.000005 |       156 | No        | 
| mysql-bin-changelog.000006 |       156 | No        |
+----------------------------+-----------+-----------+
1 row in set (0.00 sec)
                      
                  

Su un database globale Amazon Aurora

Su un database globale Amazon Aurora, i dati del file di log binario del cluster database primario non vengono replicati nei cluster database secondari. Dopo un processo di failover tra regioni, i dati del file di log binario non sono disponibili nel cluster database primario appena promosso. Se il file di log binario è attivato, il cluster database appena promosso avvia la propria sequenza di file di log binario, a partire da 1 (mysql-bin-changelog.000001).

Per attivare il file di log binario avanzato dopo il failover, è necessario impostare i parametri del cluster database richiesti sul cluster database secondario. Per ulteriori informazioni, consulta Configurazione dei parametri del file di log binario avanzato.

Esempio: operazione di failover globale del database eseguita con il file di log binario avanzato attivato

Vecchio cluster database primario (prima del failover):

mysql>show binary logs;
                  
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        |
| mysql-bin-changelog.000002 |       156 | No        |
| mysql-bin-changelog.000003 |       156 | No        |
| mysql-bin-changelog.000004 |       156 | No        | --> Enhanced Binlog enabled
| mysql-bin-changelog.000005 |       156 | No        | --> Enhanced Binlog enabled
| mysql-bin-changelog.000006 |       156 | No        | --> Enhanced Binlog enabled
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)
                  

Nuovo cluster database primario (dopo il failover):

I file di log binario non vengono replicati nelle regioni secondarie quando il file di log binario avanzato è attivato. Per evitare discontinuità nei dati del file di log binario, i file di log binario scritti prima di attivare il file di log binario avanzato non sono disponibili.

mysql>show binary logs;
                      
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        | --> Fresh sequence of Binlog files
+----------------------------+-----------+-----------+ 
1 row in set (0.00 sec)                          
                      
                  

Esempio: operazione di failover globale del database eseguita con il file di log binario avanzato disattivato

Cluster database di origine:

mysql>show binary logs;
                  
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 |       156 | No        |
| mysql-bin-changelog.000002 |       156 | No        | --> Enhanced Binlog enabled
| mysql-bin-changelog.000003 |       156 | No        | --> Enhanced Binlog enabled
| mysql-bin-changelog.000004 |       156 | No        | 
| mysql-bin-changelog.000005 |       156 | No        | 
| mysql-bin-changelog.000006 |       156 | No        |
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)
                  
                  

Cluster database ripristinato o clonato:

Il file di log binario avanzato viene disabilitato dopo mysql-bin-changelog.000003. I file di log binario scritti dopo aver disattivato il file di log binario avanzato vengono replicati e sono disponibili nel cluster database appena promosso.

mysql>show binary logs;
                  
+----------------------------+-----------+-----------+
| Log_name                   | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000004 |       156 | No        | 
| mysql-bin-changelog.000005 |       156 | No        | 
| mysql-bin-changelog.000006 |       156 | No        |
+----------------------------+-----------+-----------+
3 rows in set (0.00 sec)
                  

Metriche Amazon CloudWatch per il file di log binario avanzato

Le seguenti metriche di Amazon CloudWatch vengono pubblicate solo quando il file di log binario avanzato è attivato.

Parametro CloudWatch	Descrizione	unità
ChangeLogBytesUsed	Quantità di spazio di archiviazione in byte utilizzato dal file di log binario avanzato.	Byte
ChangeLogReadIOPs	Numero di operazioni I/O di lettura eseguite nel file di log binario avanzato in intervalli di 5 minuti.	Conteggio per 5 minuti
ChangeLogWriteIOPs	Numero di operazioni I/O di scrittura su disco eseguite nel file di log binario avanzato in intervalli di 5 minuti.	Conteggio per 5 minuti

Limitazioni del file di log binario avanzato

Le seguenti limitazioni si applicano ai cluster database Amazon Aurora quando il file di log binario avanzato è attivato.

• Il file di log binario avanzato è supportato solo in Aurora MySQL versione 3.03.1 e successive.

• I file di log binario avanzati scritti sul cluster database primario non vengono copiati nei cluster database clonati o ripristinati.

• Se utilizzati con un database globale Amazon Aurora, i file di log binario avanzati del cluster database primario non vengono replicati nei cluster database secondari. Pertanto, dopo il processo di failover, i dati dei file di log binario storici non sono disponibili nel nuovo cluster database primario.

• I seguenti parametri di configurazione del file di log binario vengono ignorati:

  • binlog_group_commit_sync_delay

  • binlog_group_commit_sync_no_delay_count

  • binlog_max_flush_queue_time

• Non è possibile eliminare o rinominare una tabella danneggiata in un database. Per eliminare queste tabelle, è possibile contattare Support.

• La cache I/O del file di log binario è disabilitata quando il file di log binario avanzato è attivato. Per ulteriori informazioni, consulta Ottimizzazione della replica dei log binari per Aurora MySQL.

  Nota

  Il file di log binario avanzato è caratterizzato da miglioramenti delle prestazioni di lettura simili a quelli della cache I/O del file di log binario e da ulteriori ottimizzazioni delle prestazioni di scrittura.

• La funzionalità Backtrack non è supportata. Il file di log binario avanzato non può essere attivato in un cluster database nelle seguenti condizioni:

  • Cluster database con la funzionalità Backtrack abilitata.

  • Cluster di database con la funzionalità Backtrack precedentemente abilitata, ma non disattivata.

  • Cluster database ripristinato da un cluster database di origine o da uno snapshot con la funzionalità Backtrack abilitata.