Share via

Eseguire la migrazione di Database di Azure per MySQL - Server singolo a Database di Azure per MySQL - Server flessibile con strumenti open source

  • Articolo

È possibile eseguire la migrazione di un'istanza di Database di Azure per MySQL - Server singolo a Database di Azure per MySQL - Server flessibile con tempi di inattività minimi per le applicazioni usando una combinazione di strumenti open source come mydumper/myloader e replica dei dati in ingresso.

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.

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 le modifiche del database hanno origine) 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 e per eseguire gli eventi nell'accesso binario nel database locale della replica.

Se si configura la replica dei dati in ingresso per sincronizzare i dati da un'istanza di Database di Azure per MySQL a un'altra, è possibile eseguire un cutover selettivo delle applicazioni dal database primario (o di origine) alla replica (o al database di destinazione).

In questa esercitazione si userà la replica mydumper/myloader e Data-in per eseguire la migrazione di un database di esempio (modelli classici) da un'istanza di Database di Azure per MySQL - Server singolo a un'istanza di Database di Azure per MySQL - Server flessibile e quindi sincronizzare i dati.

In questa esercitazione apprenderai a:

  • Configurare Impostazioni di rete per la replica dei dati in per scenari diversi.
  • Configurare la replica dei dati tra la replica primaria e quella di .
  • Testare la replica.
  • Cutover per completare la migrazione.

Prerequisiti

Per completare questa esercitazione è necessario:

  • Istanza di Database di Azure per MySQL server singolo che esegue la versione 5.7 o 8.0.

    Nota

    Se si esegue Database di Azure per MySQL server singolo versione 5.6, aggiornare l'istanza alla versione 5.7 e quindi configurare i dati nella replica. Per altre informazioni, vedere Aggiornamento della versione principale in Database di Azure per MySQL - Server singolo.

  • Istanza di Database di Azure per MySQL server flessibile. Per altre informazioni, vedere l'articolo Creare un'istanza in Database di Azure per MySQL server flessibile.

    Nota

    La configurazione della replica dei dati in ingresso per i server a disponibilità elevata con ridondanza della zona non è supportata. Se si vuole avere la disponibilità elevata con ridondanza della zona per il server di destinazione, seguire questa procedura:

    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 GTID_Mode abbia la stessa impostazione nei server di origine e di destinazione.

  • Per connettersi e creare un database usando MySQL Workbench. Per altre informazioni, vedere l'articolo Usare MySQL Workbench per connettersi ed eseguire query sui dati.

  • Per assicurarsi di avere una macchina virtuale di Azure che esegue Linux nella stessa area (o nella stessa rete virtuale, con accesso privato) che ospita i database di origine e di destinazione.

  • Per installare il client mysql o MySQL Workbench (gli strumenti client) nella macchina virtuale di Azure. Assicurarsi di potersi connettere sia al server primario che al server di replica. Ai fini di questo articolo, viene installato il client mysql.

  • Per installare mydumper/myloader nella macchina virtuale di Azure. Per altre informazioni, vedere l'articolo mydumper/myloader.

  • Per scaricare ed eseguire lo script di database di esempio per il database classicmodels nel server di origine.

  • Configurare binlog_expire_logs_seconds nel server di origine per assicurarsi che i binlog non vengano eliminati prima che la replica esemetta le modifiche. Dopo aver completato correttamente il cut over, è possibile reimpostare il valore.

Configurare i requisiti di rete

Per configurare la replica dei dati in ingresso, è necessario assicurarsi che la destinazione possa connettersi all'origine sulla porta 3306. In base al tipo di endpoint configurato nell'origine, seguire questa procedura.

  • Se un endpoint pubblico è abilitato nell'origine, assicurarsi che la destinazione possa connettersi all'origine abilitando "Consenti l'accesso ai servizi di Azure" nella regola del firewall. Per altre informazioni, vedere Regole del firewall - Database di Azure per MySQL.
  • Se nell'origine è abilitato un endpoint privato e Nega accesso pubblico, installare il collegamento privato nella stessa rete virtuale che ospita la destinazione. Per altre informazioni, vedere collegamento privato - Database di Azure per MySQL.

Configurare la replica dei dati in ingresso

Per configurare i dati nella replica, seguire questa procedura:

  1. Accedere alla macchina virtuale di Azure in cui è stato installato lo strumento client mysql.

  2. Connessione all'origine e alla destinazione usando lo strumento client mysql.

  3. Usare lo strumento client mysql per determinare se log_bin è abilitato nell'origine eseguendo il comando seguente:

    SHOW VARIABLES LIKE 'log_bin';

    Nota

    Con Database di Azure per MySQL server singolo con l'archiviazione di grandi dimensioni, che supporta fino a 16 TB, questa opzione è abilitata per impostazione predefinita.

    Suggerimento

    Con Database di Azure per MySQL server singolo, che supporta fino a 4 TB, questa opzione non è abilitata per impostazione predefinita. Tuttavia, se si alza di livello una replica di lettura per il server di origine e quindi si elimina la replica di lettura, il parametro verrà impostato su ON.

  4. In base all'imposizione SSL per il server di origine, creare un utente nel server di origine con l'autorizzazione di replica eseguendo il comando appropriato.

    Se si usa SSL, eseguire il comando seguente:

    CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%' REQUIRE SSL;

    Se non si usa SSL, eseguire il comando seguente:

    CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%';

  5. Per eseguire il backup del database usando mydumper, eseguire il comando seguente nella macchina virtuale di Azure in cui è stato installato mydumper\myloader:

    mydumper --host=<primary_server>.mysql.database.azure.com --user=<username>@<primary_server> --password=<Password> --outputdir=./backup --rows=100000 -G -E -R -z --trx-consistency-only --compress --build-empty-files --threads=16 --compress-protocol --ssl  --regex '^(classicmodels\.)' -L mydumper-logs.txt

    Suggerimento

    L'opzione --trx-consistency-only è necessaria per la coerenza transazionale durante l'esecuzione del backup.

    • Equivalente mydumper di mysqldump --single-transaction.
    • Utile se tutte le tabelle sono InnoDB.
    • Il thread "main" deve contenere solo il blocco globale fino a quando i thread "dump" non possono avviare una transazione.
    • Offre la durata più breve del blocco globale

    Il thread "main" deve contenere solo il blocco globale fino a quando i thread "dump" non possono avviare una transazione.

    Le variabili in questo comando sono illustrate di seguito:

    HOW-TO-MANAGE-FIREWALL-PORTAL --host: Nome del server primario

    • --user: nome di un utente (nel formato username@servername poiché il server primario è in esecuzione Database di Azure per MySQL - Server singolo). È possibile usare l'amministratore del server o un utente con autorizzazioni edizione Standard LECT e RELOAD.
    • --Password: password dell'utente precedente

    Per altre informazioni sull'uso di mydumper, vedere mydumper/myloader

  6. Leggere il file di metadati per determinare il nome e l'offset del file di log binario eseguendo il comando seguente:

    cat ./backup/metadata

    In questo comando . /backup fa riferimento alla directory di output usata nel comando nel passaggio precedente.

    I risultati dovrebbero essere visualizzati come illustrato nell'immagine seguente:

    Continuous sync with the Azure Database Migration Service

    Assicurarsi di annotare il nome del file binario da usare nei passaggi successivi.

  7. Ripristinare il database usando myloader eseguendo il comando seguente:

    myloader --host=<servername>.mysql.database.azure.com --user=<username> --password=<Password> --directory=./backup --queries-per-transaction=100 --threads=16 --compress-protocol --ssl --verbose=3 -e 2>myloader-logs.txt

    Le variabili in questo comando sono illustrate di seguito:

    • --host: nome del server di replica
    • --user: nome di un utente. È possibile usare l'amministratore del server o un utente con autorizzazione di lettura/scrittura in grado di ripristinare gli schemi e i dati nel database
    • --Password: password per l'utente precedente

  8. A seconda dell'imposizione SSL nel server primario, connettersi al server di replica usando lo strumento client mysql e seguire questa procedura.

    • Se l'imposizione SSL è abilitata, procedere come illustrato di seguito:

      i. Scaricare il certificato necessario per comunicare tramite SSL con il server Database di Azure per MySQL da qui.

      ii. Aprire il file nel Blocco note e incollare il contenuto nella sezione "INSERIRE IL CONTESTO DEL CERTIFICATO DI CHIAVE PUBBLICA QUI".

      SET @cert = '-----BEGIN CERTIFICATE-----
PLACE YOUR PUBLIC KEY CERTIFICATE'S CONTEXT HERE
-----END CERTIFICATE-----'

      iii. Per configurare i dati nella replica, eseguire il comando seguente:

      CALL mysql.az_replication_change_master('<Primary_server>.mysql.database.azure.com', '<username>@<primary_server>', '<Password>', 3306, '<File_Name>', <Position>, @cert);

      Nota

      Determinare la posizione e il nome del file dalle informazioni ottenute nel passaggio 6.

    • Se l'imposizione SSL non è abilitata, eseguire il comando seguente:

      CALL mysql.az_replication_change_master('<Primary_server>.mysql.database.azure.com', '<username>@<primary_server>', '<Password>', 3306, '<File_Name>', <Position>, ‘’);

  9. Per avviare la replica dal server di replica, chiamare la stored procedure seguente.

    call  mysql.az_replication_start;

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

    show slave status \G;

    Nota

    Se si usa MySQL Workbench, il modificatore \G non è obbligatorio.

    Se lo stato di Slave_IO_Running e Slave_SQL_Running sono Sì e il valore di Seconds_Behind_Master è 0, la replica funziona correttamente. Seconds_Behind_Master indica la ritardo della replica. Se il valore è diverso da 0, la replica sta elaborando gli aggiornamenti.

Test della replica (facoltativo)

Per verificare che la replica dei dati in ingresso funzioni correttamente, è possibile verificare che le modifiche apportate alle tabelle nella replica primaria siano state replicate nella replica.

  1. Identificare una tabella da usare per il test, ad esempio la tabella Customers e quindi verificare che il numero di voci che contiene sia lo stesso nei server primario e di replica eseguendo il comando seguente in ognuno di essi:

    select count(*) from customers;

  2. Prendere nota del conteggio delle voci per un confronto successivo.

    Per testare la replica, provare ad aggiungere alcuni dati alle tabelle dei clienti nel server primario e verificare che i nuovi dati vengano replicati. In questo caso, si aggiungeranno due righe a una tabella nel server primario e quindi si conferma che vengono replicate nel server di replica.

  3. Nella tabella Customers del server primario inserire righe eseguendo il comando seguente:

    insert  into `customers`(`customerNumber`,`customerName`,`contactLastName`,`contactFirstName`,`phone`,`addressLine1`,`addressLine2`,`city`,`state`,`postalCode`,`country`,`salesRepEmployeeNumber`,`creditLimit`) values
(<ID>,'name1','name2','name3 ','11.22.5555','54, Add',NULL,'Add1',NULL,'44000','country',1370,'21000.00');

  4. Per controllare lo stato della replica, chiamare lo stato dello slave show \G per verificare che la replica funzioni come previsto.

  5. Per verificare che il conteggio sia lo stesso, nel server di replica eseguire il comando seguente:

    select count(*) from customers;

Assicurarsi che il cutover sia stato completato correttamente

Per garantire un cutover riuscito, eseguire le attività seguenti:

  1. Configurare il firewall a livello di server e le regole di rete virtuale in modo appropriato per connettersi al server di destinazione. È possibile confrontare le regole del firewall per l'origine e la destinazione dal portale.
  2. Configurare gli account di accesso e le autorizzazioni a livello di database appropriati nel server di destinazione. È possibile eseguire edizione Standard LECT FROM mysql.user; nei server di origine e di destinazione da confrontare.
  3. Assicurarsi che tutte le connessioni in ingresso a Database di Azure per MySQL server singolo siano arrestate.

    Suggerimento

    È possibile impostare la Database di Azure per MySQL server singolo su sola lettura.

  4. Verificare che la replica sia stata rilevata con la replica primaria eseguendo show slave status \G e confermando che il valore per il parametro Seconds_Behind_Master è 0.
  5. Reindirizzare client e applicazioni client all'istanza di destinazione di Database di Azure per MySQL server flessibile.
  6. Effettuare il cutover finale eseguendo la stored procedure mysql.az_replication_stop, che arresterà la replica del server di replica.
  7. Chiamare mysql.az_replication_remove_master per rimuovere la configurazione della replica dei dati in ingresso.

A questo punto, le applicazioni sono connesse al nuovo server flessibile Database di Azure per MySQL e le modifiche nell'origine non verranno più replicate nella destinazione. Creare e gestire regole del firewall di Database di Azure per MySQL con il portale di Azure

Passaggi successivi