Réplication : Incohérence des données insérées

Version imprimable

2 pièce(s) jointe(s)

Bonjour,

je ai effectuer une installation de serveur sgbd de type mariadb 10.1.37 sur deux machines serveurs pour but de garantir une haute disponibilité d’accès à la base de donnes en utilisant la méthode de réplication classique en mettant en place les deux serveurs en tant que des machines MASTER-MASTER, comme il illustrer dans l'image ci-dessous.

Pièce jointe 440051

durant la période de test de cette solution, j'ai constater que il y une incohérence des donnes insérées. toujours il y a des enregistrements ont le même id dans les deux serveurs mais avec des données différents.

S1 mariadb S2 mariadb

INSERT INTO `contact_user` (id, user_id, numero_telphone, adresse) VALUES
(7673,7673,'70775806',NULL),
(7674,7674,'83298117',NULL),
(7675,7675,'73874812',NULL),
(7676,7676,'77636225',NULL),
(7677,7677,'93607684',NULL),
(7678,7678,'76225441',NULL),
(7679,7679,'75385298',NULL); INSERT INTO `contact_user` (id, user_id, numero_telphone, adresse) VALUES
(7673,7673,'70775806',NULL),
(7674,7674,'83298117',NULL),
(7675,7675,'90635536',NULL),
(7676,7676,'90911015',NULL),
(7677,7677,'93607684',NULL),
(7678,7678,'76225441',NULL),
(7679,7679,'75385298',NULL);

j'ai besoin d'une solution pour résoudre ce problème.

Merci d'avance.

09/01/2019, 17h38
SQLpro

Une solution de réplication des données bidirectionnelle présente toujours ce genre de problématique qui ne peut pas être résolu automatiquement. En effet de chaque côté, au même moment des données peuvent être mises à jours sur les mêmes tables/lignes/colonnes…
Cela s'appelle un conflit de réplication.
Dans certains SGBDR avancé, la résolution de tels conflits peut être automatisé en précisant par exemple que la priorité est donnée au temps (mais même là il peut y avoir conflit et surtout il faut travailler en TU), ou encore au nœud. Par exemple dans MS SQL Server….

A +
10/01/2019, 12h07
Artemus24

Salut à tous.

Je n'ai jamais testé le mode de réplication master/master, juste testé celui du master/slave.
Je suppose que cela doit être la même chose, sauf que la replication se fait dans les deux sens.

Plusieurs questions :

1) sur quel type de système d'exploitation travaillez-vous ?
Linux ou Windows ? Et quelle distribution et version ?

2) la version de votre serveur est mariadb 10.1.37.
La dernière version stable est la 10.3.12.
Pourquoi ne pas envisager de mettre à jour vos serveurs mariadb avec cette dernière version ?

3) à moins de me tromper, je pense que vous ne faites pas assez de maintenance sur vos serveurs.
Avez-vous un traitement quotidien pour optimiser vos bases de données ?
Est-ce lors de cette maintenance que vous avez détecté ce problème ?

4) vous avez identifié ce problème d'intégrité dans la réplication de vos serveurs.
Connaissez-vous la cause de ce problème ?
Un plantage de l'un des serveurs ?
Un plantage d'une applcation ?
Un problème de maintenance sur l'un de vos serveurs ?
Autre chose ?

5) faites-vous aussi un backup quotidien de vos bases de données ?

6) faites-vous tourner quotidiennemt vos fichiers "binary log" ?
Cela se fait automatiquement en redémarrant le serveur. Un redémarrage par jour est suffisant.
Il vous faut identifier le fichier "binary log" à partir duquel vous allez effectuer la restauration.

7) Avez-vous identifié le serveur qui est en cause ?
Vous nous indiquez "S1 mariadb" & "S2 mariadb" avec une différence dans vos identifiants.
Est-ce "S1 mariadb" ou "S2 mariadb" qui est correcte ?

8) combien de tables sont impactées par ce problème ?

9) avez-vous marqué vos lignes avec une date et une heure de modification ?
Cela serait très utile pour identifier le serveur qui est en déséquilibre.
La ligne qui aurait la date et l'heure la plus ancienne serait en cause.

10) Avez-vous le jour et l'heure précis où se problème a été produit ?
Ce n'est pas la même chose que précédemment.
Dans une réplication, quand un serveur plante, on repart des fichiers "binary log".
Mais pour ne pas tout réinstaller, vous devez connaitre le moment précis, à savoir le jour et l'heure du plantage.
Il existe dans les "binary log" des points de reprises pour effectuer une restauration.

11) pour effectuer une restauration dans une base de données à partir d'un point de reprise, il ne doit rien exister au delà du jour et de l'heure du plantage.
Si c'est le cas, c'est comme si vous insérez une nouvelle ligne alors que celle-ci est déjà existante.
Et par voie de conséquence, vous aurez un plantage lors de la restauration.

12) si comme l'indique SQLPRO il y a eu un conflit dans la réplication, je comprends que le rétablissement ne sera pas aussi simple que je le crois.
Dans le cas d'une réplication master/slave, vous avez dans le serveur master des fichiers "binary log" qui contiennent d'une part les points de reprises et d'autre part tout ce qui a été fait en terme de requêtes.
Vous comprenez qu'il suffit de connaitre le point de reprise pour effectuer la replication qui manque dans le serveur slave (ou vice versa).

Dans la replication master/master, je ne sais pas s'il y a un seul fichier "binary log" et où il se trouve, ou s'il en existe deux.

Si comme je le suppose, il en existe un, le problème sera assez simple.
S'il en existe deux, je ne sais pas faire car je ne l'ai jamais fait.

13) comment procéder s'il existe qu'un seul "binary log" ?
Cette solution me semble la plus logique, car il faut centraliser toutes les interventions croisées sur vos deux serveurs.

13-a) si vous avez des sauvegardes quotidiennes, partir la dernière, juste avant le problème.
Cela doit se faire sur vos deux serveurs !

13-b) surtout ne pas toucher aux fichiers "binary log" puisque c'est à partir d'eux que vous allez effectuer votre restauration.

13-c) vous devez connaitre le point de reprise. Dans ce cas, c'est celui correspondant au jour d'après la sauvegarde.
Et si vos fichiers "binary log" tourne chaque jour, c'est le premier point de reprise que vous trouverez.

13-d) il suffit de lancer la restauration et c'est tout.

14) comme je le suppose vous n'avez jamais fait cela ?
Est-ce bien le cas ?

@+

Salut, merci pour votre intervention.

Je veux vous répondre sur quelques questions pertinentes qui ressemble à mon cas:
je suis en train de test un environnement une application web développer en symfony qui suit l’architecture mentionné dans le premier commentaire.
La réplication master-master consiste à mettre en place 2 réplication de type maser-slave dans les deux sens, cela permet de faire une modification sur l'un des serveurs bd et automatiquement sera répliquer sur l'autre serveur bd.

1) le système d’exploitation debian 9 x64 installé sur le serveur

2) J’ai utilisé la version par défaut qui vient avec les packages de debian.

3) Non, je n’ai pas fait aucun traitement pour optimiser la base de données

4) J’ai détecté ce problème à partir des fichiers dump des deux bases de données en comparent les lignes sql ligne par ligne

5) Oui, j’ai programmé un tache cron pour faire le backup chaque jour à minuit.

6) Je ne fais pas un redémarre quotidien sauf si nécessaire après une modification au niveau config de serveur bd

7) En fait les deux serveurs contiennent à 98% des données correctes sauf il y a 50 enregistrements ont des différences au niveau des identifiant sur chaque serveur.

8) Pour le moment 2 tables seulement (on est maintenant en période de test) et peut après aller jusqu’à 10 (en phase production si ce problème va persister après)

9) Oui il y a la table user qui un champ date qui indique la date d'insertion et la date de dernière modification, dans mon cas je les trouvées sont insérées avec les mêmes valeurs

S1 mariadb
INSERT INTO `user` (id, nom, prenom, refernece, naissance, createdAt, updatedAt, active) VALUES 
(7673,NULL,NULL,'7673-2019',NULL,'2019-01-01 22:11:37',NULL,0), 
(7674,NULL,NULL,'7674-2019',NULL,'2019-01-01 22:11:39',NULL,0), 
(7675,NULL,NULL,'7675-2019',NULL,'2019-01-01 22:11:39',NULL,0), 
(7676,NULL,NULL,'7676-2019',NULL,'2019-01-01 22:11:39',NULL,0), 
(7677,NULL,NULL,'7677-2019',NULL,'2019-01-01 22:11:43',NULL,0), 
(7678,NULL,NULL,'7678-2019',NULL,'2019-01-01 22:11:43',NULL,0), 
(7679,NULL,NULL,'7679-2019',NULL,'2019-01-01 22:11:43',NULL,0); S2 mariadb
INSERT INTO `user` (id, nom, prenom, refernece, naissance, createdAt, updatedAt, active) VALUES 
(7673,NULL,NULL,'7673-2019',NULL,'2019-01-01 22:11:37',NULL,0), 
(7674,NULL,NULL,'7674-2019',NULL,'2019-01-01 22:11:39',NULL,0), 
(7675,NULL,NULL,'7675-2019',NULL,'2019-01-01 22:11:39',NULL,0), 
(7676,NULL,NULL,'7676-2019',NULL,'2019-01-01 22:11:39',NULL,0), 
(7677,NULL,NULL,'7677-2019',NULL,'2019-01-01 22:11:43',NULL,0), 
(7678,NULL,NULL,'7678-2019',NULL,'2019-01-01 22:11:43',NULL,0), 
(7679,NULL,NULL,'7679-2019',NULL,'2019-01-01 22:11:43',NULL,0);

10) Avez-vous le jour et l'heure précis où se problème a été produit ?
Ce n'est pas la même chose que précédemment.
==> oui j’ai le jour et l’heure de chaque incohérence produite, mais cette anomalie est reproduite presque chaque jour
Dans une réplication, quand un serveur plante, on repart des fichiers "binary log".
Mais pour ne pas tout réinstaller, vous devez connaitre le moment précis, à savoir le jour et l'heure du plantage.
Il existe dans les "binary log" des points de reprises pour effectuer une restauration.
Je ne sais pas comment faire ça !

11) Ce n’est le cas d’un plantage du serveur, mais j’espère qu’il du d’un accès concurrent entre les deux applications web

12) En fait chaque serveur génère son propre "binary log" et par la suite à chaque nouvelle requête exécuter sur un serveur master, sera réappliquer sur l'autre serveur master

13) Ce n'est pas le cas

13-a) oui j'ai configuré des cron de sauvegardes quotidiennes sur les deux bd et à partir des fichiers dump j'ai détecté l'incohérence des données

13-b) avez-vous une méthode pour faire ça?

13-c) Et si vos fichiers "binary log" tourne chaque jour, c'est le premier point de reprise que vous trouverez.

A bientôt.

S1 mariadb	S2 mariadb
INSERT INTO `contact_user` (id, user_id, numero_telphone, adresse) VALUES (7673,7673,'70775806',NULL), (7674,7674,'83298117',NULL), (7675,7675,'73874812',NULL), (7676,7676,'77636225',NULL), (7677,7677,'93607684',NULL), (7678,7678,'76225441',NULL), (7679,7679,'75385298',NULL);	INSERT INTO `contact_user` (id, user_id, numero_telphone, adresse) VALUES (7673,7673,'70775806',NULL), (7674,7674,'83298117',NULL), (7675,7675,'90635536',NULL), (7676,7676,'90911015',NULL), (7677,7677,'93607684',NULL), (7678,7678,'76225441',NULL), (7679,7679,'75385298',NULL);