3 Rechenzentren:
Patroni-Version: 2.1.4
PostgreSQL-Version: 14.4
Etcd-Version: 3.3.11
| Gleichstrom | Server | Name | Gastgeber | Status |
|---|---|---|---|---|
| 1 | Patroni | patroni-s11 | 172.16.0.2 | Führer |
| 1 | Patroni | patroni-s12 | 172.16.0.3 | Sync-Standby |
| 1 | ETCD | etcd-s11 | 172.16.0.4 | Führer |
| 2. Platz | Patroni | patroni-s21 | 172.16.1.2 | Replik |
| 2. Platz | Patroni | patroni-s22 | 172.16.1.3 | Replik |
| 2. Platz | ETCD | etcd-s21 | 172.16.1.4 | Sklave |
| 3. Platz | Patroni | patroni-s31 | 172.16.2.2 | Replik |
| 3. Platz | ETCD | etcd-s31 | 172.16.2.4 | Sklave |
Ich habe einen Verbindungsfehler zwischen dem 1. und dem 2. Rechenzentrum simuliert. Beide Rechenzentren sind aktiv, aber das 1. und das 2. „sehen“ sich nicht.
In diesem Fall bleibt der Patroni-Leader weiterhin im 1. Rechenzentrum. Aber die Server im 2. Rechenzentrum werden nicht mit dem Cluster synchronisiert. Wenn man an die Gesundheit des Clusters glaubt, ist alles in Ordnung, keine Replikationsverzögerung zwischen den Servern. In Wirklichkeit werden alle Änderungen am Master nicht mit Replikaten im 2. Rechenzentrum synchronisiert.
[user@patroni-s11 ~]$ sudo patronictl -c /etc/patroni/patroni.yml list
2022-12-01 16:00:00,015 - ERROR - Request to server 172.16.1.4:2379 failed: MaxRetryError("HTTPConnectionPool(host='172.16.1.4', port=2379): Max retries exceeded with url: /v2/keys/service/patroni_cluster/?recursive=true (Caused by ProtocolError('Connection aborted.', ConnectionResetError(104, 'Connection reset by peer')))",)
+ Cluster: patroni_cluster (7117639577766255236) ---+---------+-----+-----------+
| Member | Host | Role | State | TL | Lag in MB |
+-----------------+---------------+--------------+---------+-----+-----------+
| patroni-s11 | 172.16.0.2 | Leader | running | 103 | |
| patroni-s12 | 172.16.0.3 | Sync Standby | running | 103 | 0 |
| patroni-s21 | 172.16.1.2 | Replica | running | 103 | 0 |
| patroni-s22 | 172.16.1.3 | Replica | running | 103 | 0 |
| patroni-s31 | 172.16.2.2 | Replica | running | 103 | 0 |
+-----------------+---------------+--------------+---------+-----+-----------+
Passiert immer noch mit Etcd-Servern, der Anführer bleibt immer noch im 1. DC.
[user@etcd-s11 ~]$ sudo etcdctl cluster-health
failed to check the health of member a85c06b926e6c6c8 on 172.16.1.4:2379: Get 172.16.1.4:2379/health: read tcp 10.220.0.3:38836->172.16.1.4:2379: read: connection reset by peer
member 261f8081db14d568 is healthy: got healthy result from 172.16.0.4:2379
member a85c06b926e6c6c8 is unreachable: [172.16.1.4: 2379] are all unreachable
member b87bd1df518cc9e4 is healthy: got healthy result from 172.16.2.4:2379
cluster is degraded
[user@etcd-s11 ~]$ sudo etcdctl member list
261f8081db14d568: name=etcd-s11 peerURLs=172.16.0.4:2380 clientURLs=172.16.0.4:2379 isLeader=true
a85c06b926e6c6c8: name=etcd-s21 peerURLs=172.16.1.4:2380 clientURLs=172.16.1.4:2379 isLeader=false
b87bd1df518cc9e4: name=etcd-s31 peerURLs=172.16.2.4:2380 clientURLs=172.16.2.4: 2379 isLeader=false
Aber Etcd im 3. Rechenzentrum sieht, dass der Cluster gesund ist
[user@etcd-s31 ~]$ sudo etcdctl cluster-health
member 261f8081db14d568 is healthy: got healthy result from http:// 172.16.0.4: 2379
member a85c06b926e6c6c8 is healthy: got healthy result from http:// 172.16.1.4: 2379
member b87bd1df518cc9e4 is healthy: got healthy result from http:// 172.16.2.4: 2379
cluster is healthy
Ich hatte erwartet, dass die Anführer die Server des 3. DC werden.
Kann Patroni\etcd in diesem Fall den Anführer austauschen?
Antwort1
Zunächst einmal ist das Quorum 5/2 mit Level-Up, 3 Servern, was erreicht wird, wenn Sie Site1 + Site 3 laufen haben und das Verhalten, das Sie gesehen haben, das erwartete ist
Wenn Site 1 + Site 3 die Anforderungen nicht erfüllen, wird es ein Diff-Seinario geben.