mySQL cluster : qqu a essayé ?

Salut

Je voulais savoir si quelqu'un ici avait deja essayé de mettre en place un cluster mySQL, et si oui, si il a des astuces ou techniques sympas.

Merci

<hs>comment je suis poli, "salut" et "merci" et tout</hs>

<mode HS>Comment je sens déja que le topic va partir en sucette...</mode HS>

Perso les ressource materielles necessaires me paraissent vraiment trop importantes.

Et ne l'ayant jamais vu fonctionner, je reste perplexe sur la capacite du truc a prendre 400 req / seconde (ce qu'on fait par exemple en moyenne, alors en pointe...) tout en restant coherent sur tous les nodes du cluster, et le tout en transactionnel Je serais curieux de voir ca un jour

d'après ce que j'ai lu il y a une forte latence, dépendant surtout du matos réseau : genre toutes les requètes mettraient minimum 500ms... Par contre en théorie le gros avantage c'est que même avec 10'000 req/s elles mettent le même temps.... enfin... en théorie hein.

En tous cas je ne suis pas encore séduit, ne serait ce qu'à cause des incompatibilités techniques.

Sinon pour répondre à la question, dans les dernières news de Nexen.net, il y a quelques conseils de Mr Wikipedia sur MySQL Cluster.

Les données étant déportées sur d'autres machines, c'est aussi pour les SELECT.

Afin d'optimiser le cache des serveurs frontaux, ils conseillent d'ailleurs de ne pas faire de load balancing mais plutôt d'essayer de séparer les frontaux par groupes... Dans le cas de wikipedia, ils ont séparé par langue, par exemple.

rano> c'est aussi la solution que j'ai retenu, je partitionne au fur et a mesure de la montee en charge, et ca marche tres bien. Moi j'ai juste la contrainte du transactionnel en plus qui fait que TOUTES les tables transactionnelles doivent etre sur le meme serveur...

Bool> merci pour ces complements d'info, donc en pratique, le cluster Mysql est meme pas immaginable si tu ne peux pas mettre tes resultats de requettes en cache Ce qui est contradictoire, car si tu peux faire du cache, je vois pas pourquoi tu serais amene a utiliser un cluster Mysql

Je n'ai pas précisé, mais il s'agit du cache de données des serveurs MySQL frontaux, pour éviter qu'ils aient à "télécharger" systématiquement les données (ce qui éliminerait les problèmes de latence).

Le soucis c'est que dès qu'il y a la moindre modif dans une table, si un SELECT doit être fait sur un des serveurs, il y a des chances pour qu'ils doivent télécharger un gros volume de données depuis un des nodes de stockage. Et si tous les serveurs "trifouillent" sans arrêt cette même table, ils doivent sans arrêt se resynchroniser, ce qui introduit une "forte" latence.


Après tout ça pour moi ce n'est que de la théorie, c'est ce que j'ai cru comprendre des divers docs et articles en anglais que j'ai lu. J'ai donc très bien pu mal interpréter.


Sinon dans les solutions "mono machines" :
- passer sur une distribution 64bits, et avec de l'opteron (pas du Xeon, même EMT64)
- beaucoup de mémoire, pour augmenter les différents buffers de mysql
- passer à MySQL 5.1 et son partitionnement de table
- InnoDB pour les tables avec beaucoup d'écriture
- remplacer ext3 par un système de fichier plus adapté
- prendre des disques très rapides, avec une latence très faible (raptor, sata 2, ou carrément scsi 15'000 tr/min)


L'idéal étant d'identifier le problème...

wo

En fait comme tu nous a pas explique la problematique, nous on papotte

Pour MySQL, d'après les quelques benchs que j'ai vu il y a une "énorme" différence de perfs entre l'Opteron et le Xeon EMT64 (celui ci faisant à peine mieux que la version 32bit).

Mais ceci n'est valable que dans un environnement 64bit. En 32bit je ne me suis pas vraiment renseigné, mais la différence ne doit pas être énorme.