>>> Mais si j'utilise le trigger_file et laisser à postgresql de gérer çà, est ce que postgresql ne va t'il pas basculer le slave S1 en master, mais aussi le master M1 en slave ? Situation que je n'aimerai pas avoir, j'aimerai seulement isoler le master M1 pour une maintenance et ne pas arrêter la production.
Avec le trigger_file le slave va devenir un master autonome. Le M1 restera master aussi. Il faudra le reconstruire en slave après.
Si vous voulez isoler le M1 pour maintenance et en attendant promouvoir le S1 en master et revenir en arrière après la maintenance et tout ça sans interruption de service, vous n'aurez pas d'autre choix (je pense) que d'opter pour une solution de haute dispo (comme PAF par exemple).
]]>Pour PAF, il s'agit d'un resource agent pour la suite Corosync / Pacemaker. L'agent en lui-même n'est pas forcément compliqué, mais les outils sur lesquels il repose le sont beaucoup plus. La documentation de PAF est ici : http://dalibo.github.io/PAF/
]]>Vous ne pourrez pas promouvoir le s1 simplement en renommant le recovery.conf en recovery.done.
Ca ne marche pas comme ça.
Il faut utiliser le trigger_file et laisser faire postgresql.
>>> Mais si j'utilise le trigger_file et laisser à postgresql de gérer çà, est ce que postgresql ne va t'il pas basculer le slave S1 en master, mais aussi le master M1 en slave ? Situation que je n'aimerai pas avoir, j'aimerai seulement isoler le master M1 pour une maintenance et ne pas arrêter la production.
J'ai vu de la réindexation, mais c'est une écriture et cela ne se fait que sur le maître (et est du coup répliqué sur l'esclave). Du coup, en dehors de la réindexation, quel autre maintenance voulez-vous faire ?
>>> Exact, mais en bref ce que je désire exactement c'est de ne faire la maintenance, la réindexation donc , que sur le serveur M1 vu que la réindexation verroux l'accès à la table, je voudrais donc basculer la production vers S1 pendant qu'on execute un réindexation sur M1. Ce cas aiderait bien lors d'une réparation de base corrompue par exemple. Mais puisque comme vous le dite
Si la "corruption" est "logique", càd qu'il vient d'un bug applicatif, oui, elle sera répliquée sur le standby.
, bah dans ce cas on devrait aussi donc réparer la réplique. Et qui est dommage, annulera donc la demande que j'aimerai faire.
Petite curiosité toute de même, n'existe donc t il pas un moyen de se protéger contre la corruption vu que celui ci prend beaucoup de temps pour la réparation surtout dans de cas de grosse lignes d'enregistrements ?
Pour basculer simplement le master en slave et vice versa vous pouvez toujours implémenter PAF (PostgreSQL Automotic Failover)
>>> Existe t il un moyen autre plus simple , ou pouvez vous me filer un lien de documentation, genre manuel pour implémenter ce PAF ?
Merci à vous
]]>Concernant la corruption, oui. Si une corruption silencieuse survient sur le maître, elle sera strictement copiée sur l'esclave. Comme le maître ne s'en rend pas compte, il ne peut pas l'empêcher. Et si le maître ne s'en rend pas compte, l'esclave ne le pourra pas plus, donc il ne pourra pas non plus l'en empêcher.
Je me permets d'apporter un peu de détail à cette phrase. Si la "corruption" est "logique", càd qu'il vient d'un bug applicatif, oui, elle sera répliquée sur le standby.
Si elle est matérielle néanmoins, comme par exemple au niveau disque ou mémoire, il y a peu de chance qu'elle ne soit pas détectée par le standby, la fiabilités des WAL (qui sont répliqués) reposant sur un contrôle CRC qui est vérifié à sa lecture.
]]>Concernant la corruption, oui. Si une corruption silencieuse survient sur le maître, elle sera strictement copiée sur l'esclave. Comme le maître ne s'en rend pas compte, il ne peut pas l'empêcher. Et si le maître ne s'en rend pas compte, l'esclave ne le pourra pas plus, donc il ne pourra pas non plus l'en empêcher.
]]>Vous ne pourrez pas promouvoir le s1 simplement en renommant le recovery.conf en recovery.done.
Ca ne marche pas comme ça.
Il faut utiliser le trigger_file et laisser faire postgresql.
Pour basculer simplement le master en slave et vice versa vous pouvez toujours implémenter PAF (PostgreSQL Automotic Failover).
]]>***** Qu'en pensez vous, est ce que ce concept pourrait marcher ? Ou avez vous des idées/méthodes meilleures ???
***** Donc, si je comprends bien et pour confirmation, si la base master est corrompue (par ex au niveau d'une ligne de pg_toast), la réplique slave elle aussi sera corrompue ???
Merci de votre attention sur ce sujet
]]>PostgreSQL ne gère pas nativement de réplication multi-maître, d'où le principe de maître/esclave. Il n'est donc pas possible de procéder ainsi.
Pour la corruption du serveur secondaire, cela dépend de quand et comment a lieu la corruption, mais c'est possible oui.
]]>J'aimerai avoir une haute disponibilité sur une base de données présente dans deux serveurs linux M1 et S1 avec postgresql9.4 installés. M1 en mode master et S1 en mode slave qui sert de réplication.
- 1er scénario >>>>, j'aimerai que lors de phase de maintenance obligatoire du master M1 (par exemple une réindexation de la base,...), on bascule les deux serveurs. C'est à dire le slave S1 devient master et le master M1 sera en maintenance durant ce temps.
Question scénario 1, déjà comment on s'y manipule exactement, pouvez vous m'indiquez les étapes à suivre pour bien basculer le slave S1 en master sachant que M1 ne doit pas être arrêté mais seulement isolé pour une maintenance?
- 2ème scénario >>>>, Une fois la maintenance de la base M1 effectuée. Il serait maintenant temps de rebasculer les deux serveurs pour atteindre leur role initial, ie M1 redevient master et S1 redevient slave.
Question scénario 2, là aussi comment on s'y prend exactement pour ne pas perdre les données et de rebasculer S1 en slave et M1 en master ?
*** Question spéciale : a) si la base master M1 est corrompue et devra donc entrer en phase de maintenance, est ce que dans ce cas le slave S1 sera elle aussi corrompue ??? b) si on a déjà entamé la phase de maintenance du master M1 sans basculer S1 en master ex: reindexation + vaccum analyze de M1, est ce que dans ce cas S1 sera aussi en phase de maintenance, ie les reindex et vaccum analyze faites sur le master sont elles aussi impactées dans le slave ?
J'espère que vous pouvez m'éclaircir sur ces points dont je ne vois pas trop d'exemple de cas détaillé dans la doc postgresql. Alors qu'il me semble vraiment important de bien connaitre les manipulations pour ces genres de cas.
Merci d'avance de vos réponses
]]>