Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
sur les différentes documentations postgresql que j'ai pu voir, la notion de STONITH (Shoot the other node in the head) apparait lorsque les différentes méthodes de réplication sont évoqués.
Il ne peut donc apparemment pas exister deux instance de serveurs maître actives sans que celà engendre un risque de corruption des données.
Voulant mettre en place la méthode de streaming replication offerte par postgresql 9, je cherche à comprendre pourquoi le cas de deux instance maître active peut être dangereux.
Prenons le cas d'une replication sur deux serveurs.
- Le premier serveur devient inacessible.
-- Interruption des services
- Les services pointant sur le premier serveur sont orientés pour utiliser la base de secours.
- La base de secours et promu en maître
-- Redémarrage des services
- Le premier serveur redevient accessible
-> Deux maîtres sont actifs
Je ne voit pas en quoi ce cas peut être problématique.
Si un enregistrement/alteration vient à être effectué sur le serveur initial, toujours à l'état de maître, elle n'influe pas sur le serveur qui est lui en opération.
Si une personne peut m'éclaircir sur le sujet, je la remercie d'avance.
Hors ligne
Oui, en effet, cela n'influe en rien sur le deuxième serveur. Cependant, le gars qui travaille sur l'ancien maître ne va pas vraiment être content d'apprendre qu'il bosse depuis plusieurs heures sur un vieux serveur qui ne devrait pas être allumé et que tout son travail ne sert à rien car il n'est pas reporté sur le serveur maître et qu'il ne tient pas compte des valeurs ajoutées par les autres sur le nouveau maître.
Donc, pour répondre simplement, oui, ce n'est pas grave en soi, il n'y a pas de corruption ni quoi que ce soit de ce genre. Par contre, ça sous-entend que, si jamais une redirection a été oubliée, une application cliente peut pointer vers des anciennes données et accepter de travailler là-dessus.
Guillaume.
Hors ligne
Je ne voit pas en quoi ce cas peut être problématique.
Si un enregistrement/alteration vient à être effectué sur le serveur initial, toujours à l'état de maître, elle n'influe pas sur le serveur qui est lui en opération.
Effectivemet si une transaction est lancée sur le serveur maitre initial cela influe sur le "nouveau" serveur maitre. Mais les deux bases seront dans un état incohérent et l'application aura potentiellement reçue une information erronnée.
Si on prend l'exemple d'un système de réservation de place de train .
- Le serveur A (maitre) distribue les places 1, 2, 3 et 4
- Le server A devient inaccessibble
- Le serveur B devient maitre
- Le serveur B distribue la place 5 et 6
- Le serveur A réapparait, reprend le traitement des requêtes en cours et distribue la place 5
Il y a donc conflit entre les deux bases. Ici l'exemple est simpliste et l'arbitrage est facile à faire mais on peut très rapidement se retrouver dans des conflits très durs à résoudre.
à un instant T, il ne doit y avoir 0 ou 1 maitre. C'est pour cela qu'il est essentiel de tuer le noeud inaccessible **avant** de basculer le noeud de secours.
damien clochard
http://dalibo.org | http://dalibo.com
Hors ligne
Merci pour toutes ces précisions
Hors ligne
Pages : 1
