----- Original Message -----
From: "Yannick Lecaillez" <yl@???>
To: <guilde@???>
Sent: Thursday, March 11, 2004 5:09 PM
Subject: Re: [HA] MySQL replication
> > Topology:
> > I understand we can have both:
> > case 1:
> >
> > master-->replica1-->replicat1.1-->replicat1.1.1
> >
> > case2:
> >
> > master-->replica1
> > |
> > ----->replica2
> > |
> > ----->replica3
> >
> > a combination could even be:
> >
> >
> > master-->replica1-->replicat1.1-->replicat1.1.1
> > |
> > ----->replica2
> > |
> > ----->replica3
> >
> > Which one (if any) should we prefer ? in the latter case, which is the
> > preferred backup in case of master failure ? if replica1 fails should we
> > replace replica1.1 by 2.1 and replica 1.1.1 by 2.1.1 ?
> Pour reprendre le schéma ci-dessus ma vision ressemblerais à :
>
> Client -> A --->B
> |
> +---->C
>
> A master B et C esclave
Cette solution est possible. cependant, quand B et C sont initialisés, il
faut (cas simple) bloquer A pendant la mise à niveau de B puis celle de C.
Le faire une seule fois semble mieux.
>
> A tombe :
>
> Client -> B ---> C
>
> B deviens Maitre, C reste esclave, A est dans les choux
>
> A reviens :
>
> Client -> B ---> C
> |
> +----> A
>
> B reste maître, C et A sont esclave
Un avantage de ta solution, c'est qu'il y a permutation complète des roles,
A revient comme esclave. Pour d'autres raisons c'est un critère que je
cherche à respecter.
L'alternative qui a été proposée est la suivante
Client --> A ---> B ---> C
|
+----> D
cette solution fait apparaitre un master A, un "Head-of-Slaves" B et des
slaves C et D
en cas de disparition de A, un remplaçant est élu parmi B,C,D
en cas de disparition de B, ou au cas ou B remplace A, un remplaçant de B
est élu parmi C,D
Dans ce scénario, tous les serveurs sont potentiellement reconfigurés.
Avantage: après la mise à niveau du premier slave, A ne devrait plus jamais
etre sollicité pour cette tache.
>
> Je suis pas sur que ce soit vraiment faisable. Ca implique de changer
> la configuration des MySQL et de les redémarrer. Ca doit être difficle à
> stabiliser je pense quand même (il faut changer la configuration et
> redémarrer 2 serveurs MySQL en cas de failure). Ca me parrâit hasardeux.
> Mais bon, faut tester :)
En effet, toute remarque sur la faisabilité est bienvenue et des tests
intensifs
seront nécessaires qoiqu'il en soit.
.....
> > Non je pense que tu te méprends. Shaman-X délivre des produits libres
> > sous licence GPL. Ces produits sont téléchargeables sur
www.shaman-x.org.
> En effet, je me suis trompé.
De mon coté, je préciserai mieux produit "libre", pour eviter toute
ambiguité vis à vis des produits commerciaux.
Une partie de la discussion venait de ce malentendu.
Je prends bonne note de ton avis sur cet autre point:
En fait
> pour dire les choses franchement c'est que JE NE COMPREND PAS pourquoi
> encore faire un truc sur MySQL ou il y a déjà beaucoup de support (la
> réplication marche) alors qu'il n'existe aucune solution de HA viable
> pour postgres. La valeur ajouté en matière de logiciel libre utilisé en
> milieu professionnel (qui est quand même la cible pour une architecture
> HA) serait je pense plus importante si nous nous mettons nos effort sur
> un projet qui justement en à besoin : Postgres. Ou alors apporter les
> transactions et autres Trigger à MySQL. Mais rajouter une couche pour
> renforcer la mise en HA de MySQL est, certes, une BONNE idée mais je
> pense que stabiliser la réplication dans Postgres serait une MEILLEUR
> idée. Car comme je le disais plus haut, postgres à (avait ?) plus de
> fonctionnalité que MySQL. Fonctionnalité se révélant très pratique
> voire vitale dans certain cas. Il s'agissait d'une OPINION.
Je trouve que tes arguments sont pertinents. A titre perso, je ne suis pas
compétent pour contribuer de facon éclairée sur les points que tu soulèves.
Je pense qu'ils nécessitent une équipe professionnelle et un budget.
>
> Maintenant vis à vis de ta remarque par rapport à ma contribution au
> logiciel libre, il est vrai que je ne suis pas un contributeur fou et
> sincèrement c'est par manque de temps. Cependant à l'époque ou j'avais
> l'ADSL à la maison j'avais contribué pendant plusieurs mois à Phing :
> http://www.phing.info/.
Ma remarque était issue de la mauvaise compréhension précédente. Il n'y
avait pas de reproche qui te soit addressé par cette remarque. Je ne mets
d'ailleurs pas les contributeurs au dessus des utilisateurs, on a besoin des
deux et on est souvent les deux a la fois. Tu as compris qu'on ne visait pas
un produit commercial, et moi j'ai compris que tu ne me reprochais pas une
approche produit. c'est ok pour moi.
> > C'est comme un coup de gueule, mais je ne sais pas à qui il est destiné
!
> Ca m'avait vraiment énervé à l'époque de ne rien trouver de vraiment
> viable en matière de réplication avec Postgres alors qu'il y avait dejà
> un bon support de réplication et des tonnes de doc pour MySQL. Et là de
> voir un projet partir sur une bonne idée mais encore une fois pour MySQL
> ... ça m'énerve :) Bon je vais aller jeter un coup d'oeil pour voir si
> MySQL intégre les transactions, les triggers et l'héritage :)
Ton plaidoyer est éloquent, qu'en pensent les autres ? Est ce que quelqu'un
serait capable de dire l'état de l'art réel de Postgresql coté réplication,
si il y a des sites importants en prod ?, et si ça nécessite encore d'être
fiabilisé ?
>
>
> Désolé pour le bruit.
On est la pour ça ;-)
>
>
