Unterbrechungsfreies Postgres-Upgrade

Vorbereitung auf ein Postgres-Upgrade

• Risikobewertung: Eine Liste der Risiken erstellen, die während des Upgrades auftreten können, und sie nach Wichtigkeit sortieren.
• Lösungswege für Risiken suchen: Lösungen in Betracht ziehen, die Risiken vollständig beseitigen oder über die Zeit verteilen können.
• Risikoliste aktualisieren: Die Liste aktualisieren, wenn während des Projekts neue Risiken entdeckt werden.

Zu Monitoring und Metriken

• System-Monitoring: Gründliche Tools einsetzen, um den Zustand der Datenbank und des Systems zu überwachen.
• Wichtige Metriken beobachten: Zentrale Metriken wie Transaction IDs, CPU-Auslastung, wartende Sessions, Query-Latenz und API-Antwortlatenz überwachen.

Postgres-Upgrade-Optionen

In-Place-Upgrade (für ein Zero-Downtime-Upgrade ungeeignet)

• Grenzen des In-Place-Upgrades: Beim Betrieb auf AWS RDS ist ein Neustart der Datenbank erforderlich; je nach Datenmenge kann das Zeit kosten.

Replikationsbasiertes Upgrade

• Wahl eines replikationsbasierten Upgrades: Ermöglicht schrittweise Migrationsphasen, Tests der neuen Datenbank mit echter Workload und realen Daten sowie mehr Kontrolle über das Upgrade.
• Einrichtung von Quell- und Zieldatenbank: Replikations-Slots einrichten, wal_level auf logical setzen.

Auswahl der Methode zur Tabellenreplikation

Replikation „kleiner“ Tabellen

• Replikation kleiner Tabellen: Kann durch einfaches Hinzufügen und Aktualisieren des Subscriptions-Status repliziert werden.

Große, append-only Tabellen

• Replikation append-only Tabellen: Die Option copy_data auf false setzen, sodass nur zukünftige Änderungen repliziert werden; ältere Daten anschließend aus einem Backup nachfüllen.

Große Tabellen mit vielen Updates

• Replikation großer Tabellen mit vielen Updates: Tabellengröße reduzieren, VACUUM ausführen, Tabellenpartitionierung in Betracht ziehen.

Status der Tabellenreplikation prüfen

• Replikationsstatus überwachen: Den Replikationsstatus über die Systemtabelle pg_subscription_rel prüfen; empfohlen wird, jeweils nur eine Tabelle gleichzeitig zu replizieren.

Replikation stoppen

• So wird die Replikation gestoppt: Bei Bedarf kann die Tabellenreplikation gestoppt und per Subscription-Refresh ein Rollback durchgeführt werden.

Hinweise zur Übertragung von Replikations-Slots

• Problem bei der Übertragung von Replikations-Slots: Das LSN eines Replikations-Slots ist für die jeweilige Primärdatenbank eindeutig und kann daher nicht direkt in die neue Datenbank kopiert werden.

Abschluss der Migration

• Konsistenz der Tabellen prüfen: Sicherstellen, dass die Anzahl der Tabellenzeilen in beiden Datenbanken übereinstimmt; falls nötig, die Datenkonsistenz per Zufallsstichprobe verifizieren.

Änderungen auf Anwendungsebene

• Änderung der Datenbankverbindung: Die Anwendung so umstellen, dass sie sich mit der neuen Datenbank verbindet, und eine Strategie für die Verkehrsumschaltung festlegen.

Zusätzliche Hinweise zu Sequenzen

• Synchronisierung von Sequenzen: Da Sequenzwerte während der Replikation nicht synchronisiert werden, müssen sie manuell gesetzt werden.

Checkliste für die Abschlussprüfung

• Abschlussprüfung: Tabellenkonsistenz, Subscription-Status, Schema-Übereinstimmung, Datenbankgröße, Hinzufügen von Replikaten, Neuaufbau von Indizes, Performance-Tests, Risikobewertung und Übungen in der Staging-Umgebung prüfen.

Finale Umschaltung

• Durchführung der finalen Umschaltung: Die Tabellenreplikation in den Abendstunden durchführen, sie mehrfach in der Staging-Umgebung üben und anschließend die Abschlussprüfung sowie das Umschalten des Flags vornehmen.

Meinung von GN⁺

• Bedeutung: Knock hat den komplexen Prozess eines Zero-Downtime-Upgrades von Postgres 11.9 auf 15.3 erfolgreich durchgeführt. Das setzt einen wichtigen Meilenstein für Datenbankverwaltung und Service-Verfügbarkeit.
• Interessant: Der replikationsbasierte Upgrade-Ansatz ermöglicht Datenbankadministratoren einen reibungslosen Übergang zu einer neuen Datenbank und dürfte in der technischen Community auf großes Interesse stoßen.
• Bemerkenswert: Der Upgrade-Prozess von Knock zeigt anhand eines systematischen Risiko-Managements und strukturierter Problemlösung ein Best-Practice-Beispiel dafür, wie sich komplexe technische Herausforderungen bewältigen lassen.

[GN⁺]

Hacker-News-Kommentare

• Es gibt einen besseren Weg, als große Tabellen zu kopieren.

  • Man kann ein logisches Replikat erstellen, indem man einen Replikationsslot anlegt, einen Snapshot erstellt, den Snapshot in einer neuen Instanz wiederherstellt, den LSN fortschreibt und dann die Replikation startet.
  • Ein Artikel von Instacart beschreibt diesen Prozess.
  • Der Artikel könnte kleine Fehler enthalten, aber diese Methode wurde mehrfach erfolgreich verwendet, um Instanzen im TB-Bereich zu upgraden.

• Der hier vorgestellte Ansatz ist interessant und gut dokumentiert, aber der Aussage „Moderne Kunden erwarten 100 % Verfügbarkeit“ wird nicht zugestimmt.

  • Nach Erfahrung als Kunde wie auch als Anbieter ist Konsistenz deutlich wichtiger als Verfügbarkeit.
  • Wenn ein Vendor Downtime ankündigt, wird das als Zeichen gesehen, dass sorgfältig mit den Daten umgegangen wird, was eher beruhigend wirkt.

• AWS unterstützt inzwischen Blue-Green-Deployments.

• Es wurde ein Tool geschrieben, das die meisten Probleme automatisiert.

  • Das Tool wird auf GitHub geteilt und kann durch Feedback oder Ideen erweitert werden.

• Bei hava.io läuft gerade eine Migration von AWS RDS PostgreSQL 11.13 auf 15.5.

  • Gewählt wurde ein unidirektionaler Replikationsansatz mit pglogical.
  • Dieser Ansatz ist nicht schnell, aber er kann die Datenbank über mehrere Tage schrittweise auf die neue Instanz replizieren.
  • Er bietet mehr Freiheit bei der Änderung von Storage-Typ und -Größe.

• Es wird infrage gestellt, dass jegliche Downtime für den Knock-Service inakzeptabel sei.

  • Komplexe Systeme haben Zwischenfälle und Ausfälle.
  • 15 Minuten vorher angekündigte Downtime sind für die meisten SaaS-Geschäfte kein Problem.
  • Wenn Engineering-Zeit stattdessen in Produktentwicklung oder in eine höhere Geschwindigkeit des Entwicklungsteams investiert wird, kann das für Nutzer zufriedenstellender sein.
  • Bei Datenbankmigrationen ist der Unterschied im Arbeitsaufwand zwischen „wenig Downtime“ und „Zero-Downtime“-Migrationen groß.

• Es überrascht, dass sich Replikation nicht aus einem Backup initialisieren lässt.

  • Das hätte den Aufwand verringern können, den bestehenden stabilen DB-Inhalt auf den neuen Server zu streamen.
  • Es wird zwar als „Zero Downtime“ bezeichnet, tatsächlich gibt es aber einige Sekunden Downtime beim Umschalten auf den neuen Server.
  • Details dazu, wie die Konsistenz gewahrt wird, fehlen.
  • Eine Rollback-Option wird nicht erwähnt, dabei braucht man bei einer einmaligen Migration großer Datenmengen immer einen Plan für den Rückweg.

• Es wird gefragt, ob Interesse an einem All-in-One-Tool besteht, das nur mit Datenbank-Credentials Zero-Downtime-Postgres-Updates durchführt.

• Das Thema der Verwendung von Sequenzen ist interessant.

  • Statt Sequenzen werden meist sequentielle UUIDs oder der HiLo-Algorithmus verwendet.

• Es wird scherzhaft angemerkt, dass sich Probleme in verteilten Systemen mit einem passenden sleep(1000) lösen lassen.

  • Postgres ist kein System, das sich für DBAs sofort vertraut anfühlt, aber es ist besser geworden als früher.