Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Membre à l'essai
    Inscrit en
    décembre 2008
    Messages
    13
    Détails du profil
    Informations forums :
    Inscription : décembre 2008
    Messages : 13
    Points : 10
    Points
    10

    Par défaut Réplication : Incohérence des données insérées

    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.

    Nom : m-m.png
Affichages : 31
Taille : 16,5 Ko

    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.
    Images attachées Images attachées  

  2. #2
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    18 395
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 18 395
    Points : 43 001
    Points
    43 001

    Par défaut

    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  3. #3
    Expert éminent sénior Avatar de Artemus24
    Homme Profil pro
    Agent secret au service du président Ulysses S. Grant !
    Inscrit en
    février 2011
    Messages
    3 731
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 79
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Agent secret au service du président Ulysses S. Grant !
    Secteur : Finance

    Informations forums :
    Inscription : février 2011
    Messages : 3 731
    Points : 11 404
    Points
    11 404

    Par défaut

    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 ?

    @+
    Si vous êtes de mon aide, vous pouvez cliquer sur .
    Mon site : http://www.jcz.fr

  4. #4
    Membre à l'essai
    Inscrit en
    décembre 2008
    Messages
    13
    Détails du profil
    Informations forums :
    Inscription : décembre 2008
    Messages : 13
    Points : 10
    Points
    10

    Par défaut

    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<br/>
    (7673,NULL,NULL,'7673-2019',NULL,'2019-01-01 22:11:37',NULL,0),<br/>
    (7674,NULL,NULL,'7674-2019',NULL,'2019-01-01 22:11:39',NULL,0),<br/>
    (7675,NULL,NULL,'7675-2019',NULL,'2019-01-01 22:11:39',NULL,0),<br/>
    (7676,NULL,NULL,'7676-2019',NULL,'2019-01-01 22:11:39',NULL,0),<br/>
    (7677,NULL,NULL,'7677-2019',NULL,'2019-01-01 22:11:43',NULL,0),<br/>
    (7678,NULL,NULL,'7678-2019',NULL,'2019-01-01 22:11:43',NULL,0),<br/>
    (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<br/>
    (7673,NULL,NULL,'7673-2019',NULL,'2019-01-01 22:11:37',NULL,0),<br/>
    (7674,NULL,NULL,'7674-2019',NULL,'2019-01-01 22:11:39',NULL,0),<br/>
    (7675,NULL,NULL,'7675-2019',NULL,'2019-01-01 22:11:39',NULL,0),<br/>
    (7676,NULL,NULL,'7676-2019',NULL,'2019-01-01 22:11:39',NULL,0),<br/>
    (7677,NULL,NULL,'7677-2019',NULL,'2019-01-01 22:11:43',NULL,0),<br/>
    (7678,NULL,NULL,'7678-2019',NULL,'2019-01-01 22:11:43',NULL,0),<br/>
    (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.

Discussions similaires

  1. [2005] Replication des données insérées/modifiées
    Par exile69 dans le forum Réplications
    Réponses: 2
    Dernier message: 09/06/2013, 19h51
  2. Réponses: 0
    Dernier message: 02/10/2010, 12h14
  3. Visualisation des données insérées depuis l'interface
    Par zdig10 dans le forum Administration
    Réponses: 4
    Dernier message: 05/03/2010, 11h21
  4. [SQL] Index des données insérées
    Par alband85 dans le forum Bibliothèques tierces
    Réponses: 7
    Dernier message: 22/04/2008, 15h01
  5. Réponses: 1
    Dernier message: 21/09/2007, 01h28

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo