Vous n'êtes pas identifié(e).
Bonjour,
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 
Hors ligne
Bonjour,
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.
Julien.
https://rjuju.github.io/
Hors ligne
Donc, il n'est pas possible d'avoir une réplication master/master avec postgresql-9.4 ?
Sinon j'ai pensé pour le sénario1 :
>>> Objectif : Isoler M1 en maintenance et lancer la produciton sur S1.
=> Step1: on paramètre S1 de façon à pouvoir basculer en mode master, ie:
- Arrêter S1
- Renommer postgresql.conf S1 en postgresql_S1_slave.conf
- Copier postgresql.conf M1 et le coller dans le repertoire data de S1 avec les bon droits notemment pour l'user postgres, veuillez à bien vérifier le répertoire de archive_command, la source étant S1 maintenant
- Renommer recovery.conf en recovery.done pour désactiver recovery.conf de S1 temporairement
- Démarrer S1, qui normalement maintenant devra pouvoir accepter les transactions de lectures/écritures
- Pointer les connexions d'applications vers S1
=> Step2: isoler M1 pour une phase de maintenance
- Sauvegarder postgresql.conf de M1 dans un emplacement temporaire
- Désactiver archive_command dans postgresql.conf de M1 puisque S1 prend la main actuellement
- Si la maintenace n'a pas encore débuter, commencer la maintenance de M1
>>> En ce moment, on devrait pouvoir travailler sur S1 et isoler M1 en phase de maintenance
Scénario2:
>>> Objectif : la phase de maintenance de M1 étant fini on voudrait maintenant rattraper le retard de M1 et puis basculer la production vers M1, S1 sera de nouveau Slave.
=> Step3: on va faire une sauvegarde à chaud de S1
- Arrêter M1 après avoir vérifier que la maintenance a réussi
- Lancer pg_start_backup('label');
- Utiliser rsync pour copier le repertoire data de S1 vers le repertoire data de M1 (normalement rsync ne va copier que les data modifié durant le retard ce qui va diminuer largement le temps de copie)
- Lancer de suite pg_stop_backup(); après avoir fini la copie avec rsync
=> Step4 : rattraper le retard de M1 et le lancer en tant que slave
- Copier postgresql_S1_slave.conf avec les bon droit notemment l'utilisateur postgres et coller dans le repertoire data de M1 en tant que postgresql.conf
- Paramétrer recovery.conf de M1
- Paramétrer et reloader pg_hba.conf de S1 afin qu'il accepte la connexion de M1
- Démarrer M1 qui va entrer en mode récupération pour rattraper son retard
=> Step5 : Une fois M1 démarrer et synchroniser avec S1, basculer M1 en mode master et faire S1 en mode slave
- M1 et S1 étant synchroniser (vérifier par select * from pg_last_xact_replay_timestamp(); sur M1), arrêter les deux serveurs.
- Sur M1: reprendre le fichier de configuration de M1 sauvegardé dans Step2. renommer recovery.conf en recovery.done. Démarrer M1 et repointer les connexions d'applications vers celui-ci. M1 est maintenant master
- Sur S1 : refaire Step4 mais cette fois ci en remplaçant M1 par S1 et en oubliant le paramétrage de pg_hba.conf qui devrait déjà être prise en compte dans M1. S1 sera de nouveau slave après son redémarrage
***** 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
Hors ligne
bonjour,
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).
Cordialement,
Sébastien.
Hors ligne
Vous n'arrêtez pas de parler de maintenance sans trop définir ce que vous voulez faire. 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 ?
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.
Guillaume.
Hors ligne
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.
Hors ligne
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
Hors ligne
Je vous conseille de commencer par le fonctionnement de la réplication sur postgres : http://docs.postgresql.fr/9.6/high-availability.html
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/
Julien.
https://rjuju.github.io/
Hors ligne
Ok, merci pour ces liens.
Et merci pour vos réponses.
Hors ligne
>>> 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).
Cordialement,
Sébastien.
Hors ligne
