Mysql-Replication et UPDATE / Mysql-Cluster et Lock

Bonjour à tous,

Toujours dans la recherche de plus de puissance, je suis aujourd'hui en train de plancher sur une solution éventuelle de mysqld multiples.

J'ai cepandant plusieurs interrogations un peu pointues et après une bonne journée de recherche infructueuse sur google, sur des listes spécialisées ou non (mais peut etre que j'ai cherché vraiment comme un pied :s), je viens quémander de l'aide ici.

Concernant la réplication Master-Slave, je me demandais quel était le comportement du Slave s'il advenait qu'il recoive un requete d'UPDATE (INSERT,DELETE ou REPLACE aussi d'ailleurs). A t il le même comportement qu'un slapd et forward t il gentillement la requete au Master, ou bien la drop t il avec un message d'erreur ?
Une autre possibilité serait qu'il la traite et se désynchronize donc du serveur. Je ne souhaite pas faire de réplication master-master, pour éviter des écrasements de modifications.

Concernant les Cluster-Mysql, étant donné qu'un SELECT, en MyISAM, est lockant sur toutes les tables et qu'il n'y a pas d'option (à ma connaissance) qui permette de faire de SELECT UNCOMMITED, comme en InnoDB, que se passe t il avec un SELECT sur un cluster Mysql : est ce que l'ensemble des data nodes sont lockés sur les tables de la requête le temps de la requete ? (plus j'y pense, plus ca me parait absurde, mais je préfère en être sur)

Merci à tous de vos lumières.

il se désaligne

Merci bcp ! C'est malheureusement ce que je craignais. Je suppose qu'il n'existe aucun moyen de lui dire de forwarder au master ?

Merci de ton aide.

multi-master replication comme décrite ici.


J'ajouterais cependant l'utilisation de ces variables : auto_increment_increment, auto_increment_offset , qui permette une meilleur cohérence de la réplication circulaire. leur utilisation est explique ici

Concernant le cluster si tu as des info, je suis preneur. je suis moi aussi actuelmment en pleine phase d'analyse pour un remodelage de nos serveurs mysql.

Mais d'après ce que je comprends de ton topic, je pense que tu veux faire les insert sur ton master et les select sur ton slave. pour cela il suffit d'intercaler entre ton appli et ton serveur mysql un proxy. Solution décrite ici


D'après ce que j'ai compris dans un cluster, la table est chargé en mémoire (j'espere ne pas dire de betise, si quelqu'un sait qu'il hesite pas à me contredire). Mais ce que je ne comprends pas ce quand tu as des table énorme (dizaine de millions d'enregistrement) comme cela se passe.

J'espere avoir reppondu a tes attentes.

@+.

Le problème de la réplication master-master, c'est le risque de me retrouver avec deux update simultanés qui s'écrasent mutuellement. J'exclus donc cette option, sauf pour faire un serveur de sauvegarde branché sur une ip fail over.

Je te remercie infiniment pour le lien sur le MySQL Proxy. Je n'ai regardé qu'en survolant, mais damned, ca ressemble fichtrement à ce qui fera mon bonheur.

J'ai écrit sur la liste cluster@lists.mysql.com et on m'a répondu déjà que (mais là, c'est ma faute, j'étais tellement concentré sur mon problème de lock que je n'ai pas pas fait gaffe à ca) les tables ne sont plus en MyISAM ou InnoDB, mais avec l'engine NDBCluster. J'ai effectivement lu la même chose, les tables seraient en RAM O_o J'ai la même interrogation que toi.
Toujours selon la personne qui m'a répondu sur la liste, NDBCluster lockerait au niveau de la ligne et non au niveau de la table, ce qui améliore déjà très grandement les performances.

Je me jète sur la doc et si j'ai des news, je te tiens au courant. Merci encore !

PS : Oui au fait, mon but est en fait de multiplier les serveurs pour pouvoir faire plusieurs requetes simultanées sur les mêmes tables. En gros, si j'ai 1 serveur, je peux faire une requete simultanée a cause du lock, donc avec 10 serveurs, en théorie, je tiens 10 requetes simultanées =) En parrallèlement, j'améliore ma disponibilité en créant de la redondance.

Pour compléter, je dirais que mysqlproxy va te permettre de résoudre un de tes problèmes c'est à dire envoyer les DML sur le master et le DQL sur tes esclaves.

Mais mysqlproxy fait du fail-over c'est à dire qu'il va essayer de requeter sur un liste d'esclave,(d'après ce que j'ai compris de mes lecture anglophones, mysqlproxy est encore trés peu documenté en français) si le premier esclave est indisponible il va s'adresser au deuxième de la liste etc.... ce qui fait que tu ne va pas partager la charge entre les serveurs. Toutefois c'est quand même une solution pour faire de la haute disponibilité.
Néanmoins, il doit être possible de coder grace à LUA une solution de partage de charge.

Cependant il subsite un problème. La réplication mysql étant du semi-temps reel, il peut arriver que certain enreg qui viennent juste d'être intégré sur ton master ne soient pas encore présentes sur tes slave. Il s'agit d'une question de secondes voir de minutes selon le volume mais cela peut être génant selon la criticité des données et des mises à jour. Peut être qu'il sera plus avantageux pour toi de te tourner vers une solution cluster


@+

Oui en effet. Je ne pensais pas que le délai pouvait atteindre le stade de minutes. Des secondes, c'est pas très grave, vu que de toute facon, j'utilise un système de cache maison, mais une minute ou plus, c'est gênant.

Pour ce qui est de la répartition de charge, le proxy doit surement pouvoir prendre un nom d'hote, et on peut faire du Round Rubin DNS dessus.

J'ai été assez pris par un problème avec hotmail cette semaine qui me classait injustement en spam, donc je n'ai pas encore eu le temps d'étudier tout ca.

Je m'y attèle dès que possible. Merci encore pour tes précisions et ton soutien.