engine=innodb, algorithm=copy;
```
Nelle sezioni seguenti, viene descritto come configurare la replica, interrompere la replica, scalare le letture per il database in uso, ottimizzare la replica binlog e configurare il file di log binario avanzato.
**Topics**
+ [
# Configurazione del processo di replica dei log binari per Aurora MySQL
](AuroraMySQL.Replication.MySQL.SettingUp.md)
+ [
# Arresto del processo di replica dei log binari per Aurora MySQL
](AuroraMySQL.Replication.MySQL.Stopping.md)
+ [
# Dimensionamento delle letture per il database MySQL con Amazon Aurora
](AuroraMySQL.Replication.ReadScaling.md)
+ [
# Ottimizzazione della replica dei log binari per Aurora MySQL
](binlog-optimization.md)
+ [
# Configurazione del file di log binario avanzato per Aurora MySQL
](AuroraMySQL.Enhanced.binlog.md)
# Configurazione del processo di replica dei log binari per Aurora MySQL
L'impostazione della replica MySQL con Aurora MySQL prevede le seguenti fasi che vengono discusse in dettaglio:
**Contents**
+ [
## 1. Abilitare l'accesso binario nella fonte di replica
](#AuroraMySQL.Replication.MySQL.EnableBinlog)
+ [
## 2. Mantieni i log binari nel master di replica fino a quando non sono più necessari
](#AuroraMySQL.Replication.MySQL.RetainBinlogs)
+ [
## 3. Creazione di una copia o un dump dell’origine della replica
](#AuroraMySQL.Replication.MySQL.CreateSnapshot)
+ [
## 4. Caricamento del dump nella destinazione di replica (se necessario)
](#AuroraMySQL.Replication.MySQL.LoadSnapshot)
+ [
## 5. Creazione di un utente di replica sull’origine di replica
](#AuroraMySQL.Replication.MySQL.CreateReplUser)
+ [
## 6. Abilitare la replica nel target di replica
](#AuroraMySQL.Replication.MySQL.EnableReplication)
+ [
### Definire una posizione per arrestare la replica su una replica di lettura
](#AuroraMySQL.Replication.StartReplicationUntil)
+ [
## 7. Monitora la replica
](#AuroraMySQL.Replication.MySQL.Monitor)
+ [
## Sincronizzazione delle password tra origine di replica e destinazione
](#AuroraMySQL.Replication.passwords)
## 1. Abilitare l'accesso binario nella fonte di replica
Seguono le istruzioni su come abilitare l'accesso binario nella fonte di replica per il motore del database.
| Motore del database | Istruzioni |
| --- | --- |
| Aurora MySQL | **Per abilitare l'accesso binario in un cluster di database Aurora MySQL** Imposta il parametro del cluster di database `binlog_format` su `ROW`, `STATEMENT` o `MIXED`. `MIXED` è consigliato a meno che tu abbia bisogno di un formato binlog specifico. Il valore predefinito è `OFF`. Per modificare il parametro `binlog_format`, crea un gruppo di parametri del cluster di database personalizzato e associalo al tuo cluster di database. Non puoi modificare i parametri in un gruppo di parametri del cluster di database predefinito. Se stai modificando il parametro `binlog_format` da `OFF` a un altro valore, riavvia il cluster di database Aurora per rendere effettiva la modifica. Per ulteriori informazioni, consulta [Parametri dell’istanza database e del cluster database di Amazon Aurora](USER_WorkingWithDBClusterParamGroups.md#Aurora.Managing.ParameterGroups) e [Gruppi di parametri per Amazon Aurora](USER_WorkingWithParamGroups.md). |
| RDS for MySQL | **Per abilitare l'accesso binario in un'istanza database Amazon RDS** Non è possibile abilitare l'accesso binario direttamente per un'istanza database Amazon RDS, ma si può abilitarlo procedendo in uno dei seguenti modi: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| MySQL (esterno) | **Per impostare la replica crittografata** Per replicare i dati in maniera sicura con Aurora MySQL versione 2, puoi utilizzare la replica crittografata. Se non hai bisogno di utilizzare la replica crittografata, puoi saltare queste fasi. Seguono i prerequisiti per l'utilizzo della replica crittografata: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) Durante la replica crittografata, il cluster di database Aurora MySQL agisce come un client per il server di database MySQL. I certificati e le chiavi per il client Aurora MySQL sono in file in formato .pem. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) **Per abilitare l'accesso binario a un database esterno MySQL** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
## 2. Mantieni i log binari nel master di replica fino a quando non sono più necessari
Quando si utilizza la replica dei log binari MySQL, Amazon RDS non gestisce il processo di replica. Come risultato, devi assicurarti che i file binlog nel master di replica siano mantenuti finché le modifiche vengono applicate alla replica. Questa manutenzione aiuta a ripristinare il database di origine in caso di errore.
Utilizza le istruzioni seguenti per mantenere i registri binari per il motore di database.
| Motore del database | Istruzioni |
| --- | --- |
| Aurora MySQL | **Per mantenere i log binari in un cluster di database Aurora MySQL** Non hai accesso ai file binlog per un cluster di database Aurora MySQL. Come risultato, devi selezionare un intervallo di tempo per mantenere i file binlog nel master di replica abbastanza a lungo per assicurare che le modifiche vengano applicate alla replica prima che il file binlog venga eliminato da Amazon RDS. Puoi mantenere i file binlog in un cluster di database Aurora MySQL fino a 90 giorni. Se stai impostando la replica con un database MySQL o un'istanza database RDS per MySQL come replica e il database per il quale stai creando la replica è di grandi dimensioni, seleziona un intervallo di tempo ampio per mantenere i file binlog finché la copia iniziale del database nella replica sia completa e il ritardo di replica sia pari a 0. Per impostare il periodo di conservazione dei log binari, usa la procedura [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) e specifica il parametro di configurazione `'binlog retention hours'` insieme al numero di ore di conservazione dei file binlog nel cluster di database. Il valore massimo per Aurora MySQL versione 2.11.0 e successive e versione 3 è 2160 (90 giorni). L'esempio seguente imposta il periodo di conservazione dei file binlog su 6 giorni: CALL mysql.rds_set_configuration('binlog retention hours', 144); Dopo l'inizio della replica, è possibile verificare che le modifiche siano state applicate alla replica eseguendo il comando `SHOW SLAVE STATUS` (Aurora MySQL versione 2) o `SHOW REPLICA STATUS` (Aurora MySQL versione 3) nella replica e controllando il campo `Seconds behind master`. Se il campo `Seconds behind master` è 0, non vi è alcun ritardo di replica. Quando non c'é ritardo di replica, riduci il periodo di tempo di conservazione dei file binlog impostando il parametro di configurazione `binlog retention hours` su un intervallo di tempo più breve. Se questa impostazione non è specificata, verrà utilizzato il valore predefinito per Aurora MySQL ovvero 24 (1 giorno). Se si specifica un valore per `'binlog retention hours'` che è superiore al valore massimo, allora Aurora MySQL utilizza il valore massimo. |
| RDS per MySQL | **Per mantenere i log binari in un'istanza database Amazon RDS** Puoi mantenere i file dei registri binari in un'istanza database di Amazon RDS impostando le ore di conservazione del binlog allo stesso modo di un cluster di database Aurora MySQL, come descritto nella riga precedente. Puoi anche mantenere i file binlog in un'istanza database Amazon RDS creando una replica di lettura per l'istanza database. La replica di lettura è temporanea e ha solamente l'obiettivo di mantenere i file binlog. Dopo che la replica di lettura è stata creata, chiama la procedura [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) nella replica di lettura. Mentre la replica è interrotta, Amazon RDS non elimina nessuno dei file binlog nel master di replica. Dopo aver impostato la replica con la replica permanente, puoi eliminare la replica di lettura quando il ritardo di replica (campo `Seconds behind master`) tra il master di replica a la replica permanente diventa 0. |
| MySQL (esterno) | **Per mantenere i log binari in un database esterno MySQL;** Siccome i file binlog in un database MySQL non sono gestiti da Amazon RDS, vengono mantenuti finché li elimini. Dopo l'inizio della replica, è possibile verificare che le modifiche siano state applicate alla replica eseguendo il comando `SHOW SLAVE STATUS` (Aurora MySQL versione 2) o `SHOW REPLICA STATUS` (Aurora MySQL versione 3) nella replica e controllando il campo `Seconds behind master`. Se il campo `Seconds behind master` è 0, non vi è alcun ritardo di replica. Quando non c'é ritardo di replica, puoi eliminare i vecchi file binlog. |
## 3. Creazione di una copia o un dump dell’origine della replica
È possibile utilizzare uno snapshot, un clone o un dump dell’origine della replica per caricare una copia di base dei dati nella replica. Quindi si inizia a replicare da quel punto.
Utilizza le istruzioni seguenti per creare una copia o un dump dell’origine della replica per il motore di database.
| Motore del database | Istruzioni |
| --- | --- |
| Aurora MySQL | **Come creare una copia di un cluster di database Aurora MySQL** Seleziona uno dei seguenti metodi: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) **Come determinare il nome e la posizione del file binlog** Seleziona uno dei seguenti metodi: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) **Come creare un dump di un cluster di database Aurora MySQL** Se la destinazione di replica è un database MySQL esterno o un’istanza database RDS per MySQL, devi creare un file dump dal cluster di database Aurora. Assicurati che il comando `mysqldump` venga eseguito nella copia del cluster di database di origine che hai creato. In questo modo si evitano considerazioni bloccanti quando si esegue il dump. Se il dump fosse eseguito direttamente sul cluster di database di origine, sarebbe necessario bloccare le tabelle di origine per evitare scritture simultanee su di esse mentre il dump è in corso. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| RDS per MySQL | **Per creare una snapshot di un'istanza database Amazon RDS** Crea una replica di lettura dell'istanza database Amazon RDS. Per ulteriori informazioni, consulta [Creazione di una replica di lettura](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.Create) nella *Guida per l'utente di Amazon Relational Database Service*. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| MySQL (esterno) | **Per creare il dump di un database MySQL esterno** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
## 4. Caricamento del dump nella destinazione di replica (se necessario)
Se intendi caricare i dati da un dump di un database MySQL che è esterno ad Amazon RDS, è consigliabile creare un’istanza EC2 in cui copiare i file dump. Quindi puoi caricare i dati nel tuo cluster di database o nell’istanza database da quell’istanza EC2. Utilizzando questo approccio, puoi comprimere i file dump prima di copiarli nell'istanza EC2 per ridurre i costi di rete associati con la copia dei dati in Amazon RDS. Puoi anche crittografare il file o i file dump per assicurare i dati mentre vengono trasferiti nella rete.
**Nota**
Se crei un nuovo cluster di database Aurora MySQL come destinazione di replica, non è necessario che tu carichi un file dump:
È possibile eseguire il ripristino da uno snapshot del cluster di database per creare un nuovo cluster di database. Per ulteriori informazioni, consulta [Ripristino da uno snapshot cluster database](aurora-restore-snapshot.md).
Puoi clonare il tuo cluster di database di origine per creare un nuovo cluster di database. Per ulteriori informazioni, consulta [Clonazione di un volume per un cluster di database Amazon Aurora](Aurora.Managing.Clone.md).
Puoi eseguire la migrazione dei dati da uno snapshot di un’istanza database in un nuovo cluster di database. Per ulteriori informazioni, consulta [Migrazione di dati a un cluster di database Amazon Aurora MySQL](AuroraMySQL.Migrating.md).
Utilizza le istruzioni seguenti per caricare il dump dell’origine di replica nella destinazione di replica per il motore di database.
| Motore del database | Istruzioni |
| --- | --- |
| Aurora MySQL | **Come caricare un dump in un cluster di database Aurora MySQL** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| RDS per MySQL | **Per caricare un dump in un'istanza database Amazon RDS** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| MySQL (esterno) | **Per caricare un dump in un database MySQL esterno** Non è possibile caricare uno snapshot di database o di cluster di database in un database MySQL esterno. Devi utilizzare invece l'output dal comando `mysqldump`. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
## 5. Creazione di un utente di replica sull’origine di replica
Crea un ID utente sull’origine utilizzato solamente per la replica. L’esempio seguente riguarda database RDS per MySQL o database di origine MySQL esterni.
```
mysql> CREATE USER 'repl_user'@'domain_name' IDENTIFIED BY 'password';
```
Per i database di origine Aurora MySQL, il parametro del cluster di database `skip_name_resolve` è impostato su `1` (`ON`) e non può essere modificato, quindi è necessario utilizzare un indirizzo IP per l’host anziché un nome di dominio. Per ulteriori informazioni, consulta [skip\$1name\$1resolve](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_skip_name_resolve) nella documentazione di MySQL.
```
mysql> CREATE USER 'repl_user'@'IP_address' IDENTIFIED BY 'password';
```
L'utente richiede i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE`. Concedi questi privilegi all'utente.
Se non hai bisogno di utilizzare la replica crittografata, richiedi le connessioni SSL per l'utente replica. Ad esempio, puoi utilizzare una delle seguenti istruzioni per richiedere connessioni SSL per l’account utente `repl_user`.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'IP_address';
```
```
GRANT USAGE ON *.* TO 'repl_user'@'IP_address' REQUIRE SSL;
```
**Nota**
Se `REQUIRE SSL` non è incluso, la connessione di replica potrebbe ridiventare una connessione non crittografata.
## 6. Abilitare la replica nel target di replica
Raccomandiamo di fare una snapshot manuale del cluster di database Aurora MySQL o del target di replica dell'istanza database RDS for MySQL, prima di abilitare la replica. Se c'è un problema e devi ristabilire la replica con il cluster di database o il target di replica dell'istanza database, puoi ripristinare il cluster di database o l'istanza database da questa snapshot invece di dover importare di nuovo i dati nel target di replica.
Utilizza le istruzioni seguenti per attivare la replica del motore di database.
| Motore del database | Istruzioni |
| --- | --- |
| Aurora MySQL | **Per abilitare la replica da un cluster di database Aurora MySQL** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) Per utilizzare la crittografia SSL, imposta il valore finale su `1` anziché `0`. |
| RDS per MySQL | **Per abilitare la replica da un'istanza database Amazon RDS** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) Per utilizzare la crittografia SSL, imposta il valore finale su `1` anziché `0`. |
| MySQL (esterno) | **Per abilitare la replica da un database esterno MySQL;** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
Se la replica fallisce, può verificarsi un notevole aumento dei dati involontari I/O sulla replica, con conseguente peggioramento delle prestazioni. Se la replica non riesce o non è più necessaria, è possibile eseguire la stored procedure [mysql.rds\$1reset\$1external\$1master (Aurora MySQL versione 2)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) o [mysql.rds\$1reset\$1external\$1source (Aurora MySQL versione 3)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_source) per rimuovere la configurazione della replica.
### Definire una posizione per arrestare la replica su una replica di lettura
In Aurora MySQL versione 3.04 e successive, puoi avviare una replica e quindi arrestarla in una posizione di file di log binario specifica mediante la stored procedure [mysql.rds\$1start\$1replication\$1until (Aurora MySQL versione 3)](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until).
**Per avviare la replica su una replica di lettura e arrestare la replica in corrispondenza di una posizione specifica**
1. Utilizzando un client MySQL, stabilisci una connessione al cluster di database Aurora MySQL di replica come utente master.
1. Eseguire la procedura archiviata [mysql.rds\$1start\$1replication\$1until (Aurora MySQL versione 3)](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until).
L'esempio seguente avvia la replica e replica le modifiche fino a raggiungere la posizione `120` nel file di log binario `mysql-bin-changelog.000777`. In caso di disaster recovery, presumere che la posizione `120` si riferisca al momento immediatamente precedente l'errore.
```
call mysql.rds_start_replication_until(
'mysql-bin-changelog.000777',
120);
```
La replica si arresta automaticamente quando viene raggiunto il punto di arresto. Viene generato il seguente evento RDS: `Replication has been stopped since the replica reached the stop point specified by the rds_start_replication_until stored procedure`.
Se si utilizza la replica basata su GTID, scegliere la stored procedure [mysql.rds\$1start\$1replication\$1until\$1gtid (Aurora MySQL versione 3)](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) invece della [mysql.rds\$1start\$1replication\$1until (Aurora MySQL versione 3)](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until). Per ulteriori informazioni sulla replica basata su GTID, consultare [Utilizzo della replica basata su GTID](mysql-replication-gtid.md).
## 7. Monitora la replica
Quando imposti la replica MySQL con un cluster di database Aurora MySQL, devi monitorare gli eventi di failover per il cluster di database Aurora MySQL quando è il target di replica. Se accade un failover, il cluster di database che è il target di replica potrebbe essere ricreato in un nuovo host con un indirizzo di rete diverso. Per informazioni su come monitorare gli eventi di failover, consulta [Utilizzo della notifica degli eventi di Amazon RDS](USER_Events.md).
È anche possibile monitorare quanto è indietro la destinazione della replica rispetto all'origine eseguendo la connessione alla destinazione della replica e il comando `SHOW SLAVE STATUS` (Aurora MySQL versione 2) o `SHOW REPLICA STATUS` (Aurora MySQL versione 3). Nell'output del comando, il campo `Seconds Behind Master` indica quanto è indietro il target di replica rispetto al master di replica.
**Importante**
Se aggiorni il tuo cluster di database e specifichi un gruppo di parametri personalizzati, assicurati di riavviare manualmente il cluster al termine dell’aggiornamento. In questo modo il cluster utilizza le nuove impostazioni dei parametri personalizzati e riavvia la replica dei log binari.
## Sincronizzazione delle password tra origine di replica e destinazione
Quando si modificano gli account utente e le password nell'origine di replica utilizzando le istruzioni SQL, tali modifiche vengono replicate automaticamente nella destinazione di replica.
Se si utilizza l'API Console di gestione AWS AWS CLI, the o RDS per modificare la password principale sull'origine della replica, tali modifiche non vengono replicate automaticamente nella destinazione di replica. Se si desidera sincronizzare l'utente principale e la password principale tra il sistema di origine e quello di destinazione, è necessario apportare la stessa modifica alla destinazione di replica.
# Arresto del processo di replica dei log binari per Aurora MySQL
Per fermare la replica dei log binari con un'istanza database MySQL, un database MySQL esterno o un altro cluster di database Aurora, segui questa procedura, che viene illustrata nel dettaglio nel seguente argomento.
[1. Arrestare la replica dei log binari nella destinazione di replica](#AuroraMySQL.Replication.MySQL.Stopping.StopReplication)
[2. Disabilitare l'accesso binario alla fonte di replica](#AuroraMySQL.Replication.MySQL.Stopping.DisableBinaryLogging)
## 1. Arrestare la replica dei log binari nella destinazione di replica
Usa le seguenti istruzioni per arrestare la replica dei log binari del motore di database.
| Motore del database | Istruzioni |
| --- | --- |
| Aurora MySQL | **Per arrestare la replica dei log binari in una destinazione di replica del cluster di database Aurora MySQL** Esegui la connessione al cluster di database Aurora che è la destinazione della replica e chiama la procedura [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication). |
| RDS per MySQL | **Per arrestare la replica binlog in un'istanza database Amazon RDS** Esegui la connessione all'istanza database RDS che è la destinazione della replica e chiama la procedura [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication). |
| MySQL (esterno) | **Per fermare la replica dei log binari in un database MySQL esterno** Connettiti al database MySQL ed esegui il comando`STOP SLAVE` (versione 5.7) o `STOP REPLICA` (versione 8.0). |
## 2. Disabilitare l'accesso binario alla fonte di replica
Usa le seguenti istruzioni per disattivare la registrazione dei log binari nell'origine della replica per il motore del database.
| Motore del database | Istruzioni |
| --- | --- |
| Aurora MySQL | **Per disabilitare l'accesso binario in un cluster di database Amazon Aurora** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.Stopping.html) |
| RDS for MySQL | **Per disabilitare l'accesso binario in un'istanza database Amazon RDS** Non è possibile abilitare l'accesso binario direttamente per un'istanza database Amazon RDS, ma è possibile abilitarlo procedendo come di seguito: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.Stopping.html) |
| MySQL (esterno) | **Per disabilitare l'accesso binario a un database esterno MySQL** Esegui la connessione al database MySQL e chiama il comando `STOP REPLICATION`. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.Stopping.html) |
# Dimensionamento delle letture per il database MySQL con Amazon Aurora
Puoi utilizzare Amazon Aurora con l'istanza database MySQL per usufruire delle funzionalità di dimensionamento della lettura di Amazon Aurora ed espandere il reale carico di lavoro della tua istanza database MySQL. Per utilizzare Aurora per ridimensionare le operazioni di lettura dell'istanza database MySQL, crea un cluster di database Amazon Aurora MySQL e rendilo una replica di lettura per l'istanza database MySQL. Ciò si applica a un'istanza database RDS per MySQL o a un database MySQL in esecuzione esternamente a Amazon RDS.
Per informazioni su come creare un cluster di database Amazon Aurora, consulta [Creazione di un cluster database Amazon Aurora](Aurora.CreateInstance.md).
Quando si configura la replica tra l'istanza database MySQL e il cluster di database Amazon Aurora, assicurarsi di seguire queste linee guida:
+ Utilizzare l'indirizzo dell'endpoint del cluster di database di Amazon Aurora quando si fa riferimento al cluster di database Amazon Aurora MySQL. Se si verifica un failover, la replica di Aurora promossa a istanza principale per il cluster di database Aurora MySQL continua a utilizzare l'indirizzo dell'endpoint del cluster di database.
+ Conservare i binlog sull'istanza di scrittura finché non si ha la conferma che siano stati applicati alla replica di Aurora. Questa manutenzione assicura il ripristino dell'istanza di lettura nel caso di errori.
**Importante**
Quando si utilizza la replica auto-gestita, si ha la responsabilità di monitorare e risolvere eventuali problemi di replica. Per ulteriori informazioni, consulta [Diagnosi e risoluzione del ritardo tra repliche di lettura](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.ReplicaLag).
**Nota**
Le autorizzazioni richieste per avviare la replica su un cluster di database Aurora MySQL sono limitate e non disponibili per l'utente master Amazon RDS. Pertanto sarà necessario utilizzare le procedure [mysql.rds\$1set\$1external\$1master (Aurora MySQL versione 2)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) o [mysql.rds\$1set\$1external\$1source (Aurora MySQL versione 3)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) e [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) per impostare la replica tra il cluster di database Aurora MySQL e l'istanza database MySQL.
## Avvio della replica tra un'istanza di origine esterna e un cluster di database Aurora MySQL
1. Rendere di sola lettura l'istanza database MySQL di origine:
```
mysql> FLUSH TABLES WITH READ LOCK;
mysql> SET GLOBAL read_only = ON;
```
1. Eseguire il comando `SHOW MASTER STATUS` nell'istanza database MySQL di origine per determinare la posizione di binlog. Viene restituito un output simile all'esempio seguente:
```
File Position
------------------------------------
mysql-bin-changelog.000031 107
------------------------------------
```
1. Copia il database dall'istanza database MySQL esterna al cluster di database Amazon Aurora MySQL utilizzando `mysqldump`. Per database di dimensioni particolarmente elevate, è possibile utilizzare la procedura descritta in [Importazione dei dati in un database Amazon RDS per MySQL con tempo di inattività ridotto](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql-importing-data-reduced-downtime.html) nella *Guida per l’utente di Amazon Relational Database Service*.
Per Linux, macOS o Unix:
```
mysqldump \
--databases \
--single-transaction \
--compress \
--order-by-primary \
-u local_user \
-p local_password | mysql \
--host aurora_cluster_endpoint_address \
--port 3306 \
-u RDS_user_name \
-p RDS_password
```
Per Windows:
```
mysqldump ^
--databases ^
--single-transaction ^
--compress ^
--order-by-primary ^
-u local_user ^
-p local_password | mysql ^
--host aurora_cluster_endpoint_address ^
--port 3306 ^
-u RDS_user_name ^
-p RDS_password
```
**Nota**
Assicurati che non siano presenti spazi tra l'opzione `-p` e la password immessa.
Utilizza le opzioni `--host`, `--user (-u)`, `--port` e `-p` nel comando `mysql` per specificare il nome host, il nome utente e la password per eseguire la connessione al cluster di database Aurora. Il nome host è il nome DNS per l'endpoint del cluster di database Amazon Aurora, ad esempio, `mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com`. Il valore dell'endpoint è disponibile nei dettagli del cluster nella console di gestione Amazon RDS.
1. Rendere nuovamente scrivibile l'istanza database MySQL di origine:
```
mysql> SET GLOBAL read_only = OFF;
mysql> UNLOCK TABLES;
```
Per ulteriori informazioni sulla creazione di backup da utilizzare con la replica, vedere [http://dev.mysql.com/doc/refman/8.0/en/replication-solutions-backups-read-only.html](http://dev.mysql.com/doc/refman/8.0/en/replication-solutions-backups-read-only.html) nella documentazione di MySQL.
1. Nella console di gestione Amazon RDS aggiungi l'indirizzo IP del server che ospita il database MySQL di origine al gruppo di sicurezza VPC per il cluster di database Amazon Aurora. Per ulteriori informazioni sulla modifica di un gruppo di sicurezza VPC, consulta [Gruppi di sicurezza per il VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) nella *Guida per l'utente di Amazon Virtual Private Cloud*.
Potrebbe anche essere necessario configurare la rete locale per consentire le connessioni dall'indirizzo IP del cluster di database Amazon Aurora, affinché possa comunicare con l'istanza di MySQL di origine. Per individuare l'indirizzo IP del cluster di database Amazon Aurora, utilizzare il comando `host`.
```
host aurora_endpoint_address
```
Il nome host è il nome DNS dell'endpoint del cluster di database Amazon Aurora.
1. Utilizzando il client scelto, eseguire la connessione all'istanza di MySQL esterna e creare un utente MySQL da utilizzare per la replica. Questo account viene utilizzato unicamente per la replica e deve essere limitato al dominio personale per aumentare la sicurezza. Di seguito è riportato un esempio.
```
CREATE USER 'repl_user'@'example.com' IDENTIFIED BY 'password';
```
1. Per un'istanza di MySQL esterna, concedere i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE` all'utente della replica. Per concedere ad esempio i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE` su tutti i database per l'utente "`repl_user`" del proprio dominio, eseguire questo comando.
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'example.com'
IDENTIFIED BY 'password';
```
1. Acquisire uno snapshot manuale del cluster di database Aurora MySQL da impostare come replica di lettura prima di impostare la replica. Se è necessario ridefinire la replica con il cluster di database come replica di lettura, è possibile ripristinare il cluster di database Aurora MySQL da tale snapshot anziché dover importare i dati dall'istanza database MySQL in un nuovo cluster di database Aurora MySQL.
1. Configurare il cluster di database Amazon Aurora come replica. Esegui la connessione al cluster di database Amazon Aurora come utente master e identifica il database MySQL di origine come origine di replica utilizzando [mysql.rds\$1set\$1external\$1master (Aurora MySQL versione 2)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) o le procedure [mysql.rds\$1set\$1external\$1source (Aurora MySQL versione 3)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) e [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication).
Utilizza il nome e la posizione del file binlog, recuperati nella fase 2. Di seguito è riportato un esempio di :
```
For Aurora MySQL version 2:
CALL mysql.rds_set_external_master ('mymasterserver.example.com', 3306,
'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);
For Aurora MySQL version 3:
CALL mysql.rds_set_external_source ('mymasterserver.example.com', 3306,
'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);
```
1. Nel cluster di database Amazon Aurora chiama la procedura [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) per avviare la replica.
```
CALL mysql.rds_start_replication;
```
Dopo aver definito la replica tra l'istanza database MySQL di origine e il cluster di database Amazon Aurora sarà possibile aggiungere le repliche di Aurora al cluster di database Amazon Aurora. È possibile quindi connettere le repliche di Aurora per il dimensionamento della lettura dei dati. Per informazioni sulla creazione di una replica di Aurora, consulta [Aggiunta di repliche di Aurora a un cluster di database](aurora-replicas-adding.md).
# 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.
**Suggerimento**
Questa discussione presuppone che tu abbia familiarità con il meccanismo di replica dei log binari MySQL e del suo funzionamento. Per informazioni di base, consulta [Implementazione della replica](https://dev.mysql.com/doc/refman/8.0/en/replication-implementation.html) nella documentazione di 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 contro arresti imprevisti, ti consigliamo di abilitare la replica GTID sull'origine e di GTIDs consentirla 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](mysql-replication-gtid.md).
Le opzioni di configurazione seguenti consentono di ottimizzare la replica multithread. Per informazioni sull'utilizzo, consulta [Opzioni e variabili di replica e registrazione binaria](https://dev.mysql.com/doc/refman/8.0/en/replication-options.html) nel *Manuale di riferimento MySQL*. Per ulteriori informazioni sulla replica multithread, consulta il blog MySQL [https://dev.mysql.com/blog-archive/improving-the-parallel-applier-with-writeset-based-dependency-tracking/](https://dev.mysql.com/blog-archive/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:
+ `binlog_format recommended value` impostato su `ROW`
+ `binlog_group_commit_sync_delay`
+ `binlog_group_commit_sync_no_delay_count`
+ `binlog_transaction_dependency_history_size`
+ `binlog_transaction_dependency_tracking`, il valore consigliato è `WRITESET`
+ `replica_preserve_commit_order`
+ `replica_parallel_type`, il valore consigliato è `LOGICAL_CLOCK`
+ `replica_parallel_workers`
+ `replica_pending_jobs_size_max`
+ `transaction_write_set_extraction`, il valore consigliato è `XXHASH64`
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.
+ Assenza di chiavi primarie: RDS non è in grado di stabilire la dipendenza writeset per le tabelle senza chiavi primarie. Con il formato `ROW`, è possibile eseguire una singola istruzione su più righe con un’unica scansione completa della tabella sull’origine, ma si ottiene una scansione completa della tabella per ogni riga modificata sulla replica. L’assenza di chiavi primarie riduce in modo significativo il throughput di replica.
+ Presenza di chiavi esterne: se sono presenti chiavi esterne, Amazon RDS non può utilizzare la dipendenza writeset per il parallelismo delle tabelle con la relazione delle chiavi esterne.
+ Dimensione delle transazioni: se una singola transazione si estende su dozzine o centinaia di megabyte o gigabyte, il thread coordinatore e uno dei thread di lavoro potrebbero impiegare molto tempo solo per elaborare quella transazione. Durante questo periodo, tutti gli altri thread di lavoro potrebbero rimanere inattivi dopo aver completato l’elaborazione delle transazioni precedenti.
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 binlog alla replica dei log binari. I/O 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.
**Nota**
Questa memoria utilizzata per questa funzione è indipendente dall'impostazione `binlog_cache` MySQL.
Questa funzione non si applica alle istanze DB Aurora che utilizzano le classi di istanza `db.t2` e `db.t3`.
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.
Le variabili `aurora_binlog_io_cache_reads` di stato `aurora_binlog_io_cache_read_requests` aiutano a monitorare la frequenza con cui i dati vengono letti dalla cache binlog. I/O
+ `aurora_binlog_io_cache_read_requests`mostra il numero di richieste di I/O lettura binlog dalla cache.
+ `aurora_binlog_io_cache_reads`mostra il numero di I/O letture binlog che recuperano informazioni dalla cache.
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 funzionalità di I/O cache binlog include anche nuove metriche relative ai thread di dump 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. Questa metrica misura il ritardo del thread di replica. I/O 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 I/O prestazioni del relay log memorizzando nella cache tutto il contenuto del relay log intermedio in memoria. Di conseguenza, riduce la latenza di commit riducendo al minimo I/O le operazioni di archiviazione poiché il contenuto del relay log 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:
+ Modalità di replica a thread singolo (replica\$1parallel\$1workers = 0)
+ Replica multithread con modalità GTID abilitata:
+ Posizionamento automatico abilitato
+ Modalità GTID impostata su ON per la replica
+ Replica basata su file con replica\$1preserve\$1commit\$1order = ON
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\$1in\$1memory\$1relaylog, 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:
1. Arrestare la replica in corso
1. Impostare aurora\$1in\$1memory\$1relaylog su ON (per abilitare) o OFF (per disabilitare) nel gruppo di parametri
1. Riavviare la replica
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\$1in\$1memory\$1relaylog è 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.
# 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.
**Topics**
+ [
## Configurazione dei parametri del file di log binario avanzato
](#AuroraMySQL.Enhanced.binlog.enhancedbinlog.parameters)
+ [
## Altri parametri correlati
](#AuroraMySQL.Enhanced.binlog.other.parameters)
+ [
## Differenze tra file di log binario avanzato e file di log binario avanzato della community MySQL
](#AuroraMySQL.Enhanced.binlog.differences)
+ [
## Metriche Amazon CloudWatch per il file di log binario avanzato
](#AuroraMySQL.Enhanced.binlog.cloudwatch.metrics)
+ [
## Limitazioni del file di log binario avanzato
](#AuroraMySQL.Enhanced.binlog.limitations)
## 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\$1format | – | Impostare il parametro binlog\$1format sul formato di registrazione binaria desiderato per attivare il file di log binario avanzato. Assicurarsi che binlog\$1format parameter non sia impostato su OFF. Per ulteriori informazioni, consultare [Configurazione del log binario di Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_LogAccess.MySQL.BinaryFormat.html). |
| aurora\$1enhanced\$1binlog | 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\$1backup | 1 | Disattivare questo parametro per attivare il file di log binario avanzato. A tale scopo, impostare il valore di questo parametro su 0. |
| binlog\$1replication\$1globaldb | 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\$1enhanced\$1binlog | 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\$1backup | Attivare questo parametro quando si disattiva il file di log binario avanzato. A tale scopo, impostare il valore di questo parametro su 1. |
| binlog\$1replication\$1globaldb | 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](#AuroraMySQL.Enhanced.binlog.enhancedbinlog.parameters).
**Example 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)
```
**Example 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](#AuroraMySQL.Enhanced.binlog.enhancedbinlog.parameters).
**Example 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)
```
**Example 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 Supporto.
+ 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](binlog-optimization.md).
**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.