pb de recopie d'une base de données
Le
Cyrille Lefevre
Bonjour,
j'ai besoin de recopier une base de données de 100+ Go.
après avoir effectuer qqs tests avec rsync, je ne suis pas convaincu
par cette solution technique.
temps observés pour 1 Go :
copie initiale sur un fs en local : 73s
idem sur un fs sur un san : 126s à 155s
recopie sans modif : 35s
maj avec 10% de modif : 64s
maj avec 20% de modif : 97s
maj avec 30% de modif : 118s
les temps de maj sont quasiment identique que l'on soit sur un fs en
local ou sur un san !
en fait, les temps en fonction du % de modif est linéaire.
il n'y a pas de différences des mesures du fait que les modifs soient
réparties ou contiguë.
ce qui donne, par extrapolation, pour 100 Go :
0% 58min
10% 1h48
20% 2h46
30% 3h44
existe-il un rsync threadé qui travaillerai sur des parties du même
fichier en // plutôt dans dans sa globalité, ce qui permettrai très=
certainement de booster tout le toutim ?
autre question, pourquoi un rsync de fs à fs se comporte tel un simple
cp et n'utilise pas son algo de recherche par somme de contrôle ?
ce qui oblige de passer par localhost à ce propos, il y a très peu=
de différences entre le protocol rsync et ssh !
pour finir, unison ne semble pas mieux faire. rdiff-backup n'a pas
encore été testé.
PS : version de rsync utilisé : 2.6.3
Cordialement,
Cyrille Lefevre.
--
mailto:Cyrille.Lefevre-news%nospam@laposte.net.invalid
supprimer "%nospam% et ".invalid" pour me repondre.
j'ai besoin de recopier une base de données de 100+ Go.
après avoir effectuer qqs tests avec rsync, je ne suis pas convaincu
par cette solution technique.
temps observés pour 1 Go :
copie initiale sur un fs en local : 73s
idem sur un fs sur un san : 126s à 155s
recopie sans modif : 35s
maj avec 10% de modif : 64s
maj avec 20% de modif : 97s
maj avec 30% de modif : 118s
les temps de maj sont quasiment identique que l'on soit sur un fs en
local ou sur un san !
en fait, les temps en fonction du % de modif est linéaire.
il n'y a pas de différences des mesures du fait que les modifs soient
réparties ou contiguë.
ce qui donne, par extrapolation, pour 100 Go :
0% 58min
10% 1h48
20% 2h46
30% 3h44
existe-il un rsync threadé qui travaillerai sur des parties du même
fichier en // plutôt dans dans sa globalité, ce qui permettrai très=
certainement de booster tout le toutim ?
autre question, pourquoi un rsync de fs à fs se comporte tel un simple
cp et n'utilise pas son algo de recherche par somme de contrôle ?
ce qui oblige de passer par localhost à ce propos, il y a très peu=
de différences entre le protocol rsync et ssh !
pour finir, unison ne semble pas mieux faire. rdiff-backup n'a pas
encore été testé.
PS : version de rsync utilisé : 2.6.3
Cordialement,
Cyrille Lefevre.
--
mailto:Cyrille.Lefevre-news%nospam@laposte.net.invalid
supprimer "%nospam% et ".invalid" pour me repondre.
Poser une question
Salut Cyrille,
Tu peux préciser de où à où parce que c'est pas si clair ?
Pour certains rsync d'un serveur à un autre, on est repassé de ssh à rsh
au taff (je sais chiant parce que pas secure, mais bon) parce que ssh
limite le débit fortement (Il y a des patchs pour openssh, voir des
forks, mais il y a vraiment qq chose à faire sur le long terme)...
A+
Salut Cyrille,
Tu peux préciser de où à où parce que c'est pas si clair ?
Pour certains rsync d'un serveur à un autre, on est repassé de ssh à rsh
au taff (je sais chiant parce que pas secure, mais bon) parce que ssh
limite le débit fortement (Il y a des patchs pour openssh, voir des
forks, mais il y a vraiment qq chose à faire sur le long terme)...
A+
reBonjour,
cette question est toujours à l'ordre du jour...
sur ce point, je me réponds à moi-même après être aller jeter u n coup
d'oeil dans le code. la réponse est --no-whole-file pour avoir un
comportement en local identique au comportement via ssh ou rsync.
pour info, les options utilisés sont : -avIP --inplace --no-whole-file
nouveaux tests en 3.0.7, pas de changement :-(
les résultats précédents étaient via localhost (rsync ou ssh).
voici les résultats en local (copie de fs à fs)...
copie initiale : 33s
0%/10% sans --no-whole-file : 45s
0% avec --no-whole-file : 31s
10% avec --no-whole-file : 63s
0% signifie recopie du même fichier non modifié.
un simple cp met entre 27s et 36s.
Cordialement,
Cyrille Lefevre.
--
mailto:Cyrille.Lefevre-news%
supprimer "%nospam% et ".invalid" pour me repondre.
Salut Jean-Yves,
copie locale avec tentative d'optimisation via rsync sans succès.
l'idée était que s'il y a moins d'écriture, ça va plus vite, mais dans
la vrai vie, ça ne se passe pas comme ça du fait de la lecture des 2
fichiers + calcul du checksum. bref, je suis déçu sur ce coup là.
d'où l'idée de trouver un rsync threadé qui travaille sur des bouts d'un
même fichier en //. mais rien à l'horizon.
j'y ai pensé aussi, mais rshd n'est même pas installé :-)
à ce tarif là, contente toi du mode rsync, je ne pense pas que ce soi t pire.
activation via inetd (ou xinetd) avec un fichier de config du genre :
# cat /etc/rsyncd.conf
use chroot = yes
[test]
path = /test
comment = /test
read only = false
host allow = localhost
uid = 0
gid = 0
puis rsync -av test/ remote::test/
note le ::
Regards, Cordialement,
Cyrille Lefevre.
--
mailto:Cyrille.Lefevre-news%
supprimer "%nospam% et ".invalid" pour me repondre.
remove "%nospam" and ".invalid" to answer me.
Tu peux redéfinir ton besoin initial ?
Parce que par exemple, quand j'ai eu besoin de changer de baie de
disques j'ai utilisé les fonctions de mirroring logiciel au niveau de la
couche unix et/ou linux... pour migrer tranquillement et après tu
supprime la patte sur lesquels il y a la baie que tu veux récupérer...
(J'ai fait ça de A à Z à chaud sur AIX par exemple...). Le mirorring se
faisant en background il ne tue pas les perfs...
Maintenant si tu veux faire des recopie des bases pour alimenter un
autre environnement, si tu as une baie de type netapp... il y a une
piste à creuser avec des snapshots...
Amicalement,