Discussion :

[Mangara]

Bonjour,

J'ai mis en place une réplication mysql de type master to master (ou chacun est aitre et esclave de l'autre).
Cela fonctionne assez bien, néanmoins je rencontre un problème assez coton : lors d'une reprise après interruption de la communication entre les deux serveurs, les requête insert passent très bien (pour les autoincrement c'est bon aussi avec les décalages d'offset), mais les requêtes update c'est autre chose...

Si je modifie la même ligne sur chacun des serveurs en y insérant des données différentes, je me retrouve à la reprise avec les données du serveur A sur le serveur B et les données du serveur B sur le serveur A, en fait la réplication se croise, ce qui pose un léger problème de cohérence de base...

J'ai regardé pour trouver une prérogative simple de façon à rendre un serveur prioritaire à l'autre, mais rien ... (en tout cas je n'ai rien trouvé...)

Est-ce que l'un d'entre vous aurait déjà été confronté à ce cas et y a-t-il une solution ?

Nota : ceci est un doublon d'un précédent post glissé dans la mauvaise section

[SQLpro]

Il n'existe pas de solution à ce problème de manière générale et il faut corriger à la main les conflits de réplication, car contrairement à d'autres SGBDR comme MS SQL Server, MySQL ne dispose pas d'un gestionnaire de conflits de réplication.
De toute façon, la réplication des données est à utiliser le moins possible pour diverses raisons, notamment les problèmes de cohérence, mais aussi de pompage des ressources (cela coûte très cher...)

A +

[Mangara]

C'est bien ce qu'il me semble aussi, à croire que j'ai rêvé ou loupé quelque chose lors des premiers test ...

Je suis en train de développer une magnifique surcouche pour gérer la reprise, ça va être coton...

Merci quand même.

[Fred_34]

Si tu es en mode Statement et que tu sais si tu es sur le master ou le slave, il est peut être possible d'avoir différentes requêtes en fonction du serveur.

Par exemple si sur le master tu fais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

UPDATE onetable SET oneColumn=newValue WHERE id=blahblah...

Et sur le Slave :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

UPDATE onetable SET oneColumn=newValue WHERE id=blahblah... AND oneColumn=oldValue

A mon avis, lors de la reprise, la requete du master va s’exécuter dans tous les cas sur le slave, mais celle du slave ne fera rien sur le master si la ligne a changée entre temps.

[overider]

Bonjour.

Les 3 variables suivantes sont hyper importantes dans une réplication multi-master

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
# ID du serveur. !!!!! l ID doit etre diffferent sur chaque serveur
server-id       = 1
# pas pour l'offset
auto_increment_increment      = 10
# offset de replication
auto_increment_offset         = 1

Voir aussi le super article de Giuseppe Maxia qui illustre les possibilités d'un replication multi-master. Il est un peu vieux mais encore d'actualité.


Le mode statement est également un nouvelle composante fondamentale d'un réplication multi master. Cela ne va pas résoudre les conflits tout seul, mais ça t'aide à les détecter; le plus délicat étant les update, car une fois que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

auto_increment_increment

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

auto_increment_offset

les insert sont moins problématiques.

BOn courage.