Forums PostgreSQL.fr

bouchigreque

Membre

Changement de slave [cascading replication]

Bonjour à tous,

J'ai une petite question pour vous.
En gros, j'ai le schema de réplication suivant :

Master -> S01 -> S02 -> S03 -> S04 -> S05
En gros, le master est répliqué sur le serveur 1 qui est répliqué sur le serveur 2 et ainsi de suite, de la réplication en cascade classique en somme.
J'aurais aimé savoir si, il m'était possible de changer (par exemple) S01 sans briser toute la chaine ? J'ai un autre serveur (appelons le S06), qui est à jour et répliqué avec le master, et j'aimerais l'utiliser à la place de S01.

Me suffit-il de changer le fichier recovery.conf de S02 avec l'ip de S06 (qui est du coup le nouveau S01) ?

Merci d'avance.
Si je n'ai pas été clair ou pas précis, n'hésitez pas à demander des informations supplémentaires.

Dernière modification par bouchigreque (05/03/2015 17:17:36)

ruizsebastien

Membre

Re : Changement de slave [cascading replication]

Bonjour,

Oui normalement ça suffit.

---

Cordialement,

Sébastien.

bouchigreque

Membre

Re : Changement de slave [cascading replication]

Bonjour,

merci pour la réponse !
Quelqu'un peut néanmoins confirmer ? Vu que c'est des serveurs de prod, je préfère ne pas me planter.

gleu

Administrateur

Re : Changement de slave [cascading replication]

Non, ça ne suffit pas. À moins d'un coup de bol, le S6 sera en retard par rapport aux autres, donc si le S6 passe maître, il faudra reconstruire les autres.

Le seul moyen de le faire à peu près à coup sûr est de les arrêter dans l'ordre (S1, puis S2, puis S3, etc).

---

Guillaume.

bouchigreque

Membre

Re : Changement de slave [cascading replication]

Merci pour vos réponses

Non, ça ne suffit pas. À moins d'un coup de bol, le S6 sera en retard par rapport aux autres, donc si le S6 passe maître, il faudra reconstruire les autres.

Le seul moyen de le faire à peu près à coup sûr est de les arrêter dans l'ordre (S1, puis S2, puis S3, etc).

Hum en fait, je comprends pas comment le S6 peut être en retard en fait, vu qu'il sera déjà synchro avec le master (S6 ne devient pas master, il remplace juste S1).

Dernière modification par bouchigreque (06/03/2015 10:04:06)

gleu

Administrateur

Re : Changement de slave [cascading replication]

La réplication de PostgreSQL est par défaut asynchrone. Les modifications apportées sur S1 ont peut être eu le temps de venir à S2 et S3 mais pas forcément à S6.

---

Guillaume.

bouchigreque

Membre

Re : Changement de slave [cascading replication]

En fait, S6 serait répliqué avec le master (vu qu'il remplace S1) (sans passer par aucun standby), du coup logiquement il devrait être le plus frais et le plus synchro ?

gleu

Administrateur

Re : Changement de slave [cascading replication]

J'avais compris que c'était de la réplication en cascade, style :

Master -> S01 -> S02 -> S03 -> S04 -> S05 -> S06

Du coup, ce sera forcément le moins à jour.

Maintenant, si j'ai mal compris et que c'est plutôt :

Master -> S01 -> S02 -> S03 -> S04 -> S05
            -> S06

Dans ce cas, il y a plus de chances que ça fonctionne. Mais aucune assurance que ce soit le cas.

---

Guillaume.

bouchigreque

Membre

Re : Changement de slave [cascading replication]

J'avais compris que c'était de la réplication en cascade, style :

Master -> S01 -> S02 -> S03 -> S04 -> S05 -> S06

Du coup, ce sera forcément le moins à jour.

Maintenant, si j'ai mal compris et que c'est plutôt :

Master -> S01 -> S02 -> S03 -> S04 -> S05
            -> S06

Dans ce cas, il y a plus de chances que ça fonctionne. Mais aucune assurance que ce soit le cas.

Effectivement, je m'étais peut-être mal exprimé, mais le deuxième schema est plutôt ce à quoi je veux arriver.

Bon ben je pense que je vais jouer avec des VM pour tester tout ça alors.

Merci en tout cas !