Discussion :

[rvzip64]

Une petite question sur la réplication.

Un petit extrait :

Si la partie de votre code qui réalise les accès aux bases de données a été proprement modularisée, la convertir en une configuration qui supporte la réplication ne sera pas un problème : modifiez simplement votre base pour qu'elle aille lire sur les esclaves et le maître, mais ne fasse que des modifications avec le maître. Si votre code n'a pas ce niveau d'abstraction, l'installation du système de réplication vous donnera alors la motivation ou la raison pour le faire. Vous devriez commencer par créer une couche d'abstraction ou un module avec les fonctions suivantes :
safe_writer_connect()
safe_reader_connect()
safe_reader_query()
safe_writer_query()

Donc si le client veut tirer parti de la réplication il conseille de code les 4 fonctions suivantes.

Mais je ne comprends pas "qu'elle aille lire sur les esclaves et le maître", ça veut dire que si j'ai 3 serveurs escalves, je dois lancé ma requete de lecteure en meme temps sur les trois serveurs ?

[Sivrît]

Nope, l'idée est de répartir les requêtes de lecture sur tous les serveurs (façon round robin par ex) pour réduire leurs charges. Et les modifications de la base ne peuvent se faire que sur le maitre.

[rvzip64]

Oui tout ça j avais bien compris , mais comment tu fais ça ???

[Maximil ian]

En mettant en place un système de load balancing (produit existant ou solution maison)

[rvzip64]

Et mysql ne fait pas ça ????

[Maximil ian]

Non.

[rvzip64]

C'est étonannt car quand je lis la faq de mysql, ils ne parlent d'une chose si compliquée. Il parle simplement de faire une couche d'abstraction dans le code client.

[Sivrît]

Si la partie de votre code qui réalise les accès aux bases de données a été proprement modularisée

Si les appels à la base passent par une couche d'abstraction, il suffit de modifier cette couche pour qu'elle aussure la répartition de façon transparente et tout est simple (il faut juste ouvrir plusieurs connections et alterner). Sinon il faut modifier tout le code d'accès à la BDD et c'est moins drole.

Ou alors, comme le suggère Maximilian il faut un outil dédié, genre CJDBC (http://c-jdbc.objectweb.org/) qui est assez transparent.

[rvzip64]

tout est simple (il faut juste ouvrir plusieurs connections et alterner).

Donc si par exemple j ai plusieur client, il suffit que dans mon code, je passe d'unserveur a l'autre simplement ?? Sans rien faire de plus?

[Sivrît]

Donc si par exemple j ai plusieur client, il suffit que dans mon code, je passe d'unserveur a l'autre simplement ?? Sans rien faire de plus?

Effectivement chaque client pourrait utiliser un serveur différent... pour ses "SELECT". Il faut veiller à ce tous effectuent leurs modifications sur le maître, ce qui ramène à la même problématique : mettre à jour le code des clients.

Il faudrait peut-être faire attention à la synchronisation entre les modifications sur le maître et des SELECT après sur une réplication (je ne sais plus si MySQL donne des garanties là dessus), et aussi à la gestion des transactions qui pourrait être plus délicate. A part cela, il s'agit juste d'intérroger différentes réplications pour répartir la charge, ce qui est d'autant plus intéressant qu'il y a peu de modifications de la base.

Et mysql ne fait pas ça ????

Avant tout la réplication de MySQL vise à protéger les données et assurer la continuité du service (si le maître a un problème une réplication peut prendre le relai). Gagner en performances est un "petit plus".

[rvzip64]

Gagner en performances est un "petit plus"

On a pas la meme conception de la réplication alors .....

Pour moi elle fait progresser le système sur deux points importants :

• Un systéme a haute tolérance de panne
• Un systéme avec de meilleur performance

La réplication MySQL est particulièrement avantageuse pour les systèmes qui gèrent des lectures fréquentes, et des écritures plus rares. En théorie, en utilisant uniquement un maître et beaucoup d'esclaves, vous pouvez augmenter les performances de votre système jusqu'à saturation de la bande passante ou du maître, pour les modifications.
Afin de déterminer le nombre d'esclaves que vous pouvez obtenir voir les performances de votre système s'améliorer, vous devez bien connaître les types de requêtes que vous utilisez, et empiriquement déterminer la relation entre le nombre de lectures et d'écritures (par secondes, ou maximum absolu), pour un maître et un esclave. L'exemple ci-dessous va vous montrer comment faire des calculs simples.

Imaginons que votre charge système soit constituée de 10% d'écriture et de 90% de lectures. Nous avons aussi déterminé que le maximum de lectures max_reads = 1200 - 2 * max_writes , ou, en d'autres mots, notre système peut voir des pics de 1200 lectures par secondes sans aucune écritures, notre temps d'écriture moyen est deux fois plus temps qu'une lecture, et la relation est linéaire. Supposons que notre maître et notre esclave sont de la même capacité, et que nous avons N esclaves et un maître. Nous avons alors pour chaque serveur (maître ou esclave) :
lectures = 1200 - 2 * écriture (issue des tests)

lectures = 9* écriture / (N + 1) (lectures réparties, mais toutes les écritures vont à tous les serveurs)
9*écriture/(N+1) + 2 * écriture = 1200

écriture = 1200/(2 + 9/(N+1)
Si N = 0, ce qui signifie que nous n'avons pas de réplication, notre système peut gérer 1200/11, environs 109 écritures par secondes, ce qui signifie (que nous aurons 9 fois plus de lectures que d'écritures, étant donné la nature de notre application).

Si N = 1, nous pouvons monter à 184 écriture par seconde.
Si N = 8, nous pouvons monter à 400 écriture par seconde.

Si N = 17, nous pouvons monter à 480 écriture par seconde.
Eventuellement, si N se rapproche de l'infini (et notre budget de l'infini négatif), nous pourrons nous rapprocher de 600 écritures par secondes, en améliorant le système 5,5 fois. Toutefois, avec 8 serveurs, nous avons pu améliorer le système de 4 fois.

Notez que nos calculs ont supposés une bande passante infinie, et que nous avons négligé des facteurs qui pourraient être significatifs pour notre système. Dans de nombreux cas, nous ne pourrions pas faire de calculs précis pour prédire l'état de notre système avec N esclaves de réplication. Toutefois, répondre aux questions ci-dessus vous permettra de décider si la réplication est une solution à votre problème ou pas.

* Quel est le ratio d'écriture/lecture de votre système?
* Quelle est la charge maximale d'un serveur en écriture, si vous pouvez limiter les lectures?
* Combien d'esclaves votre réseau peut supporter?

[Sivrît]

Disons un gros petit plus ?
Personnellement, compte tenu de fait de MySQL ne founit pas les outils pour la répartition de charge et les laisse... à la charge de l'utilisateur, je considère que ce n'est pas le but premier. Comme on a plusieurs bases identiques, il se trouve que l'on peut intérroger n'importe laquelle. Bon j'arrête les sophismes et