Problème d'import d'un dump MySQL
Bonjour FRsaG, Je suis en train de m'arracher les cheveux depuis plusieurs jours sur un problème de réplication MySQL et je n'arrive pas à m'en sortir. Mon problème de réplication est en réalité un problème d'import de dump MySQL. Je m'explique. Sur mon premier serveur que nous appellerons aujourd'hui serveur1, je fais un dump d'une base de données précise. Lorsque j'importe ce dump sur ce même serveur (dans une autre base), il n'y a aucun soucis, les données sont toutes présentes. Cependant, si je scp ce dump vers mon second serveur que nous appellerons serveur2, et que je l'importe, des données sont manquantes. Le checksum md5 du dump est identique de part et d'autre. Je n'ai aucune erreur mais alors aucune que ce soit stderr, syslog ou log MySQL. Je fais le dump avec la commande suivante : mysqldump -u backup -p -rdump-preprod.sql preprod_current J'ai déjà essayé avec --single-transaction, --extended-insert et --compress sans changement. Mes bases sont de l'innoDB. Ce n'est pas un soucis d'espace disque (trop facile sinon :P). Mes deux serveurs sont du MySQL 5.1 mais j'avais le même soucis quand ils étaient en MySQL 5.0. Niveau hardware c'est du EG SSD (les deux) de chez OVH (donc Octo-core, 12Go RAM et 2xSSD). Est-ce que quelqu'un aurait une idée ? Merci d'avance pour votre aide, Antoine
...
Je fais le dump avec la commande suivante :
mysqldump -u backup -p -rdump-preprod.sql preprod_current
...
Antoine
Bonjour Antoine, bonjour FRSAG Peux-tu nous donner des précisions sur les différents imports que tu as essayés ? Bien que ton serveur 1 importe bien tes datas, cette question est bête, mais vois-tu bien ces données dans le dump ? Se passe t'il la même chose quand tu exécute un échantillon de ton dump ? (INSERT unitaire toussa toussa après avoir créé la structure) Philippe
Merci pour vos réponses ! Je fais l'import avec "mysql -u root -p < dump.sql" Les données sont bien dans le dump car lorsque je l'insert dans le premier serveur, les données apparaissent bien. Voici le mysql --help (la partie variables car je doute que ce qu'il y a avant est pertinent ici) : Variables (--variable-name=value) and boolean options {FALSE|TRUE} Value (after reading options) --------------------------------- ----------------------------- auto-rehash TRUE character-sets-dir (No default value) column-type-info FALSE comments FALSE compress FALSE debug-check FALSE debug-info FALSE database (No default value) default-character-set latin1 delimiter ; vertical FALSE force FALSE named-commands FALSE ignore-spaces FALSE local-infile FALSE no-beep FALSE host (No default value) html FALSE xml FALSE line-numbers TRUE unbuffered FALSE column-names TRUE sigint-ignore FALSE port 3306 prompt mysql> quick FALSE raw FALSE reconnect TRUE socket /var/run/mysqld/mysqld.sock ssl FALSE ssl-ca (No default value) ssl-capath (No default value) ssl-cert (No default value) ssl-cipher (No default value) ssl-key (No default value) ssl-verify-server-cert FALSE table FALSE user (No default value) safe-updates FALSE i-am-a-dummy FALSE connect_timeout 0 max_allowed_packet 16777216 net_buffer_length 16384 select_limit 1000 max_join_size 1000000 secure-auth FALSE show-warnings FALSE Et la conf MySQL : [client] port = 3306 socket = /var/run/mysqld/mysqld.sock [mysqld_safe] socket = /var/run/mysqld/mysqld.sock nice = 0 [mysqld] user = mysql pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port = 3306 basedir = /usr datadir = /data/mysql tmpdir = /tmp language = /usr/share/mysql/english skip-external-locking key_buffer = 384M max_allowed_packet = 1M table_cache = 768 sort_buffer_size = 2M read_buffer_size = 2M read_rnd_buffer_size = 8M myisam_sort_buffer_size = 64M thread_cache_size = 8 query_cache_size = 50M thread_concurrency = 16 tmp_table_size = 64M max_heap_table_size = 64M innodb_buffer_pool_size = 2G tmp_table_size = 256M max_heap_table_size = 256M skip-name-resolve query_cache_limit = 1M log_slow_queries = /var/log/mysql/mysql-slow.log long_query_time = 2 server-id = 2 log_bin = /data/mysql/mysql-bin.log expire_logs_days = 10 max_binlog_size = 1000M master-connect-retry = 10 log_slave_updates = 1 master_host = serveurserveur master_user = useruser master_password = pwdpwd binlog_do_db = xxxxx replicate-do-db = xxxxx [mysqldump] quick quote-names max_allowed_packet = 16M [mysql] [isamchk] key_buffer = 16M !includedir /etc/mysql/conf.d/ 2010/12/10 Philippe Bais <philippe.bais@transatel.com>
…
Je fais le dump avec la commande suivante :
mysqldump -u backup -p -rdump-preprod.sql preprod_current
…
Antoine
Bonjour Antoine, bonjour FRSAG
Peux-tu nous donner des précisions sur les différents imports que tu as essayés ?
Bien que ton serveur 1 importe bien tes datas, cette question est bête, mais vois-tu bien ces données dans le dump ? Se passe t’il la même chose quand tu exécute un échantillon de ton dump ? (INSERT unitaire toussa toussa après avoir créé la structure)
Philippe
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 10/12/2010 14:08, Antoine Benkemoun a écrit :
Merci pour vos réponses !
Je fais l'import avec "mysql -u root -p < dump.sql"
Tu oublierais pas le nom de ta base ?
Les données sont bien dans le dump car lorsque je l'insert dans le premier serveur, les données apparaissent bien.
Oops petit typo. Quand j'importe juste une base, je précise bien le nom de base. Antoine 2010/12/10 <ml@admin-serv.net>
Le 10/12/2010 14:08, Antoine Benkemoun a écrit :
Merci pour vos réponses !
Je fais l'import avec "mysql -u root -p < dump.sql"
Tu oublierais pas le nom de ta base ?
Les données sont bien dans le dump car lorsque je l'insert dans le premier serveur, les données apparaissent bien.
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Est-ce que tu as tenté : mysqldump -h sql1 -u root -ppass ta_base | mysql ta_base ? Ou dans l'autre sens depuis SQL1 vers SQL2 ? Le 10/12/2010 14:11, Antoine Benkemoun a écrit :
Oops petit typo. Quand j'importe juste une base, je précise bien le nom de base.
Antoine
2010/12/10 <ml@admin-serv.net <mailto:ml@admin-serv.net>>
Le 10/12/2010 14:08, Antoine Benkemoun a écrit :
Merci pour vos réponses !
Je fais l'import avec "mysql -u root -p < dump.sql"
Tu oublierais pas le nom de ta base ?
Les données sont bien dans le dump car lorsque je l'insert dans le premier serveur, les données apparaissent bien.
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Tu as des Contraintes sur tes tables ? Après le dump, que donne un show warnings? (tu peux importer ton dump avec mysql> \. dump.sql) Benjamin Le 10/12/2010 21:08, Antoine Benkemoun a écrit :
Merci pour vos réponses !
Je fais l'import avec "mysql -u root -p < dump.sql"
Les données sont bien dans le dump car lorsque je l'insert dans le premier serveur, les données apparaissent bien.
Voici le mysql --help (la partie variables car je doute que ce qu'il y a avant est pertinent ici) :
Variables (--variable-name=value) and boolean options {FALSE|TRUE} Value (after reading options) --------------------------------- ----------------------------- auto-rehash TRUE character-sets-dir (No default value) column-type-info FALSE comments FALSE compress FALSE debug-check FALSE debug-info FALSE database (No default value) default-character-set latin1 delimiter ; vertical FALSE force FALSE named-commands FALSE ignore-spaces FALSE local-infile FALSE no-beep FALSE host (No default value) html FALSE xml FALSE line-numbers TRUE unbuffered FALSE column-names TRUE sigint-ignore FALSE port 3306 prompt mysql> quick FALSE raw FALSE reconnect TRUE socket /var/run/mysqld/mysqld.sock ssl FALSE ssl-ca (No default value) ssl-capath (No default value) ssl-cert (No default value) ssl-cipher (No default value) ssl-key (No default value) ssl-verify-server-cert FALSE table FALSE user (No default value) safe-updates FALSE i-am-a-dummy FALSE connect_timeout 0 max_allowed_packet 16777216 net_buffer_length 16384 select_limit 1000 max_join_size 1000000 secure-auth FALSE show-warnings FALSE
Et la conf MySQL :
[client] port = 3306 socket = /var/run/mysqld/mysqld.sock [mysqld_safe] socket = /var/run/mysqld/mysqld.sock nice = 0 [mysqld] user = mysql pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port = 3306 basedir = /usr datadir = /data/mysql tmpdir = /tmp language = /usr/share/mysql/english skip-external-locking key_buffer = 384M max_allowed_packet = 1M table_cache = 768 sort_buffer_size = 2M read_buffer_size = 2M read_rnd_buffer_size = 8M myisam_sort_buffer_size = 64M thread_cache_size = 8 query_cache_size = 50M thread_concurrency = 16 tmp_table_size = 64M max_heap_table_size = 64M innodb_buffer_pool_size = 2G tmp_table_size = 256M max_heap_table_size = 256M skip-name-resolve query_cache_limit = 1M log_slow_queries = /var/log/mysql/mysql-slow.log long_query_time = 2 server-id = 2 log_bin = /data/mysql/mysql-bin.log expire_logs_days = 10 max_binlog_size = 1000M master-connect-retry = 10 log_slave_updates = 1 master_host = serveurserveur master_user = useruser master_password = pwdpwd binlog_do_db = xxxxx replicate-do-db = xxxxx [mysqldump] quick quote-names max_allowed_packet = 16M [mysql] [isamchk] key_buffer = 16M !includedir /etc/mysql/conf.d/
2010/12/10 Philippe Bais <philippe.bais@transatel.com <mailto:philippe.bais@transatel.com>>
…
>Je fais le dump avec la commande suivante :
>mysqldump -u backup -p -rdump-preprod.sql preprod_current
…
>Antoine
Bonjour Antoine, bonjour FRSAG
Peux-tu nous donner des précisions sur les différents imports que tu as essayés ?
Bien que ton serveur 1 importe bien tes datas, cette question est bête, mais vois-tu bien ces données dans le dump ? Se passe t’il la même chose quand tu exécute un échantillon de ton dump ? (INSERT unitaire toussa toussa après avoir créé la structure)
Philippe
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
@Greg : Oui il y a : /etc/mysql/conf.d/mysqld_safe_syslog.cnf qui comporte deux lignes avec les infos suivantes : [mysqld_safe] syslog @ml@admin-serv.net : Merci pour l'astuce je n'y avais pas pensé ! Ca ne change rien cependant. @Benjamin : Merci pour le show-warnings ! Je ne connaissais pas du tout. Quand j'importe la base, ca ne me donne aucun warning... 2010/12/10 Greg <greg-frsag@duchatelet.net>
Le 10/12/2010 14:08, Antoine Benkemoun a écrit :
!includedir /etc/mysql/conf.d/
et dans ce dossier, il y a des fichiers ?
-- Greg
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 10/12/2010 14:08, Antoine Benkemoun a écrit :
Merci pour vos réponses !
Je fais l'import avec "mysql -u root -p < dump.sql"
Peux tu SVP nous donner les infos suivantes : wc -l dump.sql time cat dump.sql >/dev/null time mysql -u root -p < dump.sql mysql -u root -p -vvv < dump.sql | tail -- Greg
Voici les infos : bdd2:~# wc -l dump-1012.sql 1972 dump-1012.sql bdd2:~# time cat dump-1012.sql > /dev/null real 0m0.013s user 0m0.000s sys 0m0.012s bdd2:~# time mysql -u root -p smc_preprod_current < dump-1012.sql Enter password: real 0m34.870s user 0m1.308s sys 0m0.052s bdd2:~# mysql -u root -p -vvv smc_preprod_current < dump-1012.sql | tail Enter password: Query OK, 0 rows affected (0.00 sec) -------------- /*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */ -------------- Query OK, 0 rows affected (0.00 sec) @Aurélien, mysqlhotcopy c'est pour les tables MyISAM seulement hors j'ai de l'innoDB. Pour voir les données manquantes je fais un "SELECT id from SALES;" et je vois que les derniers id ne sont pas les mêmes. Pour l'encodage, comment est-ce que je peux le vérifier/forcer ? Ces deux serveurs sont pratiquement identiques. 2010/12/10 Greg <greg-frsag@duchatelet.net>
Le 10/12/2010 14:08, Antoine Benkemoun a écrit :
Merci pour vos réponses !
Je fais l'import avec "mysql -u root -p < dump.sql"
Peux tu SVP nous donner les infos suivantes : wc -l dump.sql time cat dump.sql >/dev/null time mysql -u root -p < dump.sql mysql -u root -p -vvv < dump.sql | tail
-- Greg
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le Ven 10 décembre 2010 14:49, Antoine Benkemoun a écrit :
l'innoDB. Pour voir les données manquantes je fais un "SELECT id from SALES;" et je vois que les derniers id ne sont pas les mêmes. Pour
Tu es sûr que ton SELECT est ordonné de la même façon des deux côtés ? Si tu fais un : "SELECT id FROM sales ORDER BY id;" sur tes deux serveurs, tu obtiens toujours une différence sur le dernier id ? -- Mikael Batard
+1 ;-) Benjamin Le 10 décembre 2010 15:36, Mikael Batard <giraya@giraya.net> a écrit :
Tu es sûr que ton SELECT est ordonné de la même façon des deux côtés ?
Si tu fais un : "SELECT id FROM sales ORDER BY id;" sur tes deux serveurs, tu obtiens toujours une différence sur le dernier id ?
-- Mikael Batard
Le 10/12/2010 13:24, Antoine Benkemoun a écrit :
Bonjour FRsaG,
Je suis en train de m'arracher les cheveux depuis plusieurs jours sur un problème de réplication MySQL et je n'arrive pas à m'en sortir.
Mon problème de réplication est en réalité un problème d'import de dump MySQL. Je m'explique. Sur mon premier serveur que nous appellerons aujourd'hui serveur1, je fais un dump d'une base de données précise. Lorsque j'importe ce dump sur ce même serveur (dans une autre base), il n'y a aucun soucis, les données sont toutes présentes.
Cependant, si je scp ce dump vers mon second serveur que nous appellerons serveur2, et que je l'importe, des données sont manquantes. Le checksum md5 du dump est identique de part et d'autre.
Je n'ai aucune erreur mais alors aucune que ce soit stderr, syslog ou log MySQL.
Bonjour, il peut y avoir des tas de raisons (moteur blackhole, triggers, pebkac, ...), il nous faut plus de précisions. Quel commande utilisez vous pour faire l'import ? L'option --show-warnings peut être utile. "select @@hostname" aussi, pour être sûr de ne pas importer sur le serveur source... Ce serait bien aussi d'avoir la config, ainsi que la sortie complète d'un "mysql --help" du serveur destination. Greg -- Greg
Hello, Le Friday 10 December 2010 à 13:24, Antoine Benkemoun écrivait:
Cependant, si je scp ce dump vers mon second serveur que nous appellerons serveur2, et que je l'importe, des données sont manquantes. Le checksum md5 du dump est identique de part et d'autre.
Et t'es pas capable de savoir quelles données sont manquantes en faisant ne serait-ce qu'un COUNT(*) sur chacune des tables ? Bref... http://www.maatkit.org/doc/maatkit.html et plus précisément http://www.maatkit.org/doc/mk-table-checksum.html Si tu lis bien, l'outil peut même te sortir un diff avec les requetes SQL à réinjecter. PS: Mon sentiment premier sur ton histoire est un soucis d'encodage qui pourri de ton dump (genre UTF8 d'un côté mais pas de l'autre). Le mieux pour sync 2 serveurs MySQL, ça reste quand même mysqlhotcopy... -- Auré
Et t'es pas capable de savoir quelles données sont manquantes en faisant ne serait-ce qu'un COUNT(*) sur chacune des tables ?
Bref... http://www.maatkit.org/doc/maatkit.html et plus précisément http://www.maatkit.org/doc/mk-table-checksum.html
Si tu lis bien, l'outil peut même te sortir un diff avec les requetes SQL à réinjecter.
PS: Mon sentiment premier sur ton histoire est un soucis d'encodage qui pourri de ton dump (genre UTF8 d'un côté mais pas de l'autre). Le mieux pour sync 2 serveurs MySQL, ça reste quand même mysqlhotcopy...
Il y a plein de raison qui peuvent foirer un reimport d'un dump. Au hasard les foreign keys, les triggers/prod stock, etc... Une parmi d'autre est le 'max_allowed_packet' de ton mysqldump. Effectivement le meilleur moyen de synchroniser une base est mysqlhotcopy ou mieux son remplacant du coté de chez perconna : innobackupex et xtrabkup. Sinon une commande relativement safe pour un dump : mysqldump -u root -pXXXXX --add-drop-database --add-drop-table --all-databases --create-options --routines --disable-keys --lock-all-tables ou : --single-transactions (mais j'ai eu des cas bizarres). -- Raphael
@Raphael : les max_allowed_packet pourrait créer des problèmes si il est trop petit ou si il est trop gros (ou les deux ?). Que recommanderais-tu ? Je vais jeter un coup d'oeil aux produits Percona que je ne connais pas du tout. J'ai essayé de faire un dump avec le mysqldump que tu m'as indiqué et ca n'a rien changé mais je comprends bien l'idée de la chose. 2010/12/10 Raphael Mazelier <raph@futomaki.net>
Et t'es pas capable de savoir quelles données sont manquantes en faisant
ne serait-ce qu'un COUNT(*) sur chacune des tables ?
Bref... http://www.maatkit.org/doc/maatkit.html et plus précisément http://www.maatkit.org/doc/mk-table-checksum.html
Si tu lis bien, l'outil peut même te sortir un diff avec les requetes SQL à réinjecter.
PS: Mon sentiment premier sur ton histoire est un soucis d'encodage qui pourri de ton dump (genre UTF8 d'un côté mais pas de l'autre). Le mieux pour sync 2 serveurs MySQL, ça reste quand même mysqlhotcopy...
Il y a plein de raison qui peuvent foirer un reimport d'un dump. Au hasard les foreign keys, les triggers/prod stock, etc... Une parmi d'autre est le 'max_allowed_packet' de ton mysqldump.
Effectivement le meilleur moyen de synchroniser une base est mysqlhotcopy ou mieux son remplacant du coté de chez perconna : innobackupex et xtrabkup. Sinon une commande relativement safe pour un dump : mysqldump -u root -pXXXXX --add-drop-database --add-drop-table --all-databases --create-options --routines --disable-keys --lock-all-tables
ou : --single-transactions (mais j'ai eu des cas bizarres).
-- Raphael
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 10/12/2010 15:09, Antoine Benkemoun a écrit :
@Raphael : les max_allowed_packet pourrait créer des problèmes si il est trop petit ou si il est trop gros (ou les deux ?). Que recommanderais-tu ?
16Meg ou 32Meg, s'il est trop petit le reimport peut foirer sur des gros inserts.
Je vais jeter un coup d'oeil aux produits Percona que je ne connais pas du tout. Vi je te les conseille vivement :p
J'ai essayé de faire un dump avec le mysqldump que tu m'as indiqué et ca n'a rien changé mais je comprends bien l'idée de la chose.
Un autre truc, il est parfois meilleur de faire un load file depuis mysql, qu'une redirection depuis le shell. -- raphael
Le 10/12/2010 14:57, Raphael Mazelier a écrit :
Il y a plein de raison qui peuvent foirer un reimport d'un dump. Au hasard les foreign keys, les triggers/prod stock, etc... Une parmi d'autre est le 'max_allowed_packet' de ton mysqldump.
Sauf que dans ce cas il aurait un message d'erreur (pas même un warning caché comme MySQL sait bien les faire...)
Effectivement le meilleur moyen de synchroniser une base est mysqlhotcopy ou mieux son remplacant du coté de chez perconna : innobackupex et xtrabkup.
Pas sûr que ça fonctionne bien entre 2 versions différentes de MySQL. -- Greg
Je suis en train de m'arracher les cheveux depuis plusieurs jours sur un problème de réplication MySQL et je n'arrive pas à m'en sortir.
dans le doute verifier la configuration des differents charsets de mysql ? charset des tables, du serveur, de la connection utilisee pour le dump . . .
Mon problème de réplication est en réalité un problème d'import de dump MySQL. Je m'explique. Sur mon premier serveur que nous appellerons aujourd'hui serveur1, je fais un dump d'une base de données précise. Lorsque j'importe ce dump sur ce même serveur (dans une autre base), il n'y a aucun soucis, les données sont toutes présentes. Cependant, si je scp ce dump vers mon second serveur que nous appellerons serveur2, et que je l'importe, des données sont manquantes. Le checksum md5 du dump est identique de part et d'autre. Je n'ai aucune erreur mais alors aucune que ce soit stderr, syslog ou log MySQL. Je fais le dump avec la commande suivante : mysqldump -u backup -p -rdump-preprod.sql preprod_current J'ai déjà essayé avec --single-transaction, --extended-insert et --compress sans changement. Mes bases sont de l'innoDB. Ce n'est pas un soucis d'espace disque (trop facile sinon :P). Mes deux serveurs sont du MySQL 5.1 mais j'avais le même soucis quand ils étaient en MySQL 5.0. Niveau hardware c'est du EG SSD (les deux) de chez OVH (donc Octo-core, 12Go RAM et 2xSSD). Est-ce que quelqu'un aurait une idée ? Merci d'avance pour votre aide, Antoine _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonsoir FRsaG, Ne trouvant pas de solution, j'ai choisi la solution de facilité qui a été de recommencer de zéro la configuration de mes deux serveurs. Je sais que c'est pas bien car je n'ai pas réussi à trouver la solution à ce problème qui se représentera peut être mais bon c'est la prod :-) Du coup, ca fonctionne sans soucis maintenant et je n'ai toujours pas d'idée précise sur la cause de ce problème. Merci beaucoup à tous pour votre aide car j'ai appris pleins de choses ! Bonne soirée, Antoine 2010/12/11 neo futur <frsag@ww7.be>
Je suis en train de m'arracher les cheveux depuis plusieurs jours sur un problème de réplication MySQL et je n'arrive pas à m'en sortir.
dans le doute verifier la configuration des differents charsets de mysql ? charset des tables, du serveur, de la connection utilisee pour le dump . . .
Mon problème de réplication est en réalité un problème d'import de dump MySQL. Je m'explique. Sur mon premier serveur que nous appellerons aujourd'hui serveur1, je fais un dump d'une base de données précise. Lorsque j'importe ce dump sur ce même serveur (dans une autre base), il n'y a aucun soucis, les données sont toutes présentes. Cependant, si je scp ce dump vers mon second serveur que nous appellerons serveur2, et que je l'importe, des données sont manquantes. Le checksum md5 du dump est identique de part et d'autre. Je n'ai aucune erreur mais alors aucune que ce soit stderr, syslog ou log MySQL. Je fais le dump avec la commande suivante : mysqldump -u backup -p -rdump-preprod.sql preprod_current J'ai déjà essayé avec --single-transaction, --extended-insert et --compress sans changement. Mes bases sont de l'innoDB. Ce n'est pas un soucis d'espace disque (trop facile sinon :P). Mes deux serveurs sont du MySQL 5.1 mais j'avais le même soucis quand ils étaient en MySQL 5.0. Niveau hardware c'est du EG SSD (les deux) de chez OVH (donc Octo-core, 12Go RAM et 2xSSD). Est-ce que quelqu'un aurait une idée ? Merci d'avance pour votre aide, Antoine _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Ce qui n'est pas bien c'est de ne pas avoir la même conf pour les deux serveurs (et de ne pas lire les warnings) ! En as-tu profité pour passer en XtraDB ? Le 12/12/2010 03:03, Antoine Benkemoun a écrit :
Bonsoir FRsaG,
Ne trouvant pas de solution, j'ai choisi la solution de facilité qui a été de recommencer de zéro la configuration de mes deux serveurs. Je sais que c'est pas bien car je n'ai pas réussi à trouver la solution à ce problème qui se représentera peut être mais bon c'est la prod :-)
Du coup, ca fonctionne sans soucis maintenant et je n'ai toujours pas d'idée précise sur la cause de ce problème.
Merci beaucoup à tous pour votre aide car j'ai appris pleins de choses !
Bonne soirée,
Antoine
Hello, Bien que ca ait l'air intéressant ce n'est pas envisageable. En fait mon second serveur MySQL réplique sur ~80 boxs qui sont des Soekris. Du coup si je passe sous XtraDB mes serveurs, il faut que j'y passe 80 boxs et vu les délais dans lesquels je me retrouve actuellement ce n'est pas tellement envisageable. Mes serveurs ont la même conf, justement je viens de les refaire à neuf :-) 2010/12/12 Benjamin Billon <bbillon-ml@splio.fr>
Ce qui n'est pas bien c'est de ne pas avoir la même conf pour les deux serveurs (et de ne pas lire les warnings) ! En as-tu profité pour passer en XtraDB ?
Le 12/12/2010 03:03, Antoine Benkemoun a écrit :
Bonsoir FRsaG,
Ne trouvant pas de solution, j'ai choisi la solution de facilité qui a été de recommencer de zéro la configuration de mes deux serveurs. Je sais que c'est pas bien car je n'ai pas réussi à trouver la solution à ce problème qui se représentera peut être mais bon c'est la prod :-)
Du coup, ca fonctionne sans soucis maintenant et je n'ai toujours pas d'idée précise sur la cause de ce problème.
Merci beaucoup à tous pour votre aide car j'ai appris pleins de choses !
Bonne soirée,
Antoine
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
participants (10)
-
Antoine Benkemoun -
Aurélien Beaujean -
Benjamin Billon -
Benjamin MALYNOVYTCH -
Greg -
Mikael Batard -
ml＠admin-serv.net -
neo futur -
Philippe Bais -
Raphael Mazelier