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:
Indice
2. Mantieni i log binari nel master di replica fino a quando non sono più necessari
3. Creazione di una copia o un dump dell’origine della replica
4. Caricamento del dump nella destinazione di replica (se necessario)
5. Creazione di un utente di replica sull’origine di replica
Sincronizzazione delle password tra origine di replica e destinazione
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 Per modificare il parametro Se stai modificando il parametro Per ulteriori informazioni, consultare Parametri dell’istanza database e del cluster database di Amazon Aurora e Gruppi di parametri per Amazon Aurora. |
|
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:
|
|
MySQL (esterno) |
Per impostare la replica crittografata Per replicare i dati in maniera sicura con Aurora MySQL versione 2, puoi utilizzare la replica crittografata. NotaSe non hai bisogno di utilizzare la replica crittografata, puoi saltare queste fasi. Seguono i prerequisiti per l'utilizzo della replica crittografata:
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.
Per abilitare l'accesso binario a un database esterno MySQL
|
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 e specifica il parametro di configurazione L'esempio seguente imposta il periodo di conservazione dei file binlog su 6 giorni:
Dopo l'inizio della replica, è possibile verificare che le modifiche siano state applicate alla replica eseguendo il comando Se questa impostazione non è specificata, verrà utilizzato il valore predefinito per Aurora MySQL ovvero 24 (1 giorno). Se si specifica un valore per |
|
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 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 |
|
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 |
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:
Come determinare il nome e la posizione del file binlog Seleziona uno dei seguenti metodi:
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
|
|
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 nella Guida per l'utente di Amazon Relational Database Service.
|
|
MySQL (esterno) |
Per creare il dump di un database MySQL esterno
|
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.
-
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.
-
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.
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
|
|
RDS per MySQL |
Per caricare un dump in un'istanza database Amazon RDS
|
|
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
|
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
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
Per utilizzare la crittografia SSL, imposta il valore finale su |
|
RDS per MySQL |
Per abilitare la replica da un'istanza database Amazon RDS
Per utilizzare la crittografia SSL, imposta il valore finale su |
|
MySQL (esterno) |
Per abilitare la replica da un database esterno MySQL;
|
Se la replica ha esito negativo, può verificarsi un notevole aumento di I/O non intenzionale sulla replica, che può compromettere le prestazioni. Se la replica non riesce o non è più necessaria, è possibile eseguire la stored procedure mysql.rds_reset_external_master (Aurora MySQL versione 2) o mysql.rds_reset_external_source (Aurora MySQL versione 3) 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).
Per avviare la replica su una replica di lettura e arrestare la replica in corrispondenza di una posizione specifica
-
Utilizzando un client MySQL, stabilisci una connessione al cluster di database Aurora MySQL di replica come utente master.
-
Eseguire la procedura archiviata mysql.rds_start_replication_until (Aurora MySQL versione 3).
L'esempio seguente avvia la replica e replica le modifiche fino a raggiungere la posizione
120nel file di log binariomysql-bin-changelog.000777. In caso di disaster recovery, presumere che la posizione120si 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_start_replication_until_gtid (Aurora MySQL versione 3) invece della mysql.rds_start_replication_until (Aurora MySQL versione 3). Per ulteriori informazioni sulla replica basata su GTID, consultare Utilizzo della replica basata su GTID.
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.
È 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 utilizzi la Console di gestione AWS, la AWS CLIo l'API RDS per modificare la password principale nell'origine di 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.