0
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.
> Lire le journal (33 commentaires, moyenne: 2,1).
Vous avez demandé le commentaire #942703.



Cluster de SQLite sur 2834 serveurs
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 ;-)
[^]Re: Cluster de SQLite sur 2834 serveurs
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
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.
Tux-planet
[^]Re: Cluster de SQLite sur 2834 serveurs
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(...)