PostgreSQL-Datenbankmigration mit 11 Sekunden Downtime abgeschlossen
(gds.blog.gov.uk)So wurde eine PostgreSQL-Datenbank migriert
- GOV.UK Notify verlagert derzeit seine gesamte Infrastruktur in ein eigenes AWS-Konto, da das aktuell genutzte PaaS eingestellt wird.
- Dieser Artikel beschreibt, wie die PostgreSQL-Datenbank mit minimaler Downtime migriert wurde.
Datenbankmigration
- Es wird eine von der PaaS bereitgestellte AWS-RDS-PostgreSQL-Datenbank verwendet, die in eine neue Datenbank im eigenen AWS-Konto migriert werden muss.
- Die zentrale Herausforderung besteht darin, eine neue PostgreSQL-Datenbank einzurichten und dafür zu sorgen, dass alle Apps mit der neuen Datenbank kommunizieren.
Weitere Informationen zur Quelldatenbank
- Die Quelldatenbank ist etwa 400 GB groß und enthält 130 Millionen Zeilen, 85 Tabellen, 185 Indizes und 120 Fremdschlüssel.
- An Werktagen gibt es etwa 1.000 Inserts oder Updates pro Sekunde, und GOV.UK Notify versendet täglich Millionen wichtiger und zeitkritischer Benachrichtigungen.
AWS Database Migration Service
- Mithilfe des AWS Database Migration Service (DMS) werden Daten von der Quelldatenbank in die Zieldatenbank übertragen.
- DMS kopiert mit einem „Full Load“-Job alle Daten bis zu einem bestimmten Zeitpunkt; im Replikationsmodus sorgt es dafür, dass alle neuen Transaktionen der Quelldatenbank in der Zieldatenbank übernommen werden.
Ablauf der Datenbankmigration
Einrichtung der DMS-Instanz
- Im AWS-Quellkonto wird eine DMS-Instanz erstellt und mit PostgreSQL-Zugangsdaten ausgestattet, die Zugriff auf Quell- und Zieldatenbank haben.
Einrichtung der Zieldatenbank
- Im eigenen AWS-Konto wird eine Ziel-RDS-Instanz erstellt und die PostgreSQL-Version auf 15 aktualisiert.
- Mit
pg_dumpwird das Schema der Quelldatenbank exportiert, und die Tabellendefinitionen werden auf die Zieldatenbank angewendet.
Full Load
- Nachdem die Tabellen in der Zieldatenbank erstellt wurden, wird der DMS-Full-Load-Job gestartet und nach etwa 6 Stunden abgeschlossen.
- Nach Abschluss des Full-Load-Jobs werden Indizes und Schlüssel-Constraints hinzugefügt.
Replikation
- Nach Abschluss des Full Load wird ein DMS-Job für kontinuierliche Replikation (Change Data Capture) gestartet, um Quell- und Zieldatenbank zu synchronisieren.
Vorbereitung der Traffic-Migration
- Es wird geplant, wie die Apps die Kommunikation mit der Quelldatenbank beenden und stattdessen mit der Zieldatenbank verbinden.
Stoppen des Traffics zur Quelldatenbank
- Mit einem Skript wird jeglicher Traffic zur Quelldatenbank gestoppt.
Überprüfung der Replikation
- Es wird geprüft, ob die Zieldatenbank vollständig synchronisiert ist.
Reibungslose Umschaltung des Traffics
- Die für die Datenbankverbindung nötigen Angaben wie Adresse, Benutzername und Passwort werden den Apps per Umgebungsvariablen bereitgestellt, und über eine DNS-Änderung wird die Datenbank schnell umgeschaltet.
Was am Tag der Migration geschah
- Das Migrationsskript wurde erfolgreich ausgeführt, sodass die Apps die Kommunikation mit der Quelldatenbank beendeten und mit der neuen Zieldatenbank kommunizierten.
- Während der Migration kam es zu einer kurzen Downtime von etwa 11 Sekunden.
Erkenntnisse
- DMS wurde gewählt, weil es von GOV.UK PaaS gut unterstützt wurde und zudem Support von AWS verfügbar war.
- Bei künftigen Datenbankmigrationen zwischen PostgreSQL-Systemen würde mehr Zeit investiert, um auch andere Tools wie pglogical auszuprobieren.
Nächste Schritte bei der Migration von GOV.UK Notify zu AWS
- Nach Abschluss der Datenbankmigration sollen die Apps zu AWS Elastic Container Service (ECS) migriert werden.
GN⁺-Meinung:
- Das Wichtigste an diesem Beitrag ist, dass das GOV.UK-Notify-Team seine PostgreSQL-Datenbank mit dem AWS Database Migration Service (DMS) erfolgreich migriert hat.
- Der Artikel bietet Technikexpertinnen und -experten, die eine Datenbankmigration planen, eine nützliche praxisnahe Orientierung.
- Er liefert Einblicke, wie sich Downtime bei einer Migration minimieren und zugleich Datenkonsistenz sicherstellen lässt, was auch für andere Organisationen oder Einzelpersonen in ähnlichen Situationen hilfreich sein kann.
1 Kommentare
Hacker-News-Kommentare
Es wird infrage gestellt, warum die Regierung AWS nutzt; stattdessen wird argumentiert, dass der Aufbau einer Public-Sector-Cloud oder ein On-Prem-Ansatz langfristig Steuergelder sparen könnte.
Es wird die Erfahrung geteilt, dass eine Datenbankmigration mit AWS RDS Blue-Green Deployment erfolgreich mit rund 20 Sekunden Downtime durchgeführt wurde.
Es werden verschiedene Methoden erwähnt, PostgreSQL-Abfragen vorübergehend anzuhalten, und erklärt, dass sich die Downtime reduzieren lässt, indem Abfragen verzögert werden, bis die Replikation aufgeholt hat.
Es wird der Prozess beschrieben, eine selbst gehostete PostgreSQL-Datenbank von Version 12 auf 16 zu migrieren; dabei wird geteilt, dass es wegen unerwarteter Probleme zu etwa 30 Minuten Downtime kam.
Es wird erwähnt, dass die Nutzung des AWS Database Migration Service und das Austauschen des DNS-Eintrags bei 11 Sekunden Downtime ein Weg ist, Komplexität zu vermeiden.
Es wird darauf hingewiesen, dass lang laufende Abfragen der Feind von Migrationen mit geringer Downtime sind, und die Schwierigkeit beschrieben, mit solchen Abfragen umzugehen.
Es wird der Migrationsprozess von PostgreSQL 14 auf 16 geteilt, mit dem Hinweis, dass beim nächsten Mal AWS Blue-Green Deployment genutzt werden soll, um Downtime zu vermeiden.
Es wird erklärt, wie ein Datenbank-Migrationsskript mit DNS-Records in AWS Route53 die DNS-Gewichtung aktualisiert und darauf wartet, dass eine TTL von 1 Sekunde abläuft.
Es wird scherzhaft angemerkt, man freue sich darauf, dass Amazon ein Produkt namens „government-as-a-service“ veröffentlicht.
Es wird die Erfahrung geteilt, mit AWS DMS einen Datensatz von AWS RDS MySQL nach RDS PostgreSQL migriert zu haben; von der Nutzung des Schema Conversion Tool wird abgeraten.