----- Original Message -----
From: "Yannick Lecaillez" <yl@???>
To: "Dominique Chabord" <dominique.chabord@???>
Sent: Thursday, March 11, 2004 2:05 PM
Subject: Re: [HA] MySQL replication
> Le jeu 11/03/2004 à 13:53, Dominique Chabord a écrit :
> > > il suffit de le coupler à
> > > heatbeat et voilà déjà un bon système de HA.
> >
> > L'intégration avec Heartbeat limite beaucoup la solution telle qu'elle a
> > déjà été proposée et nous pensons qu'il
> > est possible de faire mieux
> Certainement
>
> > > C'est sur que packager le
> > > tout serait intéressant pour faciliter le déploiement et le
monitoring.
> >
> > L'intégration d'une solution HeartBeat n'est pas l'objet du projet
> > mentionné. En revanche, si quelqu'un veut s'y attaquer, c'est un projet
que
> > je suivrais avec attention.
> 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.
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.
>
> Le seul (GROS) inconvénient sont les modifications faîtes sur l'esclave
> qu'il faut répercuter ensuite sur le maître. C'est un problème qui se
> pose peut souvent (car normalement le serveur tourne bien) et le
> downtime du serveur "maître" est faible. Du coup on utilise la fameuse
> méthode dite ala-mano (un dump des deux bases, un diff, ...). Ca tourne
> pas trop mal pour le moment. Certe, c'est très loin d'être parfait.
>
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
> > > [...] Bref tout ça pour dire que construire une BDD sans contrainte
> > > d'intégrité référentielle et sans Trigger, je ne trouve pas ça très
> > > "stable". C'est pourquoi je préfère toujours Postgres à MySQL dans
> > > des environnements "sérieux" (autre que dans le cadre d'un forum ou
> > > un livre d'or ...).
> >
> > 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)
>
> > > Peut-être seriez-vous prés à intégrer postgres dans ce projet ?
> >
> > Bien sur, mais nous n'avons pas d'expertise POSTGRESQL dans l'équipe qui
se
> > constitue. Veux tu jouer ce role et décliner la version POSTGRESQL du
projet
> > ?
> > Je pense que les mêmes règles de conception doivent s'appliquer aux deux
> > bases.
> > La version Postgres libre GPL ou compatible comporte t elle ien toutes
les
> > fonctions nécessaires de réplication au niveau de qualité requis ?
> Ben non justement, c'est bien ça le problème qu'il faudrait résoudre :)
> Apparemment la team Postgres commence à s'y atteler avec eRserver. Mais
> bon, je suis pas sur que ce soit utilisable en prod ...
>
Sur ce point aussi, ça ne pose pas de problème pour un business service,
parce qu'un client peut acheter les licences dont il a besoin, mais c'est
une contrainte pour un produit redistribué.
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.
A +
Dominique
