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 ;-)
> 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 ?
> > > 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. 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).
> > > 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.
Donc en fait vous allez "créer" un produit commerciale, c'est bien ça ?
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.
Cordialement.
