Re: [HA] MySQL replication

Pàgina inicial

Reply to this message
Autor: Yannick Lecaillez
Data:  
A: guilde
Assumpte: Re: [HA] MySQL replication
Le jeu 11/03/2004 à 16:25, Dominique Chabord a écrit :
> > > 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.

Cool :)

> > 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.
> Ta description est pas mal ! Je n'avais jamais essayé de le rédiger !

Merci :)

> 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 ?

Pour reprendre le schéma ci-dessus ma vision ressemblerais à :

Client -> A --->B
          |
          +---->C


A master B et C esclave

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

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 :)

> > > > > 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.

Ah ben dans ce cas ça change tout ! :) Vraiment je pense que j'ai du mal
comprendre ton message.

> > 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.

Moi non plus ?

> > 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>

En effet, je me suis trompé.

> > 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 pense qu'il doit y avoir un problème de communication. Je ne vois
pas en quoi ma remarque peut se traduire par ce que tu dis ? 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.

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/.

> 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 :)


Désolé pour le bruit.