Hochverfügbarkeitseinrichtung testen

Wählen Sie eine Dokumentationsversion aus:

Die Zuverlässigkeit und Qualität Ihrer Patroni-Einrichtung mit hoher Verfügbarkeit ist entscheidend für die Aufrechterhaltung des kontinuierlichen Datenbankbetriebs und die Minimierung von Ausfallzeiten. Auf dieser Seite finden Sie eine umfassende Anleitung zum Testen Ihres Patroni-Clusters. Dabei werden verschiedene Fehlerszenarien, die Konsistenz der Replikation und Failover-Mechanismen behandelt.

Patroni-Einrichtung testen

Stellen Sie eine Verbindung zu einer Ihrer patroni-Instanzen (alloydb-patroni1, alloydb-patroni2 oder alloydb-patroni3) her und rufen Sie den AlloyDB Omni-patroni-Ordner auf.
```
cd /alloydb/
```

Prüfen Sie die Patroni-Logs.

docker compose logs alloydbomni-patroni

Die letzten Einträge sollten Informationen zum Patroni-Knoten enthalten. Die Ausgabe sollte in etwa so aussehen:

alloydbomni-patroni        | 2024-06-12 15:10:29,020 INFO: no action. I am (patroni1), the leader with the lock
alloydbomni-patroni        | 2024-06-12 15:10:39,010 INFO: no action. I am (patroni1), the leader with the lock
alloydbomni-patroni        | 2024-06-12 15:10:49,007 INFO: no action. I am (patroni1), the leader with the lock

Stellen Sie eine Verbindung zu einer beliebigen Instanz her, auf der Linux ausgeführt wird und die eine Netzwerkverbindung zu Ihrer primären Patroni-Instanz alloydb-patroni1 hat, und rufen Sie Informationen zur Instanz ab. Möglicherweise müssen Sie das jq-Tool installieren, indem Sie sudo apt-get install jq -y ausführen.

curl -s http://alloydb-patroni1:8008/patroni | jq .

Die Ausgabe sollte in etwa so aussehen:

{
  "state": "running",
  "postmaster_start_time": "2024-05-16 14:12:30.031673+00:00",
  "role": "master",
  "server_version": 150005,
  "xlog": {
    "location": 83886408
  },
  "timeline": 1,
  "replication": [
    {
      "usename": "alloydbreplica",
      "application_name": "patroni2",
      "client_addr": "10.172.0.40",
      "state": "streaming",
      "sync_state": "async",
      "sync_priority": 0
    },
    {
      "usename": "alloydbreplica",
      "application_name": "patroni3",
      "client_addr": "10.172.0.41",
      "state": "streaming",
      "sync_state": "async",
      "sync_priority": 0
    }
  ],
  "dcs_last_seen": 1715870011,
  "database_system_identifier": "7369600155531440151",
  "patroni": {
    "version": "3.3.0",
    "scope": "my-patroni-cluster",
    "name": "patroni1"
  }
}

Wenn Sie den Patroni HTTP API-Endpunkt auf einem Patroni-Knoten aufrufen, werden verschiedene Details zum Status und zur Konfiguration der jeweiligen PostgreSQL-Instanz angezeigt, die von Patroni verwaltet wird. Dazu gehören Informationen zum Clusterstatus, zur Zeitachse, zu WAL und zu Health Checks, die angeben, ob die Knoten und der Cluster ordnungsgemäß ausgeführt werden.

HAProxy-Einrichtung testen

Rufen Sie auf einem Computer mit einem Browser und einer Netzwerkverbindung zu Ihrem HAProxy-Knoten die folgende Adresse auf: http://haproxy:7000. Alternativ können Sie anstelle des Hostnamens die externe IP-Adresse der HAProxy-Instanz verwenden.

Die Ausgabe sollte in etwa so aussehen:

Abbildung 1. HAProxy-Statusseite mit dem Integritätsstatus und der Latenz von Patroni-Knoten.

Im HAProxy-Dashboard sehen Sie den Systemstatus und die Latenz Ihres primären Patroni-Knotens patroni1 sowie der beiden Replikate patroni2 und patroni3.
Sie können Abfragen ausführen, um die Replikationsstatistiken in Ihrem Cluster zu prüfen. Stellen Sie über einen Client wie pgAdmin eine Verbindung zu Ihrem primären Datenbankserver über HAProxy her und führen Sie die folgende Abfrage aus.
```
SELECT
      pid, usename, application_name, client_addr, state, sync_state
FROM
      pg_stat_replication;
```
Es sollte ein Diagramm ähnlich dem folgenden angezeigt werden, das zeigt, dass patroni2 und patroni3 von patroni1 gestreamt werden.

Abbildung 2. Ausgabe von „pg_stat_replication“ mit dem Replikationsstatus der Patroni-Knoten.

Automatisches Failover testen

In diesem Abschnitt simulieren wir in Ihrem Cluster mit drei Knoten einen Ausfall auf dem primären Knoten, indem wir den angehängten laufenden Patroni-Container stoppen. Sie können entweder den Patroni-Dienst auf dem primären Knoten beenden, um einen Ausfall zu simulieren, oder einige Firewallregeln erzwingen, um die Kommunikation mit diesem Knoten zu beenden.

Rufen Sie auf der primären Patroni-Instanz den AlloyDB Omni-Patroni-Ordner auf.
```
cd /alloydb/
```
Beenden Sie den Container.
```
docker compose down
```
Die Ausgabe sollte in etwa so aussehen. Dadurch sollte bestätigt werden, dass der Container und das Netzwerk beendet wurden.
```
[+] Running 2/2
✔ Container alloydb-patroni            Removed
✔ Network alloydbomni-patroni_default  Removed
```
Aktualisieren Sie das HAProxy-Dashboard und sehen Sie sich an, wie das Failover abläuft.

Abbildung 3. HAProxy-Dashboard mit dem Failover vom primären Knoten zum Standby-Knoten.

Die Instanz patroni3 wurde zur neuen primären Instanz und patroni2 ist das einzige verbleibende Replikat. Die vorherige primäre Instanz, patroni1, ist nicht verfügbar und die Systemdiagnosen schlagen fehl.

Patroni führt den Failover durch eine Kombination aus Monitoring, Konsens und automatisierter Orchestrierung durch und verwaltet ihn. Sobald der primäre Knoten sein Lease nicht innerhalb eines bestimmten Zeitlimits verlängert oder einen Fehler meldet, erkennen die anderen Knoten im Cluster diesen Zustand über das Konsenssystem. Die verbleibenden Knoten koordinieren sich, um das am besten geeignete Replikat als neuen primären Knoten auszuwählen. Sobald ein Kandidatenreplikat ausgewählt wurde, stuft Patroni diesen Knoten zum primären Knoten hoch, indem die erforderlichen Änderungen vorgenommen werden, z. B. die PostgreSQL-Konfiguration aktualisiert und alle ausstehenden WAL-Datensätze wiedergegeben werden. Der neue primäre Knoten aktualisiert dann das Konsenssystem mit seinem Status und die anderen Replikate werden neu konfiguriert, um dem neuen primären Knoten zu folgen. Dazu gehört auch, dass sie ihre Replikationsquelle ändern und möglicherweise neue Transaktionen nachholen. HAProxy erkennt den neuen primären Knoten und leitet Clientverbindungen entsprechend weiter, um Unterbrechungen zu minimieren.
Stellen Sie über einen Client wie pgAdmin eine Verbindung zu Ihrem Datenbankserver über HAProxy her und prüfen Sie die Replikationsstatistiken in Ihrem Cluster nach dem Failover.
```
SELECT
      pid, usename, application_name, client_addr, state, sync_state
FROM
      pg_stat_replication;
```
Es sollte ein Diagramm ähnlich dem folgenden angezeigt werden, in dem nur patroni2 gestreamt wird.

Abbildung 4. Ausgabe von „pg_stat_replication“ mit dem Replikationsstatus der Patroni-Knoten nach dem Failover.
Ihr Cluster mit drei Knoten kann einen weiteren Ausfall überstehen. Wenn Sie den aktuellen primären Knoten patroni3 beenden, erfolgt ein weiteres Failover.

Abbildung 5. HAProxy-Dashboard mit dem Failover vom primären Knoten patroni3 zum Standby-Knoten patroni2.

Überlegungen zu Fallback-Intents

Ein Fallback ist der Prozess der Reaktivierung des vorherigen Quellknotens nach einem Failover. Ein automatisches Failback wird in einem Datenbankcluster mit hoher Verfügbarkeit im Allgemeinen nicht empfohlen, da es mehrere kritische Probleme gibt, z. B. unvollständige Wiederherstellung, Risiko von Split-Brain-Szenarien und Replikationsverzögerung.

Wenn Sie in Ihrem Patroni-Cluster die beiden Knoten hochfahren, mit denen Sie einen Ausfall simuliert haben, werden sie dem Cluster als Standby-Replikate wieder beitreten.

HAProxy-Dashboard mit der Wiederherstellung von „patroni1“ und „patroni3“ als Standby-Knoten

Abbildung 6. HAProxy-Dashboard, auf dem die Wiederherstellung von patroni1 und patroni3 als Standby-Knoten angezeigt wird.

patroni1 und patroni3 werden jetzt von der aktuellen primären Instanz patroni2 repliziert.

pg_stat_replication-Ausgabe mit dem Replikationsstatus der Patroni-Knoten nach dem Fallback

Abbildung 7. Ausgabe von „pg_stat_replication“ mit dem Replikationsstatus der Patroni-Knoten nach dem Fallback.

Wenn Sie manuell zum ursprünglichen primären Knoten zurückkehren möchten, können Sie die patronictl-Befehlszeile verwenden. Wenn Sie sich für das manuelle Fallback entscheiden, können Sie einen zuverlässigeren, konsistenteren und gründlich geprüften Wiederherstellungsprozess sicherstellen und so die Integrität und Verfügbarkeit Ihrer Datenbanksysteme aufrechterhalten.