PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#1 18/04/2018 09:33:53

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

Hors ligne

#2 18/04/2018 09:41:25

gleu
Administrateur

Re : Failover JDBC et risque de split brain

Toujours le premier serveur.

Hors ligne

#3 18/04/2018 14:36:30

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, ...) ?

Hors ligne

#4 18/04/2018 17:08:25

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.

Hors ligne

#5 18/04/2018 19:05:56

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.

Hors ligne

Pied de page des forums