Migrera Amazon RDS for MySQL till Azure Database for MySQL med Datareplikering

  • Artikel
  • 10 minuter för att läsa

GÄLLER FÖR: Azure Database for MySQL – enskild server Azure Database for MySQL – flexibel server

Anteckning

Den här artikeln innehåller referenser till termen slave, 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.

Du kan använda metoder som MySQL-dump och -återställning, MySQL Workbench-export och -import eller Azure Database Migration Service för att migrera dina MySQL-databaser till Azure Database for MySQL. Genom att använda en kombination av verktyg med öppen källkod som mysqldump eller mydumper och myloader med Datareplikering kan du migrera dina arbetsbelastningar med minsta stilleståndstid.

Datareplikering är en teknik som replikerar dataändringar från källservern till målservern baserat på positionsmetoden för binär loggfil. I det här scenariot skriver MySQL-instansen som fungerar som källa (som databasen ändras från) uppdateringar och ändringar som händelser i den binära loggen. Informationen i den binära loggen lagras i olika loggningsformat beroende på vilka databasändringar som registreras. Repliker är konfigurerade för att läsa den binära loggen från källan och köra händelserna i den binära loggen på replikens lokala databas.

Om du har ställt in Datareplikering att synkronisera data från en MySQL-källserver till en MySQL-målserver kan du göra en selektiv övergång av dina program från den primära (eller källdatabasen) till repliken (eller måldatabasen).

I den här självstudien lär du dig att konfigurera Datareplikering mellan en källserver som kör Amazon Relational Database Service (RDS) för MySQL och en målserver som kör Azure Database for MySQL.

Saker att tänka på gällande prestanda

Innan du påbörjar den här självstudien bör du tänka på prestandakonsekvenserna av platsen och kapaciteten för den klientdator som du kommer att använda för att utföra åtgärden.

Klientplats

Utför dumpnings- eller återställningsåtgärder från en klientdator som startas på samma plats som databasservern:

  • För Azure Database for MySQL-servrar ska klientdatorn finnas i samma virtuella nätverk och i samma tillgänglighetszon som måldatabasservern.
  • För Amazon RDS-källdatabasinstanser bör klientinstansen finnas i samma Amazon Virtual Private Cloud och tillgänglighetszon som källdatabasservern. I föregående fall kan du flytta dumpfiler mellan klientdatorer med hjälp av filöverföringsprotokoll som FTP eller SFTP eller ladda upp dem till Azure Blob Storage. Om du vill minska den totala migreringstiden komprimerar du filerna innan du överför dem.

Klientkapacitet

Oavsett var klientdatorn finns krävs tillräcklig beräknings-, I/O- och nätverkskapacitet för att utföra de begärda åtgärderna. De allmänna rekommendationerna är:

  • Om dumpen eller återställningen omfattar realtidsbearbetning av data, till exempel komprimering eller dekomprimering, väljer du en instansklass med minst en PROCESSORkärna per dump eller återställningstråd.
  • Se till att det finns tillräckligt med nätverksbandbredd tillgänglig för klientinstansen. Använd instanstyper som stöder funktionen för accelererat nätverk. Mer information finns i avsnittet "Accelererat nätverk" i nätverksguiden för virtuella Azure-datorer.
  • Se till att klientdatorns lagringslager ger den förväntade läs-/skrivkapaciteten. Vi rekommenderar att du använder en virtuell Azure-dator med Premium SSD-lagring.

Förutsättningar

För att slutföra den här kursen behöver du:

  • Installera mysqlclient på klientdatorn för att skapa en dump och utför en återställningsåtgärd på Azure Database for MySQL servern.

  • För större databaser installerar du mydumper och myloader för parallell dumpning och återställning av databaser.

    Anteckning

    Mydumper kan bara köras på Linux-distributioner. Mer information finns i Så här installerar du mydumper.

  • Skapa en instans Azure Database for MySQL server som kör version 5.7 eller 8.0.

    Viktigt

    Om målet är Azure Database for MySQL flexibel server med zonredundant hög tillgänglighet (HA), observera att Datareplikering inte stöds för den här konfigurationen. En tillfällig lösning är att konfigurera zonredundant HÖG när servern skapas:

    1. Skapa servern med zonredundant HA aktiverad.
    2. Inaktivera HA.
    3. Följ artikeln för att konfigurera Datareplikering.
    4. Efter övergången tar du bort Datareplikering konfiguration.
    5. Aktivera HA.

Se till att flera parametrar och funktioner har konfigurerats och konfigurerats korrekt, enligt beskrivningen:

  • Av kompatibilitetsskäl bör käll- och måldatabasservrarna ha samma MySQL-version.
  • Ha en primärnyckel i varje tabell. Brist på primära nycklar i tabeller kan göra replikeringsprocessen långsammare.
  • Kontrollera att teckenuppsättningen för källan och måldatabasen är desamma.
  • Ange wait_timeout parametern till en rimlig tid. Hur lång tid det tar beror på hur mycket data eller arbetsbelastning du vill importera eller migrera.
  • Kontrollera att alla dina tabeller använder InnoDB. Den Azure Database for MySQL servern stöder endast InnoDB-lagringsmotorn.
  • För tabeller med många sekundära index eller för tabeller som är stora är effekterna av prestandakostnader synliga under återställningen. Ändra dumpfilerna så att CREATE TABLE isatserna inte innehåller definitioner för sekundär nyckel. När du har importerat data återskapar du sekundära index för att undvika prestandaförseningen under återställningsprocessen.

Slutligen för att förbereda för Datareplikering:

  • Kontrollera att målservern Azure Database for MySQL ansluta till Amazon RDS för MySQL-källservern via port 3306.
  • Kontrollera att Amazon RDS för MySQL-källservern tillåter både inkommande och utgående trafik på port 3306.
  • Se till att du tillhandahåller plats-till-plats-anslutning till källservern genom att använda antingen Azure ExpressRoute eller Azure VPN Gateway. Mer information om hur du skapar ett virtuellt nätverk finns i dokumentationen om Azure Virtual Network. Se även snabbstartsartiklarna med stegvis information.
  • Konfigurera källdatabasserverns nätverkssäkerhetsgrupper för att tillåta Azure Database for MySQL serverns IP-adress.

Viktigt

Om Amazon RDS for MySQL-källinstansen har GTID_mode på PÅ måste målinstansen av Azure Database for MySQL Flexible Server också ha GTID_mode inställt på PÅ.

Konfigurera målinstansen för Azure Database for MySQL

Så här konfigurerar du målinstansen Azure Database for MySQL, vilket är målet för Datareplikering:

  1. Ange max_allowed_packet parametervärdet till det högsta värdet 1073741824, vilket är 1 GB. Det här värdet förhindrar spillproblem som rör långa rader.

  2. Ställ in parametrarna , , och på AV under migreringen för att eliminera slow_query_log eventuella kostnader som rör general_log audit_log_enabled query_store_capture_mode frågeloggning.

  3. Skala upp målserverns beräkningsstorlek Azure Database for MySQL högst 64 virtuella kärnor. Den här storleken ger fler beräkningsresurser när du återställer databasdumpen från källservern.

    Du kan alltid skala tillbaka beräkningen för att uppfylla dina programkrav när migreringen är klar.

  4. Skala upp lagringsstorleken för att få mer IOPS under migreringen eller öka den maximala IOPS:en för migreringen.

    Anteckning

    Tillgängliga maximala IOPS bestäms av beräkningsstorleken. Mer information finns i avsnittet IOPS i Beräknings- och lagringsalternativ i Azure Database for MySQL – flexibel server.

Konfigurera Amazon RDS-källservern för MySQL

Förbered och konfigurera MySQL-servern som finns i Amazon RDS, vilket är källan för Datareplikering:

  1. Bekräfta att binär loggning är aktiverat på Amazon RDS för MySQL-källservern. Kontrollera att automatiska säkerhetskopieringar är aktiverade eller kontrollera att det finns en skrivskyddade replik för Amazon RDS för MySQL-källservern.

  2. Se till att de binära loggfilerna på källservern bevaras tills ändringarna har tillämpats på målinstansen av Azure Database for MySQL.

    Med Datareplikering hanterar Azure Database for MySQL inte replikeringsprocessen.

  3. Om du vill kontrollera kvarhållningen av binär logg på Amazon RDS-källservern för att fastställa hur många timmar de binära loggarna bevaras anropar du den mysql.rds_show_configuration lagrade proceduren:

    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. Om du vill konfigurera kvarhållningsperioden för binär logg kör du den lagrade proceduren för att säkerställa att de binära loggarna bevaras på källservern rds_set_configuration under önskad tid. Exempel:

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

    Om du skapar en dump och sedan återställer hjälper det föregående kommandot dig att snabbt komma ikapp deltaändringarna.

    Anteckning

    Se till att det finns gott om diskutrymme för att lagra de binära loggarna på källservern baserat på den kvarhållningsperiod som definierats.

Det finns två sätt att samla in en dump av data från Amazon RDS for MySQL-källservern. En metod är att samla in en dump av data direkt från källservern. Den andra metoden handlar om att samla in en dump från en Amazon RDS for MySQL-skrivskyddade replik.

  • Så här samlar du in en datadump direkt från källservern:

    1. Se till att du stoppar skrivningar från programmet i några minuter för att få en transaktionsmässigt konsekvent datadump.

      Du kan också tillfälligt ange parametern till värdet 1 så att skrivningar inte bearbetas när du samlar read_only in en dump av data.

    2. När du har stoppat skrivningar på källservern samlar du in namnet på den binära loggfilen och förskjutningen genom att köra kommandot Mysql> Show master status; .

    3. Spara dessa värden för att starta replikeringen från Azure Database for MySQL servern.

    4. Om du vill skapa en dump av data kör mysqldump du genom att köra följande kommando:

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

  • Om det inte är ett alternativ att stoppa skrivningar på källservern, eller om prestanda för dumpning av data inte är acceptabel på källservern, kan du samla in en dump på en replikserver:

    1. Skapa en Amazon MySQL-skrivskyddade replik med samma konfiguration som källservern. Skapa sedan dumpen där.

    2. Låt Amazon RDS for MySQL-skrivskyddade repliker komma ikapp med Amazon RDS for MySQL-källservern.

    3. När replikfördröjning når 0 på den skrivskyddade repliken stoppar du replikeringen genom att anropa den mysql.rds_stop_replication lagrade proceduren.

      Mysql> call mysql.rds_stop_replication;

    4. När replikeringen har stoppats ansluter du till repliken. Kör sedan kommandot för att hämta det aktuella binära loggfilsnamnet från Relay_Master_Log_File fältet och SHOW SLAVE STATUS loggfilens position från Exec_Master_Log_Pos fältet.

    5. Spara dessa värden för att starta replikeringen från din Azure Database for MySQL server.

    6. Om du vill skapa en dump av data från Amazon RDS for MySQL-skrivskyddad replik kör mysqldump du genom att köra följande kommando:

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

    Anteckning

    Du kan också använda mydumper för att samla in en parallelliserad dump av dina data från Amazon RDS för MySQL-källdatabasen. Mer information finns i Migrera stora databaser till Azure Database for MySQL mydumper/myloader.

  1. Om du vill återställa databasen med hjälp av intern mysql-återställning kör du följande kommando:

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

    Anteckning

    Om du i stället använder myloader kan du se Migrera stora databaser för att Azure Database for MySQL mydumper/myloader.

  2. Logga in på Amazon RDS-källan för MySQL-servern och konfigurera en replikeringsanvändare. Ge sedan den här användaren de behörigheter som krävs.

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

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

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

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

    Alla Datareplikering-funktioner utförs med lagrade procedurer. Information om alla procedurer finns i Datareplikering lagrade procedurer. Du kan köra dessa lagrade procedurer i MySQL-gränssnittet eller MySQL Workbench.

  3. Om du vill länka Amazon RDS för MySQL-källservern och Azure Database for MySQL-målservern loggar du in på Azure Database for MySQL servern. Ange Amazon RDS för MySQL-servern som källserver genom att köra följande kommando:

    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. Kör följande kommando för att starta replikeringen mellan Amazon RDS för MySQL-Azure Database for MySQL målservern:

    Mysql> CALL mysql.az_replication_start;

  5. Kontrollera replikeringens status genom att köra följande kommando på replikservern:

    Mysql> show slave status\G

    Om tillståndet för parametrarna Slave_IO_Running och Slave_SQL_Running är Ja har replikeringen startats och är i ett körningstillstånd.

  6. Kontrollera värdet för Seconds_Behind_Master parametern för att avgöra hur fördröjd målservern är.

    Om värdet är 0 har målet bearbetat alla uppdateringar från källservern. Om värdet är något annat än 0 bearbetar målservern fortfarande uppdateringar.

Säkerställa en lyckad övergång

Så här säkerställer du en lyckad övergång:

  1. Konfigurera lämpliga inloggningar och behörigheter på databasnivå i Azure Database for MySQL servern.
  2. Stoppa skrivningar till Amazon RDS för MySQL-källservern.
  3. Se till att Azure Database for MySQL servern har kommit ikapp källservern och att Seconds_Behind_Master värdet är 0 från show slave status .
  4. Anropa den lagrade proceduren mysql.az_replication_stop för att stoppa replikeringen eftersom alla ändringar har replikerats till Azure Database for MySQL servern.
  5. Anropa mysql.az_replication_remove_master för att ta bort Datareplikering konfiguration.
  6. Omdirigera klienter och klientprogram till Azure Database for MySQL servern.

Nu är migreringen klar. Dina program är anslutna till den server som kör Azure Database for MySQL.

Nästa steg