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