3 centros de dados:
Versão patroni: 2.1.4
Versão PostgreSQL: 14.4
Versão etcd: 3.3.11
| CC | Servidor | Nome | Hospedar | Status |
|---|---|---|---|---|
| 1º | Patroni | patroni-s11 | 172.16.0.2 | Líder |
| 1º | Patroni | patroni-s12 | 172.16.0.3 | Sincronização em espera |
| 1º | ETCD | etcd-s11 | 172.16.0.4 | Líder |
| 2º | Patroni | patroni-s21 | 172.16.1.2 | Réplica |
| 2º | Patroni | patroni-s22 | 172.16.1.3 | Réplica |
| 2º | ETCD | etcd-s21 | 172.16.1.4 | escravo |
| 3º | Patroni | patroni-s31 | 172.16.2.2 | Réplica |
| 3º | ETCD | etcd-s31 | 172.16.2.4 | escravo |
Simulei falha de interconexão entre o 1º Data Center e o 2º, ambos os DC estão ativos, mas o 1º e o 2º não se “vêem”.
Neste caso, o líder Patroni ainda permanece no 1º DC. Mas os servidores no segundo DC não sincronizam com o cluster. Se acreditar na integridade do cluster, tudo bem, sem atraso de replicação entre os servidores. Na verdade, todas as alterações no master não sincronizam com as réplicas do 2º Data Center.
[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 |
+-----------------+---------------+--------------+---------+-----+-----------+
Ainda acontece com os servidores Etcd, o líder ainda permanece no 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
Mas o Etcd no 3º Data Center vê que o cluster está íntegro
[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
Eu esperava que os líderes se tornassem os servidores do 3º DC.
Patroni\etcd pode mudar o líder neste caso?
Responder1
Primeiro de tudo o qourm é 5/2 com level up, 3 servidores que serão atendidos se você tiver o site1 + site 3 rodando e o comportamento que você viu for o esperado
se o site 1 + site 3 não atender ao qourm será diff seinario