Journal Solutions de cluster pour MySQL

Posté par (page perso) .
Tags : aucun
0
20
juin
2008
Bonjour,

Nous recherchons actuellement une solution afin de garantir la haute disponibilité de nos services d'hébergement de bases de données MySQL (au nombre de 300 environ).

Aujourd'hui, nous utilisons un cluster MySQL Sun (en actif-backup) : la solution fonctionne a peu près, mais on des gros soucis de performances (certaines requêtes dure 20-30 secondes au lieu d’une seconde par exemple). Cela est lié à MySQL qui ne fonctionne pas bien sur les T2000 (machines Sun). Il n'existe aujourd'hui aucune solution pour y remédier (d'après les experts de MYSQL qui sont venus chez nous, Sun quant à lui pratique la politique de l'autruche sur ce sujet, normal ils ont déjà encaissé les chèques). Nous devons donc abandonner cette solution.

Dans un autre temps, nous souhaitons également ne plus utiliser le système d'exploitation Solaris, au profit de Linux.

Nous avons donc étudiés d'autres solutions (uniquement sur le papier) :

1/ Mise en place d'un cluster Mysql avec LVS et Heartbeat (actif-backup) : on est pas très chaud, car on pense qu'à un moment donnée, si il y a un problème de communication entre les noeuds du cluster, Heartbeat risque de démarrer le MySQL de secours alors que le MySQL maître fonctionne toujours. Cela aura pour conséquence d'avoir 2 MySQL qui écrivent en même temps et les données risquent de devenir incohérentes.

2/ Mise en place d'un cluster avec Redhat-Cluster : aujourd'hui nous n'avons aucune compétence sur cet outils.

3/ Utilisation de la solution de cluster propre à MySQL (actif-actif) : on a étudié la solution, elle semble correcte mais on a tout de même de gros doutes. Premièrement au niveau du nouveau moteur de stockage NDBCluster (qui remplace InnoDB et MyISAM). Est-il fiable étant donnée que le projet est assez jeune ? Trouvera t-on de l'aide en cas de problème (la communauté d'utilisateur n'est pas forcément importante) ?

De plus, nous avons énormément d'applications JAVA qui utilisent Hibernate pour écrire dans les bases. Au jour d'aujourd'hui, nous utilisons les dialects InnoDB. Existe-il les mêmes dialects pour NDBCluster ? Sont-ils fiables ?

Voilà a peu près ce que l'on peut dire sur notre situation actuelle.

Nous voudrions donc savoir :

- si vous avez déjà mit en place une solution de cluster MySQL ?
- pour combien de bases ? Sur combien de machines ?
- si elle fonctionne bien ?
- quels sont les problèmes rencontrés ?
...

Bref, nous donner votre point de vue sur ce domaine et votre retour d'expérience.
Merci d’avance pour vos réponse.
  • # Cluster de SQLite sur 2834 serveurs

    Posté par (page perso) . Évalué à 1.

    Non, je déc... mais c'est fou qu'un aussi gros projet cherche des pistes sur Linux FR. A croire que je suis entouré de pros en consulting, qui vont me piquer un mouton chacun ;-)

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: Cluster de SQLite sur 2834 serveurs

      Posté par (page perso) . Évalué à 2.

      C'est plutôt une bonne idée si le projet veut se monter hors du cadre d'une offre extérieure...

      Et puis même si c'est le cas, deux avis valent mieux qu'un (son de cloche)...
    • [^] # Re: Cluster de SQLite sur 2834 serveurs

      Posté par (page perso) . Évalué à 6.

      On cherche des pistes ici, car on a chercher ailleurs avant, et on a pas eu de vrai réponses.

      LinuxFR rassemble beaucoup d'utilisateurs de Linux et de logiciels libres, j'espère donc y trouver des solutions.
      • [^] # Re: Cluster de SQLite sur 2834 serveurs

        Posté par . Évalué à 5.

        Pour compléter la liste des choix, il y a aussi :
        - Utilisation de DRBD (cherche sur le whitepaper de MySQL A.B. sur le sujet sur leur site). Note cependant que DRBD n'est pas encore intégré dans le noyau standard "kernel.org", donc une part de "polishing" attendu leur reste à faire. http://www.mysql.com/products/enterprise/drbd.html
        - MySQL proxy en frontal. C'est une solution assez simple, qui permet, à minima, de répartir automatiquement les lectures sur les slaves, les écritures sur le master (ou plus, si mode master-master, etc.). http://forge.mysql.com/wiki/MySQL_Proxy

        Et en commentaire plus personnel :
        - Pour le NDBCLUSTER (qui est en fait _leç "MySQL cluster" à proprement parler, selon la terminologie officielle de MySQL A.B./Sun), il faut des machines avec beaucoup de ram, si vos bases sont grosses. Et vous n'aurez pas d'isolation des transaction (un point qui peut avoir son importance, ou pas, selon l'application).
        - Le mode master-master est assez simple et efficace, la réplication est très fiable ; mais à mon gout, heartbeat (+ stonith & co) n'est pas toujours ce qu'il y a de plus fiable ; je préfère keepalived en tout cas (et veiller à avoir un lien direct fiable entre les sgbd, placer du loadbalancing/détection de pannes/failover en frontal (enfin, entre les serveurs applicatifs et les bados) plutôt qu'entre les bases est à mon avis plus fiable, ...).
        - Le site mysqlperformanceblog.com est une mine d'informations, par exemple pour ta problématiques: http://www.mysqlperformanceblog.com/2008/04/28/mysql-replica(...)
  • # juste comme ça

    Posté par . Évalué à -3.

    je te dirais RHCS en payant le support.
  • # mon experience

    Posté par (page perso) . Évalué à 4.

    j'ai testé plusieurs méthode de clusterisation de mysql. Par contre, je ne me souviens plus exactement des version de mysql que j'ai utilisé pour les tests, je suis désolé.

    1- mysql-cluster (ndbcluster)

    date: fevrier l'année dernière

    le principe: 2 nœuds sql (qui recoivent les requêtes) balancés avec LVS/heartbeat. 3 nœuds de stockages (qui se synchronisent entre eux)

    Résultat: la catastrophe. Super instable, les noeuds de stockage tombent sans raison, la synchro ne fonctionnent pas toujours, etc.

    2- mysql replication master-master

    date: avril 2008

    le principe: 2 serveurs mysql qui se répliquent mutuellement et vls/heartbeat devant

    conclusion: cela fonctionne plutot bien, mais il y a quelques problemes: visiblement on ne peut répliquer la base mysql, donc pour créer une nouvelle BD ou un utilisateur ,on ne peut utiliser le cluster, et on doit passer sur chaque nœud exécuter les requetes en local. Autre problème: si je ne me suis pas trompé, la réplication se fait au niveau des bases et pas globalement, il faut donc énumérer dans la conf des nœuds les bases de données que l'on veut répliquer. Cela implique donc de modifier tous les noeuds à chaque ajout de base de donnée, et évidement, il faut relancer les noeuds à chaque fois. Donc vraiment pas terrible finalement. De plus, certains services qui utilisaient une connexion mysql persistante perdaient la connexion sans raison.

    Au final, je n'ai rien validé, je suis toujours avec mon serveur mysql unique, bien backupé, au cas ou. Donc si jamais tu trouves une solution viable, je suis très interessé!
    • [^] # Re: mon experience

      Posté par (page perso) . Évalué à 2.

      Merci pour ton retour, c'est exactement le genre de témoignages que j'attends.
      Visiblement, tu n'est pas plus avancé que nous ...
      • [^] # Re: mon experience

        Posté par . Évalué à 4.

        Bonjour !
        Est-ce que le livre blanc "MySQL et les architectures DRBD à haute disponibilité Introduction aux architectures à haute disponibilité avec MySQL, DRBD et Linux Heartbeat" écrit par MySQL AB pourrait vous intéresser (15 pages). Je l'avais eu par mail, en le demandant via leur site web. Peut-être trouverez vous votre bonheur.
        • [^] # Re: mon experience

          Posté par . Évalué à 1.

          J'ai vu que mon email n'était plus valide. Je l'ai actualisé, et ajouté mon Jabber ID. Donc je suis joignable directement si besoin. N'hésitez pas!
    • [^] # Re: mon experience

      Posté par (page perso) . Évalué à 2.

      Bizarre, ça : j'ai une simple réplication master-slave, et si je crée/supprime des bases et/ou utilisateurs, tout va bien. La seule différence est que le 2ème n'est pas maître pour le premier, mais bon, on peut répliquer TOUT le serveur MySQL.

      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: mon experience

      Posté par . Évalué à 5.

      je fais du master-master-plein de slaves depuis plus de 2 ans sans soucis. Les bases sont crées sur une seule instance et repliquées.
      En frontal j'ai un keepalived qui verifie que les moteurs sont UP. En plus j'ai une table qui me sert a indiquer le poids de chaque instance, pour pouvoir facilement mettre off-line un noeud.

      Par contre le master-plein-de-slaves ne marche que parceque le code sait ou ecrire et ou lire (2 connections différentes).

      Les slaves sont ausi retirés du pool lorsqu'ils commencent a prendre le large en replication, afin de 1) eviter de servir des infos trop anciennes et 2) leur permettre de recuperer.

      Parmis les "soucis", le fait que la replication ne prend qu'un thread, donc si tu replique une grosse requete, toutes les petites requetes suivantes doivent attendre. Faut aussi faire gaffe que les dev codent "propre", cad utilisent bien les auto-increment sant faire des calculs debiles dessus.

      Si t'as des applis specifiques comme du reporting, c'est pratique de les faires tourner sur un seul noeud, pour eviter de paralyser le reste de la prod.

      Pour les backups, tu freezes un slave (tu stopes la replication) et tu fais soi un dump, soi une bete copie de fichiers une fois le slave arreté. profite en pour suavegarder aussi les infos de replication, pour pouvoir re-utiliser ce backup sur un autre noeud et reprendre facilement.
  • # Solutions de cluster pour MySQL

    Posté par . Évalué à 3.

    Si je reprend tes pistes :

    1 - Au lieu de résonner actif/backup, si ton application le permet, essaye plutôt lecteur/écriture : 1 base master uniquement pour les écritures et n bases slaves uniquement pour la lecture, avec LVS en loadbalancing/failover.

    2 - A ma connaissance, RHCS fonctionne au niveau de MySQL en actif/backup donc même problème... (RHCS te propose un FS partagé, GFS, et des outils intégrés permettant des synchro type actif/passif ou actif/actif)

    3 - Je connais mal, mais c'est peut être la solution la moins couteuse en terme d'ingénierie.

    Sur des solutions de cluster MySQL, de part mon expérience, il vaut mieux séparer tes flux, en vision application ou business.

    Tu peux répartir tes charges de lecture/écriture, avec des synchro croisés. C'est un enfer à administrer mais ça marche plutôt bien. (me souviens d'un client ayant des bases MySQL à plus de 100 Go, avec des SLA sur les performances réparti sur 6 serveurs dédiés).

    Quoi qu'il arrive, tu sera sans doute obligé de passer par un redéveloppement d'une partie de tes applications pour prendre en compte ton cluster.

    Bon courage !
    • [^] # Re: Solutions de cluster pour MySQL

      Posté par (page perso) . Évalué à 3.

      Je rajoute quelques précisions sur notre problématique :

      - on veut de la haute disponibilité, on a pas de problème de charge. D'où un raisonnement en actif/backup qui semble la technologie la moins risqué.

      - on héberge au total plus de 1000 sites Internet. Je dirais que l'on a une centaine d'applications JAVA répartie sur une ferme de 20 serveurs, le reste c'est du php/MySQL (Apache). Il est donc hors de question de toucher au code des applications, et c'est à cause de cela que l'on a des gros doute sur l'utilisation du nouveau moteur NDBCluster, car on aura du mal à voir les effets de bords.

      La solution Redhat cluster semble bien, mais on ne connait pas. On veut bien acquérir la compétences, mais il nous faudrait plus de retour d'expérience pour savoir si c'est quelque chose de fiable.
      • [^] # Re: Solutions de cluster pour MySQL

        Posté par . Évalué à 4.

        Ah oui, et bien dans ce cas la réplication master-master me semble un peu risquée : il faut que les applications laissent mysql générer les auto increments proprement (c'est à dire le laisser faire en sorte que deux insertions simultanées sur une même table sur deux noeuds différents ne génèrent pas la même clef primaire, sous peine de conflit à la synchronisation) ; et il me semble difficile de vérifier ça sur une centaine d'applications. À moins que toutes ces applications utilisent une bibliothèque identique et auditable gérant ce genre de choses (hibernate ?)...
        • [^] # Re: Solutions de cluster pour MySQL

          Posté par . Évalué à 3.

          Quoi qu'en fait non, pardon ; si vous voulez seulement de la haute disponibilité sans équilibrage de charge, alors vous pouvez avoir du master-master avec un seul master actif à un instant donné, donc sans aucun risque d'incohérences, même avec des applications peu coopératives.

          De plus, en plaçant la répartition/l'aiguillage des requêtes en amont des bases (load balancers, ou MySQL proxy, ou haproxy, ou une paire de keepalived en frontal), aucun risque de "splitted brain". La réplication native de MySQL marche _très_ bien, aucun soucis à se faire. C'est un des rares points où MySQL dispose d'une large avance technologique sur PostgreSQL.
        • [^] # Re: Solutions de cluster pour MySQL

          Posté par . Évalué à 1.

          >c'est à dire le laisser faire en sorte que deux insertions simultanées sur une même table sur deux noeuds différents ne génèrent pas la même clef primaire, sous peine de conflit à la synchronisation

          ça c'est facile a faire avec MySQL, il suffit d'utiliser des autoincrements en spécifiant dans my.cnf le premier index et le pas d'incrément.
          Par exemple avec deux serveurs, en demarrant à 0 sur l'un et a 1 sur l'autre et en utilisant un pas de 2, tu aura systématiquement des index pair sur l'un et impair sur l'autre.

          mais ce n'est pas le seul problème lié à la réplication mysql. le plus gros problème est qu'elle n'est pas synchrone et que en cas de crash on ne sait pas dire quelles transactions sont passées et quelles transactions ont subit le crash sur tous les noeuds.
          • [^] # Re: Solutions de cluster pour MySQL

            Posté par . Évalué à 1.

            > ça c'est facile a faire avec MySQL, il suffit d'utiliser des autoincrements en spécifiant dans my.cnf le premier index et le pas d'incrément.

            Bin oui, c'est pour ça que je disais qu'il faut que les applications laissent MySQL gérer ceci.
  • # Et Sequoia ?

    Posté par (page perso) . Évalué à 1.

    Il existe un projet open-source en Java pour fournir une solution middleware pour faire des clusters de bases données.

    Le projet s'appelle Sequoia (http://sequoia.continuent.org) et était anciennement nommé C-JDBC. En fait, Sequoia fournit des drivers JDBC qui permettent d'être intégrée dans une application JAVA.

    Concernant MySQL, la société derrière (Continuent) propose une solution propriétaire uni/cluster basée sur Sequoia.
    Voici le lien : http://www.continuent.com/index.php?option=com_content&t(...)

    Perso, j'ai vu en oeuvre Sequoia lors de démo mais je ne sais pas ce que cela vaut.

    Xavier
    • [^] # Re: Et Sequoia ?

      Posté par (page perso) . Évalué à 2.

      J'ai pas mal bossé dessus il y a un moment (et contribué un peu aussi) pour monter un cluster PostgreSQL.

      C'est un beau projet, pas parfait (la réplication parfaite n'existe pas vraiment...) mais c'est bien fini et les gens qui bossent dessus sont très ouverts et sympas. J'en garde un très bon souvenir.

      On n'est pas allé jusqu'à la mise en production à cause de l'application au dessus qui avait un gestionnaire de pools de connexion merdique mais en dehors de ça, ça marchait plutôt bien (on avait des idle in transaction qui restaient et Sequoia attend que les transactions soient terminées avant de manipuler le cluster). C'est un problème récurrent pour ceux qui ont la "chance" de connaître RH WAF/CCM.

      L'autre point est qu'il faut bien voir ça comme de la sécurisation et de la mise à l'échelle car l'overhead est loin d'être négligeable. Ca se sent surtout en utilisation avec plein de petites requêtes.

      Par contre, je conseillerais soit de toucher un peu sa bille en java et de creuser un peu la solution pour pouvoir dégrossir les problèmes rencontrés, soit de prendre un contrat de support chez Continuent.

      La communauté est plutôt réactive et Continuent joue clairement le jeu de l'open source mais il faut quand même arriver à détailler un peu ce qu'il se passe.
  • # Proxy ...

    Posté par (page perso) . Évalué à 1.

    Il me semble qu'un proxy MySQL écrit en LUA existe.

    Il permet de loadbalancer "Intelligemment" les requêtes. Sa config étant un langage de programmation assez évolué, il est possible de quasiment tout faire : Actif / passif, Master / N slave, réécriture de requêtes, etc ...

    Cyril

    http://la-rache.com

  • # je sais que je vais me faire jeter...

    Posté par (page perso) . Évalué à 4.

    ma la réalité est là: le seul SGBD qui gère (de manière fiable / efficace) du clustering actif/actif est Oracle avec l'option Real Application Cluster.

    C'est cher: 45 K€ / processeur, c'est compliqué, mais ça marche bien, ça supporte un nombre important de noeuds dans le cluster (en fait, dépendant de l'OS: 255 pour Linux), et la technologie de Cache Fusion permet d'avoir un overhead limité.

    voilà, je m'en vais....
  • # Un bouquin qui pourrait t'aider

    Posté par . Évalué à 1.

    http://books.google.com/books?id=sgMvu2uZXlsC&printsec=f(...)

    Je pense qu'il pourra t'être utile, ils filent pas mal de schema concernant la réplication et autres techniques de clusturing.
  • # drbd / heartbeat

    Posté par (page perso) . Évalué à 2.

    on utilise depuis environ 8 ans une solution drbd/heartbeat pour environ une 50antaine de bases pas forcément très sollicités, de l'hébergement web essentiellement ou des bases ldap mais naturellement utilisé surtout en lecture.
    En 8 ans on a changé 3 fois les machines d'origines (ajouté 2 autres clusters) ont a eu quelques casses de disque dur, ce qui permet de basculer sur les machines de secours avec 5secondes d'interruption. La liaison heartbeat est un câble croisé entre des cartes gigabits. Un maladroit a déjà débranché ce câble sans qu'on ai eu de corruption de données, sans doute parce que les bases sont peu sollicités en écriture.
    Pour de l'hébergement web on est très satisfait de cette solution. On n'a pas fait de tests récents sur des bases avec beaucoup d'écritures.
    • [^] # Re: drbd / heartbeat

      Posté par . Évalué à 2.

      drbd depuis 8 ans ... c'était très très très jeune à l'époque !!
      du coup nous on utilise plutot du mirroring RAID (couche md) sur des lun SAN. On avait testé drbd en 2002/2003 sans être vraiment convaincus. Mais on relance un projet drbd cette année, conscient que ce produit a beaucoup évolué.

      <mode chieur> PS: pas besoin de cable croisé pour des cartes gigabit, le "sens" d'utilisation des paires est négocié dynamiquement.</mode chieur>
      • [^] # Re: drbd / heartbeat

        Posté par (page perso) . Évalué à 2.

        > drbd depuis 8 ans ... c'était très très très jeune à l'époque !!
        et oui, fallait oser mais nos tests pour un objectif d'hébergement web nous ont convaincu.
        L'état actuel du projet confirme que nous avons fait le bon choix.
        Ensuite pour d'autres utilisations en écritures intensives, il ne faut sans doute pas se faire d'illusion, il y a sûrement perte de performance. Il faut ensuite identifier les cas d'usage acceptables.

        Actuellement nos tests sur les modes actif/actif ne sont pas totalement concluant : c'est surtout difficile à tester.

        Merci au chieur j'essaierai à l'occasion le mode auto-négocié. C'est fou ce que la technologie progresse ;-)
        • [^] # Re: drbd / heartbeat

          Posté par . Évalué à 1.

          Actif/Actif dans quel sens ?
          Nous avons prévu de tester avec un GFS par dessus un drbd actif/actif, les ébauches de tests me font croire que c'est utopique ... est-ce le genre de tests que vous faites ?
        • [^] # Re: drbd / heartbeat

          Posté par . Évalué à 1.

          DRBD est effectivement assez impressionnant. Mais on reste dans du failover.

          Y a t il une solution actif actif sur de la synchronisation de données ? (a part rsync ou du bon vieux NFS)
  • # Cluster RedHat

    Posté par . Évalué à 1.

    Nous utilisons un cluster RedHat en actif/passif pour nos bases MySQL et en actif/actif pour les frontaux Apache.

    Le principe pour les bases MySQL :

    2 serveurs (ou plus) avec une partition SAN (avec GFS) ou NFS commune sur lesquelles se trouvent les bases. Les noeuds communiquent en permance leur état. Si un noeud ne détecte plus l'autre, il le sort du cluster par différents moyens. Chez nous, il effectue une coupure électrique ou niveau du Chassis, comme ça nous somme sûr que le noeud défaillant de viendra pas corrompre les données.

    La reprise du serveur MySQL s'effectue automatiquement par les scripts RedHat en 10 à 20 secondes.

    Nous n'avons encore pas vraiement eu l'occasion de tester en conditions réelles, mais lors des essais, cela fonctionnait bien. Nous avons parfois des problèmes au redémarrage des machines pour leur faire remonter la partition commune, mais c'est anecdotique.

    L'avantage de RedHat, c'est qu'on peut faire appel au support. Pour tout ce qui concerne les cluster, il n'y a qu'un gars qui puisse répondre, mais il est plutôt callé, même si ça demande parfois de passer de longues heures au téléphone.

    Bref, on est assez content de la solution car c'est assez stable et le basculement fonctionne bien. En revanche, le projet de cluster RedHat mérite de murir encore un peu je pense pour être totalement fiable.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.