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 telle
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
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
> 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 . . .
>
+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
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
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 i
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 jete
@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é e
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 dif
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:
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 savoi
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 : 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
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/
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 bie
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...
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 ?
>
>
>
>> L
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.
_
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) :
Va
...
>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 q
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'expliqu
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
aujour
23 matches
Mail list logo
