----- Original Message -----
From: "Yannick Lecaillez" <yl@???>
To: <guilde@???>
Sent: Thursday, March 11, 2004 3:29 PM
Subject: Re: [HA] MySQL replication
> Le jeu 11/03/2004 à 14:55, Dominique Chabord a écrit :
> > > Et bien c'est un système que j'ai déjà déployé sur deux serveurs. Un
> > > serveur mâitre fait tourner MySQL et réplique sur un autre serveur
> > > "esclave". Si le maître tombe, l'esclave prend le relais (grâce à
> > > Heartbeat).
> >
> > La litterature dont je dispose à ce sujet est ici:
> > http://www.karkomaonline.com/article.php?story=2004012416185184
> > Elle n'est pas référencée sur le site Linux-HA.org
> >
> > Connais tu d'autres personnes qui aient travaillé sur le sujet ?
> > je connais deux autres projets de réalisation de scripts ex-nihilo.
> Non, désolé.
>
> > Dans mon esprit, il y a une différence entre intégrer une solution pour
un
> > site client et intégrer deux produits pour en faire un troisième, qui
puisse
> > etre utilisé sans service.
> Je ne suis pas un business man, je laisse cette tâche à d'autre ;-)
Il ne s'agit pas encore de business ici, mais de contribution au libre.
>
> > C'est déjà pas mal. L'objectif est de recréer le couple primaire-réplica
> > automatiquement...
> > On dispose pour cela d'au moins trois serveurs, contrairement à
HeartBeat.
> > Ton expérience va nous etre précieuse
> ok. Je suppose un maitre qui fonctionne par défaut, un esclave qui est
> le réplica du mâitre et qui prend le relais en cas de PB et le troisième
> est l'esclave de celui qui reste (le maître par défaut ou l'esclave si
> le maître est tombé).
>
> et les rôles maitre / esclave /esclave "secondaire" tourne selon la
> défaillance de chacun d'eux ?
>
> Si le maitre plante, l'esclave prend le relais et continue la
> réplication sur l'esclave "secondaire". Cette esclave (le primaire)
> deviens alors en fait un maître, l'esclave "secondaire" deviens le
> nouvel esclave et le maitre qui à planté deviens l'esclave secondaire.
>
> Bon c'est pas forcément très clair mais bon, j'me comprend :)
> Vous allez bosser dans cette direction ?
Ta description est pas mal ! Je n'avais jamais essayé de le rédiger !
Il faut en plus dissocier:
- les pannes,
- les opérations de maintenance (déplacement volontaire des roles)
- les autres opérations (mises à jour, sauvegarde et restauration etc)
je reproduis ici un extrait d'un message récent interne au projet:
(désolé pour l'anglais)
First open questions:
Are we able to automate all recovery process upon master's failure ?
Are we able to automate master/replica set up ?
Are we able to reestablish automatically master/replicaB in case of replicaA
failure ?
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 ?
>
> > > > MySQL a été choisie pour des raisons non techniques.
> > > Pour sa popularité ? (est-ce que MySQL supporte les transactions ?)
> > 4 raisons:
> > Popularité en nombre d'installations
> > Limitée, préferrée des solutions modestes (pas trop d'implémentations
> > possibles)
> > Proximité stratégique de SAP/R3
> > Des compétences se sont proposées (partenaire mySQL en UK)
> >
> > Le message PostgreSQL semble plus flou (en terme de produit intégré sur
> > CD-ROM)
> Ah ok. Comme je le disais plus haut, je ne suis pas un business man.
Rien à voir avec du business. (Dommage, ça m'arrangerait). Il s'agit de
gestion de produit.
Je
> laisse ça à mes collègues de travail. Je ne suis pas à la recherche de
> solutions rentable à vendre. Mon métier consiste à apporter des
> solutions exploitables en production (et si possible dans le LL, mais ça
> c'est une question de conviction personnelle).
C'est louable.
Je ne vois pas cette barrière entre utilisateurs et contributeurs. Tu
utilises
des produits libres pour les mettre en production. Mais il faut bien que des
contributeurs aient mis leurs "oeuvres" à ta disposition. C'est l'objet du
projet
Shaman-X.
>
> > > > La version Postgres libre GPL ou compatible comporte t elle ien
toutes
> > les
> > > > fonctions nécessaires de réplication au niveau de qualité requis ?
>
> > Hors micro, l'objectif du projet "Shaman-X Database Recovery" est
d'intégrer
> > une distribution Mandrake spéciale entreprise au cours du deuxième
semestre
> > 2004.
> Donc en fait vous allez "créer" un produit commerciale, c'est bien ça ?
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.
Mandrake diffuse des CD-ROM de logiciels libres dont Linux. Le fait d'etre
diffusé sur une distribution d'un grand éditeur permettrait à beaucoup
plus d'utilisateurs d'avoir accès à nos développements, parce que la
mise en oeuvre est facilitée par les outils d'install de la distribution.
C'est peut etre le mot produit, qui te fait penser au commercial ?
<Un produit peut etre libre sous licence GNU/GPL; Un logiciel sur
mesure peut etre commercial sous licence propriétaire>
> Donc évidement autant prendre la tête d'affiche en matière de base de
> donnée libre. C'est tout à fait logique et je comprend très bien. Ceci
> dit, cela ne correspond pas à mes attentes. Comme dit plus haut, j'ai
> besoin d'une "vrai" base de données. Qu'elle soit distribué sur CD
> avec/sans support technique 24h/24h 7j/7 ce n'est pas un problème pour
> moi.
c'est à dire que tu veux bien utiliser ce que les autres
ont fait (gratuitement),
mais que contribuer à ton tour n'est pas ton problème ?
Je n'ai rien à redire la dessus, la licence GNU/GPL te le permet aussi.
Je pense cependant que tes propos ne traduisent pas ta pensée ;-)
C'est comme un coup de gueule, mais je ne sais pas à qui il est destiné !
En tout cas, en ce qui concerne Shaman-X c'est un procès injuste.;-)
>
> Cordialement.
>
>
