Fehlerbehebung bei häufigen Failover- und Verbindungsfehlern in PostgreSQL-HA-Clustern

PostgreSQL-High-Availability-Cluster (HA) versagen auf zwei verschiedene Arten. Manchmal bricht das Datenbank-Failover selbst zusammen: Es wird kein Replikat befördert, zwei Knoten sind sich über den Primärserver uneinig, oder der neue Primärserver kann keine Schreibvorgänge annehmen. Ein anderes Mal ist die Datenbank in Ordnung, aber die Anwendung kann sich trotzdem nicht verbinden, weil ein Pooler, ein DNS-Eintrag, eine virtuelle IP, eine Firewall-Regel oder eine Client-Wiederholungsschleife der Beförderung nicht gefolgt ist.

Wenn Sie sich im Vorfall befinden, trennen Sie diese Ebenen schnell. Fragen Sie zuerst: Gibt es genau einen beschreibbaren Primärserver? Fragen Sie dann: Kann der Pooler ihn erreichen? Fragen Sie dann: Kann die Anwendung den Pooler oder den Service-Endpunkt erreichen? Diese Reihenfolge verhindert viel verschwendete Zeit beim Starren auf Anwendungsprotokolle, während der Cluster-Manager immer noch in der Leader-Wahl feststeckt.

Grundlagen von PostgreSQL-HA verstehen

Bevor wir in die Fehlerbehebung eintauchen, ist es wichtig, die Kernkomponenten eines PostgreSQL-HA-Clusters kurz zusammenzufassen:

Primär-/Replikat-Architektur: Eine primäre Datenbank verarbeitet alle Schreibvorgänge, während ein oder mehrere Replikate asynchron oder synchron Änderungen über Streaming-Replikation empfangen. Replikate sind schreibgeschützt, dienen aber als Kandidaten für die Beförderung während eines Failovers.
Failover-Manager: Tools wie Patroni, pg_auto_failover oder Corosync/Pacemaker überwachen die Gesundheit des Primärservers, erkennen Ausfälle, wählen einen neuen Primärserver aus den verfügbaren Replikaten aus und verwalten den Beförderungsprozess. Sie kümmern sich auch um die Neukonfiguration anderer Replikate, um dem neuen Primärserver zu folgen.
Verbindungspooling: Anwendungen verbinden sich oft mit einem PostgreSQL-Verbindungspooler (z. B. PgBouncer, Odyssey) und nicht direkt mit der Datenbank. Der Pooler leitet dann Abfragen an den aktuellen Primärserver weiter, bietet Verbindungsmultiplexing, Lastausgleich und abstrahiert möglicherweise die tatsächliche Netzwerkadresse des Primärservers von den Anwendungen. Diese Abstraktion ist während eines Failovers entscheidend.

Häufige Failover- und Verbindungsprobleme und ihre Lösungen

1. Verbindungspooling-Probleme während des Failovers

Eines der häufigsten Probleme nach einem Failover ist, dass Anwendungen keine Verbindung zum neu beförderten Primärserver herstellen können, obwohl die Datenbank selbst betriebsbereit ist. Dies deutet oft auf Probleme mit dem Verbindungspooler oder dem clientseitigen Caching hin.

Problemsymptome:

Anwendungen melden Datenbankverbindungsfehler (FATAL: database "mydb" does not exist, connection refused, server closed the connection unexpectedly).
Bestehende Verbindungen durch den Pooler scheinen hängen zu bleiben oder versuchen, eine Verbindung zur IP des alten Primärservers herzustellen.
Auch neue Verbindungen schlagen fehl, selbst nachdem das Failover abgeschlossen ist.

Ursachen:

Veraltete Verbindungen im Pooler: Der Verbindungspooler könnte offene Verbindungen zum alten Primärserver halten und versuchen, sie wiederzuverwenden, was zu Fehlern führt, wenn der alte Primärserver ausgefallen ist oder jetzt ein Replikat ist.
Falsche Pooler-Konfiguration: Der Pooler ist möglicherweise nicht richtig konfiguriert, um den neuen Primärserver zu erkennen und zu ihm zu wechseln, oder seine server_reset_query fehlt oder ist falsch.
DNS-Caching: Wenn Ihre Anwendungen oder der Pooler einen DNS-Eintrag verwenden, um die Adresse des Primärservers aufzulösen, können veraltete DNS-Cache-Einträge (entweder lokal oder auf der Ebene des DNS-Resolvers) dazu führen, dass sie weiterhin versuchen, eine Verbindung zur alten IP herzustellen.
Fehlende clientseitige Wiederholungslogik: Anwendungen sind möglicherweise nicht mit robusten Wiederholungsmechanismen ausgestattet, um vorübergehende Verbindungsprobleme während eines Failovers zu behandeln.

Debugging-Schritte:

Pooler-Status prüfen: Greifen Sie auf die Konsole Ihres Poolers zu (z. B. psql -p 6432 pgbouncer -U pgbouncer) und überprüfen Sie die Ausgabe von SHOW SERVERS, SHOW CLIENTS, SHOW DATABASES, um zu sehen, ob er den neuen Primärserver kennt und ob er aktive Verbindungen zur richtigen Adresse hat.
Netzwerkkonnektivität überprüfen: Führen Sie vom Pooler-Host aus ping und telnet zum PostgreSQL-Port des neuen Primärservers durch (telnet new_primary_ip 5432).
Pooler-Protokolle prüfen: Überprüfen Sie die Protokolle des Poolers auf Fehlermeldungen im Zusammenhang mit der Verbindung zur Datenbank oder dem Versuch, Hostnamen aufzulösen.
DNS-Auflösung prüfen: Verwenden Sie dig oder nslookup auf dem Pooler-Host, um sicherzustellen, dass der DNS-Eintrag für Ihren primären Service-Endpunkt (z. B. primary.mydomain.com) in die IP-Adresse des neuen Primärservers aufgelöst wird.

Lösungen:

server_reset_query konfigurieren: Stellen Sie sicher, dass Ihr Pooler eine server_reset_query hat (z. B. DISCARD ALL;), um den Sitzungsstatus zu bereinigen, wenn eine Verbindung an den Pool zurückgegeben und bevor sie von einem anderen Client wiederverwendet wird. Dies ist entscheidend für Umgebungen, die temporäre Objekte oder sitzungsspezifische Einstellungen verwenden.
max_db_connections und max_user_connections: Legen Sie geeignete Grenzwerte fest, um zu verhindern, dass der Pooler alle Verbindungen zum neuen Primärserver monopolisiert und möglicherweise andere Dienste aushungert.
Pooler neu laden/neu starten: In einigen Fällen kann ein ordentliches Neuladen oder Neustarten des Verbindungspoolers erforderlich sein, um ihn zu zwingen, neue Konfigurationen zu übernehmen oder DNS neu aufzulösen. Dies sollte der letzte Ausweg sein und vorzugsweise von Ihrem Failover-Manager automatisiert werden.
Kürzere DNS-TTL: Wenn Sie DNS-basierte Serviceerkennung verwenden, konfigurieren Sie eine sehr kurze Time-To-Live (TTL) für den DNS-Eintrag des Primärservers (z. B. 30-60 Sekunden), um die Auswirkungen des DNS-Cachings zu minimieren.
Clientseitige Wiederholungen: Implementieren Sie exponentielle Backoff- und Wiederholungslogik in Ihrem Anwendungscode. Dies macht Anwendungen widerstandsfähiger gegen vorübergehende Verbindungsprobleme während eines Failovers.
Virtuelle IP (VIP): Erwägen Sie die Verwendung einer von Ihrer HA-Lösung verwalteten virtuellen IP. Die VIP bewegt sich mit dem Primärserver, sodass sich Anwendungen mit einer statischen IP verbinden und der zugrunde liegende Datenbankserver transparent wechselt.

# Beispiel für einen PgBouncer-Konfigurationsausschnitt
[databases]
mydb = host=primary_cluster_service_ip port=5432 dbname=mydb
# Oder Verwendung eines Hostnamens, der von Ihrem Failover-Manager aktualisiert wird
# mydb = host=primary.mydomain.com port=5432 dbname=mydb

[pgbouncer]
listen_addr = 0.0.0.0
listen_port = 6432
auth_type = md5
auth_file = /etc/pgbouncer/userlist.txt
pool_mode = session
server_reset_query = DISCARD ALL;
server_fast_close = 1 # Verbindungen schnell schließen, wenn der Server nicht reagiert
server_check_delay = 10 # Serverzustand alle 10 Sekunden überprüfen

2. Übermäßige Replikatverzögerung behindert Failover

Replikatverzögerung tritt auf, wenn eine Standby-Datenbank hinter dem Primärserver zurückbleibt, was bedeutet, dass sie nicht alle vom Primärserver gesendeten WAL-Datensätze (Write-Ahead Log) wiedergegeben hat. Während eines Failovers kann die Beförderung eines stark verzögerten Replikats zu Datenverlust führen oder den Failover-Prozess erheblich verzögern, wenn der HA-Manager darauf wartet, dass es aufholt.

Problemsymptome:

Überwachungsalarme weisen auf eine hohe Replikatverzögerung hin (z. B. in Bytes oder Zeit).
Failover-Manager weigern sich, ein Replikat zu befördern, weil es einen konfigurierten Verzögerungsschwellenwert überschreitet.
Nach einem Failover stellen Anwendungen fehlende Daten fest, die auf dem alten Primärserver vorhanden waren.

Ursachen:

Hohe primäre Schreiblast: Ein anhaltend hohes Volumen an Schreibvorgängen auf dem Primärserver kann die Fähigkeit des Replikats, Schritt zu halten, überfordern, insbesondere wenn die Hardware des Replikats (E/A, CPU) unterlegen ist.
Netzwerklatenz/-bandbreite: Langsame oder überlastete Netzwerkverbindungen zwischen Primärserver und Replikat können den WAL-Versand verzögern.
Langsame Replikat-E/A: Das Festplattensubsystem des Replikats ist möglicherweise nicht schnell genug, um WAL-Datensätze effizient zu schreiben und wiederzugeben.
wal_level-Einstellung: Wenn wal_level nicht auf replica oder höher gesetzt ist, werden die notwendigen Informationen für die Streaming-Replikation nicht generiert.
max_wal_senders: Unzureichende max_wal_senders auf dem Primärserver können die Anzahl der aktiven Replikations-Slots oder gleichzeitigen Replikationsverbindungen begrenzen und den Durchsatz beeinträchtigen.
archive_command / restore_command-Probleme: Bei Verwendung von WAL-Archivierung und -Wiederherstellung können Probleme mit diesen Befehlen (z. B. langsamer Archivspeicher) zu Verzögerungen führen.

Debugging-Schritte:

pg_stat_replication überwachen: Diese Ansicht bietet Echtzeitinformationen zum Replikationsstatus, einschließlich write_lag, flush_lag und replay_lag.
LSNs vergleichen: Vergleichen Sie manuell die aktuelle WAL-LSN auf dem Primärserver mit der zuletzt wiedergegebenen LSN auf dem Replikat.
Systemressourcen prüfen: Verwenden Sie iostat, vmstat, top sowohl auf dem Primärserver als auch auf dem Replikat, um E/A-Engpässe, CPU-Sättigung oder Speicherdruck zu identifizieren.
Netzwerkdiagnose: Testen Sie die Netzwerkleistung zwischen Primärserver und Replikat mit iperf.

Lösungen:

max_wal_senders erhöhen: Erhöhen Sie auf dem Primärserver max_wal_senders (z. B. max_wal_senders = 10), um mehr gleichzeitige Replikationsverbindungen zu ermöglichen. Neustart erforderlich.
Replikat-Hardware verbessern: Wenn E/A oder CPU ein Engpass sind, erwägen Sie ein Upgrade der Hardware des Replikats oder optimieren Sie seine Speicherkonfiguration (z. B. schnellere SSDs, separates WAL-Laufwerk).
wal_compression optimieren: Das Setzen von wal_compression = on auf dem Primärserver kann das WAL-Volumen reduzieren und möglicherweise die Replikationsgeschwindigkeit über netzwerkeingeschränkte Verbindungen verbessern, jedoch auf Kosten der Primärserver-CPU.
wal_keep_size oder wal_keep_segments anpassen: Stellen Sie sicher, dass genügend WAL-Dateien auf dem Primärserver aufbewahrt werden, um zu verhindern, dass Replikate aus dem Tritt geraten und eine vollständige Basis-Backup erfordern.
synchronous_commit: Während synchronous_commit = on stärkere Datenhaltbarkeitsgarantien bietet, führt es zu Latenz bei Schreibvorgängen auf dem Primärserver. Verwenden Sie remote_write oder remote_apply für bestimmte Tabellen oder Transaktionen, wenn eine strenge synchrone Replikation erforderlich ist, bewerten Sie jedoch sorgfältig die Auswirkungen auf die Leistung.
Überwachung und Alarmierung: Implementieren Sie eine robuste Überwachung für pg_stat_replication und richten Sie Alarme ein, wenn die Verzögerung akzeptable Schwellenwerte überschreitet.

-- Auf dem Primärserver: Aktuelle WAL-LSN prüfen
SELECT pg_current_wal_lsn();

-- Auf dem Primärserver: Verbundene Standbys und Verzögerung prüfen
SELECT
    usename, application_name, client_addr, state, sync_state,
    pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replay_lag_bytes,
    write_lag, flush_lag, replay_lag
FROM pg_stat_replication;

Verwenden Sie auf einem Standby:

SELECT
    pg_is_in_recovery() AS is_standby,
    pg_last_wal_receive_lsn(),
    pg_last_wal_replay_lsn(),
    now() - pg_last_xact_replay_timestamp() AS time_since_last_replay;

Die Zeitstempelabfrage kann auf einem Leerlaufsystem irreführend sein, da möglicherweise keine kürzliche Transaktion wiedergegeben wurde. Verwenden Sie sie mit LSN-Vergleichen und Arbeitslastkontext.

3. Fehlgeschlagene oder hängengebliebene Primärübergabe

Ein automatisiertes Failover sollte ein Replikat schnell und zuverlässig befördern. Wenn dieser Prozess ins Stocken gerät oder vollständig fehlschlägt, kann dies zu längeren Ausfallzeiten führen und manuelle Eingriffe erfordern.

Problemsymptome:

Nach dem Ausfall des alten Primärservers wird kein neuer Primärserver gewählt oder befördert.
Der Cluster gerät in einen Split-Brain-Zustand, in dem zwei Knoten glauben, der Primärserver zu sein.
Failover-Manager-Protokolle zeigen Fehler im Zusammenhang mit Quorum, Leader-Wahl oder Datenbankbeförderung.
Anwendungen bleiben ausgefallen, da kein Primärserver verfügbar ist.

Ursachen:

Split-Brain: Tritt auf, wenn Netzwerkpartitionen Knoten isolieren, was zu mehreren Primärservern oder einer mehrdeutigen Primärwahl führt. Dies ist das gefährlichste Szenario, das das Risiko von Datenabweichungen birgt.
Quorum-Probleme: Der Failover-Manager kann möglicherweise kein Quorum (Mehrheitsentscheidung) unter seinen Knoten erreichen, was ihn daran hindert, eine Entscheidung über die Beförderung zu treffen. Dies ist häufig in Clustern mit einer geraden Anzahl von Knoten oder zu wenigen Knoten der Fall.
Netzwerkisolation: Die Failover-Manager-Knoten können nicht miteinander oder mit den PostgreSQL-Instanzen kommunizieren, was Gesundheitschecks oder die Befehlsausführung verhindert.
Unzureichende Berechtigungen: Dem Benutzer des Failover-Managers fehlen möglicherweise die erforderlichen PostgreSQL-Berechtigungen (z. B. pg_promote()) oder Systemberechtigungen (z. B. zum Verwalten von VIPs).
Konfigurationsfehler: Falsche restore_command, primary_conninfo oder andere Einstellungen in der Konfiguration des Failover-Managers.

Debugging-Schritte:

Failover-Manager-Protokolle prüfen: Dies ist die primäre Informationsquelle. Suchen Sie für Patroni in seinen spezifischen Protokollen (oft journalctl -u patroni oder der in patroni.yml konfigurierten Protokolldatei). Für pg_auto_failover überprüfen Sie journalctl -u pgautofailover_monitor und die Agentenprotokolle.
Quorum-Status überprüfen: Verwenden Sie für Patroni patronictl list, um den Status aller Cluster-Mitglieder zu sehen und den gewählten Leader zu bestätigen. Für pg_auto_failover überprüfen Sie pg_autoctl show state.
Netzwerkkonnektivität: Führen Sie ping-, traceroute- und telnet-Prüfungen zwischen allen HA-Knoten und dem verteilten Konsensspeicher (z. B. Etcd, Consul, ZooKeeper für Patroni) durch.
Systemprotokolle: Überprüfen Sie journalctl -xe oder /var/log/syslog auf allen Knoten auf Systemfehler, die den Failover-Manager beeinträchtigen könnten (z. B. volle Festplatte, Speicherprobleme).
PostgreSQL-Protokolle: Untersuchen Sie die PostgreSQL-Protokolle auf dem Kandidaten-Replikat für die Beförderung, um zu sehen, ob es während des Beförderungsversuchs Probleme meldet.

Lösungen:

Fencing/STONITH implementieren: Fencing ist entscheidend, um Split-Brain zu verhindern, indem sichergestellt wird, dass ein ausgefallener Primärserver keine Schreibvorgänge mehr annehmen kann, bevor ein neuer befördert wird. Dies wird normalerweise vom Failover-Manager oder der Infrastrukturschicht übernommen.
Ungerade Anzahl von Knoten für Quorum: Stellen Sie immer eine ungerade Anzahl von abstimmenden Knoten (z. B. 3, 5) für den verteilten Konsensspeicher Ihres Failover-Managers (Etcd, Consul, ZooKeeper) bereit, um sicherzustellen, dass auch dann ein Quorum erreicht werden kann, wenn ein oder zwei Knoten ausfallen.
Robuste Netzwerkkonfiguration: Stellen Sie redundante Netzwerkpfade, ordnungsgemäße Firewall-Regeln, die die Kommunikation auf den erforderlichen Ports (PostgreSQL, Konsensspeicher, Patroni-API) erlauben, und eine konsistente Hostnamenauflösung sicher.
Berechtigungsprüfung: Überprüfen Sie, ob das Benutzerkonto, unter dem der Failover-Manager läuft, über alle erforderlichen PostgreSQL-Berechtigungen und Systemberechtigungen verfügt, um Beförderungs- und Neukonfigurationsaufgaben durchzuführen.
Failover-Manager-Konfiguration überprüfen: Überprüfen Sie die patroni.yml- oder pg_auto_failover-Einstellungen auf Tippfehler, falsche Pfade oder falsch konfigurierte restore_command.
Manueller Eingriff (vorsichtig): Bei einem schwerwiegenden, hängengebliebenen Failover kann eine manuelle Beförderung oder das erneute Hinzufügen von Knoten erforderlich sein. Gehen Sie mit äußerster Vorsicht vor und stellen Sie sicher, dass der alte Primärserver vollständig heruntergefahren ist, bevor Sie einen neuen befördern, um Datenabweichungen zu vermeiden.

# Beispiel: Patroni-Cluster-Status prüfen
patronictl -c /etc/patroni/patroni.yml list

# Erwartete Ausgabe (Beispiel):
# + Cluster: my_ha_cluster (6979219803154942080) ------+----+-----------+----+-----------+
# | Member  | Host         | Role    | State    | TL | Lag |
# +---------+--------------+---------+----------+----+-----+
# | node1   | 192.168.1.10 | Leader  | running  | 2  |     |
# | node2   | 192.168.1.11 | Replica | running  | 2  | 0   |
# | node3   | 192.168.1.12 | Replica | running  | 2  | 0   |
# +---------+--------------+---------+----------+----+-----+

4. Netzwerkkonnektivitäts- und DNS-Auflösungsprobleme

Vielen HA-Problemen liegen grundlegende Netzwerkprobleme zugrunde, die verhindern, dass Knoten kommunizieren oder Anwendungen den richtigen Datenbank-Endpunkt finden.

Problemsymptome:

connection refused- oder no route to host-Fehler von Anwendungen oder zwischen Cluster-Knoten.
Failover-Manager meldet Knoten als nicht erreichbar.
Dienste, die auf DNS angewiesen sind, können den Hostnamen des Primärservers nicht korrekt auflösen.

Ursachen:

Firewall-Regeln: Falsch konfigurierte Firewall-Regeln (z. B. iptables, Sicherheitsgruppen), die den PostgreSQL-Port (5432), Failover-Manager-Ports oder Konsensspeicher-Ports blockieren.
Netzwerkpartition: Physische oder logische Netzwerkteilung, die die Kommunikation zwischen einer Teilmenge von Knoten verhindert.
Falsches Routing: Falsch konfigurierte Netzwerkrouten auf einem oder mehreren Knoten.
DNS-Caching/-Fehlkonfiguration: Wie in Abschnitt 1 erläutert, können veraltete DNS-Einträge oder eine falsche DNS-Serverkonfiguration den Datenverkehr fehlleiten.
Fehler bei der Migration der virtuellen IP (VIP): Wenn eine VIP verwendet wird, kann es sein, dass sie nicht zum neuen Primärserver migriert wird, sodass der Dienst unerreichbar bleibt.

Debugging-Schritte:

Grundlegende Konnektivität: Verwenden Sie ping <target_ip> zwischen allen Knoten.
Port-Konnektivität: Verwenden Sie telnet <target_ip> <port> (z. B. telnet 192.168.1.10 5432), um zu überprüfen, ob der PostgreSQL-Port geöffnet ist und lauscht.
Firewall-Prüfung: Überprüfen Sie auf jedem Knoten die aktiven Firewall-Regeln (sudo iptables -L, sudo ufw status oder Cloud-Anbieter-Sicherheitsgruppenkonfigurationen).
Netzwerkschnittstellenstatus: Verwenden Sie ip addr show oder ifconfig, um sicherzustellen, dass die Netzwerkschnittstellen aktiv und korrekt konfiguriert sind.
DNS-Auflösung: Verwenden Sie dig <hostname> oder nslookup <hostname>, um die Hostnamenauflösung von relevanten Knoten (Anwendungsserver, Pooler, HA-Knoten) zu überprüfen.

Lösungen:

Firewall-Regeln überprüfen: Stellen Sie sicher, dass die erforderlichen Ports für PostgreSQL (5432), die Steuerungsebene des Failover-Managers (z. B. 8008 für Patroni-API, 8000/8001 für pg_auto_failover) und den verteilten Konsensspeicher (z. B. Etcd: 2379/2380, Consul: 8300/8301/8302) geöffnet sind.
Konsistentes Networking: Stellen Sie sicher, dass sich alle Knoten im selben Subnetz befinden oder korrektes Routing konfiguriert ist, wenn sie sich über mehrere Subnetze erstrecken.
DNS-Updates: Automatisieren Sie DNS-Updates als Teil des Failover-Prozesses oder verwenden Sie eine kürzere TTL. VIPs werden aus diesem Grund oft bevorzugt.
VIP-Verwaltung: Wenn Sie eine VIP verwenden, stellen Sie sicher, dass das VIP-Verwaltungstool (z. B. Keepalived, IP-Verwaltung des Cloud-Anbieters) korrekt konfiguriert ist und funktioniert. Testen Sie die VIP-Migration explizit.
Hostbasierter Zugriff: Stellen Sie der Einfachheit halber in kleineren Clustern sicher, dass pg_hba.conf Verbindungen von allen potenziellen Primär-/Replikat-IP-Adressen und der IP des Verbindungspoolers zulässt.

Wichtige Tools zur Fehlerbehebung

psql: Zum Ausführen von SQL-Abfragen wie pg_stat_replication, pg_current_wal_lsn(), SHOW *-Befehlen.
Failover-Manager-CLI: patronictl, pg_autoctl zum Abfragen des Cluster-Zustands, von Protokollen und zum Initiieren von Aktionen.
Systemüberwachung: Tools wie Prometheus + Grafana, Zabbix, Nagios oder Cloud-Anbieter-Überwachung für Echtzeit-Einblicke in die Ressourcennutzung, Replikationsverzögerung und den Dienststatus.
journalctl / tail -f: Zum Anzeigen von System- und Anwendungsprotokollen.
Netzwerkdienstprogramme: ping, traceroute, telnet, iperf, netstat, dig, nslookup zur Diagnose der Konnektivität.
dmesg: Für Kernel-Level-Fehler, insbesondere im Zusammenhang mit Festplatten-E/A oder OOM (Out Of Memory) Killer.

Eine schnelle Incident-Checkliste

Wenn ein HA-Failover-Alarm ausgelöst wird, verwenden Sie eine kurze Checkliste, bevor Sie etwas ändern:

Bestätigen Sie die Cluster-Ansicht:

patronictl -c /etc/patroni/patroni.yml list

Bestätigen Sie die eigene Rolle von PostgreSQL auf jedem erreichbaren Knoten:

SELECT pg_is_in_recovery();

false bedeutet, dass der Knoten ein beschreibbarer Primärserver ist. true bedeutet, dass es sich um einen Standby handelt. Wenn mehr als ein Knoten false meldet, stoppen Sie und behandeln Sie den Vorfall als möglichen Split-Brain.

Bestätigen Sie den Anwendungsendpunkt:

dig primary-db.internal.example.com
nc -vz primary-db.internal.example.com 5432

Bestätigen Sie das Pooler-Ziel, falls Sie PgBouncer verwenden:

SHOW SERVERS;
SHOW POOLS;

Überprüfen Sie, ob Fehler alt oder aktuell sind. Anwendungsprotokolle enthalten oft Wiederholungsmeldungen aus den ersten Sekunden des Failovers. Vergleichen Sie Zeitstempel, bevor Sie annehmen, dass der Fehler noch auftritt.

Diese Checkliste ist bewusst einfach gehalten. Während eines echten Failovers ist der beste Befehl der, den jeder im Team versteht und ohne Raten ausführen kann.

Best Practices zur Vermeidung von Failover-Problemen

Regelmäßige Failover-Tests: Simulieren Sie regelmäßig Primärausfälle und beobachten Sie den Failover-Prozess. Dies schafft Vertrauen und deckt Fehlkonfigurationen auf.
Robuste Überwachung und Alarmierung: Überwachen Sie wichtige Metriken wie Replikatverzögerung, Primärstatus, Verbindungspooler-Zustand und Systemressourcen. Richten Sie Alarme für Abweichungen ein.
Ordnungsgemäße Verbindungspooler-Konfiguration: Stellen Sie sicher, dass server_reset_query konfiguriert ist, pool_mode für Ihre Anwendung geeignet ist und Gesundheitschecks aktiviert sind.
Replikationsparameter optimieren: Konfigurieren Sie wal_level, max_wal_senders, wal_keep_size und synchronous_commit sorgfältig basierend auf Ihren Leistungs- und Haltbarkeitsanforderungen.
Dokumentieren Sie Ihr HA-Setup: Dokumentieren Sie klar Ihre HA-Architektur, Failover-Manager-Konfiguration, Netzwerkeinstellungen und Wiederherstellungsverfahren.
Verwenden Sie einen dedizierten Failover-Manager: Verlassen Sie sich für kritische HA-Logik auf bewährte Lösungen wie Patroni oder pg_auto_failover anstelle von benutzerdefinierten Skripten.
Dedizierter Konsensspeicher: Wenn Sie einen Manager wie Patroni verwenden, stellen Sie einen separaten, hochverfügbaren Cluster für seinen verteilten Konsensspeicher (Etcd, Consul) bereit, um einen Single Point of Failure zu vermeiden.

Die nützlichsten HA-Tests sind keine sauberen Demos, bei denen der Primärserver höflich gestoppt wird. Testen Sie auch die hässlichen Fälle: Der alte Primärserver verliert das Netzwerk, läuft aber weiter, DNS aktualisiert langsam, PgBouncer hält veraltete Serververbindungen, ein Replikat ist 30 Sekunden zurück oder der Konsensspeicher verliert ein Mitglied. Diese Tests zeigen, ob Ihre Runbooks mit dem System übereinstimmen, das Sie tatsächlich betreiben.