MySQL naar Azure Database for MySQL-gegevensmigratie - Consistente mySQL-momentopname
MySQL Consistente momentopname is een nieuwe functie waarmee gebruikers een consistente momentopname van een MySQL-server kunnen maken zonder gegevensintegriteit bij de bron te verliezen vanwege lopende CRUD-bewerkingen (Maken, Lezen, Bijwerken en Verwijderen). Transactionele consistentie wordt bereikt zonder dat u de bronserver via deze functie hoeft in te stellen op de modus Alleen-lezen. Bovendien zijn er meerdere opties voor gegevensconsistentie beschikbaar voor de gebruiker: consistente momentopname inschakelen met leesvergrendeling (GA), consistente momentopname inschakelen zonder vergrendelingen (preview), bronserver alleen-lezen en geen maken. Als u de optie Geen selecteert, worden er geen extra maatregelen genomen om gegevensconsistentie te garanderen. We raden u ten zeerste aan de optie 'Consistente momentopname inschakelen zonder vergrendelingen' te selecteren om transactionele consistentie te behouden.
Consistente momentopname inschakelen zonder vergrendelingen (preview)
Wanneer u deze optie inschakelt, vindt er een afstemmingsfase plaats na de eerste belasting. Dit is om ervoor te zorgen dat de gegevens die naar uw doel worden geschreven, transactioneel consistent zijn met de bronserver vanaf een specifieke positie in het binaire logboek.
Met deze functie nemen we geen leesvergrendeling op de server. In plaats daarvan lezen we tabellen op een ander moment, terwijl we de verschillende binlog-posities van elke tabel bijhouden. Dit helpt bij het afstemmen van de tabellen aan het einde van de eerste belasting door replicatie uit te voeren in de inhaalmodus om een consistente momentopname te krijgen.
Belangrijke functies van consistente momentopname zonder vergrendelingen:
- Mogelijkheid om zware werkbelastingservers of -servers te ondersteunen met langlopende transacties zonder leesvergrendelingen.
- Tolerant bij het voltooien van migraties, zelfs in het geval van storingen die worden veroorzaakt door tijdelijke netwerk-/server-blip's die leiden tot verlies van alle vooraf gemaakte verbindingen.
Consistente momentopname inschakelen met leesvergrendeling (GA)
Wanneer u deze optie inschakelt, worden alle tabellen op de bronserver door de service leeggemaakt met een leesvergrendeling om de momentopname van een bepaald tijdstip te verkrijgen. Dit leegmaken wordt uitgevoerd omdat een globale vergrendeling betrouwbaarder is dan het vergrendelen van afzonderlijke databases of tabellen. Als gevolg hiervan, zelfs als u niet alle databases op een server migreert, worden ze vergrendeld als onderdeel van het instellen van het migratieproces. De migratieservice initieert een herhaalbare leesbewerking en combineert de huidige tabelstatus met de inhoud van het ongedaan maken van het logboek voor de momentopname. De momentopname wordt gegenereerd nadat de serverbrede vergrendeling is verkregen en verschillende verbindingen voor de migratie zijn verkregen. Nadat alle verbindingen voor de migratie zijn gemaakt, worden de vergrendelingen in de tabel vrijgegeven.
Herhaalbare leesbewerkingen zijn ingeschakeld om de logboeken voor ongedaan maken toegankelijk te houden tijdens de migratie, waardoor de opslag die nodig is voor de bron toeneemt vanwege langdurige verbindingen. Een langdurige migratie met meerdere tabelwijzigingen leidt tot een uitgebreide logboekgeschiedenis die opnieuw moet worden afgespeeld en kan ook de rekenvereisten en belasting op de bronserver verhogen.
De bronserver alleen-lezen maken
Als u deze optie selecteert, blijft de gegevensintegriteit van de doeldatabase behouden terwijl de bron wordt gemigreerd door schrijf-/verwijderbewerkingen op de bronserver tijdens de migratie te voorkomen. Wanneer u de bronserver alleen-lezen maakt als onderdeel van het migratieproces, is de selectie van toepassing op alle databases van de bronserver, ongeacht of deze zijn geselecteerd voor migratie.
Als u de bronserver alleen-lezen maakt, voorkomt u dat gebruikers de gegevens wijzigen, waardoor de database niet beschikbaar is voor updatebewerkingen. Als deze optie echter niet is ingeschakeld, is er een mogelijkheid dat gegevensupdates plaatsvinden tijdens de migratie. Hierdoor kunnen gemigreerde gegevens inconsistent zijn omdat de momentopnamen van de database op verschillende tijdstippen worden gelezen.
Vereisten voor het inschakelen van consistente momentopnamen met leesvergrendeling
De migratie voltooien met consistente momentopname waarvoor leesvergrendeling is ingeschakeld:
Zorg ervoor dat de gebruiker die tabellen probeert te leegmaken met een leesvergrendeling de machtiging RELOAD of FLUSH heeft.
Gebruik het hulpprogramma mysql-client om te bepalen of log_bin is ingeschakeld op de bronserver. Het bin-logboek is niet altijd standaard ingeschakeld en moet worden gecontroleerd of het is ingeschakeld voordat de migratie wordt gestart. Het hulpprogramma mysql-client wordt gebruikt om te bepalen of log_bin is ingeschakeld op de bron door de opdracht SHOW VARIABLES LIKE 'log_bin' uit te voeren;
Notitie
Met Azure Database for MySQL Enkele server, die maximaal 4 TB ondersteunt, is dit niet standaard ingeschakeld. Als u echter een leesreplica voor de bronserver promoveert en vervolgens leesreplica verwijdert, wordt de parameter ingesteld op AAN.
- Configureer de parameter binlog_expire_logs_seconds op de bronserver om ervoor te zorgen dat binlog-bestanden niet worden opgeschoond voordat de replica de wijzigingen doorvoert. Na een geslaagde cutover kan de waarde opnieuw worden ingesteld.
Bekende problemen en beperkingen voor het inschakelen van consistente momentopnamen zonder vergrendelingen
- Tabellen met refererende sleutels met Trapsgewijs of Null instellen bij verwijderen/bijwerken worden niet ondersteund.
- Er moeten geen DDL-wijzigingen optreden tijdens de eerste belasting.
Bekende problemen en beperkingen voor het inschakelen van consistente momentopnamen met leesvergrendeling
De bekende problemen en beperkingen die zijn gekoppeld aan Consistente back-up vallen in grote lijnen in twee categorieën: vergrendelingen en nieuwe pogingen.
Notitie
De migratieservice voert de QUERY START TRANSACTION WITH CONSISTENT SNAPSHOT uit voor alle werkrolthreads om de momentopname van de server op te halen. Maar dit wordt alleen ondersteund door InnoDB. Meer informatie hier.
Vergrendelingen
Normaal gesproken is het een eenvoudig proces om een vergrendeling te verkrijgen. Dit duurt een paar seconden tot een paar minuten. In enkele scenario's kunnen pogingen om een vergrendeling op de bronserver te verkrijgen echter mislukken.
De aanwezigheid van langlopende query's kan leiden tot onnodige downtime, omdat DMS een subset van de tabellen kan vergrendelen en er vervolgens een time-out optreedt die wacht tot de laatste paar beschikbaar zijn. Controleer voordat u de migratie start op langdurige bewerkingen door de opdracht SHOW PROCESSLIST uit te voeren.
Als de bronserver veel schrijfupdates ondervindt op het moment dat een vergrendeling wordt aangevraagd, kan de vergrendeling niet direct worden verkregen en kan deze mislukken na de time-out voor vergrendelingswachttijden. Dit gebeurt in het geval van batchverwerkingstaken in de tabellen, wat kan leiden tot het weigeren van de aanvraag voor een vergrendeling. Zoals eerder vermeld, is de aangevraagde vergrendeling één algemene vergrendeling voor de hele server, dus zelfs als één tabel of database wordt verwerkt, moet de vergrendelingsaanvraag wachten tot de lopende taak is afgesloten.
Een andere beperking heeft betrekking op het migreren van een AWS RDS-bronserver. RDS biedt geen ondersteuning voor leeggemaakte tabellen met leesvergrendeling en LOCK TABLE-query wordt uitgevoerd op de geselecteerde tabellen onder de kap. Omdat de tabellen afzonderlijk zijn vergrendeld, kan het vergrendelingsproces minder betrouwbaar zijn en kan het langer duren voordat de vergrendelingen worden verkregen.
Nieuwe pogingen
De migratie verwerkt tijdelijke verbindingsproblemen en aanvullende verbindingen worden doorgaans vooraf ingericht voor dit doel. We kijken naar de migratie-instellingen, met name het aantal parallelle leesbewerkingen op de bron en passen een factor toe (meestal ~1,5) en maken zo veel verbindingen vooraf. Op deze manier zorgt de service ervoor dat bewerkingen parallel worden uitgevoerd. Als er op enig moment een verbindingsverlies is of als de service geen vergrendeling kan verkrijgen, gebruikt de service de overschotverbindingen die zijn ingericht om de migratie opnieuw uit te voeren. Als alle ingerichte verbindingen uitgeput zijn, wat resulteert in het verlies van de synchronisatie naar een bepaald tijdstip, moet de migratie vanaf het begin opnieuw worden gestart. In gevallen van slagen en mislukken worden alle opschoonacties uitgevoerd door deze offlinemigratieservice en hoeft de gebruiker geen expliciete opschoonacties uit te voeren.