Probleme de synchronisation de BDD MySQL

Support Debian
#1

Bonjour,

J’ai deux serveurs Debian 6 qui sont configurés pour se synchroniser (architecture maitre/maitre). Des serveurs qui sont en production donc je dois faire attention aux bases.

Bien entendu j’ai réaliser auparavant une maquette sur des VM pour utiliser et tester cette synchronisation avec MySQL et tout fonctionnait.

Bien sur en production rien ne fonctionne c’est toujours comme ça …

Voilà mon soucis :
Après avoir configuré mes deux fichiers /etc/mysql/my.cnf sur chaque serveur je démarre la synchronisation (start slave) et donc je met à jour les données du serveur dit “secondaire” qui pointe sur les données du primaire avec un “load data from master;”.
Hélas j’ai cette erreur :
ERROR 1217 (23000): Cannot delete or update a parent row: a foreign key constraint fails

Et bien entendu je n’ai aucun log nulle part :confused:

Donc déjà j’aimerais activer les logs de MySQL, de plus j’aimerais résoudre ce soucis de clé étrangère :confused:

Une idée ?

Merci

#2

Je viens de me rendre compte que la synchronisation fonctionne parfaitement bien en fait ^^’ . C’est dès lors que je fait cette commande que cela met en arrêt la synchronisation.

Cette commande bloque :confused:

Si je ne la fait pas c’est bon.

#3

Salut,

[quote=“flyght”]Après avoir configuré mes deux fichiers /etc/mysql/my.cnf sur chaque serveur

…

Et bien entendu je n’ai aucun log nulle part [/quote]

Tu es passé à côté. :wink:

[code]$ cat /etc/mysql/my.cnf

…

Both location gets rotated by the cronjob.

Be aware that this log type is a performance killer.

As of 5.1 you can enable the log at runtime!

general_log_file = /var/log/mysql/mysql.log
general_log = 1

Error logging goes to syslog due to /etc/mysql/conf.d/mysqld_safe_syslog.cnf.

Here you can see queries with especially long duration

#log_slow_queries = /var/log/mysql/mysql-slow.log
#long_query_time = 2
#log-queries-not-using-indexes

The following can be used as easy to replay backup logs or for replication.

note: if you are setting up a replication slave, see README.Debian about

other settings you may need to change.

#server-id = 1
#log_bin = /var/log/mysql/mysql-bin.log
expire_logs_days = 10
max_binlog_size = 100M
#binlog_do_db = include_database_name
#binlog_ignore_db = include_database_name

…
[/code]

Les pistes à exploitées.

1.5.5.5. Les clés étrangères

15.7.4. Contraintes de clés étrangères FOREIGN KEY

Extrait.

[quote] Lors des vérifications des contraintes, InnoDB pose des verrous de lignes sur les lignes parents ou enfants qu’il utilise. InnoDB vérifie immédiatement les contraintes de clés : la vérification n’est pas reportée jusqu’à la validation de la transaction.

Pour simplifier l’importation de données dans des tables qui ont des contraintes, mysqldump ajoute automatiquement la commande qui met la variable FOREIGN_KEY_CHECKS à 0, depuis MySQL version 4.1.1. Cela évite des problèmes spécifiques avec les tables qui doivent être chargées dans un ordre particulier. Pour les versions antérieures, vous pouvez désactiver manuellement la variable depuis mysql lors du chargement du fichier comme ceci :

mysql> SET FOREIGN_KEY_CHECKS = 0; mysql> SOURCE dump_file_name; mysql> SET FOREIGN_KEY_CHECKS = 1;

Cela vous permet de faire l’importation des données des tables dans n’importe quel ordre. Cela accélère aussi l’opération d’importation. FOREIGN_KEY_CHECKS est disponible depuis MySQL 3.23.52 et 4.0.3.

Mettre FOREIGN_KEY_CHECKS à 0 peut aussi être utile pour les opérations de LOAD DATA.

InnoDB permet l’effacement de n’importe quelle table, même si cela casse les contraintes de clés étrangères. Lorsque vous effacez une table, les contraintes définies sur cette table sont aussi effacées. [/quote]

Création et manipulation des schémas : CREATE, ALTER, DROP

#4

Merci beaucoup pour ta réponse.

En effet je suis passé totalement à coté des logs, je n’arrête pas de travailler sur ce fichier et je ne l’ai même pas vu …

Donc parfait pour les logs.
En revanche lorsque je fait un “load data from master;” cela n’écrit pas dans les logs l’erreur :confused: , tout le reste oui ^^

Je vais essayer ta solution :

mysql> SET FOREIGN_KEY_CHECKS = 0; mysql> SOURCE dump_file_name; mysql> SET FOREIGN_KEY_CHECKS = 1;
Qui a l’air très adaptée pour moi.
En revanche il est bien dit que cela va permettre de faire l’importation des données dans n’importe quel ordre. Cela ne risque rien pour le bon fonctionnement des BDD ??
Car même cette phrase fait peur lol :

Par contre dans mon cas j’importe mon dump avec PhpMyAdmin, je lance ensuite cette commande c’est bien ça ou je la lance avant ? Avec mon nom de fichier dump après SOURCE ?
Ou alors faut il que je stocke le fichier dump quelques part ? je ne vois pas trop :confused: . Car je l’ai en local sur mon PC ce fichier pas sur le serveur.

Car moi il me faut juste à 0 et non pas à 1

Merci

#5

J’ai essayé sur un serveur de test la commande directe :
mysql > SET FOREIGN_KEY_CHECKS=0;

Maintenant lorsque je fait un load data from master;

Cela me met :
ERROR 1189 (08S01): Net error reading from master