Re: [FRsAG] Reverse DNS

[Raphael Mazelier]

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 d'autres serveurs le font
tres bien aussi, meme des serveurs FTP.

Ca permet par exemple de dire qu'une certaine page est accessible a tous
les IP faisant parti eu domaine example.org, mais inaccessible a tous les
IP faisant partie de frsag.org.

Pour savoir le domaine pose sur une IP, apache va faire des 'reserve DNS
requests'.

En esperant que j'ai pu eclaircir cette partie.

Cdlt,
Karel.

Sans oublier mysql qui fait exactement la même chose quand on fait des 
grant u...@ma.machine.com (une mauvaise idée soit dit en passant).


Tiens personne n'a de script qui génère automatiquement les ptrs 
automatiquement pour bind (j'en avais trouvé mais j'ai oublié) ? ah que 
je regrette mon djbdns.


--
raph
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Reverse DNS

[Clément]

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 tente de me
loguer à une machine en ssh.

D'ailleurs quelqu'un ne serait pas au courant d'un fichier sous les
linux pour changer le timeout de la résolution DNS inverse ? Toutes
mes recherches sont restées vaines.

--
Clément Léger

2010/12/11 Karel MALBROUKOU 
>
> 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 des serveurs FTP.
>
> Ca permet par exemple de dire qu'une certaine page est accessible a tous
> les IP faisant parti eu domaine example.org, mais inaccessible a tous les
> IP faisant partie de frsag.org.
>
> Pour savoir le domaine pose sur une IP, apache va faire des 'reserve DNS
> requests'.
>
> En esperant que j'ai pu eclaircir cette partie.
>
> Cdlt,
> Karel.
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Reverse DNS

[Karel MALBROUKOU]

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 des serveurs FTP.

Ca permet par exemple de dire qu'une certaine page est accessible a tous
les IP faisant parti eu domaine example.org, mais inaccessible a tous les
IP faisant partie de frsag.org.

Pour savoir le domaine pose sur une IP, apache va faire des 'reserve DNS
requests'.

En esperant que j'ai pu eclaircir cette partie.

Cdlt,
Karel.

On Sat, 11 Dec 2010 01:14:57 +0100, Sylvain Rochet 
wrote:
> 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 plus lisible.
> 
> 
>> J'aperçois déjà les connaisseurs hurler "bah pour le SMTP !" oui
>> d'accord.
>> Et c'est tout ?
> 
> Même pour SMTP cela ne sert techniquement à rien. C'est une vérification

> courante mais elle n'est nullement justifiée.
> 
> Quelques sources bien écrites:
>  -
> 
http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/dns-avoid-double-reverse.html
>  -
> 
http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/smtp-avoid-helo.html
> 
> 
>> J'ai cru comprendre que le l'hébergement web et le FTP cela
>> pouvait être utile (certain mécanisme de contrôle peut-être)...
> 
> Aucunement.
> 
> 
>> Pour un serveur/service ok mais pour un équipement réseau ? (aide pour
>> le
>> "traceroute" ?)
> 
> 'xactement.
> 
> 
> Faut voir le PTR comme une chaîne simple de charactères permettant de 
> poser une description sur une IP, c'est tout. Ici on l'utilise et on 
> doit pas être les seuls pour savoir si une IP est attribuée ou 
> disponible.
> 
> De même rien n'impose qu'un PTR ait un A qui lui corresponde et il peut 
> y avoir plusieurs PTR par record.
> 
> 
> Sylvain

-- 
Karel Malbroukou
MSN:   karel.malbrou...@gmail.com
Skype: kenryu974
Home Phone:06 16 40 50 23
LinkedIn: 
http://www.linkedin.com/pub/karel-malbroukou/13/825/7a8
Wordpress: http://blog.open-tribute.org/

Linux / FreeBSD Specialist
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Problème d'import d'un dump MySQL

[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/

Re: [FRsAG] Reverse DNS

[Sylvain Rochet]

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 plus lisible.


> J'aperçois déjà les connaisseurs hurler "bah pour le SMTP !" oui d'accord.
> Et c'est tout ?

Même pour SMTP cela ne sert techniquement à rien. C'est une vérification 
courante mais elle n'est nullement justifiée.

Quelques sources bien écrites:
 - 
http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/dns-avoid-double-reverse.html
 - http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/smtp-avoid-helo.html


> J'ai cru comprendre que le l'hébergement web et le FTP cela
> pouvait être utile (certain mécanisme de contrôle peut-être)...

Aucunement.


> Pour un serveur/service ok mais pour un équipement réseau ? (aide pour le
> "traceroute" ?)

'xactement.


Faut voir le PTR comme une chaîne simple de charactères permettant de 
poser une description sur une IP, c'est tout. Ici on l'utilise et on 
doit pas être les seuls pour savoir si une IP est attribuée ou 
disponible.

De même rien n'impose qu'un PTR ait un A qui lui corresponde et il peut 
y avoir plusieurs PTR par record.


Sylvain


signature.asc
Description: Digital signature
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Reverse DNS

[Yannick Palanque]

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/

[FRsAG] Reverse DNS

[Manuel OZAN]

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 utile (certain mécanisme de contrôle peut-être)...
Pour un serveur/service ok mais pour un équipement réseau ? (aide pour le
"traceroute" ?)

-- 
Cordialement.

Manuel
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] Problème d'import d'un dump MySQL

[Benjamin MALYNOVYTCH]

+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

[Greg]

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

[Mikael Batard]

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

[Raphael Mazelier]

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

[Antoine Benkemoun]

@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

[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/

Re: [FRsAG] Problème d'import d'un dump MySQL

[Antoine Benkemoun]

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

[Aurélien Beaujean]

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

[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/

Re: [FRsAG] Problème d'import d'un dump MySQL

[Antoine Benkemoun]

@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

[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/

Re: [FRsAG] Problème d'import d'un dump MySQL

[Benjamin Billon]

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

[ml]

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

[Antoine Benkemoun]

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

[ml]

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

[Antoine Benkemoun]

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

[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/

Re: [FRsAG] Problème d'import d'un dump MySQL

[Greg]

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

[Antoine Benkemoun]

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/

Re: [FRsAG] Partage de sessions cluster Apache/PHP (Sharedance?)

[[WHD-RS] Benjamin SCHILZ]

> 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 du FRsAG
http://www.frsag.org/

Re: [FRsAG] Partage de sessions cluster Apache/PHP (Sharedance?)

[Lilian RIGARD - Devclic]

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. 2010 à 07:54, Guillaume Plessis a écrit :

Le 10 décembre 2010 04:20, eldre8 > a écrit :


mais c'est deja une surcouche!:p Tu devrais aussi tester Redis
qui inclut du
master/slaves.


Bonjour,

D'autant plus que l'extension phpredis 
(https://github.com/owlient/phpredis) possède dorénavant un 
session_handler transparent, "à la memcache".


Bonne journée.

--
Guillaume Plessis
___
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/