Re: [FRsAG] Problème d'import d'un dump MySQL
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 > 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/ > ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Problème d'import d'un dump MySQL
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/
Re: [FRsAG] Problème d'import d'un dump MySQL
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 > > 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/ > ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Problème d'import d'un dump MySQL
> 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/
Re: [FRsAG] Problème d'import d'un dump MySQL
+1 ;-) Benjamin Le 10 décembre 2010 15:36, Mikael Batard 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 > > ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Problème d'import d'un dump MySQL
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 ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Problème d'import d'un dump MySQL
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 ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Problème d'import d'un dump MySQL
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 ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Problème d'import d'un dump MySQL
@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 > > 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 -pX --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/ > ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Problème d'import d'un dump MySQL
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 -pX --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/
Re: [FRsAG] Problème d'import d'un dump MySQL
Voici les infos : bdd2:~# wc -l dump-1012.sql 1972 dump-1012.sql bdd2:~# time cat dump-1012.sql > /dev/null real0m0.013s user0m0.000s sys 0m0.012s bdd2:~# time mysql -u root -p smc_preprod_current < dump-1012.sql Enter password: real0m34.870s user0m1.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_not...@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 > 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/ > ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Problème d'import d'un dump MySQL
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é ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Problème d'import d'un dump MySQL
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/
Re: [FRsAG] Problème d'import d'un dump MySQL
@Greg : Oui il y a : /etc/mysql/conf.d/mysqld_safe_syslog.cnf qui comporte deux lignes avec les infos suivantes : [mysqld_safe] syslog @m...@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 > 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/ > ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Problème d'import d'un dump MySQL
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/
Re: [FRsAG] Problème d'import d'un dump MySQL
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-infoFALSE
database (No default value)
default-character-set latin1
delimiter ;
vertical FALSE
force FALSE
named-commandsFALSE
ignore-spaces FALSE
local-infile FALSE
no-beep FALSE
host (No default value)
html FALSE
xml FALSE
line-numbers TRUE
unbufferedFALSE
column-names TRUE
sigint-ignore FALSE
port 3306
promptmysql>
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-certFALSE
table FALSE
user (No default value)
safe-updates FALSE
i-am-a-dummy FALSE
connect_timeout 0
max_allowed_packet16777216
net_buffer_length 16384
select_limit 1000
max_join_size 100
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 = x
replicate-do-db= x
[mysqldump]
quick
quote-names
max_allowed_packet = 16M
[mysql]
[isamchk]
key_buffer = 16M
!includedir /etc/mysql/conf.d/
2010/12/10 Philippe Bais >
…
>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/
__
Re: [FRsAG] Problème d'import d'un dump MySQL
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 mailto:m...@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/ ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Problème d'import d'un dump MySQL
Oops petit typo. Quand j'importe juste une base, je précise bien le nom de base. Antoine 2010/12/10 > 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/
Re: [FRsAG] Problème d'import d'un dump MySQL
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/
Re: [FRsAG] Problème d'import d'un dump MySQL
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-infoFALSE
database (No default value)
default-character-set latin1
delimiter ;
vertical FALSE
force FALSE
named-commandsFALSE
ignore-spaces FALSE
local-infile FALSE
no-beep FALSE
host (No default value)
html FALSE
xml FALSE
line-numbers TRUE
unbufferedFALSE
column-names TRUE
sigint-ignore FALSE
port 3306
promptmysql>
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-certFALSE
table FALSE
user (No default value)
safe-updates FALSE
i-am-a-dummy FALSE
connect_timeout 0
max_allowed_packet16777216
net_buffer_length 16384
select_limit 1000
max_join_size 100
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 = x
replicate-do-db= x
[mysqldump]
quick
quote-names
max_allowed_packet = 16M
[mysql]
[isamchk]
key_buffer = 16M
!includedir /etc/mysql/conf.d/
2010/12/10 Philippe Bais
> …
>
> >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/
Re: [FRsAG] Problème d'import d'un dump MySQL
... >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/
Re: [FRsAG] Problème d'import d'un dump MySQL
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 ___ Liste de diffusion du FRsAG http://www.frsag.org/
[FRsAG] 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 ___ Liste de diffusion du FRsAG http://www.frsag.org/
