Condividi tramite

Eseguire la migrazione di Amazon RDS per MySQL a Database di Azure per MySQL usando la replica dei dati in ingresso

  • Articolo

SI APPLICA A:Database di Azure per MySQL - Server singolo Database di Azure per MySQL - Server flessibile

Importante

Il server singolo del Database di Azure per MySQL è in fase di ritiro. È consigliabile eseguire l'aggiornamento al server flessibile del Database di Azure per MySQL. Per altre informazioni sulla migrazione a un server flessibile del Database di Azure per MySQL, vedere Che cosa sta succedendo al server singolo del Database di Azure per MySQL?

Nota

Questo articolo contiene riferimenti al termine slave, che Microsoft non usa più. Quando il termine verrà rimosso dal software, verrà rimosso anche dall'articolo.

È possibile usare metodi come il dump e il ripristino di MySQL, l'esportazione e l'importazione di MySQL Workbench oppure Servizio Migrazione del database di Azure per eseguire la migrazione dei database MySQL a Database di Azure per MySQL server flessibile. È possibile eseguire la migrazione dei carichi di lavoro con tempi di inattività minimi usando una combinazione di strumenti open source, ad esempio mysqldump o mydumper e myloader con replica dei dati in ingresso.

La replica dei dati in ingresso è una tecnica che replica le modifiche dei dati dal server di origine al server di destinazione in base al metodo di posizione del file di log binario. In questo scenario, l'istanza di MySQL che opera come origine (in cui ha origine le modifiche del database) scrive gli aggiornamenti e le modifiche come eventi nel log binario. Le informazioni nel log binario vengono archiviate in formati di registrazione diversi in base alle modifiche del database registrate. Le repliche sono configurate per leggere il log binario dall'origine ed eseguire gli eventi nel log binario nel database locale della replica.

Configurare Replica dati in ingresso per sincronizzare i dati da un server MySQL di origine a un server MySQL di destinazione. È possibile eseguire un cutover selettivo delle applicazioni dal database primario (o di origine) alla replica (o al database di destinazione).

In questa esercitazione si apprenderà come configurare la replica dei dati tra un server di origine che esegue Amazon Relational Database Service (RDS) per MySQL e un server di destinazione che esegue Database di Azure per MySQL server flessibile.

Considerazioni sulle prestazioni

Prima di iniziare questa esercitazione, prendere in considerazione le implicazioni sulle prestazioni della posizione e la capacità del computer client che verrà usato per eseguire l'operazione.

Posizione del client

Eseguire operazioni di dump o ripristino da un computer client avviato nella stessa posizione del server di database:

  • Per Database di Azure per MySQL istanze del server flessibile, il computer client deve trovarsi nella stessa rete virtuale e nella stessa zona di disponibilità del server di database di destinazione.
  • Per le istanze di database Amazon RDS di origine, l'istanza del client deve essere presente nella stessa zona di cloud privato virtuale Amazon e nella stessa zona di disponibilità del server di database di origine. Nel caso precedente, è possibile spostare i file di dump tra computer client usando protocolli di trasferimento file come FTP o SFTP o caricarli in Archiviazione BLOB di Azure. Per ridurre il tempo totale di migrazione, comprimere i file prima di trasferirli.

Capacità client

Indipendentemente dal punto in cui si trova il computer client, richiede un'adeguata capacità di elaborazione, I/O e di rete per eseguire le operazioni richieste. Le raccomandazioni generali sono:

  • Se il dump o il ripristino comporta l'elaborazione in tempo reale dei dati, ad esempio la compressione o la decompressione, scegliere una classe di istanza con almeno un core CPU per ogni thread di dump o ripristino.
  • Verificare che sia disponibile una larghezza di banda di rete sufficiente per l'istanza del client. Usare i tipi di istanza che supportano la funzionalità di rete accelerata. Per altre informazioni, vedere la sezione "Rete accelerata" nella guida alla rete di macchine virtuali di Azure.
  • Assicurarsi che il livello di archiviazione del computer client fornisca la capacità di lettura/scrittura prevista. È consigliabile usare una macchina virtuale di Azure con archiviazione SSD Premium.

Prerequisiti

Per completare questa esercitazione, è necessario:

  • Installare mysqlclient nel computer client per creare un dump ed eseguire un'operazione di ripristino nell'istanza del server flessibile Database di Azure per MySQL di destinazione.

  • Per i database di dimensioni maggiori, installare mydumper e myloader per il dump parallelo e il ripristino dei database.

    Nota

    Mydumper può essere eseguito solo nelle distribuzioni Linux. Per altre informazioni, vedere Come installare mydumper.

  • Creare un'istanza di Database di Azure per MySQL server flessibile che esegue la versione 5.7 o 8.0.

    Importante

    Se la destinazione è Database di Azure per MySQL server flessibile con disponibilità elevata con ridondanza della zona, si noti che la replica dei dati in ingresso non è supportata per questa configurazione. Come soluzione alternativa, durante la creazione del server configurare la disponibilità elevata con ridondanza della zona:

    1. Creare il server con disponibilità elevata con ridondanza della zona abilitata.
    2. Disabilitare la disponibilità elevata.
    3. Seguire l'articolo per configurare la replica dei dati in ingresso.
    4. Dopo il cutover, rimuovere la configurazione della replica dei dati in ingresso.
    5. Abilitare la disponibilità elevata.

Assicurarsi che siano configurati e impostati correttamente diversi parametri e funzionalità, come descritto di seguito:

  • Per motivi di compatibilità, disporre dei server di database di origine e di destinazione nella stessa versione di MySQL.
  • Avere una chiave primaria in ogni tabella. La mancanza di chiavi primarie nelle tabelle può rallentare il processo di replica.
  • Assicurarsi che il set di caratteri dell'origine e del database di destinazione siano uguali.
  • Impostare il parametro wait_timeout su un tempo ragionevole. Il tempo dipende dalla quantità di dati o carico di lavoro di cui si vuole importare o eseguire la migrazione.
  • Verificare che tutte le tabelle usino InnoDB. Database di Azure per MySQL server flessibile supporta solo il motore di archiviazione InnoDB.
  • Per le tabelle con molti indici secondari o tabelle di grandi dimensioni, gli effetti di overhead delle prestazioni sono visibili durante il ripristino. Modificare i file di dump in modo che le istruzioni CREATE TABLE non includano definizioni di chiave secondaria. Dopo aver importato i dati, ricreare gli indici secondari per evitare la riduzione delle prestazioni durante il processo di ripristino.

Infine, per preparare la replica dei dati in ingresso:

  • Verificare che la destinazione Database di Azure per MySQL'istanza del server flessibile possa connettersi al server Amazon RDS per MySQL di origine sulla porta 3306.
  • Assicurarsi che il server Amazon RDS per MySQL di origine consenta il traffico in ingresso e in uscita sulla porta 3306.
  • Assicurarsi di fornire la connettività da sito a sito al server di origine usando Azure ExpressRoute o il gateway VPN di Azure. Per altre informazioni sulla creazione di una rete virtuale, vedere la documentazione relativa alla rete virtuale di Azure. Vedere anche gli articoli di avvio rapido con informazioni dettagliate.
  • Configurare i gruppi di sicurezza di rete del server di database di origine per consentire l'indirizzo IP del server flessibile di destinazione Database di Azure per MySQL.

Importante

Se l'istanza di Amazon RDS per MySQL di origine è GTID_mode impostata su ON, anche l'istanza di destinazione di Database di Azure per MySQL server flessibile deve avere GTID_mode impostato su ON.

Configurare l'istanza di destinazione di Database di Azure per MySQL

Per configurare l'istanza di destinazione di Database di Azure per MySQL server flessibile, che è la destinazione per la replica dei dati in ingresso:

  1. Impostare il valore del parametro max_allowed_packet sul valore massimo di 1073741824, ovvero 1 GB. Questo valore impedisce eventuali problemi di overflow correlati alle righe lunghe.

  2. Impostare i parametri slow_query_log, general_log, audit_log_enabled e query_store_capture_mode su OFF durante la migrazione per eliminare eventuali sovraccarichi correlati alla registrazione delle query.

  3. Aumentare le dimensioni di calcolo della destinazione Database di Azure per MySQL'istanza del server flessibile fino a un massimo di 64 vCore. Questa dimensione offre più risorse di calcolo durante il ripristino del dump del database del server di origine.

    È sempre possibile ridurre il numero di risorse di calcolo per soddisfare le esigenze dell'applicazione al termine della migrazione.

  4. Aumentare le dimensioni di archiviazione per ottenere più operazioni di I/O al secondo durante la migrazione o aumentare il numero massimo di operazioni di I/O al secondo per la migrazione.

    Nota

    Le operazioni di I/O al secondo disponibili sono determinate dalle dimensioni di calcolo. Per altre informazioni, vedere la sezione Operazioni di I/O al secondo in Opzioni di calcolo e archiviazione in Database di Azure per MySQL server flessibile.

Configurare il server Amazon RDS per MySQL di origine

Per preparare e configurare il server MySQL ospitato in Amazon RDS, ovvero l'origine per la replica dei dati in ingresso:

  1. Verificare che la registrazione binaria sia abilitata nel server Amazon RDS per MySQL di origine. Verificare che i backup automatizzati siano abilitati o assicurarsi che esista una replica di lettura per il server Amazon RDS per MySQL di origine.

  2. Assicurarsi che i file di log binari nel server di origine vengano mantenuti fino a quando non vengono applicate le modifiche nell'istanza di destinazione di Database di Azure per MySQL server flessibile.

    Con la replica dei dati in ingresso, Database di Azure per MySQL server flessibile non gestisce il processo di replica.

  3. Per controllare la conservazione dei log binari nel server Amazon RDS di origine per determinare il numero di ore di conservazione dei log binari, chiamare la stored procedure mysql.rds_show_configuration:

    mysql> call mysql.rds_show_configuration;
+------------------------+-------+-----------------------------------------------------------------------------------------------------------+
| name | value | description |
+------------------------+-------+-----------------------------------------------------------------------------------------------------------+
| binlog retention hours | 24 | binlog retention hours specifies the duration in hours before binary logs are automatically deleted. |
| source delay | 0 | source delay specifies replication delay in seconds between current instance and its master. |
| target delay | 0 | target delay specifies replication delay in seconds between current instance and its future read-replica. |
+------------------------+-------            +-----------------------------------------------------------------------------------------------------------+
3 rows in set (0.00 sec)

  4. Per configurare il periodo di conservazione dei log binari, eseguire la stored procedure rds_set_configuration per assicurarsi che i log binari vengano conservati nel server di origine per il tempo desiderato. Ad esempio:

    Mysql> Call mysql.rds_set_configuration(‘binlog retention hours', 96);

    Se si sta creando un dump e il ripristino, il comando precedente consente di recuperare rapidamente le modifiche differenziali.

    Nota

    Assicurarsi che lo spazio su disco sia ampio per archiviare i log binari nel server di origine in base al periodo di conservazione definito.

Esistono due modi per acquisire un dump dei dati dal server Amazon RDS per MySQL di origine. Un approccio prevede l'acquisizione di un dump dei dati direttamente dal server di origine. L'altro approccio prevede l'acquisizione di un dump da una replica in lettura Amazon RDS per MySQL.

  • Per acquisire un dump dei dati direttamente dal server di origine:

    1. Assicurarsi di arrestare le scritture dall'applicazione per alcuni minuti per ottenere un dump dei dati coerente in modo transazionale.

      È anche possibile impostare temporaneamente il parametro read_only su un valore 1 in modo che le scritture non vengano elaborate quando si acquisisce un dump dei dati.

    2. Dopo aver arrestato le scritture nel server di origine, raccogliere il nome e l'offset del file di log binari eseguendo il comando Mysql> Show master status;.

    3. Salvare questi valori per avviare la replica dall'istanza del server flessibile Database di Azure per MySQL.

    4. Per creare un dump dei dati, eseguire mysqldump eseguendo il comando seguente:

      $ mysqldump -h hostname -u username -p –single-transaction –databases dbnames –order-by-primary> dumpname.sql

  • Se l'arresto delle scritture nel server di origine non è un'opzione o le prestazioni dei dati di dump non sono accettabili nel server di origine, acquisire un dump in un server di replica:

    1. Creare una replica in lettura Amazon MySQL con la stessa configurazione del server di origine. Creare quindi il dump.

    2. Consentire alla replica in lettura Amazon RDS per MySQL di recuperare il server Amazon RDS per MySQL di origine.

    3. Quando il ritardo della replica raggiunge 0 nella replica in lettura, arrestare la replica chiamando la stored procedure mysql.rds_stop_replication.

      Mysql> call mysql.rds_stop_replication;

    4. Con la replica arrestata, connettersi alla replica. Eseguire quindi il comando SHOW SLAVE STATUS per recuperare il nome del file di log binario corrente dal campo Relay_Master_Log_File e dalla posizione del file di log dal campo Exec_Master_Log_Pos.

    5. Salvare questi valori per avviare la replica dall'istanza del server flessibile Database di Azure per MySQL.

    6. Per creare un dump dei dati dalla replica di lettura Amazon RDS per MySQL, eseguire mysqldump eseguendo il comando seguente:

      $ mysqldump -h hostname -u username -p –single-transaction –databases dbnames –order-by-primary> dumpname.sql

    Nota

    È anche possibile usare mydumper per acquisire un dump parallelizzato dei dati dal database Amazon RDS per MySQL di origine. Per altre informazioni, vedere Eseguire la migrazione di database di grandi dimensioni a Database di Azure per MySQL server flessibile tramite mydumper/myloader.

  1. Per ripristinare il database usando il ripristino nativo mysql, eseguire il comando seguente:

    $ mysql -h <target_server> -u <targetuser> -p < dumpname.sql

    Nota

    Se invece si usa myloader, vedere Eseguire la migrazione di database di grandi dimensioni a Database di Azure per MySQL server flessibile usando mydumper/myloader.

  2. Accedere al server Amazon RDS per MySQL di origine e configurare un utente di replica. Concedere quindi i privilegi necessari all'utente.

    • Se si usa SSL, eseguire i comandi seguenti:

      Mysql> CREATE USER 'syncuser'@'%' IDENTIFIED BY 'userpassword';
Mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT on *.* to 'syncuser'@'%' REQUIRE SSL;
Mysql> SHOW GRANTS FOR syncuser@'%';

    • Se non si usa SSL, eseguire i comandi seguenti:

      Mysql> CREATE USER 'syncuser'@'%' IDENTIFIED BY 'userpassword';
Mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT on *.* to 'syncuser'@'%';
Mysql> SHOW GRANTS FOR syncuser@'%';

    Le stored procedure eseguono tutte le funzioni di replica dei dati in ingresso. Per informazioni su tutte le procedure, vedere Stored procedure di replica dei dati in ingresso. È possibile eseguire queste stored procedure nella shell MySQL o in MySQL Workbench.

  3. Per collegare il server di origine Amazon RDS per MySQL e il server di destinazione server flessibile Database di Azure per MySQL, accedere all'istanza del server flessibile Database di Azure per MySQL di destinazione. Impostare il server Amazon RDS per MySQL come server di origine eseguendo il comando seguente:

    CALL mysql.az_replication_change_master('source_server','replication_user_name','replication_user_password',3306,'<master_bin_log_file>',master_bin_log_position,'<master_ssl_ca>');

  4. Per avviare la replica tra il server Amazon RDS per MySQL di origine e l'istanza del server flessibile di destinazione Database di Azure per MySQL, eseguire il comando seguente:

    Mysql> CALL mysql.az_replication_start;

  5. Per controllare lo stato della replica nel server di replica, eseguire il comando seguente:

    Mysql> show slave status\G

    Se lo stato dei parametri Slave_IO_Running e Slave_SQL_Running è Sì, la replica è stata avviata ed è in esecuzione.

  6. Controllare il valore del parametro Seconds_Behind_Master per determinare il ritardo del server di destinazione.

    Se il valore è 0, la destinazione ha elaborato tutti gli aggiornamenti dal server di origine. Se il valore è diverso da 0, il server di destinazione sta ancora elaborando gli aggiornamenti.

Assicurarsi che il cutover sia stato completato correttamente

Per garantire un cutover riuscito:

  1. Configurare gli account di accesso appropriati e le autorizzazioni a livello di database nell'istanza del server flessibile Database di Azure per MySQL di destinazione.
  2. Arrestare le scritture nel server Amazon RDS per MySQL di origine.
  3. Assicurarsi che la destinazione Database di Azure per MySQL'istanza del server flessibile sia stata rilevata con il server di origine e che il Seconds_Behind_Master valore sia 0 da show slave status.
  4. Chiamare la stored procedure mysql.az_replication_stop per arrestare la replica perché tutte le modifiche sono state replicate nell'istanza del server flessibile Database di Azure per MySQL di destinazione.
  5. Chiamare mysql.az_replication_remove_master per rimuovere la configurazione della replica dei dati in ingresso.
  6. Reindirizzare client e applicazioni client all'istanza del server flessibile di Database di Azure per MySQL di destinazione.

A questo punto, la migrazione è stata completata. Le applicazioni sono connesse al server che esegue Database di Azure per MySQL server flessibile.

Passaggi successivi