MySQL till Azure Database for MySQL-datamigrering – MySQL-konsekvent ögonblicksbild

MySQL Consistent Snapshot är en ny funktion som gör det möjligt för användare att ta en konsekvent ögonblicksbild av en MySQL-server utan att förlora dataintegriteten vid källan på grund av pågående CRUD-åtgärder (Skapa, Läsa, Uppdatera och Ta bort). Transaktionskonsekvens uppnås utan att källservern behöver ställas in på skrivskyddat läge via den här funktionen. Dessutom finns det flera alternativ för datakonsekvens som presenteras för användaren – aktivera konsekvent ögonblicksbild med läslås (GA), aktivera konsekvent ögonblicksbild utan lås (förhandsversion), Gör källservern skrivskyddad och Ingen. Att välja alternativet Ingen innebär att inga extra åtgärder vidtas för att säkerställa datakonsekvens. Båda alternativen – aktivera konsekvent ögonblicksbild med läslås (GA), aktivera konsekvent ögonblicksbild utan lås stöd för att utföra en onlinemigrering. Vi rekommenderar starkt att du väljer alternativet "Aktivera konsekvent ögonblicksbild utan lås" för att upprätthålla transaktionskonsekvens.

Aktivera konsekvent ögonblicksbild utan lås (förhandsversion)

När du aktiverar det här alternativet sker en avstämningsfas efter den första inläsningen. Detta är för att säkerställa att de data som skrivs till målet är transaktionsmässigt konsekventa med källservern från en specifik position i binärloggen.

Med den här funktionen tar vi inte ett läslås på servern. Vi läser i stället tabeller vid olika tidpunkter, samtidigt som vi håller reda på de olika binlogpositionerna för varje tabell. Detta hjälper dig att stämma av tabellerna mot slutet av den inledande belastningen genom att utföra replikering i catchup-läge för att få en konsekvent ögonblicksbild.

Viktiga funktioner i Konsekvent ögonblicksbild utan lås:

• Möjlighet att stödja tunga arbetsbelastningsservrar eller servrar med långvariga transaktioner utan att behöva läsa lås.
• Motståndskraftig vid slutförande av migreringar även i händelse av fel som orsakas av tillfälliga nätverks-/server-blippar som resulterar i förlust av alla förskapade anslutningar.

Aktivera konsekvent ögonblicksbild med läslås (GA)

När du aktiverar det här alternativet rensar tjänsten alla tabeller på källservern med ett läslås för att hämta ögonblicksbilden för tidpunkt. Den här tömningen görs eftersom ett globalt lås är mer tillförlitligt än att försöka låsa enskilda databaser eller tabeller. Även om du inte migrerar alla databaser på en server är de därför låsta som en del av konfigurationen av migreringsprocessen. Migreringstjänsten initierar en upprepningsbar läsning och kombinerar det aktuella tabelltillståndet med innehållet i ångra-loggen för ögonblicksbilden. Ögonblicksbilden genereras efter att serverns breda lås har hämtats i några sekunder och flera anslutningar har skapats för migreringen. När alla anslutningar som används för migreringen har skapats släpps låsen på tabellen.

Upprepningsbara läsningar är aktiverade för att hålla ångra loggarna tillgängliga under migreringen, vilket ökar lagringen som krävs på källan på grund av långvariga anslutningar. En långvarig migrering med flera tabelländringar leder till en omfattande ångra logghistorik som måste spelas upp igen och kan också öka beräkningskraven och belastningen på källservern.

Gör källservern skrivskyddad

Om du väljer det här alternativet bibehålls dataintegriteten för måldatabasen eftersom källan migreras genom att förhindra skriv-/borttagningsåtgärder på källservern under migreringen. När du gör källservern skrivskyddad som en del av migreringsprocessen gäller valet för alla källserverns databaser, oavsett om de har valts för migrering.

Att göra källservern skrivskyddad hindrar användare från att ändra data, vilket gör databasen otillgänglig för alla uppdateringsåtgärder. Men om det här alternativet inte är aktiverat finns det en möjlighet att datauppdateringar sker under migreringen. Därför kan migrerade data vara inkonsekventa eftersom databasögonblicksbilderna skulle läsas vid olika tidpunkter.

Förutsättningar för att aktivera konsekvent ögonblicksbild med läslås

Så här slutför du migreringen med konsekvent ögonblicksbild med läslås aktiverat:

• Kontrollera att användaren som försöker rensa tabeller med ett läslås har behörigheten RELOAD eller FLUSH.

• Använd mysql-klientverktyget för att avgöra om log_bin är aktiverat på källservern. Bin-loggen är inte alltid aktiverad som standard och bör kontrolleras för att se om den är aktiverad innan migreringen påbörjas. Mysql-klientverktyget används för att avgöra om log_bin är aktiverat på källan genom att köra kommandot: SHOW VARIABLES LIKE 'log_bin';

• Konfigurera parametern binlog_expire_logs_seconds på källservern så att binlogfiler inte rensas innan repliken genomför ändringarna. Efter en snabb snabb återställning kan värdet återställas.

Kända problem och begränsningar för Aktivera konsekvent ögonblicksbild utan lås

• Tabeller med sekundärnycklar som har Cascade eller Set Null vid borttagning/vid uppdatering stöds inte.
• Inga DDL-ändringar bör ske under den första inläsningen.

Kända problem och begränsningar för Aktivera konsekvent ögonblicksbild med läslås

Kända problem och begränsningar som är associerade med konsekvent säkerhetskopiering finns i stort sett i två kategorier: lås och återförsök.

Lås

Vanligtvis är det en enkel process att få ett lås, vilket bör ta mellan några sekunder och ett par minuter att slutföra. I några scenarier kan dock försök att få ett lås på källservern misslyckas.

• Förekomsten av tidskrävande frågor kan leda till onödig stilleståndstid, eftersom DMS kan låsa en delmängd av tabellerna och sedan överskrida tidsgränsen i väntan på att de sista ska vara tillgängliga. Innan du påbörjar migreringen kontrollerar du om det finns tidskrävande åtgärder genom att köra kommandot SHOW PROCESSLIST .

• Om källservern har många skrivuppdateringar när ett lås begärs kan låset inte enkelt hämtas och kan misslyckas efter tidsgränsen för låsningsväntetid. Detta sker när det gäller batchbearbetningsuppgifter i tabellerna, vilket när det pågår kan leda till att begäran om ett lås nekas. Som tidigare nämnts är det begärda låset ett enda lås på global nivå för hela servern, så även om en enskild tabell eller databas bearbetas måste låsbegäran vänta tills den pågående uppgiften avslutas.

• En annan begränsning gäller migrering från en AWS RDS-källserver. RDS stöder inte tömningstabeller med läslås och LOCK TABLE-frågan körs på de valda tabellerna under huven. Eftersom tabellerna är låsta individuellt kan låsningsprocessen vara mindre tillförlitlig och lås kan ta längre tid att hämta.

Försök

Migreringen hanterar tillfälliga anslutningsproblem och ytterligare anslutningar etableras vanligtvis i förväg för detta ändamål. Vi tittar på migreringsinställningarna, särskilt antalet parallella läsåtgärder på källan och tillämpar en faktor (vanligtvis ~1,5) och skapar så många anslutningar i förväg. På så sätt ser tjänsten till att vi kan hålla åtgärderna igång parallellt. När som helst, om det uppstår en anslutningsförlust eller om tjänsten inte kan hämta ett lås, använder tjänsten de överskottsanslutningar som har etablerats för att försöka utföra migreringen igen. Om alla etablerade anslutningar är uttömda, vilket resulterar i att synkroniseringen vid tidpunkten går förlorad, måste migreringen startas om från början. Vid både lyckade och misslyckade åtgärder utförs alla rensningsåtgärder av den här offlinemigreringstjänsten och användaren behöver inte utföra några explicita rensningsåtgärder.

Relaterat innehåll

• Datareplikering
• Självstudie: Migrera MySQL till Azure Database for MySQL offline med DMS