Dela via

Migrera Azure Database for MySQL – enskild server till Azure Database for MySQL – flexibel server med verktyg med öppen källkod

  • Artikel

Du kan migrera en instans av Azure Database for MySQL – enskild server till Azure Database for MySQL – flexibel server med minimal stilleståndstid till dina program med hjälp av en kombination av verktyg med öppen källkod som mydumper/myloader och datareplikering.

Kommentar

Den här artikeln innehåller referenser till termen slav, en term som Microsoft inte längre använder. När termen tas bort från programvaran tar vi bort den från den här artikeln.

Datareplikering är en teknik som replikerar dataändringar från källservern till målservern baserat på positioneringsmetoden för binär loggfil. I det här scenariot skriver MySQL-instansen som fungerar som källa (där databasändringarna kommer) uppdateringar och ändringar som "händelser" till den binära loggen. Informationen i den binära loggen lagras i olika loggningsformat enligt de databasändringar som registreras. Repliker konfigureras för att läsa den binära loggen från källan och köra händelserna i binärtecknet i replikens lokala databas.

Om du konfigurerar Data-in-replikering för att synkronisera data från en instans av Azure Database for MySQL till en annan kan du göra en selektiv snabbväxling av dina program från den primära (eller källdatabasen) till repliken (eller måldatabasen).

I den här självstudien använder du mydumper/myloader och datareplikering för att migrera en exempeldatabas (classicmodels) från en instans av Azure Database for MySQL – enskild server till en instans av Azure Database for MySQL – flexibel server och sedan synkronisera data.

I den här självstudien lär du dig att:

  • Konfigurera nätverksinställningar för datareplikering för olika scenarier.
  • Konfigurera datareplikering mellan den primära repliken och repliken.
  • Testa replikeringen.
  • Snabb för att slutföra migreringen.

Förutsättningar

För att slutföra självstudierna behöver du:

  • En instans av Azure Database for MySQL – enskild server som kör version 5.7 eller 8.0.

    Kommentar

    Om du kör Azure Database for MySQL Single Server version 5.6 uppgraderar du instansen till 5.7 och konfigurerar sedan data i replikering. Mer information finns i Högre versionsuppgradering i Azure Database for MySQL – enskild server.

  • En instans av Azure Database for MySQL – flexibel server. Mer information finns i artikeln Skapa en instans i Azure Database for MySQL – flexibel server.

    Kommentar

    Det går inte att konfigurera datareplikering för zonredundanta servrar med hög tillgänglighet. Om du vill ha zonredundant HA för målservern utför du följande steg:

    1. Skapa servern med zonredundant HA aktiverat
    2. Inaktivera HA
    3. Följ artikeln för att konfigurera datareplikering
    4. Ta bort konfigurationen för datareplikering efter snabb användning
    5. Aktivera HA

    Kontrollera att GTID_Mode har samma inställning på käll- och målservrarna.

  • Ansluta och skapa en databas med MySQL Workbench. Mer information finns i artikeln Använda MySQL Workbench för att ansluta och fråga efter data.

  • För att säkerställa att du har en virtuell Azure-dator som kör Linux i samma region (eller på samma virtuella nätverk med privat åtkomst) som är värd för dina käll- och måldatabaser.

  • Installera mysql-klienten eller MySQL Workbench (klientverktygen) på den virtuella Azure-datorn. Se till att du kan ansluta till både den primära servern och replikservern. I den här artikeln installeras mysql-klienten.

  • Installera mydumper/myloader på din virtuella Azure-dator. Mer information finns i artikeln mydumper/myloader.

  • Så här laddar du ned och kör exempeldatabasskriptet för classicmodels-databasen på källservern.

  • Konfigurera binlog_expire_logs_seconds på källservern för att säkerställa att binlogs inte rensas innan repliken genomför ändringarna. Efter en lyckad klippning kan du återställa värdet.

Konfigurera nätverkskrav

För att konfigurera datareplikeringen måste du se till att målet kan ansluta till källan via port 3306. Utför följande steg baserat på vilken typ av slutpunkt som har konfigurerats på källan.

Konfigurera datareplikering

Utför följande steg för att konfigurera data i replikering:

  1. Logga in på den virtuella Azure-dator där du installerade mysql-klientverktyget.

  2. Anslut till källan och målet med hjälp av mysql-klientverktyget.

  3. Använd mysql-klientverktyget för att avgöra om log_bin är aktiverat på källan genom att köra följande kommando:

    SHOW VARIABLES LIKE 'log_bin';

    Kommentar

    Med Azure Database for MySQL – enskild server med det stora lagringsutrymmet, som har stöd för upp till 16 TB, aktiveras detta som standard.

    Dricks

    Med Azure Database for MySQL – enskild server, som stöder upp till 4 TB, är detta inte aktiverat som standard. Men om du höjer upp en läsreplik för källservern och sedan tar bort skrivskyddade repliker ställs parametern in på PÅ.

  4. Baserat på SSL-tillämpningen för källservern skapar du en användare på källservern med replikeringsbehörigheten genom att köra rätt kommando.

    Om du använder SSL kör du följande kommando:

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

    Om du inte använder SSL kör du följande kommando:

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

  5. Om du vill säkerhetskopiera databasen med mydumper kör du följande kommando på den virtuella Azure-dator där vi installerade 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

    Dricks

    Alternativet --trx-consistency-only krävs för transaktionskonsekvens medan vi säkerhetskopierar.

    • Mydumper-motsvarigheten till mysqldump:s --single-transaction.
    • Användbart om alla dina tabeller är InnoDB.
    • Huvudtråden behöver bara hålla det globala låset tills "dump"-trådarna kan starta en transaktion.
    • Erbjuder den kortaste varaktigheten för global låsning

    Huvudtråden behöver bara hålla det globala låset tills "dump"-trådarna kan starta en transaktion.

    Variablerna i det här kommandot beskrivs nedan:

    HOW-TO-MANAGE-FIREWALL-PORTAL --host: Namnet på den primära servern

    • --user: Namnet på en användare (i formatet username@servername eftersom den primära servern kör Azure Database for MySQL – enskild server). Du kan använda serveradministratören eller en användare som har behörigheten SELECT och RELOAD.
    • --Password: Lösenordet för användaren ovan

    Mer information om hur du använder mydumper finns i mydumper/myloader

  6. Läs metadatafilen för att fastställa namnet på den binära loggfilen och förskjutningen genom att köra följande kommando:

    cat ./backup/metadata

    I det här kommandot refererar ./backup till utdatakatalogen som användes i kommandot i föregående steg.

    Resultatet bör visas på följande bild:

    Skärmbild av kontinuerlig synkronisering med Azure Database Migration Service.

    Observera namnet på den binära filen för användning i senare steg.

  7. Återställ databasen med myloader genom att köra följande kommando:

    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

    Variablerna i det här kommandot beskrivs nedan:

    • --host: Namnet på replikservern
    • --user: Namnet på en användare. Du kan använda serveradministratören eller en användare med läs-/skrivbehörighet som kan återställa scheman och data till databasen
    • --Password: Lösenord för användaren ovan

  8. Beroende på SSL-tillämpningen på den primära servern ansluter du till replikservern med hjälp av mysql-klientverktyget och utför följande steg.

    • Om SSL-tillämpning är aktiverat:

      i. Ladda ned certifikatet som behövs för att kommunicera via SSL med din Azure Database for MySQL-server härifrån.

      ii. Öppna filen i anteckningar och klistra in innehållet i avsnittet "PLACERA DITT OFFENTLIGA NYCKELCERTIFIKATS KONTEXT HÄR".

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

      iii. Kör följande kommando för att konfigurera data i replikering:

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

      Kommentar

      Fastställ position och filnamn från den information som hämtas i steg 6.

    • Om SSL-tvingande inte är aktiverat kör du följande kommando:

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

  9. Om du vill starta replikeringen från replikservern anropar du den lagrade proceduren nedan.

    call  mysql.az_replication_start;

  10. Kontrollera replikeringsstatusen genom att köra följande kommando på replikservern:

    show slave status \G;

    Kommentar

    Om du använder MySQL Workbench krävs inte \G-modifieraren.

    Om tillståndet för Slave_IO_Running och Slave_SQL_Running är Ja och värdet för Seconds_Behind_Master är 0 fungerar replikeringen bra. Seconds_Behind_Master anger hur sent repliken är. Om värdet är något annat än 0 bearbetar repliken uppdateringar.

Testa replikeringen (valfritt)

För att bekräfta att datareplikeringen fungerar korrekt kan du kontrollera att ändringarna i tabellerna i den primära repliken har replikerats till repliken.

  1. Identifiera en tabell som ska användas för testning, till exempel tabellen Kunder, och bekräfta sedan att antalet poster som den innehåller är detsamma på de primära servrarna och replikservrarna genom att köra följande kommando på var och en:

    select count(*) from customers;

  2. Anteckna antalet poster för senare jämförelse.

    Testa replikeringen genom att prova att lägga till data i kundtabellerna på den primära servern och se sedan kontrollera att de nya data replikeras. I det här fallet lägger du till två rader i en tabell på den primära servern och bekräftar sedan att de replikeras på replikservern.

  3. I tabellen Kunder på den primära servern infogar du rader genom att köra följande kommando:

    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. Om du vill kontrollera replikeringsstatusen anropar du statusen visa slav \G för att bekräfta att replikeringen fungerar som förväntat.

  5. Kontrollera att antalet är detsamma genom att köra följande kommando på replikservern:

    select count(*) from customers;

Se till att snabbväxlingen lyckas

Gör följande för att säkerställa en snabbmigrering:

  1. Konfigurera lämpliga brandväggsregler på servernivå och regler för virtuella nätverk för att ansluta till målservern. Du kan jämföra brandväggsreglerna för källan och målet från portalen.
  2. Konfigurera lämpliga inloggningar och behörigheter på databasnivå på målservern. Du kan köra SELECT FROM mysql.user på käll- och målservrarna för att jämföra.
  3. Kontrollera att alla inkommande anslutningar till Azure Database for MySQL – enskild server har stoppats.

    Dricks

    Du kan ange Azure Database for MySQL – enskild server till skrivskyddad.

  4. Kontrollera att repliken har kommit ikapp den primära genom att köra visa slavstatus \G och bekräfta att värdet för parametern Seconds_Behind_Master är 0.
  5. Omdirigera klienter och klientprogram till målinstansen av Azure Database for MySQL – flexibel server.
  6. Utför den slutliga snabbmigreringen genom att köra den lagrade proceduren mysql.az_replication_stop som stoppar replikeringen från replikservern.
  7. Anropa mysql.az_replication_remove_master för att ta bort konfigurationen för datareplikering.

I det här läget är dina program anslutna till den nya flexibla Azure Database for MySQL-servern och ändringar i källan replikeras inte längre till målet. Skapa och hantera brandväggsregler för Azure Database for MySQL med hjälp av Azure-portalen

Relaterat innehåll