Forums PostgreSQL.fr

scheu.postgresql

Membre

Failover JDBC et risque de split brain

Bonjour

J'ai un master et 1 slave en Streaming replication
Le slave sert juste pour le PRA, toutes les connexions lecture et écriture de l'application se font uniquement sur le master

L'URL JDBC paramétrée au niveau du driver JDBC de l'application :

jdbc:postgresql://serveur1:5432,serveur2:5432/accounting?targetServerType=master

Si je comprends bien, avec "targetServerType=master", toutes les connexions lecture et écriture se feront uniquement sur le serveur qui est le master

Ma question est la suivante :
Si après un PRA failover où le slave devient master, mais que l'ancien master est redémarré et redevient opérationnel, je peux me retrouver dans la situation où les 2 serveurs sont master (chacun en standalone). Dans cette situation, les connexions applicatives lecture et écriture vont-elles être faites aléatoirement sur l'un ou l'autre serveur, ou bien toujours sur le premier serveur de la liste trouvé à l'état master (serveur1 dans mon exemple) ?
Avec les risques de split brain qui en découlent ...

Merci d'avance

gleu

Administrateur

Re : Failover JDBC et risque de split brain

Toujours le premier serveur.

---

Guillaume.

scheu.postgresql

Membre

Re : Failover JDBC et risque de split brain

Merci pour ta réponse

Du coup ça peut être dangereux finalement ce genre de chaîne de connexion : jdbc:postgresql://serveur_master:5432,serveur_slave:5432/accounting?targetServerType=master

Si après un failover, les connexions se font sur le slave (devenu master), il faut bien faire attention à ce que le master ne redevienne pas opérationnel et accessible ?
Il y a un moyen moins risqué de faire ça ?
Avec un alias DNS qu'on modifierait manuellement ou bien un outil tierce pour pooler les connexions ? (pgpool, pgbouncer, ...) ?

stefan

Membre

Re : Failover JDBC et risque de split brain

Bonjour,

Il faut effectivement éviter que l'ancien maître ne soit à nouveau actif. L'idéal serait de l'isoler (via le firewall par exemple) jusqu'à ce qu'il soit remis en réplication par exemple.

Sans utiliser cette possibilité de la chaîne de connexion, une ip virtuelle que vous basculez sur le nouveau maître après bascule devrait faire l'affaire.

---

Stefan.

gleu

Administrateur

Re : Failover JDBC et risque de split brain

Le problème n'est pas la chaîne de connexion. Le problème est que l'ancien maître ne doit surtout pas re-devenir opérationnel. Le moyen moins risqué est de ne JAMAIS faire de bascule automatique.

---

Guillaume.