Share via

Amazon RDS for MySQL migreren naar Azure Database for MySQL met behulp van replicatie van inkomende gegevens

  • Artikel

VAN TOEPASSING OP: Azure Database for MySQL - Enkele server Azure Database for MySQL - Flexibele server

Belangrijk

Azure Database for MySQL enkele server bevindt zich op het buitengebruikstellingspad. We raden u ten zeerste aan een upgrade uit te voeren naar een flexibele Azure Database for MySQL-server. Zie Wat gebeurt er met Azure Database for MySQL Enkele server voor meer informatie over migreren naar Azure Database for MySQL Flexibele server ?

Notitie

Dit artikel bevat verwijzingen naar de term slave, een term die Microsoft niet meer gebruikt. Zodra de term uit de software wordt verwijderd, verwijderen we deze uit dit artikel.

U kunt methoden zoals MySQL-dump en -herstel, MySQL Workbench Exporteren en importeren of Azure Database Migration Service gebruiken om uw MySQL-databases te migreren naar een flexibele Azure Database for MySQL-server. U kunt uw workloads migreren met minimale downtime door gebruik te maken van een combinatie van opensource-hulpprogramma's zoals mysqldump of mydumper en myloader met Data-in Replication.

Replicatie van inkomende gegevens is een techniek waarmee gegevenswijzigingen van de bronserver naar de doelserver worden gerepliceerd op basis van de positiemethode van het binaire logboekbestand. In dit scenario schrijft het MySQL-exemplaar dat werkt als de bron (waarop de databasewijzigingen afkomstig zijn) updates en wijzigingen als gebeurtenissen in het binaire logboek. De informatie in het binaire logboek wordt opgeslagen in verschillende indelingen voor logboekregistratie, afhankelijk van de wijzigingen in de database die worden vastgelegd. Replica's zijn geconfigureerd voor het lezen van het binaire logboek uit de bron en het uitvoeren van de gebeurtenissen in het binaire logboek in de lokale database van de replica.

Stel Replicatie van inkomende gegevens in om gegevens van een MySQL-bronserver te synchroniseren met een MySQL-doelserver. U kunt een selectieve cutover van uw toepassingen uitvoeren van de primaire (of brondatabase) naar de replica (of doeldatabase).

In deze zelfstudie leert u hoe u Gegevens-in-replicatie instelt tussen een bronserver waarop Amazon Relational Database Service (RDS) voor MySQL wordt uitgevoerd en een doelserver waarop azure Database for MySQL flexibele server wordt uitgevoerd.

Prestatieoverwegingen

Voordat u aan deze zelfstudie begint, moet u rekening houden met de gevolgen voor de prestaties van de locatie en de capaciteit van de clientcomputer die u gaat gebruiken om de bewerking uit te voeren.

Clientlocatie

Dump- of herstelbewerkingen uitvoeren vanaf een clientcomputer die wordt gestart op dezelfde locatie als de databaseserver:

  • Voor exemplaren van flexibele Azure Database for MySQL-servers moet de clientcomputer zich in hetzelfde virtuele netwerk en dezelfde beschikbaarheidszone bevinden als de doeldatabaseserver.
  • Voor bronexemplaren van Amazon RDS-database moet het clientexemplaren zich in dezelfde Amazon Virtual Private Cloud en beschikbaarheidszone bevinden als de brondatabaseserver. In het voorgaande geval kunt u dumpbestanden verplaatsen tussen clientcomputers met behulp van protocollen voor bestandsoverdracht, zoals FTP of SFTP, of uploaden naar Azure Blob Storage. Als u de totale migratietijd wilt verminderen, comprimeert u bestanden voordat u ze overbrengt.

Clientcapaciteit

Ongeacht waar de clientcomputer zich bevindt, vereist het voldoende reken-, I/O- en netwerkcapaciteit om de aangevraagde bewerkingen uit te voeren. De algemene aanbevelingen zijn:

  • Als de dump of herstel realtime verwerking van gegevens omvat, bijvoorbeeld compressie of decomprimatie, kiest u een instantieklasse met ten minste één CPU-kern per dump of herstelthread.
  • Zorg ervoor dat er voldoende netwerkbandbreedte beschikbaar is voor het clientexemplaren. Gebruik instantietypen die ondersteuning bieden voor de functie versneld netwerken. Zie de sectie Versneld netwerken in de netwerkhandleiding voor virtuele Azure-machines voor meer informatie.
  • Zorg ervoor dat de opslaglaag van de clientcomputer de verwachte lees-/schrijfcapaciteit biedt. U wordt aangeraden een virtuele Azure-machine te gebruiken met Premium SSD-opslag.

Vereisten

Voor het voltooien van deze zelfstudie hebt u het volgende nodig:

  • Installeer de mysqlclient op uw clientcomputer om een dump te maken en voer een herstelbewerking uit op uw doelexemplaren van Azure Database for MySQL flexibele server.

  • Voor grotere databases installeert u mydumper en myloader voor parallelle dumping en het herstellen van databases.

    Notitie

    Mydumper kan alleen worden uitgevoerd op Linux-distributies. Zie Mydumper installeren voor meer informatie.

  • Maak een exemplaar van een flexibele Azure Database for MySQL-server waarop versie 5.7 of 8.0 wordt uitgevoerd.

    Belangrijk

    Als uw doel Azure Database for MySQL flexibele server is met zone-redundante hoge beschikbaarheid (HA), moet u er rekening mee houden dat Data-in Replication niet wordt ondersteund voor deze configuratie. Als tijdelijke oplossing stelt u tijdens het maken van de server zone-redundante hoge beschikbaarheid in:

    1. Maak de server waarvoor zone-redundante hoge beschikbaarheid is ingeschakeld.
    2. Hoge beschikbaarheid uitschakelen.
    3. Volg het artikel voor het instellen van inkomende replicatie.
    4. Na de cutover verwijdert u de configuratie voor replicatie van inkomende gegevens.
    5. Hoge beschikbaarheid inschakelen.

Zorg ervoor dat verschillende parameters en functies correct zijn geconfigureerd en ingesteld, zoals beschreven:

  • Om compatibiliteitsredenen moet u de bron- en doeldatabaseservers in dezelfde MySQL-versie hebben.
  • Een primaire sleutel in elke tabel hebben. Een gebrek aan primaire sleutels in tabellen kan het replicatieproces vertragen.
  • Zorg ervoor dat de tekenset van de bron en de doeldatabase hetzelfde zijn.
  • Stel de wait_timeout parameter in op een redelijke tijd. De tijd is afhankelijk van de hoeveelheid gegevens of werkbelasting die u wilt importeren of migreren.
  • Controleer of alle tabellen Gebruikmaken van InnoDB. Flexibele Azure Database for MySQL-server ondersteunt alleen de InnoDB-opslagengine.
  • Voor tabellen met veel secundaire indexen of grote tabellen zijn overhead-effecten voor prestaties zichtbaar tijdens het herstellen. Wijzig de dumpbestanden zodat de CREATE TABLE instructies geen secundaire sleuteldefinities bevatten. Nadat u de gegevens hebt geïmporteerd, maakt u secundaire indexen opnieuw om de prestatiestraf te voorkomen tijdens het herstelproces.

Ten slotte moet u zich voorbereiden op replicatie van inkomende gegevens:

  • Controleer of het doelexemplaren van de flexibele Azure Database for MySQL-server via poort 3306 verbinding kunnen maken met de bron-Amazon RDS for MySQL-server.
  • Zorg ervoor dat de bron-Amazon RDS voor MySQL-server zowel inkomend als uitgaand verkeer op poort 3306 toestaat.
  • Zorg ervoor dat u site-naar-site-connectiviteit met uw bronserver biedt met behulp van Azure ExpressRoute of Azure VPN Gateway. Zie de documentatie van Azure Virtual Network voor meer informatie over het maken van een virtueel netwerk. Zie ook de quickstart-artikelen met stapsgewijze details.
  • Configureer de netwerkbeveiligingsgroepen van de brondatabaseserver om het IP-adres van de flexibele server van Azure Database for MySQL toe te staan.

Belangrijk

Als de bronexemplaren van Amazon RDS voor MySQL GTID_mode ingesteld op AAN, moet het doelexemplaren van de flexibele Azure Database for MySQL-server ook GTID_mode ingesteld op AAN.

Het doelexemplaren van Azure Database for MySQL configureren

Het doelexemplaren van de flexibele Azure Database for MySQL-server configureren. Dit is het doel voor replicatie van inkomende gegevens:

  1. Stel de max_allowed_packet parameterwaarde in op het maximum van 1073741824, wat 1 GB is. Deze waarde voorkomt eventuele overloopproblemen met betrekking tot lange rijen.

  2. Stel tijdens de migratie de slow_query_logparameters , general_logaudit_log_enableden query_store_capture_mode parameters in op UIT om eventuele overhead met betrekking tot querylogboekregistratie te voorkomen.

  3. Schaal de rekenkracht van het doelexemplaren van Azure Database for MySQL flexibele server omhoog tot maximaal 64 vCores. Deze grootte biedt meer rekenresources bij het herstellen van de databasedump van de bronserver.

    U kunt de berekening altijd terugschalen om te voldoen aan de vereisten van uw toepassing nadat de migratie is voltooid.

  4. Schaal de opslaggrootte omhoog om meer IOPS te krijgen tijdens de migratie of verhoog de maximale IOPS voor de migratie.

    Notitie

    De beschikbare maximale IOPS worden bepaald door de rekengrootte. Zie de sectie IOPS in Compute- en opslagopties in Azure Database for MySQL Flexibele server voor meer informatie.

De bron-Amazon RDS voor MySQL-server configureren

De MySQL-server die wordt gehost in Amazon RDS voorbereiden en configureren. Dit is de bron voor replicatie van gegevens in:

  1. Controleer of binaire logboekregistratie is ingeschakeld op de bron-Amazon RDS voor MySQL-server. Controleer of automatische back-ups zijn ingeschakeld of controleer of er een leesreplica bestaat voor de bron-Amazon RDS voor MySQL-server.

  2. Zorg ervoor dat de binaire logboekbestanden op de bronserver behouden blijven totdat de wijzigingen zijn toegepast op het doelexemplaren van de flexibele Azure Database for MySQL-server.

    Met replicatie van gegevens beheert Azure Database for MySQL flexibele server het replicatieproces niet.

  3. Als u de bewaarperiode van het binaire logboek op de Amazon RDS-bronserver wilt controleren om het aantal uren te bepalen dat de binaire logboeken worden bewaard, roept u de mysql.rds_show_configuration opgeslagen procedure aan:

    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. Als u de bewaarperiode voor binaire logboeken wilt configureren, voert u de rds_set_configuration opgeslagen procedure uit om ervoor te zorgen dat de binaire logboeken gedurende de gewenste tijd op de bronserver worden bewaard. Voorbeeld:

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

    Als u een dump maakt en herstelt, helpt de voorgaande opdracht u snel bij te komen met de deltawijzigingen.

    Notitie

    Zorg ervoor dat er voldoende schijfruimte is om de binaire logboeken op de bronserver op te slaan op basis van de gedefinieerde bewaarperiode.

Er zijn twee manieren om een dump van gegevens vast te leggen van de Amazon RDS-bronserver voor MySQL. Eén benadering omvat het vastleggen van een dump van gegevens rechtstreeks vanaf de bronserver. De andere benadering omvat het vastleggen van een dump van een Amazon RDS voor MySQL-leesreplica.

  • Een dump van gegevens rechtstreeks vanaf de bronserver vastleggen:

    1. Zorg ervoor dat u de schrijfbewerkingen van de toepassing enkele minuten stopt om een transactioneel consistente dump van gegevens op te halen.

      U kunt de read_only parameter ook tijdelijk instellen op een waarde van 1 , zodat schrijfbewerkingen niet worden verwerkt wanneer u een dump met gegevens vastlegt.

    2. Nadat u de schrijfbewerkingen op de bronserver hebt gestopt, verzamelt u de naam en verschuiving van het binaire logboekbestand door de opdracht Mysql> Show master status;uit te voeren.

    3. Sla deze waarden op om de replicatie te starten vanuit uw flexibele Azure Database for MySQL-serverexemplaren.

    4. Voer de volgende opdracht uit mysqldump om een dump van de gegevens te maken:

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

  • Als het stoppen van schrijfbewerkingen op de bronserver geen optie is of de prestaties van dumpinggegevens niet acceptabel zijn op de bronserver, legt u een dump vast op een replicaserver:

    1. Maak een Amazon MySQL-leesreplica met dezelfde configuratie als de bronserver. Maak vervolgens de dump daar.

    2. Laat de Amazon RDS for MySQL leesreplica inhalen met de bron-Amazon RDS for MySQL-server.

    3. Wanneer de replicavertraging 0 bereikt op de leesreplica, stopt u de replicatie door de opgeslagen procedure mysql.rds_stop_replicationaan te roepen.

      Mysql> call mysql.rds_stop_replication;

    4. Als de replicatie is gestopt, maakt u verbinding met de replica. Voer vervolgens de SHOW SLAVE STATUS opdracht uit om de naam van het huidige binaire logboekbestand op te halen uit het veld Relay_Master_Log_File en de positie van het logboekbestand uit het veld Exec_Master_Log_Pos .

    5. Sla deze waarden op om de replicatie te starten vanuit uw flexibele Azure Database for MySQL-serverexemplaren.

    6. Als u een dump van de gegevens wilt maken van de Amazon RDS for MySQL-leesreplica, voert mysqldump u de volgende opdracht uit:

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

    Notitie

    U kunt mydumper ook gebruiken voor het vastleggen van een geparallelliseerde dump van uw gegevens uit uw bron Amazon RDS for MySQL-database. Zie Grote databases migreren naar een flexibele Azure Database for MySQL-server met behulp van mydumper/myloader voor meer informatie.

  1. Als u de database wilt herstellen met behulp van systeemeigen mysql-herstel, voert u de volgende opdracht uit:

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

    Notitie

    Als u in plaats daarvan myloader gebruikt, raadpleegt u Grote databases migreren naar Azure Database for MySQL Flexibele server met behulp van mydumper/myloader.

  2. Meld u aan bij de bron-Amazon RDS for MySQL-server en stel een replicatiegebruiker in. Verdeel vervolgens de benodigde bevoegdheden aan deze gebruiker.

    • Als u SSL gebruikt, voert u de volgende opdrachten uit:

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

    • Als u geen SSL gebruikt, voert u de volgende opdrachten uit:

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

    Opgeslagen procedures doen alle functies voor replicatie van gegevens. Zie Opgeslagen procedures voor gegevens in replicatie voor meer informatie over alle procedures. U kunt deze opgeslagen procedures uitvoeren in de MySQL-shell of MySQL Workbench.

  3. Als u de Amazon RDS for MySQL-bronserver en de doelserver van de flexibele Server van Azure Database for MySQL wilt koppelen, meldt u zich aan bij het doelexemplaren van Azure Database for MySQL Flexibele server. Stel de Amazon RDS voor MySQL-server in als de bronserver door de volgende opdracht uit te voeren:

    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. Voer de volgende opdracht uit om de replicatie tussen de bron-Amazon RDS for MySQL-server en het doelexemplaren van Azure Database for MySQL flexibele server te starten:

    Mysql> CALL mysql.az_replication_start;

  5. Voer de volgende opdracht uit om de status van de replicatie op de replicaserver te controleren:

    Mysql> show slave status\G

    Als de status van de Slave_IO_Running en Slave_SQL_Running parameters Ja is, is de replicatie gestart en heeft deze de status Actief.

  6. Controleer de waarde van de Seconds_Behind_Master parameter om te bepalen hoe vertraagd de doelserver is.

    Als de waarde 0 is, heeft het doel alle updates van de bronserver verwerkt. Als de waarde iets anders is dan 0, verwerkt de doelserver nog steeds updates.

Een geslaagde cutover garanderen

Een geslaagde cutover garanderen:

  1. Configureer de juiste aanmeldingen en machtigingen op databaseniveau in het doelexemplaren van Azure Database for MySQL Flexibele server.
  2. Stop schrijfbewerkingen naar de bron-Amazon RDS voor MySQL-server.
  3. Zorg ervoor dat het doelexemplaren van de flexibele Azure Database for MySQL-server de bronserver hebben opgepikt en dat de Seconds_Behind_Master waarde 0 is.show slave status
  4. Roep de opgeslagen procedure mysql.az_replication_stop aan om de replicatie te stoppen omdat alle wijzigingen zijn gerepliceerd naar het doelexemplaren van Azure Database for MySQL Flexibele server.
  5. Aanroep mysql.az_replication_remove_master om de replicatieconfiguratie voor inkomende gegevens te verwijderen.
  6. Clients en clienttoepassingen omleiden naar het doelexemplaren van Azure Database for MySQL Flexibele server.

Op dit moment is de migratie voltooid. Uw toepassingen zijn verbonden met de server waarop flexibele Azure Database for MySQL-server wordt uitgevoerd.

Volgende stappen