> exemple de cas problématique :
> j'insère une donnée avec auto incrément à gauche.
Heu non, super mauvais exemple.
MySQL dispose d'une paire de paramètres, auto-increment-increment et auto-increment-offset, qui permettent de faire en sorte que les valeurs générées par auto increments soient systématiquement différents sur les divers serveurs.
Exemple, si on a deux serveurs, on mettra :
* my.cnf du server1:
auto-increment-increment = 2 # le nombre total de serveur du cluster
auto-increment-offset = 1 # un nombre unique par serveur inclus entre 1 et auto-increment-increment
Dès lors, server1 ne générera que des incréments impairs et server2 que des incréments pairs : pas de conflits possibles sur les clefs primaires tant qu'on utilise l'auto increment natif.
Le même principe fonctionne avec n serveurs (on aura un "auto-increment-increment = n" partout, des "auto-increment-offset = x" distincts sur chaque serveurs, et les ids générés sur les divers serveurs seront des multiples de "n % x", toujours distincts).
> donc globalement la réplication master/master est possible, mais avec des limitations dont il faut tenir compte dans le développement de son appli.
Exact, disons qu'elle est asynchrone et qu'il n'y a pas de verrous partagés ; donc il est possible que des transactions exécutées sur divers serveurs simultanément s'exécutent bien, mais que leurs modifs respectives soient écrasées lors de la synchro, en particulier dans le cas des UPDATE (ce qui est assez différent d'un très gênant conflit sur une clef primaire).
Ca peux néanmoins suffire prou des applis très exigeantes en termes de répartition de charge et perfs et moins exigeantes en terme de garantie de persistance des modifs (cas courant pour des applis du "web 2.0 social"), ou du moins pour la partie (le "bulk") des données pouvant tolérer ces contraintes (il n'est pas forcément toujours nécessaire de répartir la charge en écriture sur un cluster master-master sur l'ensemble des données).
Le cas échéant (applis ayant un besoin impérieux de garanties), ça peux toujours servir pour préparer un hot spare redondant sur lequel on n'écrit pas (on peux y lire, l'utiliser comme un slave), mais dont on sait qu'il est vraiment pret à prendre la main de façon robuste et supportera bien les problèmes éventuels de flip-flop ; bref, assortis à keepalived ou hearbeat ou wackamole, un "slave amélioré" prêt à être promu en vrais master sans bidouille / intervention manuelle / exécution de script / bricolage de protection (pas besoin de s'inquiéter, par ex., que le précédent master déchu puisse être de retour et re-promu en master principal). L'automatisation de la reprise d'activité sur des environnement ne supportant que la réplication unidirectionnelle (master->slave) est toujours très dangereuse et fragile...
[^] # Re: Réplication Mysql master/master
Posté par herodiade . En réponse à la dépêche Répartition de charge : axes de réflexion et quelques exemples de solutions libres. Évalué à 10.
> j'insère une donnée avec auto incrément à gauche.
Heu non, super mauvais exemple.
MySQL dispose d'une paire de paramètres, auto-increment-increment et auto-increment-offset, qui permettent de faire en sorte que les valeurs générées par auto increments soient systématiquement différents sur les divers serveurs.
Exemple, si on a deux serveurs, on mettra :
* my.cnf du server1:
auto-increment-increment = 2 # le nombre total de serveur du cluster
auto-increment-offset = 1 # un nombre unique par serveur inclus entre 1 et auto-increment-increment
* my.cnf de server2 :
auto-increment-increment = 2
auto-increment-offset = 2
Dès lors, server1 ne générera que des incréments impairs et server2 que des incréments pairs : pas de conflits possibles sur les clefs primaires tant qu'on utilise l'auto increment natif.
Le même principe fonctionne avec n serveurs (on aura un "auto-increment-increment = n" partout, des "auto-increment-offset = x" distincts sur chaque serveurs, et les ids générés sur les divers serveurs seront des multiples de "n % x", toujours distincts).
Hop, la doc de ref : http://dev.mysql.com/doc/refman/5.1/en/replication-options-m(...)
> donc globalement la réplication master/master est possible, mais avec des limitations dont il faut tenir compte dans le développement de son appli.
Exact, disons qu'elle est asynchrone et qu'il n'y a pas de verrous partagés ; donc il est possible que des transactions exécutées sur divers serveurs simultanément s'exécutent bien, mais que leurs modifs respectives soient écrasées lors de la synchro, en particulier dans le cas des UPDATE (ce qui est assez différent d'un très gênant conflit sur une clef primaire).
Ca peux néanmoins suffire prou des applis très exigeantes en termes de répartition de charge et perfs et moins exigeantes en terme de garantie de persistance des modifs (cas courant pour des applis du "web 2.0 social"), ou du moins pour la partie (le "bulk") des données pouvant tolérer ces contraintes (il n'est pas forcément toujours nécessaire de répartir la charge en écriture sur un cluster master-master sur l'ensemble des données).
Le cas échéant (applis ayant un besoin impérieux de garanties), ça peux toujours servir pour préparer un hot spare redondant sur lequel on n'écrit pas (on peux y lire, l'utiliser comme un slave), mais dont on sait qu'il est vraiment pret à prendre la main de façon robuste et supportera bien les problèmes éventuels de flip-flop ; bref, assortis à keepalived ou hearbeat ou wackamole, un "slave amélioré" prêt à être promu en vrais master sans bidouille / intervention manuelle / exécution de script / bricolage de protection (pas besoin de s'inquiéter, par ex., que le précédent master déchu puisse être de retour et re-promu en master principal). L'automatisation de la reprise d'activité sur des environnement ne supportant que la réplication unidirectionnelle (master->slave) est toujours très dangereuse et fragile...