Dela via

MySQL till Azure Database for MySQL-datamigrering – MySQL-replikeringsändringar

Genom att köra en migrering av replikera ändringar, med vårt offlinescenario med "Aktivera transaktionell konsekvens" kan företag migrera sina databaser till Azure medan databaserna förblir i drift. Med andra ord kan migreringar slutföras med minsta stilleståndstid för kritiska program, vilket begränsar påverkan på tillgängligheten på servicenivå och olägenheter för deras slutkunder.

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.

Aktuell implementering

Du måste köra ett offlinemigreringsscenario med "Aktivera transaktionell konsekvens" för att hämta bin-loggfilen och positionen för att replikera de inkommande ändringarna. Användargränssnittet för DMS-portalen visar det binära loggfilnamnet och den position som är justerad efter den tid då låsen hämtades på källan för den konsekventa ögonblicksbilden. Du kan använda det här värdet i vår migrering av replikerade ändringar för att strömma inkommande ändringar.

Skärmbild av skärmen Lägg till källinformation.

När du kör migreringen av replikerade ändringar, när målet nästan är ifatt källservern, stoppar du alla inkommande transaktioner till källdatabasen och väntar tills alla väntande transaktioner har tillämpats på måldatabasen. För att bekräfta att måldatabasen är uppdaterad på källservern kör du frågan "SHOW MASTER STATUS;" och jämför sedan den positionen med den senaste bekräftade binloghändelsen (visas under Migreringsförlopp). När de två positionerna är desamma har målet kommit ikapp alla ändringar och du kan starta snabbstarten.

Så här fungerar replikerade ändringar

Den aktuella implementeringen baseras på binlogändringar för direktuppspelning från källservern och tillämpar dem på målservern. Precis som datareplikering är det enklare att konfigurera och kräver ingen fysisk anslutning mellan källan och målservrarna.

Servern kan skicka Binlog som en dataström som innehåller binära data som dokumenteras här. Klienten kan ange den första loggpositionen som strömmen ska startas med. Loggfilens namn beskriver loggpositionen, positionen i filen och eventuellt GTID (globalt transaktions-ID) om gtid-läget är aktiverat vid källan.

Dataändringarna skickas som "radhändelser", som innehåller data för enskilda rader (före och/eller efter ändringen beroende på åtgärdstypen, som är infoga, ta bort eller uppdatera). Radhändelserna tillämpas sedan i sitt råformat med hjälp av en BINLOG-instruktion: MySQL 8.0 Referenshandbok :: 13.7.8.1 BINLOG-instruktion. Men för en DMS-migrering till en 5.7-server tillämpar DMS inte ändringar som BINLOG-instruktioner (eftersom DMS inte har nödvändiga behörigheter för att göra det) och översätter i stället radhändelserna till INSERT-, UPDATE- eller DELETE-instruktioner.

Förutsättningar

För att slutföra migreringen av replikerade ändringar kontrollerar du att följande förutsättningar är uppfyllda:

  • Använd det kommandoradsverktyg för MySQL som du väljer för att avgöra om log_bin är aktiverat på källservern. Binlog är inte alltid aktiverat som standard, så kontrollera att det är aktiverat innan du påbörjar migreringen. Om du vill ta reda på om log_bin är aktiverat på källservern kör du kommandot: VISA VARIABLER SOM "log_bin"
  • Kontrollera att användaren har behörigheten "REPLICATION_APPLIER" eller "BINLOG_ADMIN" på målservern för att tillämpa lagerplatsloggen.
  • Kontrollera att användaren har behörigheten "REPLIKERINGSSLAV" på målservern.
  • Kontrollera att användaren har behörigheten "REPLIKERINGSKLIENT" och "REPLIKERINGSSLAV" på källservern för att läsa och tillämpa bin-loggen.
  • Kör ett offlinemigreringsscenario med "Aktivera transaktionell konsekvens" för att hämta lagerplatsloggfilen och positionen.
  • Om du riktar in dig på en migrering av replikerade ändringar konfigurerar du parametern binlog_expire_logs_seconds på källservern så att binlogfilerna inte rensas innan repliken genomför ändringarna. Vi rekommenderar minst två dagar, till att börja med. Efter en snabb snabb återställning kan värdet återställas.

Begränsningar

  • När du utför en replikeringsmigrering måste namnet på databasen på målservern vara samma som namnet på källservern.
  • Stödet är begränsat till row binlog-formatet.
  • Replikering av DDL-ändringar stöds endast när du har valt alternativet replikera datadefinitions- och administrationsinstruktioner för valda objekt i DMS-användargränssnittet. Replikeringsfunktionen stöder replikering av datadefinitions- och administrationsinstruktioner som inträffar efter den första inläsningen och loggas i binärloggen till målet.
  • Det går inte att byta namn på databaser eller tabeller när ändringar replikeras.

Relaterat innehåll