PostgreSQL-Datenbank mit 11 Sekunden Downtime migriert

• GOV.UK Notify reduzierte die Downtime beim Umzug einer 400-GB-PostgreSQL-11-Datenbank auf PostgreSQL 15 RDS im eigenen AWS-Konto im Zuge des PaaS-Endes auf rund 11 Sekunden
• In der Ziel-DB wurden zunächst nur die Tabellen angelegt und die Daten per DMS full load kopiert; Indizes und Schlüssel-Constraints wurden erst danach angewendet, um die Ladezeit großer Datenmengen zu verkürzen
• Die Quelldatenbank umfasste rund 1,3 Milliarden Zeilen, 85 Tabellen, 185 Indizes und 120 Fremdschlüssel; an Werktagen fielen etwa 1.000 Inserts/Updates pro Sekunde sowie ähnlich viele Lesezugriffe an
• Wegen der Einschränkung, dass ein Redeploy der Anwendung etwa 5 Minuten dauert, wurden im Vorfeld identische Zugangsdaten und eine Route53-DNS-Gewichtungsumschaltung vorbereitet, um die eigentliche Umschaltzeit zu verkürzen
• DMS wurde gewählt, weil es auf der PaaS gut unterstützt wurde und AWS-Support leicht verfügbar war; für Migrationen zwischen PostgreSQL-Systemen wäre eine Alternative wie pglogical womöglich einfacher gewesen

---

Notify-Datenbankmigration im Zuge des PaaS-Endes

• GOV.UK Notify wurde auf GOV.UK Platform as a Service gehostet, und wegen des Endes der PaaS musste die gesamte Infrastruktur in ein eigenes AWS-Konto umziehen
• Die Datenbank von Notify ist eine AWS RDS PostgreSQL im AWS-Konto der PaaS und speichert alles von Benachrichtigungsversanddaten bis zu den Inhalten von Hunderttausenden Vorlagen, die die Service-Teams verwenden
• Zur Unterscheidung während der Migration wurde die bestehende Datenbank als source database und die neue Datenbank als target database bezeichnet
• Die zentrale Herausforderung war nicht das Erstellen einer neuen PostgreSQL-Datenbank, sondern die Downtime zu minimieren, während alle Daten umgezogen und die Anwendungen auf die neue Zielinstanz umgeschaltet wurden

Umfang der Quelldatenbank und Service-Einschränkungen

• Die Quelldatenbank war eine PostgreSQL-11-Instanz mit rund 400 GB
  • etwa 1,3 Milliarden Zeilen
  • 85 Tabellen
  • 185 Indizes
  • 120 Fremdschlüssel
• An einem normalen Werktag gab es etwa 1.000 Inserts oder Updates pro Sekunde, dazu eine ähnliche Zahl von Lesezugriffen
• GOV.UK Notify versendet täglich Millionen wichtiger und zeitkritischer Benachrichtigungen, etwa Hochwasserwarnungen oder Statusupdates zu Passanträgen
• Da jeder Benachrichtigungsversand einen Datenbankzugriff benötigt, musste die Unterbrechung des Dienstes kurz gehalten werden

Architektur für Initial-Load und kontinuierliche Replikation mit DMS

• Das PaaS-Team stellte einen Migrationsansatz mit dem AWS Database Migration Service bereit
• DMS übernimmt die Übertragung der Daten von der Quelldatenbank in die Zieldatenbank und kann im AWS-Konto der Quelle oder des Ziels laufen
• Ein DMS-Task besteht aus zwei Phasen
  • full load: Alle bis zu einem bestimmten Zeitpunkt vorhandenen Daten werden tabellenweise kopiert
  • kontinuierliche Replikation: Neue Transaktionen aus der Quelldatenbank werden in der Zieldatenbank wiedergegeben, damit beide Datenbanken synchron bleiben
• Die eigentliche Umschaltung der Anwendung von der Quelldatenbank auf die Zieldatenbank lag direkt beim Notify-Team

Vorbereitung der Zieldatenbank und full load

• Die DMS-Instanz wurde im AWS-Konto der Quelle erstellt
  • Das PaaS-Team hatte bereits eine DMS-Instanz im Konto eingerichtet, sodass die Vorbereitung schnell erfolgen konnte
  • Die DMS-Instanz benötigte Zugangsdaten für die Verbindung zur Quell- und zur Ziel-PostgreSQL-Datenbank
• Da sich DMS-Instanz und Zieldatenbank in unterschiedlichen VPCs befanden, wurde VPC peering eingerichtet, damit DMS-Traffic aus der PaaS-VPC ohne Umweg über das öffentliche Internet in die eigene VPC geroutet werden konnte
• Die Ziel-RDS-Instanz wurde im eigenen AWS-Konto angelegt; da das Support-Ende für PostgreSQL 11 näher rückte, wurde die neue Datenbank als PostgreSQL 15 aufgesetzt
• Mit pg_dump wurde das Schema der Quelldatenbank exportiert, um eine SQL-Datei zur Schema-Neuerstellung zu erzeugen; zunächst wurden daraus nur die Tabellendeklarationen in die Zieldatenbank eingespielt
• Fremdschlüssel wurden beim full load nicht angewendet
  • Der Grund: DMS full load kopiert Daten nicht in einer Reihenfolge, die Fremdschlüssel-Constraints berücksichtigt
• Primärschlüssel und Indizes wurden ebenfalls nicht vor dem full load angelegt
  • Sonst müsste bei jedem Insert ein Index aktualisiert werden, was bei Milliarden von Zeilen die Gesamtzeit deutlich erhöhen kann
  • Es war schneller, erst alle Daten zu kopieren und die Indizes anschließend hinzuzufügen
• Der full load kopierte die Daten, die zum Zeitpunkt des Startklicks vorhanden waren
  • Neue Daten oder Änderungen nach diesem Zeitpunkt waren nicht Teil des full load
  • Der Abschluss des full load dauerte etwa 6 Stunden
• Nach dem full load wurde der restliche Teil der Schema-Datei angewendet, um Indizes und Schlüssel-Constraints hinzuzufügen; das dauerte etwa 3 Stunden

Zehn Tage Replikation vor der Verkehrsumschaltung

• Nach dem full load entsprach die Zieldatenbank dem Stand der Quelldatenbank zum Beginn des full load, doch in der Quelle liefen Inserts, Updates und Deletes weiter
• Deshalb wurde die kontinuierliche Replikation von DMS gestartet, also change data capture, um Transaktionen aus dem transaction log der Quelldatenbank seit Start des full load in die Zieldatenbank zu übertragen
• Es dauerte einige Stunden, bis der Replikationsprozess aufgeholt hatte; danach wurde die Replikationsverzögerung von DMS überwacht, um den Synchronisationszustand zu prüfen
• Die DMS-Replikation lief rund 10 Tage im Hintergrund und hielt beide Datenbanken bis zum vorab angekündigten Umschaltzeitpunkt synchron
• Das Verfahren für die Verkehrsumschaltung wurde vorab als Python-Skript geschrieben
  • Es stoppt den Anwendungstraffic zur Quelldatenbank
  • es prüft, ob die Replikation vollständig aufgeholt hat
  • es erlaubt der Anwendung, sich mit der Zieldatenbank zu verbinden
• Es musste vermieden werden, dass ein Teil der Anwendungen noch die Quell-DB und der Rest bereits die Ziel-DB verwendet
  • Änderungen in der Ziel-DB werden nicht zurück in die Quell-DB gespiegelt, sodass Nutzer inkonsistente Daten sehen könnten
• Das Skript wurde so gebaut, dass es expliziter, wiederholbar und schneller ist als manuelle Arbeit, und wurde in Vorabtests und Übungen mindestens 40 Mal verwendet
• Ziel war eine Downtime von unter 5 Minuten, und der Migrationszeitpunkt wurde auf einen relativ ruhigen Samstagabend gelegt, ohne mitten in der Nacht zu liegen

DNS-Umschaltung für 11 Sekunden Downtime

• Das Stoppen des Traffics zur Quelldatenbank erfolgte durch Aufrufe von pg_terminate_backend für Anwendungsverbindungen und dauerte weniger als eine Sekunde
• Damit sich die Anwendung nicht erneut mit der Quell-DB verbinden konnte, wurde zusätzlich das Passwort des PostgreSQL-Benutzers geändert, sodass Reconnects an der Authentifizierung scheiterten
• DMS legte in der Zieldatenbank eine Replikationsstatus-Tabelle an und aktualisierte sie jede Minute; das Migrationsskript nutzte diese Tabelle, um die Verzögerung zwischen Quelle und Ziel zu prüfen
• Als zusätzliche Sicherheitsmaßnahme schrieb das Skript, nachdem die Anwendung den Zugriff auf die Quell-DB beendet hatte, einen einzelnen Datensatz in die Quell-DB und wartete darauf, dass er in der Ziel-DB ankam
• Die Verbindungsinformationen der Anwendung zur Datenbank wurden über die Umgebungsvariable SQLALCHEMY_DATABASE_URI bereitgestellt
  • Das bisherige Format war postgresql://[e-mail]:5432 mit Benutzername, Passwort und RDS-Standort
  • Änderungen an Datenbankadresse oder Zugangsdaten erforderten ein Redeploy der Anwendung, das etwa 5 Minuten dauerte
• Um zusätzliche Downtime durch ein Redeploy zu vermeiden, wurden vor der Migration zwei Dinge vorbereitet
  • In Quell- und Zieldatenbank wurden Benutzer mit identischem Benutzernamen und Passwort angelegt
  • In AWS Route53 wurde ein DNS-Record database.notifications.service.gov.uk mit einer TTL von 1 Sekunde erstellt
• Der DNS-Record war anfangs auf 100 % Gewichtung für die Quelle und 0 % für das Ziel gesetzt
• Die Anwendungs-URI wurde vorab auf den gemeinsamen Benutzernamen, das gemeinsame Passwort und den neuen Domainnamen umgestellt
• Bei der eigentlichen Umschaltung änderte das Skript die DNS-Gewichtung in AWS auf 100 % für das Ziel und wartete, bis die TTL von 1 Sekunde abgelaufen war
• Zum Umschaltzeitpunkt am Samstagabend, dem 4. November 2023, lag die Verzögerung zwischen Ziel- und Quelldatenbank bei wenigen Sekunden
• Nach Ausführung des Migrationsskripts stoppte die Anwendung den Zugriff auf die Quell-DB, begann die neue Zieldatenbank zu nutzen, und die Downtime betrug etwa 11 Sekunden

Bewertung der DMS-Wahl und nächste Schritte

• DMS wurde gewählt, weil es in der GOV.UK-PaaS gut unterstützt wurde und AWS-Support verfügbar war
• Falls künftig erneut eine Datenbankmigration zwischen PostgreSQL-Systemen ansteht, sollen alternative Werkzeuge wie pglogical stärker geprüft werden
• Möglicherweise brachte DMS mehr Komplexität und einen weniger vertrauten Replikationsprozess mit als andere Werkzeuge
• Nach der Datenbankmigration folgt als nächster Schritt die Migration der Anwendung
• Die GOV.UK-Notify-Anwendung soll zu AWS Elastic Container Service umziehen; der Verlauf dieses Schritts soll später geteilt werden

[GN⁺]

Meinungen auf Hacker News

• Wir haben eine ähnliche Migration mit AWS RDS Blue-Green Deployments gemacht; die Datenbank war etwas größer, die Downtime lag aber bei etwa 20 Sekunden und der Arbeitsaufwand war deutlich geringer. Ich bin überrascht, dass das in diesem Thread noch nicht erwähnt wurde.
  Im Grunde startet man ein neues Blue/Green-Deployment mit den gewünschten Änderungen, und während die bestehende Blue-Konfiguration weiter Traffic verarbeitet, synchronisiert AWS das Green-Deployment per logischer Replikation.
  Auf Green kann man Änderungen vornehmen sowie Tests und Lasttests durchführen, solange man nur nicht darauf schreibt; Schreibvorgänge gehen weiterhin auf das live laufende Blue und werden dann nach Green repliziert.
  Wenn alles bereit ist, führt man den Switch-Befehl aus, und AWS kümmert sich um die Synchronisationsprüfung, das Unterbrechen von Schreibvorgängen und Verbindungen, das Warten, bis die Replikation aufgeholt hat, das Umbenennen der Datenbanken sowie das Wiederaufnehmen von Verbindungen und Schreibvorgängen.
  Bei uns lag die Downtime unter 20 Sekunden, und die gesamte Konfiguration einschließlich Primary und mehrerer Read Replicas wurde problemlos umgeschaltet. AWS ändert auch die Datenbank-URL, sodass man keine Konfiguration anpassen muss; Green wird zu Blue, das bisherige Blue wird zu Old Blue und kann später gelöscht werden.
  Klare Empfehlung, auch wenn es Einschränkungen gibt, etwa dass es bei kontoübergreifenden Umzügen möglicherweise nicht funktioniert: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-...

  • +1 für Blue/Green. Allerdings dürfte es in diesem Fall wegen des kontoübergreifenden Umzugs nicht nutzbar gewesen sein. Ich habe es sowohl mit MySQL als auch mit Postgres verwendet; bei MySQL lag die Zahl der Queries pro Sekunde um zwei Größenordnungen höher als im Artikel, und beides lief reibungslos.
    Man sollte die Dokumentation, insbesondere die Einschränkungen, lesen und noch einmal lesen. Am besten testet man es in der Entwicklungsumgebung unter Last und wiederholt es dann auch im Staging.
    Oder man wirft es einfach YOLO in die Produktion; wahrscheinlich geht es trotzdem gut.
  • Wir haben RDS Blue/Green Deployments für ein Major-Engine-Version-Upgrade von MySQL 5.7 auf 8.0 verwendet, und aus Downtime-Sicht war es hervorragend. Die in der API beobachtete Downtime lag meiner Erinnerung nach bei etwa 13 Sekunden.
    Allerdings haben wir auf die harte Tour gelernt, dass RDS Blue/Green nicht für beliebige Änderungen einsetzbar ist. In unserem Fall stellte sich heraus, dass wir es nur für ein Upgrade der Engine-Version nutzen konnten, nicht für ein Downgrade.
    Unter MySQL 8.0 schlug eine gespeicherte Prozedur sehr gelegentlich fehl, daher prüften wir die Option, auf 5.7 zurückzugehen, aber das war nicht möglich.
  • Mich würde interessieren, ob schon jemand zuvor unverschlüsselten RDS-Storage per Blue/Green verschlüsselt hat.
  • Mich würde interessieren, wie ihr die Anwendungen, die auf die Datenbank zugreifen, angehalten und neu gestartet habt. Wir haben mehrere Tasks in ECS laufen; das Herunterfahren kann eine Minute dauern, das erneute Hochfahren mehrere Minuten.
  • +1 für Route53 Groups und eine Blue/Green-Konfiguration. Wir haben etwas Ähnliches bei einem PostgreSQL-Upgrade gemacht und es mit AWS R53 Groups sowie einem eigenen Patch für Rails-ActiveRecord-Transaktionen umgesetzt, der laufende Queries erneut versucht hat, sodass es ohne Downtime funktionierte.
    Der Trade-off war, dass einige Requests für ein paar Sekunden langsamer wurden.
    Die Kombination aus DNS Groups und Retries ist für solche Arbeiten ein ziemlich brauchbarer Mechanismus.
    Verwendetes Tool: https://github.com/shayonj/pg_easy_replicate

• Es gibt mehrere Möglichkeiten, eingehende Postgres-Queries „anzuhalten“, zum Beispiel mit pgbouncer, sodass sie nicht fehlschlagen, sondern verzögert werden, bis die Replikation aufgeholt hat, und dann auf der neuen Datenbank weiterlaufen.
  Wenn etwas schiefgeht und die Replikation nicht aufholt, kann man die Pause aufheben und diese Queries auf der alten Datenbank ausführen lassen.
  Damit werden aus 11 Sekunden Downtime 0 bis 11 Sekunden zusätzliche Seitenladezeit. Wichtiger noch: Bei Tausenden von Datenbanknutzern, die bisher noch nie eine fehlgeschlagene Query gesehen haben, reduziert das den Kollateralschaden erheblich, falls es fehlerhafte Error-Handling-Pfade gibt oder eine einzige fehlgeschlagene Query einen gesamten Batch-Job ruiniert.

  • Queries anzuhalten dürfte möglich sein, aber ich frage mich, ob man auch bereits laufende Transaktionen anhalten kann. Wie funktioniert das?

• Im Vergleich mit https://knock.app/blog/zero-downtime-postgres-upgrades ist das interessant. Die zugehörige Diskussion gab es unter https://news.ycombinator.com/item?id=38616181
  Ein großer Teil der damaligen Diskussion lief auf „Ist das nicht zu kompliziert, nur um ein paar Minuten Downtime zu vermeiden?“ hinaus. Dieser Fall wirkt wie ein Beleg dafür und sieht eher danach aus, dass man AWS Data Migration Service verwendet, die DNS-Einträge ändert, auf den Betrieb umschaltet und dann 11 Sekunden Downtime in Kauf nimmt.

  • Hier gibt es kein „einfach“. Die wichtigste Lehre steht in „Was wir gelernt haben“

    Wir haben uns für DMS entschieden, weil es auf GOV.UK PaaS gut unterstützt wurde und wir auch AWS-Support bekommen konnten. Wenn wir künftig eine Datenbank von PostgreSQL nach PostgreSQL migrieren, werden wir uns mehr Zeit nehmen, alternative Tools wie pglogical zu prüfen. DMS hat möglicherweise mehr Komplexität und ungewohnte Replikationsprozesse hinzugefügt, als wir sie mit anderen Tools gehabt hätten. Das passt auch zu dem, was AWS selbst über Migrationen zwischen PostgreSQL-Datenbanken sagt
    Die Botschaft hier ist nicht „nimm einfach DMS“.

  • Ich frage mich, ob jemand mit https://cloud.google.com/database-migration/docs/postgres/qu... schon etwas Ähnliches gemacht hat. Funktioniert das ähnlich wie AWS DMS?
  • DMS scheint intern pglogical zu verwenden, hat aber viele Fallstricke. Da es keine Replikation auf Hardware-Ebene ist, kann es bei großen Zeilen, großen Spalten und großen Tabellen Probleme geben, und Foreign Keys werden auch nicht sauber behandelt.
    Manche speziellen Datentypen kann es möglicherweise gar nicht verarbeiten. Nach der Migration müssen außerdem die Sequenzen aktualisiert werden, sonst kann es zu Fehlern wegen doppelter Primärschlüssel kommen.
    Wenn es keinen geeigneten Primärschlüssel gibt, können ebenfalls Probleme entstehen, weil nicht immer die gesamte Zeile auf einmal kopiert wird.
    Wenn die Datenbanken im selben AWS-Account liegen und man 4–5 Minuten Downtime akzeptieren kann, ist Replikation auf Hardware-Ebene über globale Datenbanken oder Snapshots wahrscheinlich einfacher.

• Kürzlich habe ich eine selbst gehostete 3-TB-PostgreSQL-Datenbank von 12 auf 16 migriert und zugleich von Ubuntu 18 auf Ubuntu 22 gewechselt. Gleichzeitig mussten mehrere Extensions aktualisiert werden, insbesondere gab es für Timescale keine kompatible Version, die alle Kombinationen abgedeckt hätte.
  Wir sind vorgegangen, indem wir eine Read-only-Replik aktualisiert haben: Ausgangspunkt war PG12, Ubuntu 18, TS2.9; zuerst haben wir auf Ubuntu 22 eine Read-only-Replik erstellt, die PG12 und TS2.9 beibehielt.
  Danach sind wir in den Wartungsmodus gegangen, haben alle Services gestoppt, die Read-only-Replik abgetrennt und dann auf Ubuntu 22 PG12 auf PG15 aktualisiert, während TS2.9 beibehalten wurde.
  Anschließend haben wir von PG15 und TS2.9 auf TS2.13 aktualisiert und zum Schluss auf Ubuntu 22 PG15 auf PG16 angehoben, während TS2.13 beibehalten wurde.
  Am Ende haben wir die Services wieder mit dem neuen Datenbankserver verbunden, alle Services wieder gestartet und den Wartungsmodus beendet.
  Alle Datenbank-Upgrade-Schritte waren mit Ansible ausreichend getestet und automatisiert, aber währenddessen trat ein Problem auf, das in den Tests nicht aufgetaucht war, wodurch sich die Downtime auf etwa 30 Minuten verlängerte. Für unseren Anwendungsfall war das völlig akzeptabel.
  Mit logischer Replikation hätten wir unerwartete Probleme im letzten Moment möglicherweise reduzieren können, und im nächsten Upgrade-Zyklus werden wir diesen Ansatz prüfen.

  • Wir sind kürzlich fast denselben Upgrade-Pfad gegangen. Allerdings unterstützte Timescale damals PG16 noch nicht, daher sind wir bei PG15 + TS 2.12 stehen geblieben.
    Wir haben auch logische Replikation geprüft, um die Upgrade-Downtime zu reduzieren, aber da Datenbankschema und DDL-Befehle nicht repliziert werden, schien das mit Timescale im Spiel nicht empfehlenswert.
    Die grundlegenden Schemaänderungen, die Timescale intern durchführen muss, dürften größtenteils eine Funktion der Hypertable-Chunk-Größe und des eingehenden Schreibmusters sein, man könnte sie also planen oder zeitlich abstimmen. Trotzdem erschien uns die potenzielle Komplexität und das Risiko deutlich zu hoch im Vergleich zu einem kurzen Wartungsfenster, während pg_upgrade durchläuft.

• Der Feind solcher Migrationen mit geringer oder keiner Downtime sind lang laufende Queries.
  Wenn es zum Beispiel eine einzelne update-Query gibt, die 30 Minuten dauert, muss man diese Query entweder beenden und zurückrollen oder 30 Minuten Verfügbarkeitsverlust hinnehmen.
  Soweit ich weiß, gibt es keine Möglichkeit, gerade laufende Queries zu migrieren.

  • Bei einem Software-Engineering-Projekt sollte man Transaktionszeiten deutlich kürzer begrenzen. Die Einstellung statement_timeout ist dein Freund.
    Wenn es extrem lange Transaktionen gibt, kann man den Cutover wahrscheinlich so legen, dass man ihnen ausweicht. Hoffentlich sind sie nicht zufällig, sondern eher das Ergebnis geplanter Jobs.
    Mit einer Kombination aus Transaktionszeitlimits, Failover-Konfigurationen, etwa indem man den bisherigen Primary fehlschlagen lässt, und etwas wie pgbouncer lässt sich statt Downtime die Zeit mit Verlangsamung ziemlich genau steuern.
    Ehrlich gesagt würde ich mir eher Sorgen machen, ob der gesamte Stack und die externen Cache-DNS-Server, von denen man abhängt, die DNS-TTL wirklich korrekt einhalten.
    Aber normalerweise ist es bei Apps nicht kritisch, etwa zehn Sekunden Downtime zu vermeiden; daher sollte man die Lösung wählen, die für einen selbst einfacher ist.
  • Persönlich fällt es mir schwer, mir eine 30-minütige update-Query vorzustellen, die nicht extrem ineffizient geschrieben ist oder keine einmalige große Datenmigration darstellt.
    Ersteres kommt natürlich in der Praxis häufig vor. Ich hatte schon ziemlich oft den Spaß, Arbeiten im Minuten- oder Stundenbereich auf Millisekunden zu bringen.
  • Wieder etwas gelernt. Ich frage mich, welcher Art Schreibvorgänge sind, die mehr als 30 Minuten dauern.
    Ich frage mich, welche Daten und welche Leute solche Datenbank-Schreibvorgänge handhaben, sodass man sich darauf verlassen muss, dass die DB-Engine so lange arbeitet, statt das auf einer höheren Ebene besser über eine Queue in kleinere Teile zu zerlegen.

• Der Teil wirkt merkwürdig, in dem sie für database.notifications.service.gov.uk einen AWS-Route53-DNS-Record mit 1 Sekunde TTL angelegt haben, das Migrationsskript dann die DNS-Gewichtung von AWS so geändert hat, dass 100 % auf den Ziel-Datenbankstandort zeigen, und anschließend 1 Sekunde bis zum Ablauf der TTL gewartet wurde.
  Sie sagen, dass die App dann beim nächsten Versuch, die Datenbank abzufragen, die Ziel-Datenbank abfragt. Heißt das, dass ihr ORM oder das Standardverhalten von Python bei jeder Query eine DNS-Abfrage macht und dabei blockiert?
  Cachen sie die aufgelöste Adresse nicht für eine gewisse Zeit und nutzen auch kein Connection Pooling oder keine Wiederverwendung?

  • Vermutlich übernimmt getaddrinfo oder gethostname des OS dieses Verhalten. Python implementiert Systemaufrufe kaum selbst neu, daher hängt es von den Systemeinstellungen ab.
    Wenn die TTL von 1 Sekunde eingehalten wurde, wäre sie 1 Sekunde lang gecacht worden, aber es ist nicht selten, dass DNS-Resolver-Bibliotheken und insbesondere cachende DNS-Server TTLs nicht vollständig respektieren. Ehrlich gesagt könnte das einen Teil der beobachteten Downtime erklären.

• Gut. Wir haben gerade drei Postgres-Cluster in RDS mit etwa 2 TB Daten und 8 Datenbanken von Postgres 14 auf 16 migriert. Von 00:00 bis 04:00 waren wir offline.
  Zuerst haben wir einen sehr leichtgewichtigen Ersatz-Website-Modus „Wartungsmodus“ aktiviert, der auf Cloudflare Workers läuft, und mit Terraform alle Apps, die die DB nutzen, auf 0 herunterskaliert.
  In der AWS-Web-UI haben wir den Upgrade-Button gedrückt, um per pg_upgrade 14→15 durchzuführen, auf den Abschluss gewartet und ihn dann erneut gedrückt, um 15→16 auszuführen.
  Wir warteten, bis die Datenbank Verbindungen annahm; sie schien schon Verbindungen anzunehmen, bevor sie als ready angezeigt wurde, und AWS schien zusätzlich zu pg_upgrade noch mehr zu tun.
  Danach haben wir VACUUM ANALYZE; REINDEX DATABASE CONCURRENTLY gestartet. Ziel war, Performance-Probleme zwischen Versionen zu vermeiden und die Performance-Verbesserungen der neuen Version zu nutzen.
  Wir begannen, die Apps wieder hochzufahren, warteten, bis bei allen Apps jeweils ein paar Container liefen, nahmen dann wieder Traffic an, schalteten die Wartungsseite aus und gingen schlafen.
  REINDEX CONCURRENTLY lief auf der größten DB noch weitere 18 Stunden, blockierte aber nichts.
  Beim nächsten Mal wollen wir AWS Blue/Green Deployments verwenden, um Downtime zu vermeiden. Diesmal konnten wir es nicht nutzen, weil wir nicht auf 14.9 waren, der minimalen Minor-Version von 14, die Blue/Green unterstützt.
  Wenn ich es selbst machen würde, würde ich keine AWS-Kosten dafür zahlen, sondern Blue/Green mit logischer Replikation und einem Load Balancer selbst aufbauen.

  • Ich würde für ein In-place-Upgrade pg_upgrade --hardlinks verwenden.
    Auf eigenen On-Premises-Postgres-Instanzen habe ich damit auch schon eine 2-TB-DB in unter einer Minute verarbeitet.

• GOV.UK Notify ist Teil eines Service-Bündels, das GDS britischen öffentlichen Einrichtungen bereitstellt. Dazu gehören auch GOV.UK Pay und GOV.UK PaaS; ursprünglich war es als Government As A Platform bekannt.

• DMS ist ein miserables Migrationstool. Wir haben fast einen Monat lang mit mehreren Migrationsproblemen gekämpft und dann aufgegeben.
  Text- und JSON-Typen konnten nicht migriert werden, und auch der AWS-Support konnte keine Lösung liefern.
  Wir haben AWS Blue/Green in einer frühen Testphase genutzt, und dadurch wurden nahezu unterbrechungsfreie Upgrades realistisch.

  • Wenn du DMS für ein schlechtes Migrationstool hältst, solltest du es mal für kontinuierliche Replikation auf ein externes Ziel verwenden.
    Es ist völlig kaputt.

• Interessant, aber ich verstehe nicht, warum die Regierung überhaupt AWS nutzt. Das ist kein Startup, das herumhackt, um Product-Market-Fit zu finden, und auch keine Situation, in der man einen marketinggetriebenen Traffic-Anstieg nicht vorhersehen konnte und nun darauf reagieren muss
  Man weiß, dass ein solcher Dienst langfristig gebraucht wird, und die Nutzungsmuster lassen sich ziemlich gut vorhersagen
  Man könnte eine Cloud für den öffentlichen Sektor aufbauen oder einen vernünftigen On-Premises-Ansatz verfolgen. Dafür braucht es Geld, Koordination und technische Führung, aber langfristig würde es den Steuerzahlern enorme Kosten ersparen
  IT im öffentlichen Sektor ist meist ein Chaos, aber ich weiß auch, dass es dort gute Ingenieure gibt

  • Als Startup nutzt man „die Cloud“, also PaaS, nicht wegen Traffic-Spitzen, sondern wegen Fokus
    Jede Stunde, die man mit Festplatten und Treibern oder deren Cloud-Versionen wie Storage und Ansible herumhantiert, ist eine Stunde, die man nicht damit verbringt, das zu bauen, was Kunden brauchen
    Warum sollte das bei der Regierung anders sein?
    Man erwartet nicht, dass die Regierung selbst Autos baut, sondern dass sie sie bei Volkswagen oder Renault kauft. Auch wenn die Regierung ganz offensichtlich Transportbedarf hat. Warum man dann bei IT-Infrastruktur darauf besteht, sie selbst zu bauen, verstehe ich nicht
  • Wenn man glaubt, die Bedürfnisse und die Nachfrage der Regierung seien vorhersehbar, hat man die Politik, insbesondere die britische Politik der letzten zehn Jahre, nicht verfolgt
    Und dann gibt es Dinge, die völlig unerwartet auftreten, wie eine Pandemie. Dass während der Pandemie passend zur Nachfrage skaliert werden konnte, war eines der zentralen Demonstrationsbeispiele dafür, warum der öffentliche Sektor kommerzielle Public Clouds nutzen sollte
  • Die britische Regierung insgesamt betreibt eine Mischung aus großen Public Clouds sowie etwas On-Premises und Colocation
    Ich empfehle, sich den Vortrag vom September über die verschiedenen Iterationen von Gov.UK und Migrationen zwischen Clouds anzusehen: https://youtube.com/watch?v=mpY1lxkikqM&pp=ygUOUmljaGFyZCB0b...
    Zumindest in der britischen Regierung muss man aufgrund der Beschaffungsanforderungen alle paar Jahre nutzungsbasierte Angebote wieder am Markt einholen
    Wenn zum Beispiel Oracle Cloud nur ein Zehntel kostet, ist die Wahrscheinlichkeit hoch, dass sie den Vertrag gewinnt; dann muss man während der Vertragslaufzeit zu Oracle migrieren, und wenn später eine andere, günstigere Cloud auftaucht, muss man möglicherweise erneut umziehen
  • Viele EU-Länder dürften öffentliche Clouds aufgebaut haben. In Kroatien habe ich das selbst erlebt und war einer der Entwickler, die dorthin deployen mussten
    Es war das Schlimmste, was ich je gesehen habe. Und das, obwohl ich schon mit viel Legacy gearbeitet habe: VB.NET, Web Forms, altes SharePoint, Basic, sogar ganze Anwendungen, die im Grunde riesige Haufen gespeicherter Prozeduren waren
    AWS, Azure und Google Cloud wurden zumindest mit dem Endnutzer, also dem Entwickler, im Blick gebaut. Regierungs-Clouds dagegen wurden vom Billigstbieter entworfen und aufgebaut, dessen oberstes Ziel es war, Kosten an jeder nur möglichen Stelle zu drücken
  • Ich weiß nicht, wie es in Großbritannien ist, aber in den USA bietet AWS schon seit Langem GovCloud an, und ehrlich gesagt ist das im Vergleich zu vieler Infrastruktur, die ich dort gesehen habe, fast ein Segen
    Umgekehrt habe ich auch wirklich hervorragende Infrastruktur- und Operations-Leute getroffen, die das interne Rechenzentrum einer deutschen staatlichen Gesundheitseinrichtung betrieben. Das Problem dort waren zu 100 % nicht die Technik oder die Leute, sondern Management und Prozesse, die bei jeder Interaktion zwischen Infrastrukturteam und Engineering-Team zum Flaschenhals werden wollten