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à. # 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: + Abilitare i backup automatici per l'istanza database. È possibile abilitare i backup automatici quando si crea un'istanza database o si possono abilitare i backup modificando un'istanza database esistente. Per ulteriori informazioni, consulta la pagina relativa alla [creazione di un'istanza database](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateDBInstance.html) nella *Guida per l'utente di Amazon RDS*.
+ Crea una replica di lettura per l'istanza database. Per ulteriori informazioni, consulta [Uso di repliche di lettura](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) nella *Guida per l'utente di Amazon RDS*. | | 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: + Secure Sockets Layer (SSL) deve essere abilitato su un database master MySQL esterno.
+ Una chiave e un certificato client devono essere preparati per il cluster di database Aurora MySQL.
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. 1. Assicurati di essere preparato per la replica crittografata: Se SSL non è abilitato sul database MySQL fonte esterno e non si dispone di una chiave client e di un certificato client preparato, abilitare SSL sul server di database MySQL e generare la chiave client e il certificato client necessari. Se SSL è abilitato sul master esterno, fornisci un certificato e una chiave client per il cluster di database Aurora MySQL. Se non disponi di questi elementi, genera una nuova chiave e un nuovo certificato per il cluster di database Aurora MySQL. Per firmare il certificato client, devi avere la chiave autorità certificato che hai utilizzato per configurare SSL nel database master esterno MySQL.
Per ulteriori informazioni, consulta [Creating SSL Certificates and Keys Using openssl](https://dev.mysql.com/doc/refman/8.0/en/creating-ssl-files-using-openssl.html) nella documentazione MySQL.
Hai bisogno del certificato autorità certificato, della chiave client e del certificato client.
2. Connettersi al cluster di database Aurora MySQL come il master utilizzando SSL.
Per informazioni sulla connessione a un cluster di database Aurora MySQL con SSL, consulta [Connessioni TLS a cluster di database Aurora MySQL](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL).
3. Esegui la procedura archiviata `mysql.rds_import_binlog_ssl_material` per importare le informazioni SSL nel cluster di database Aurora MySQL.
Per il parametro `ssl_material_value` inserisci le informazioni dai file in formato .pem per il cluster di database Aurora MySQL nel payload JSON corretto.
L'esempio seguente importa le informazioni SSL in un cluster di database Aurora MySQL. Nei file in formato .pem, il codice del corpo è in genere più lungo del codice del corpo riportato nell'esempio. 
call mysql.rds_import_binlog_ssl_material(
'{"ssl_ca":"-----BEGIN CERTIFICATE-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END RSA PRIVATE KEY-----\n"}');

Per ulteriori informazioni, consultare [mysql.rds\_import\_binlog\_ssl\_material](mysql-stored-proc-replicating.md#mysql_rds_import_binlog_ssl_material) e [Connessioni TLS a cluster di database Aurora MySQL](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL). Dopo aver eseguito la procedura, i segreti vengono archiviati in file. Per eliminare i file in un secondo momento, puoi eseguire la stored procedure [mysql.rds\_remove\_binlog\_ssl\_material](mysql-stored-proc-replicating.md#mysql_rds_remove_binlog_ssl_material).
**Per abilitare l'accesso binario a un database esterno MySQL** 1. Da un shell comando, interrompi il servizio mysql. 
sudo service mysqld stop

2. Modificare il file `my.cnf` (posto in genere sotto `/etc`). 
sudo vi /etc/my.cnf

Aggiungere le opzioni `log_bin` e `server_id` alla sezione `[mysqld]`. L'opzione `log_bin` fornisce un identificatore di nome file per i file di log binari. L'opzione `server_id` fornisce un identificatore univoco per il server in relazioni master-replica.
Se la replica crittografata non è necessaria, assicurarsi che il database MySQL esterno venga avviato con binlog abilitati e SSL disabilitato.
Seguono le voci rilevanti nel file `/etc/my.cnf` per dati non crittografati. 
log-bin=mysql-bin
server-id=2133421
innodb_flush_log_at_trx_commit=1
sync_binlog=1

Se la replica crittografata è necessaria, assicurati che il database MySQL esterno venga avviato con SSL e i binlog abilitati.
Le voci rilevanti nel file `/etc/my.cnf` includono le posizioni del file .pem per il server di database MySQL. 
log-bin=mysql-bin
server-id=2133421
innodb_flush_log_at_trx_commit=1
sync_binlog=1

# Setup SSL.
ssl-ca=/home/sslcerts/ca.pem
ssl-cert=/home/sslcerts/server-cert.pem
ssl-key=/home/sslcerts/server-key.pem

In aggiunta, l'opzione `sql_mode` per l'istanza database MySQL deve essere impostata su 0 o non deve essere inclusa nel file my.cnf.
Durante la connessione al database esterno MySQL, registra la posizione del log binario del database esterno MySQL. 
mysql> SHOW MASTER STATUS;

L'output visualizzato dovrebbe essere simile al seguente: 
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000031 |      107 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

Per ulteriori informazioni, vedere [Setting the replication source configuration](http://dev.mysql.com/doc/refman/8.0/en/replication-howto-masterbaseconfig.html) nella documentazione di MySQL.
3. Avvia il servizio mysql. 
sudo service mysqld start
| ## 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\_set\_configuration](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\_stop\_replication](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:+ Ripristino da uno snapshot di un cluster di database: Crea una snapshot di un cluster di database del cluster di database Amazon Aurora. Per ulteriori informazioni, consulta [Creazione di uno snapshot del cluster database](USER_CreateSnapshotCluster.md). Crea un nuovo cluster di database Aurora ripristinandolo dalla snapshot cluster di database che hai appena creato.
Assicurati di mantenere il gruppo di parametri database per il cluster di database ripristinato come con il cluster di database originale. Ciò assicura che la copia del cluster di database abbia l'accesso binario abilitato. Per ulteriori informazioni, consulta [Ripristino da uno snapshot cluster database](aurora-restore-snapshot.md).
+ Clona il tuo cluster di database. Per ulteriori informazioni, consulta [Clonazione di un volume per un cluster di database Amazon Aurora](Aurora.Managing.Clone.md).
**Come determinare il nome e la posizione del file binlog**
Seleziona uno dei seguenti metodi:+ Nel Console di gestione AWS: Scegli **Database**, quindi scegli l’istanza primaria (di scrittura) per fare in modo che il nuovo cluster di database Aurora mostri i dettagli. Scorri fino a **Recent Events (Eventi recenti)**. Viene visualizzato un messaggio di evento che include il nome e la posizione del file binlog. Il messaggio evento è nel formato seguente. 
Binlog position from crash recovery is {{binlog-file-name}} {{binlog-position}}
Salva i valori del nome e della posizione del file binlog per quando avvierai la replica.
+ Chiamate il AWS CLI comando [describe-events](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-events.html), come nell'esempio seguente. 
aws rds describe-events

{
    "Events": [
        {
            "EventCategories": [],
            "SourceType": "db-instance",
            "SourceArn": "arn:aws:rds:us-west-2:123456789012:db:sample-restored-instance",
            "Date": "2016-10-28T19:43:46.862Z",
            "Message": "Binlog position from crash recovery is mysql-bin-changelog.000003 4278",
            "SourceIdentifier": "sample-restored-instance"
        }
    ]
}

+ Controlla nel log degli errori di MySQL l’ultima posizione del file binlog MySQL.
**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.1. Effettua la connessione al tuo cluster di database utilizzando un client MySQL.
2. Emetti il comando `mysqldump`. Esempio: 
PROMPT> mysqldump --databases {{database_name}} --single-transaction
--order-by-primary -r backup.sql -u {{local_user}}s -p

3. Dopo aver creato il file dump, puoi eliminare la copia del cluster di database. | | 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*. 1. Esegui la connessione alla replica di lettura e interrompi la replica eseguendo la procedura [mysql.rds\_stop\_replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication).
2. Mentre la replica di lettura è **Arrestata**, esegui la connessione alla replica di lettura e quindi il comando `SHOW SLAVE STATUS` (Aurora MySQL versione 2) o `SHOW REPLICA STATUS` (Aurora MySQL versione 3). Recupera il nome dei file di log binario corrente dal campo `Relay_Master_Log_File` e la posizione del file di log dal campo `Exec_Master_Log_Pos`. Salva questi valori per quando avvierai la replica.
3. Mentre la replica di lettura rimane nello stato **Stopped (Interrotto)**, crea una snapshot DB di una replica di lettura. Per ulteriori informazioni, consulta [Creazione di uno snapshot DB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html) nella *Guida per l'utente di Amazon Relational Database Service*.
4. Elimina la replica di lettura. | | MySQL (esterno) | **Per creare il dump di un database MySQL esterno**1. Prima di creare un dump, devi assicurarti che la posizione del binlog per il dump sia aggiornata con i dati nell'istanza di origine. Per fare ciò, devi prima fermare qualsiasi operazione di scrittura all'istanza con il seguente comando: 
mysql> FLUSH TABLES WITH READ LOCK;

2. Crea un dump di un database MySQL utilizzando il comando `mysqldump` come illustrato di seguito: 
PROMPT> sudo mysqldump --databases {{database_name}} --master-data=2  --single-transaction \
--order-by-primary -r backup.sql -u {{local_user}} -p

3. Dopo aver creato il dump, sblocca le tabelle nel database MySQL con il seguente comando: 
mysql> UNLOCK TABLES;
| ## 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** 1. Copia l'output del comando `mysqldump` dal master di replica in una posizione che può anche connettersi al cluster di database Aurora MySQL.
2. Connettersi al cluster di database Aurora MySQL utilizzando il comando `mysql`. Di seguito è riportato un esempio. 
PROMPT> mysql -h {{host_name}} -port=3306 -u {{db_master_user}} -p

3. Al prompt `mysql`, esegui il comando `source` e passagli il nome del file dump del database per caricare i dati nel cluster di database Aurora MySQL, ad esempio: 
mysql> source backup.sql;
| | RDS per MySQL | **Per caricare un dump in un'istanza database Amazon RDS**1. Copia l'output del comando `mysqldump` dal master di replica in una posizione che può anche connettersi all'istanza database MySQL.
2. Connettersi all'istanza database MySQL utilizzando il comando `mysql`. Di seguito è riportato un esempio. 
PROMPT> mysql -h {{host_name}} -port=3306 -u {{db_master_user}} -p

3. Al prompt `mysql`, esegui il comando `source` e passagli il nome del file dump del database per caricare i dati nell'istanza database MySQL, ad esempio: 
mysql> source backup.sql;
| | 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`.1. Copia l'output del comando `mysqldump` dal master di replica in una posizione che può anche connettersi al database MySQL.
2. Connettersi al database MySQL utilizzando il comando `mysql`. Di seguito è riportato un esempio. 
PROMPT> mysql -h {{host_name}} -port=3306 -u {{db_master_user}} -p

3. Al prompt `mysql`, esegui il comando `source` e passagli il nome del file dump del database per caricare i dati nel database MySQL. Di seguito è riportato un esempio. 
mysql> source backup.sql;
| ## 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\_name\_resolve](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** 1. Individua il punto di partenza per la replica. Hai bisogno del nome e della posizione del file binlog.
Se la destinazione della replica del cluster di database è stata creata da: Snapshot o clone del cluster di database: recupera il nome e la posizione del file binlog dagli eventi recenti per il tuo nuovo cluster di database, come mostrato in [3. Creazione di una copia o un dump dell’origine della replica](#AuroraMySQL.Replication.MySQL.CreateSnapshot). Snapshot di database: hai recuperato il nome e la posizione del file binlog con il comando `SHOW SLAVE STATUS` (Aurora MySQL versione 2) o `SHOW REPLICA STATUS` (Aurora MySQL versione 3) quando hai creato lo snapshot dell'origine della replica.
2. Connettiti al cluster di database e richiama le seguenti procedure per avviare la replica con l'origine utilizzando il nome e il percorso del file di log binario del passaggio precedente: [mysql.rds\_set\_external\_source (Aurora MySQL versione 3)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) [mysql.rds\_set\_external\_master (Aurora MySQL versione 2)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) [mysql.rds\_start\_replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) (tutte le versioni)
L'esempio seguente si applica ad Aurora MySQL versione 3. 
CALL mysql.rds_set_external_source ('mydbinstance.123456789012.us-east-1.rds.amazonaws.com', 3306,
    'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);
CALL mysql.rds_start_replication;

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** 1. Se il target di replica dell'istanza database è stato creato da una snapshot DB, hai bisogno del file e della posizione binlog che sono il punto di partenza per la replica. Hai recuperato questi valori con il comando `SHOW SLAVE STATUS` (Aurora MySQL versione 2) o `SHOW REPLICA STATUS` (Aurora MySQL versione 3), quando hai creato lo snapshot dell'origine della replica.
2. Esegui la connessione all'istanza database e chiama le procedure [mysql.rds\_set\_external\_master (Aurora MySQL versione 2)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) o [mysql.rds\_set\_external\_source (Aurora MySQL versione 3)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) e [mysql.rds\_start\_replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) per avviare la replica con l'origine. Utilizza il nome e il percorso del file di log binario del passaggio precedente. Di seguito è riportato un esempio di : 
CALL mysql.rds_set_external_master ('mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com', 3306,
    'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);
CALL mysql.rds_start_replication;

Per utilizzare la crittografia SSL, imposta il valore finale su `1` anziché `0`. | | MySQL (esterno) | **Per abilitare la replica da un database esterno MySQL;** 1. Recupera il file e la posizione binlog che sono il punto di inizio per la replica. Hai recuperato questi valori con il comando `SHOW SLAVE STATUS` (Aurora MySQL versione 2) o `SHOW REPLICA STATUS` (Aurora MySQL versione 3), quando hai creato lo snapshot dell'origine della replica. Se il target di replica MySQL esterno è stato popolato dall'output del comando `mysqldump` con l'opzione `--master-data=2`, il file e la posizione binlog sono inclusi nell'output. Di seguito è riportato un esempio di : 
--
-- Position to start replication or point-in-time recovery from
--

-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000031', MASTER_LOG_POS=107;

2. Esegui la connessione alla destinazione della replica MySQL esterna ed emetti `CHANGE MASTER TO` e `START SLAVE` (Aurora MySQL versione 2) o `START REPLICA` (Aurora MySQL versione 3) per avviare la replica con l'origine della replica utilizzando il nome e il percorso del file di log binario dalla fase precedente, ad esempio: 
CHANGE MASTER TO
  MASTER_HOST = 'mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com',
  MASTER_PORT = 3306,
  MASTER_USER = 'repl_user',
  MASTER_PASSWORD = 'password',
  MASTER_LOG_FILE = 'mysql-bin-changelog.000031',
  MASTER_LOG_POS = 107;
-- And one of these statements depending on your engine version:
START SLAVE; -- Aurora MySQL version 2
START REPLICA; -- Aurora MySQL version 3
| 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\_reset\_external\_master (Aurora MySQL versione 2)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) o [mysql.rds\_reset\_external\_source (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\_start\_replication\_until(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\_start\_replication\_until(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 GTID-based replica, utilizzare la stored procedure anziché la [mysql.rds\_start\_replication\_until\_gtid (Aurora MySQL versione 3)](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) stored procedure. [mysql.rds\_start\_replication\_until(Aurora MySQL versione 3)](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) Per ulteriori informazioni sulla GTID-based replica, vedere. [Utilizzo della GTID-based replica](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.