Teilen über

Datenmigration von MySQL zu Azure Database for MySQL: MySQL – Konsistente Momentaufnahme

  • Artikel

MySQL – Konsistente Momentaufnahme ist ein neues Feature, mit dem Sie eine konsistente Momentaufnahme eines MySQL-Servers durchführen können, ohne die Datenintegrität der Quelle zu verlieren, da fortlaufende CRUD-Vorgänge (Erstellen, Lesen, Aktualisieren und Löschen) ausgeführt werden. Transaktionskonsistenz wird erreicht, ohne dass der Quellserver durch dieses Feature in den schreibgeschützten Modus versetzt werden muss. Darüber hinaus haben Sie mehrere Optionen für die Datenkonsistenz: „Konsistente Momentaufnahme mit Lesesperre aktivieren“ (GA), „Konsistente Momentaufnahme ohne Sperren aktivieren“ (Vorschau), „Schreibschutz für Quellserver festlegen“ und „Keine“. Wenn Sie die Option „Keine“ auswählen, werden keine zusätzlichen Maßnahmen ergriffen, um die Datenkonsistenz sicherzustellen. Beide Optionen: Aktivieren Sie eine konsistente Momentaufnahme mit Lesesperre (GA), ermöglichen Sie eine konsistente Momentaufnahme ohne Sperren, die die Durchführung einer Onlinemigration unterstützen. Es wird dringend empfohlen, die Option „Konsistente Momentaufnahme ohne Sperren aktivieren“ auszuwählen, um die Transaktionskonsistenz aufrechtzuerhalten.

Datenmigrations-Assistent für MySQL zu Azure Database for MySQL: Aktivieren der Transaktionskonsistenz

Konsistente Momentaufnahme ohne Sperren aktivieren (Vorschau)

Wenn Sie diese Option aktivieren, wird nach dem ersten Laden eine Abgleichsphase durchgeführt. Dadurch wird sichergestellt, dass die in Ihr Ziel geschriebenen Daten transaktionskonsistent mit dem Quellserver an einer bestimmten Stelle im Binärprotokoll sind.

Bei diesem Feature erfolgt keine Lesesperre auf dem Server. Stattdessen werden die Tabellen zu unterschiedlichen Zeitpunkten gelesen und dabei die verschiedenen Binärprotokollpositionen jeder Tabelle nachverfolgt. Dadurch können die Tabellen am Ende des anfänglichen Ladens abgeglichen werden, indem die Replikation im Nachholmodus ausgeführt wird, um eine konsistente Momentaufnahme zu erhalten.

Datenmigrations-Assistent für MySQL zu Azure Database for MySQL: Migrationsstatus

Datenmigrations-Assistent für MySQL zu Azure Database for MySQL: Abgleichsstatus

Wichtige Features der konsistenten Momentaufnahme ohne Sperren:

  • Möglichkeit zur Unterstützung von Servern mit hoher Workload oder Servern mit zeitintensiven Transaktionen, ohne dass Lesesperren erforderlich sind
  • Ausfallsicherheit beim Abschließen von Migrationsvorgängen auch im Fall von Fehlern, die durch vorübergehende Netzwerk-/Serverausfälle verursacht werden und zum Verlust aller vordefinierten Verbindungen führen

Konsistente Momentaufnahme mit Lesesperre aktivieren (GA)

Wenn Sie diese Option aktivieren, leert der Dienst alle Tabellen auf dem Quellserver mit einer Lesesperre, um die Zeitpunktmomentaufnahme abzurufen. Diese Leerung erfolgt, da eine globale Sperre zuverlässiger ist als der Versuch, einzelne Datenbanken oder Tabellen zu sperren. Daher werden die Datenbanken bei der Einrichtung des Migrationsprozesses auch dann gesperrt, wenn Sie nicht alle Datenbanken auf einem Server migrieren. Der Migrationsdienst initiiert einen wiederholbaren Lesevorgang und kombiniert den aktuellen Tabellenzustand mit dem Inhalt des Protokolls zum Rückgängigmachen für die Momentaufnahme. Die Momentaufnahme wird generiert, nachdem die serverweite Sperre für einige Sekunden eingerichtet wurde und mehrere Verbindungen für die Migration erzeugt wurden. Nach der Erstellung aller Verbindungen, die für die Migration verwendet werden sollen, werden die Sperren in der Tabelle aufgehoben.

Wiederholbare Lesevorgänge werden aktiviert, damit während der Migration weiter auf die Protokolle zum Rückgängigmachen zugegriffen werden kann. Dadurch wird der für die Quelle benötigte Speicher aufgrund zeitintensiver Verbindungen erhöht. Eine zeitintensive Migration mit mehreren Tabellenänderungen führt zu einem umfangreichen Protokoll für das Rückgängigmachen, das wiedergegeben werden muss, und sie kann auch die Computeanforderungen und die Last auf dem Quellserver erhöhen.

Schreibschutz für Quellserver festlegen

Bei Auswahl dieser Option bleibt die Datenintegrität der Zieldatenbank erhalten, da die Quelle migriert wird, indem Schreib-/Löschvorgänge auf dem Quellserver während der Migration verhindert werden. Wenn Sie den Quellserver im Rahmen des Migrationsprozesses als schreibgeschützt festlegen, gilt dies für alle Datenbanken des Quellservers, unabhängig davon, ob sie für die Migration ausgewählt wurden.

Durch Versetzen des Quellservers in den schreibgeschützten Modus wird verhindert, dass Benutzer die Daten bearbeiten und dass die Datenbank dadurch nicht mehr für Aktualisierungsvorgänge verfügbar ist. Wenn diese Option jedoch nicht aktiviert ist, besteht die Möglichkeit, dass während der Migration Datenupdates erfolgen. Daher können migrierte Daten inkonsistent sein, da die Datenbankmomentaufnahmen zu verschiedenen Zeitpunkten gelesen werden wurden.

Voraussetzungen für „Konsistente Momentaufnahme mit Lesesperre aktivieren“

So schließen Sie die Migration mit der Option „Konsistente Momentaufnahme mit Lesesperre aktivieren“ erfolgreich ab

  • Stellen Sie sicher, dass der Benutzer, der versucht, Tabellen mit einer Lesesperre zu leeren, über die Berechtigung zum erneuten Laden oder zum Leeren verfügt.

  • Verwenden Sie das mysql-Clienttool, um zu bestimmen, ob log_bin auf dem Quellserver aktiviert ist. Das Binärprotokoll ist standardmäßig nicht immer aktiviert. Vor dem Start der Migration muss überprüft werden, ob es aktiviert ist. Das mysql-Clienttool wird verwendet, um zu ermitteln, ob log_bin auf der Quelle aktiviert ist, indem Sie folgenden Befehl ausführen: SHOW VARIABLES LIKE 'log_bin';

Hinweis

Bei Azure Database for MySQL Single Server mit Unterstützung für bis zu 4 TB ist die Option nicht standardmäßig aktiviert. Wenn Sie jedoch ein Lesereplikat für den Quellserver höher stufen und dann das Lesereplikat löschen, wird der Parameter auf „ON“ festgelegt.

  • Konfigurieren Sie den binlog_expire_logs_seconds-Parameter auf dem Quellserver, um sicherzustellen, dass Binärprotokolldateien nicht endgültig gelöscht werden, bevor das Replikat die Änderungen committet. Nach der erfolgreichen Übernahme kann der Wert zurückgesetzt werden.

Bekannte Probleme und Einschränkungen bei „Konsistente Momentaufnahme ohne Sperren aktivieren“

  • Tabellen mit Fremdschlüsseln mit „Cascade“ oder „Set Null“ in der delete- oder on update-Klausel werden nicht unterstützt.
  • Während des anfänglichen Ladens sollten keine DDL-Änderungen vorgenommen werden.

Bekannte Probleme und Einschränkungen bei „Konsistente Momentaufnahme mit Lesesperre aktivieren“

Die bekannten Probleme und Einschränkungen in Verbindung mit der konsistenten Sicherung fallen allgemein in zwei Kategorien: Sperrungen und Wiederholungen.

Hinweis

Der Migrationsdienst führt die Abfrage START TRANSACTION WITH CONSISTENT SNAPSHOT für alle Arbeitsthreads aus, um die Servermomentaufnahme abzurufen. Dies wird jedoch nur von InnoDB unterstützt. Weitere Informationen

Locks

Normalerweise ist es einfach, eine Sperre zu erhalten, die zwischen einigen Sekunden und ein paar Minuten dauern sollte. In einigen Szenarien können jedoch bei Versuchen, eine Sperre auf dem Quellserver zu erhalten, Fehler auftreten.

  • Zeitintensive Abfragen könnten zu unnötigen Ausfallzeiten führen, da DMS eine Teilmenge der Tabellen sperren kann und dann ein Timeout auftreten kann, während gewartet wird, bis die letzten verfügbar werden. Suchen Sie vor dem Start der Migration nach zeitintensiven Vorgängen, indem Sie den Befehl SHOW PROCESSLIST ausführen.

  • Wenn auf dem Quellserver zu dem Zeitpunkt, zu dem eine Sperre angefordert wird, viele Schreibupdates auftreten, kann die Sperre nicht sofort abgerufen werden, und nach dem Lock-Wait-Timeout könnte ein Fehler auftreten. Dies geschieht bei Batchverarbeitungsaufgaben in den Tabellen, die zu einem Ablehnen der Anforderung für eine Sperrung führen können. Wie bereits erwähnt, ist die angeforderte Sperre eine einzelne globale Sperre für den gesamten Server, sodass auch bei Verarbeitung von nur einer einzelnen Tabelle oder Datenbank die Sperranforderung auf den Abschluss der laufenden Aufgabe warten muss.

  • Eine weitere Einschränkung bezieht sich auf die Migration von einem AWS RDS-Quellserver. RDS unterstützt keine Bereinigungstabellen mit Lesesperre. Außerdem wird die LOCK TABLE-Abfrage im Hintergrund an den ausgewählten Tabellen ausgeführt. Da die Tabellen einzeln gesperrt sind, kann der Sperrvorgang weniger zuverlässig sein, und der Erwerb von Sperren kann länger dauern.

Wiederholungsversuche

Die Migration behandelt vorübergehende Verbindungsprobleme. Zusätzliche Verbindungen werden zudem in der Regel vorher zu diesem Zweck bereitgestellt. Wir betrachten die Migrationseinstellungen, insbesondere die Anzahl der parallelen Lesevorgänge an der Quelle, wenden einen Faktor (normalerweise ~1,5) an und erstellen eine entsprechende Anzahl an Verbindungen vorab. Auf diese Weise stellt der Dienst sicher, dass wir Vorgänge parallel ausführen können. Wenn zu einem beliebigen Zeitpunkt ein Verbindungsverlust auftritt oder der Dienst keine Sperrung erlangen kann, verwendet der Dienst die bereitgestellten überschüssigen Verbindungen, um die Migration zu wiederholen. Wenn die Anzahl der bereitgestellten Verbindungen erschöpft ist, was zum Verlust der Zeitpunktsynchronisierung führt, muss die Migration neu gestartet werden. Bei Erfolg und bei einem Fehler werden alle Bereinigungsaktionen von diesem Offlinemigrationsdienst durchgeführt. Der Benutzer muss keine expliziten Bereinigungsaktionen ausführen.

Nächste Schritte