3 Centros de Datos:
Versión de Patroni: 2.1.4
Versión de PostgreSQL: 14.4
Versión de etcd: 3.3.11
| corriente continua | Servidor | Nombre | Anfitrión | Estado |
|---|---|---|---|---|
| 1er | patroni | patroni-s11 | 172.16.0.2 | Líder |
| 1er | patroni | patroni-s12 | 172.16.0.3 | Sincronización en espera |
| 1er | ETCD | etcd-s11 | 172.16.0.4 | Líder |
| 2do | patroni | patroni-s21 | 172.16.1.2 | Réplica |
| 2do | patroni | patroni-s22 | 172.16.1.3 | Réplica |
| 2do | ETCD | etcd-s21 | 172.16.1.4 | esclavo |
| 3er | patroni | patroni-s31 | 172.16.2.2 | Réplica |
| 3er | ETCD | etcd-s31 | 172.16.2.4 | esclavo |
Simulé una falla de interconexión entre el primer centro de datos y el segundo, ambos DC están activos, pero el primero y el segundo no se "ven" entre sí.
En este caso, el líder de Patroni aún permanece en el 1º DC. Pero los servidores en 2nd DC no se sincronizan con el clúster. Si cree en el estado del clúster, todo está bien, no hay retrasos en la replicación entre servidores. En realidad, todos los cambios en el maestro no se sincronizan con las réplicas en el segundo centro de datos.
[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 |
+-----------------+---------------+--------------+---------+-----+-----------+
Todavía sucede con los servidores de Etcd, el líder aún permanece en 1er 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
Pero Etcd en el tercer centro de datos ve que el clúster está en buen estado.
[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
Esperaba que los líderes se convirtieran en servidores del 3er DC.
¿Puede Patroni\etcd cambiar de líder en este caso?
Respuesta1
En primer lugar, el qourm es 5/2 con nivel superior, 3 servidores que se cumplirán si tiene el sitio 1 + el sitio 3 ejecutándose y el comportamiento que vio es el esperado.
si el sitio 1 + el sitio 3 no cumple con el qourm, será diferente seinario