Auf dieser Seite wird die AlloyDB Omni-Version 16.3.0 mit der Bereitstellungsoption Container dokumentiert. Wählen Sie eine andere Bereitstellungsoption aus.

Hochverfügbarkeitseinrichtung testen

Wählen Sie eine Dokumentationsversion aus:

Die Zuverlässigkeit und Qualität Ihrer Patroni-Einrichtung mit Hochverfü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 Patroni-Ordner von AlloyDB Omni 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 bereitgestellt, die von Patroni verwaltet wird. Dazu gehören Informationen zum Clusterstatus, zur Zeitachse, zu WAL und zu Systemdiagnosen, 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 aussehen wie der folgende Screenshot.

Abbildung 1. HAProxy-Statusseite mit dem Systemstatus 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 angibt, dass patroni2 und patroni3 von patroni1 gestreamt werden.

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

Automatischen 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 Patroni-Ordner von AlloyDB Omni 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 zum neuen primären Knoten und patroni2 ist das einzige verbleibende Replikat. Der vorherige primäre Knoten, 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ängern kann 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 wiederholt werden. Der neue primäre Knoten aktualisiert dann das Konsenssystem mit seinem Status und die anderen Replikate konfigurieren sich neu, 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 Störungen 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 dargestellt wird, dass aktuell nur patroni2 streamt.

Abbildung 4. pg_stat_replication-Ausgabe 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 weiterer Failover.

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

Überlegungen zum Fallback

Ein Fallback ist der Prozess der Reaktivierung des vorherigen Quellknotens nach einem Failover. Ein automatischer Fallback wird in einem Datenbankcluster mit Hochverfü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 mit der Wiederherstellung von patroni1 und patroni3 als Standby-Knoten

patroni1 und patroni3 werden jetzt vom aktuellen primären Knoten patroni2 repliziert.

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

Abbildung 7. pg_stat_replication-Ausgabe 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 dafür die patronictl-Befehlszeile verwenden. Wenn Sie sich für den manuellen 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.