Le 11/12/2010 03:12, Karel MALBROUKOU a écrit :
Pas tout a fait d'accord avec Sylvain, sans vouloir lancer un Troll.
Le PTR est super intelligent par exemple dans Apache pour pouvoir faire
des restrictions au niveau domaine plutot qu'au niveau IP.
En fait, je prends ici l'exemple d'Apache, mais
Mais ce n'est pas un peu lent de faire un reverse DNS avant
d'autoriser l'accès ?
En particulier lorsqu'il n'y a pas de nom de domaine correspondant ça
prend des lustres.
Mention à mon école qui nous fournit une IP publique par machine, mais
pas de nom ce qui me fait rager à chaque fois que je tent
Pas tout a fait d'accord avec Sylvain, sans vouloir lancer un Troll.
Le PTR est super intelligent par exemple dans Apache pour pouvoir faire
des restrictions au niveau domaine plutot qu'au niveau IP.
En fait, je prends ici l'exemple d'Apache, mais d'autres serveurs le font
tres bien aussi, meme d
> 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 . . .
>
Bonsoir,
On Fri, Dec 10, 2010 at 11:57:24PM +0100, Manuel OZAN wrote:
> Bonsoir FRsAG,
> Une question me taraude...
>
> Quel est l'intérêt du reverse DNS ?
> J'entend par la les enregistrements PTR dans le NS.
Aucun intérêt hormis avoir un beau reverse sur l'IRC et avoir des
traceroutes un peu
Bonjour,
À 2010-12-10T23:57:24+0100,
Manuel OZAN écrivit :
> Quel est l’intérêt du reverse DNS ?
Faire le kakoo sur IRC !
--
Yannick Palanque
___
Liste de diffusion du FRsAG
http://www.frsag.org/
Bonsoir FRsAG,
Une question me taraude...
Quel est l’intérêt du reverse DNS ?
J'entend par la les enregistrements PTR dans le NS.
J'aperçois déjà les connaisseurs hurler "bah pour le SMTP !" oui d'accord.
Et c'est tout ?
J'ai cru comprendre que le l'hébergement web et le FTP cela
pouvait être uti
+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
> mais c'est deja une surcouche!:p
C'est pas faux ;)
> Tu devrais aussi tester Redis qui inclut du master/slaves.
Effectivement ça semble pas mal du tout, d'autant plus que c'est un projet
plutôt actif.
Je vais tester également.
___
Liste de diffusion
Je préconise cette solution :) mais comme on partait sur du Memcached ;)
Je vais, je pense, sou peu tester le client redis, on va voir ce que ça
donne :)
Le 10/12/10 08:43, JF Bustarret a écrit :
Très bon produit Redis : rapide + les données sont persistantes.
+1 pour la solution.
Le 10 déc
28 matches
Mail list logo
