Configurazione del processo di replica dei log binari per Aurora MySQL - Amazon Aurora

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:

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.

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.

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.

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:

Utilizza le istruzioni seguenti per caricare il dump dell’origine di replica nella destinazione di replica per il motore di database.

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 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.

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
  1. Utilizzando un client MySQL, stabilisci una connessione al cluster di database Aurora MySQL di replica come utente master.

  2. 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 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_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.