Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Nouveau sur ce forum, je suis à la recherche d'informations concernant la mise en place d'un système de réplication entre deux équipements Master - Slave avec la version 8.3 de postgresql.
Il m'a semblé voir que la mise en place d'une réplication warm standby pouvait répondre à ce besoin.
J'ai pu trouver des informations sur la mise en place de cette réplication, ainsi que sur le déroulement d'un scénario de panne du Master.
Ce scenario est le suivant :
Lorsque le master tombe, déclanchement (manuel ?) du passage de Status Esclave --> Maitre de la part du Serveur Esclave.
Redirection des ressources utilisant la Bdd initiale vers le nouveau Maitre.
Si ce processus est correct,
ma question concerne le rétablissement du Maitre initial :
-- Le Maitre initial doit être passé en Esclave ?
-- Quelle procédure doit être utilisée pour effectuer une bascule planifié vers le Maitre initial, qu’est-ce que cela engendre au niveau des interruption de service ?
Question supplémentaire, est-il possible d’assurer une certaine automatisation de ces processus de basculement : Echec Maitre --> Base de secours --> Retour Maitre
(si non, quels sont les points à vérifier lors de ces bascules manuelles ?)
Merci d’avance.
Hors ligne
En fait, il faut reconstruire le maître à zéro, à partir d'une sauvegarde de l'esclave (et donc en faire le nouvel esclave à la fin de la procédure). Il n'y a pas de 'bascule planifiée' sans reconstruction du maître. En tout cas pas pour le moment.
Marc.
Hors ligne
Merci pour cette première réponse,
Si je récapitule, le processus complet serait le suivant ? :
- Lors d’une panne, s’assurer manuellement que le Maître n’as plus d’instance de postgresql active.
- Créer un trigger sur l’esclave afin de le promouvoir en Maître.
- Faire pointer les ressources sur le nouveau Maître
- Passage du maitre initial en Esclave (recovery.conf)
- Création d’un backup du nouveau Maître, envoi vers le Maître initial.
- Arrêt du Maître actuel, passage de ce Maître en Esclave (Recovery.conf), redémarrage
- Créer un trigger sur l’esclave (Maître initial) afin de le promouvoir en Maître.
- Faire pointer les ressources sur le nouveau Maître
Autre question, quel est le risque lorsque deux maîtres sont simultanément actif ? Leurs envois de WAL sont intégrés par les maîtres distants ?
Merci
Hors ligne
Si je récapitule, le processus complet serait le suivant ? :
- Lors d’une panne, s’assurer manuellement que le Maître n’as plus d’instance de postgresql active.
Oui. Ou l'éteindre au bouton si vous êtes pressé 
- Créer un trigger sur l’esclave afin de le promouvoir en Maître.
Oui
- Faire pointer les ressources sur le nouveau Maître
Oui. Migrer l'IP du serveur est le plus rapide (donc avoir une IP associée à l'instance, que vous baladerez d'un noeud à l'autre).
- Passage du maitre initial en Esclave (recovery.conf)
- Création d’un backup du nouveau Maître, envoi vers le Maître initial.
Oui. Enfin, le recovery.conf, vous le mettrez à ce moment là… tant que vous n'avez pas le backup ça ne sert à rien.
- Arrêt du Maître actuel, passage de ce Maître en Esclave (Recovery.conf), redémarrage
Seulement si vous voulez revenir dans la situation de départ, mais oui.
- Créer un trigger sur l’esclave (Maître initial) afin de le promouvoir en Maître.
- Faire pointer les ressources sur le nouveau Maître
Oui. Et reconstruire à nouveau l'esclave (qu'est ce qu'on s'amuse 
)
C'est la limitation du mécanisme. Vous pouvez probablement l'optimiser un peu à coup de rsync: 99% des données ne sont pas modifiées lors des bascules. Ça dépend vraiment de la taille de vos bases.
Autre question, quel est le risque lorsque deux maîtres sont simultanément actif ? Leurs envois de WAL sont intégrés par les maîtres distants ?
Non, un maître n'intègre plus de journaux. Le problème est que vous avez deux instances actives, avec risque que certaines opérations aient lieu sur l'une, et d'autres sur l'autre. Et donc de passer très longtemps à nettoyer la situation ensuite. C'est pour cela qu'on utilise souvent pour piloter cette architecture soit un produit en amont (pgpool), soit un logiciel de clustering (heartbeat ou red hat cluster suite par exemple, sous linux): ces solutions évitent (ou du moins font de leur mieux) d'avoir deux serveurs actifs sans le savoir.
Marc.
Hors ligne
Merci
Hors ligne
Pages : 1
