Jede Datenbankmigration muss die Standardphasen der Datenmigration durchlaufen, wie z. B. die Analyse der Kompatibilität, die Schema-Validierung usw. Zwei erwähnenswerte Herausforderungen sind die Geschwindigkeit, mit der wir in der Lage sein werden, über eine Milliarde Zeilen (fast 1 TB) zu dumpen und neu zu laden, und die Planung einer Migration, die es uns ermöglicht, auf unerwartete Situationen zu reagieren, indem wir in eine sichere Umgebung mit minimaler Ausfallzeit und ohne Datenverlust wechseln.
Wir haben einige Zeit damit verbracht, herauszufinden, wie wir Daten schneller in Aurora laden können. Der übliche Engpass ist der Datenexport/-import. Jetzt wissen wir, dass der Datenimport abgeschlossen sein muss, bevor das Binlog rotiert wird. Nachdem wir verschiedene Optionen auf eigene Faust ausprobiert hatten, wandten wir uns an den AWS-Support, um eine zweite Meinung einzuholen. Indem wir die Elastizität von AWS und insbesondere von RDS Aurora nutzten, konnten wir die Datenlast innerhalb von Stunden statt Tagen hochskalieren und abschließen und sie dann wieder auf die normale Nutzung zurückführen.
Die zweite Herausforderung der Live-Migration und des Rollforwards im Falle einer Katastrophe ist eine ziemlich komplizierte Aufgabe. Zunächst mussten wir unsere neue Aurora-Datenbank als Replikat der aktuellen Datenbank erstellen. Sobald die Replikation abgeschlossen war, erstellten wir eine weitere Datenbank mit der alten DB-Engine als Replikat der neuen Aurora-Datenbank. Schau, wie das Diagramm aussieht. Auf PowerPoint sieht es einfach aus, aber in Wirklichkeit sind es Bits & Bytes und etwas dunkle Magie. Dank ausgiebiger Tests und Planung konnten wir die Live-Migration ohne Hindernisse durchführen, und nach ein paar Tagen war auch der Rollforward entfernt.
