pb de recopie d'une base de données

Le 05/06/2010 00:33, Cyrille Lefevre a écrit :

Bonjour,

j'ai besoin de recopier une base de données de 100+ Go.

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+

Le 05/06/2010 00:33, Cyrille Lefevre a écrit :

Bonjour,

j'ai besoin de recopier une base de données de 100+ Go.

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+

Le 05/06/2010 00:33, Cyrille Lefevre a écrit :
reBonjour,

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 ?

cette question est toujours à l'ordre du jour...

autre question, pourquoi un rsync de fs à fs se comporte tel un simpl e
cp et n'utilise pas son algo de recherche par somme de contrôle ?

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

PS : version de rsync utilisé : 2.6.3

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%nospam@laposte.net.invalid
supprimer "%nospam% et ".invalid" pour me repondre.

Le 05/06/2010 02:00, LENHOF Jean-Yves a écrit :

Le 05/06/2010 00:33, Cyrille Lefevre a écrit :

j'ai besoin de recopier une base de données de 100+ Go.

Salut Jean-Yves,

Tu peux préciser de où à où parce que c'est pas si clair ?

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.

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)...

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%nospam@laposte.net.invalid
supprimer "%nospam% et ".invalid" pour me repondre.
remove "%nospam" and ".invalid" to answer me.

Le 05/06/2010 02:49, Cyrille Lefevre a écrit :

Le 05/06/2010 02:00, LENHOF Jean-Yves a écrit :

Le 05/06/2010 00:33, Cyrille Lefevre a écrit :

j'ai besoin de recopier une base de données de 100+ Go.

Salut Jean-Yves,

Tu peux préciser de où à où parce que c'est pas si clair ?

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.

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,

Le 05/06/2010 13:23, LENHOF Jean-Yves a écrit :

Le 05/06/2010 02:49, Cyrille Lefevre a écrit :

Le 05/06/2010 02:00, LENHOF Jean-Yves a écrit :

Le 05/06/2010 00:33, Cyrille Lefevre a écrit :

j'ai besoin de recopier une base de données de 100+ Go.

Tu peux préciser de où à où parce que c'est pas si clair ?

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, m ais 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 bo uts d'un
même fichier en //. mais rien à l'horizon.

Tu peux redéfinir ton besoin initial ?

environnement RHEL 4 ou 5
pas le droit aux miroirs linux, même en LVM
baies SAN EMC avec snap ou clone, pas de bcv ni de srdf car baie locale
le snap consomme 15 à 20% de perf
pour info, un miroir sous AIX consomme également 15 à 20% de perf
l'idée est d'impacter au minimum les perf de la base de prod
pb : recopier cette base de prod sur un autre serveur tout en impactant
au minimum les perfs et dans un temps record (moins de 2h pour 120 Go)
un test a été effectué via un cp depuis un snap sur une base de 80G o
résultat : 2h pour 80 Go ! on est dedans pour 120 Go...
alternative envisagé, restauration du snap sur une autre source visible
du serveur cible mais pb de perf sur la base de prod...
avantage, le snap est tout de suite visible côté cible.
les clones ont aussi été envisagés, mais le fw de la baie ne permet pas
de resynchro du clone en mode incrémental à cause des anciens paliers
techniques connectés au SAN, solution rejeté donc, d'autant plus que
cela aurai nécessité 30+ jours de dev pour mettre à niveau les
procédures existantes, et que la solution doit être prête pour hier :-)
d'après les recherches que j'ai faites hier, je vais me rapprocher de
l'équipe sgbd pour passer par RMAN ? pb, RMAN n'est pas utilisé à c e
jour. avantage de RMAN, permettrai de ne synchroniser que ce qui a
changé au niveau de la base, une sorte de clone incrémental mais au
niveau SGBD.
autre alternative envisagé, découpage au max de la base (un table spa ce
par fs) pour multiplier les axes, pour autant, ej ne sais pas si cela
est faisable côté projet.
d'où l'idée de départ de passer par un rsync amélioré...

à propos d'unison, il ne semble pas y avoir d'option -inplace, pb, il
faut le double du plus gros fichier d'espace libre sur la cible.

Cordialement,

Cyrille Lefevre.
--
mailto:Cyrille.Lefevre-news%nospam@laposte.net.invalid
supprimer "%nospam% et ".invalid" pour me repondre.

"Cyrille Lefevre" a écrit

environnement RHEL 4 ou 5
pas le droit aux miroirs linux, même en LVM
baies SAN EMC avec snap ou clone, pas de bcv ni de srdf car baie locale
le snap consomme 15 à 20% de perf
pour info, un miroir sous AIX consomme également 15 à 20% de perf
l'idée est d'impacter au minimum les perf de la base de prod
pb : recopier cette base de prod sur un autre serveur tout en impactant au
minimum les perfs et dans un temps record (moins de 2h pour 120 Go)
un test a été effectué via un cp depuis un snap sur une base de 80Go
résultat : 2h pour 80 Go ! on est dedans pour 120 Go...

Etonnant qu'une copie au travers de fs soit moins couteux en perf dans un
unix qu'au travers une copie de blocks, j'aurais pas cru.

Cyrille Lefevre wrote in message <hubuvl$1nl3$1@talisker.lacave.net>:

ce qui donne, par extrapolation, pour 100 Go :

0% 58min
10% 1h48
20% 2h46
30% 3h44

Cette extrapolation n'est pas valable : 1 Go, de nos jours, ça tient en RAM,
donc tout se retrouve dans le cache, et c'est le CPU le facteur limitant. Au
contraire, 100 Go, ça ne tient pas en RAM, donc c'est le disque le facteur
limitant (à moins que le disque ne soit très rapide par rapport au CPU).

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 ?

L'algorithme de rsync consiste en ceci :

- lecture complète du fichier source pour construire une signature formée de
sommes de contrôle par blocs ;

- transfert de la signature ;

- lecture complète du fichier destination pour rechercher, par sommes de
contrôle glissante, les blocs déjà présents ;

- transfert des blocs manquants et construction du fichier destination.

On notera que, dans le meilleur des cas, quand le fichier cible est déjà
quasiment identique au fichier source, rsync exige toujours deux lectures
complètes non parallélisables. L'intérêt premier de rsync est de minimiser
les données échangées entre les deux extrémités.

Quand il s'agit d'une copie locale, le transfert ne coûte rien, une bête
copie demande une lecture complète et une écriture complètes,
parallélisables : même dans le meilleur des cas, ça fait mieux que rsync.

Il y a quelques cas capilotractés où on peut vouloir préférer que rsync
fasse ses deux lectures complètes. On peut imaginer par exemple que la cible
soit sur un support dont les écritures sont très lentes ou très coûteuses
par rapport aux lectures. Mais c'est marginal.

L'autre intérêt d'utiliser rsync en local, c'est pour la possibilité de
considérer que le fichier cible est identique au fichier source dès que la
taille et le mtime concordent. Dans les cas favorables (où personne ne va
faire exprès de falsifier le mtime pour tromper l'ennemi), c'est très
pratique.

(Une remarque au passage : les filesystems FAT stockent le mtime à deux
secondes près, ce qui fait échouer cette heuristique une fois sur deux ;
chercher FAT dans le man de rsync pour la contre-mesure.)

Le 05/06/2010 23:19, Cyrille Lefevre a écrit :

Le 05/06/2010 13:23, LENHOF Jean-Yves a écrit :

Le 05/06/2010 02:49, Cyrille Lefevre a écrit :

Le 05/06/2010 02:00, LENHOF Jean-Yves a écrit :

Le 05/06/2010 00:33, Cyrille Lefevre a écrit :

j'ai besoin de recopier une base de données de 100+ Go.

Tu peux préciser de où à où parce que c'est pas si clair ?

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.

Tu peux redéfinir ton besoin initial ?

environnement RHEL 4 ou 5
pas le droit aux miroirs linux, même en LVM
baies SAN EMC avec snap ou clone, pas de bcv ni de srdf car baie locale
le snap consomme 15 à 20% de perf

<snip>

autre alternative envisagé, découpage au max de la base (un table space
par fs) pour multiplier les axes, pour autant, ej ne sais pas si cela
est faisable côté projet.
d'où l'idée de départ de passer par un rsync amélioré...

Qq autres idées :

- Dans cette veine, as-tu envisagé la piste cpio "en parallèle"...
suivant les cas cela pourrait être plus rapide si tu as plusieurs axes
et plusieurs processeurs.

Infos ici :

http://rightsock.com/~kjw/Ramblings/tar_v_cpio.html

- Le dd est une autre piste pour recopier aussi...

- Sinon le snapshot LVM est-il une piste envisageable ou pas ?

Amicalement,

Le 06/06/2010 12:24, LENHOF Jean-Yves a écrit :
<snip>

Qq autres idées :

- Dans cette veine, as-tu envisagé la piste cpio "en parallèle"...
suivant les cas cela pourrait être plus rapide si tu as plusieurs axe s
et plusieurs processeurs.

d'ou l'idée d'avoir un maximum d'axes, mais merci quand même :-)

Infos ici :

http://rightsock.com/~kjw/Ramblings/tar_v_cpio.html

je note...

- Le dd est une autre piste pour recopier aussi...

- Sinon le snapshot LVM est-il une piste envisageable ou pas ?

déjà testé en RHEL 4 :
activation d'un snap
remplissage du snap à 100%
suppression du snap
panic !

non testé en RHEL 5, mais cela ne concerne pas l'architecture en
question de toutes les façons. autre pb des snaps LVM, il faut
connaitre à l'avance l'espace qu'il peut représenté dans le VG.

PS : toto: host not found :-)

Cordialement,

Cyrille Lefevre.
--
mailto:Cyrille.Lefevre-news%nospam@laposte.net.invalid
supprimer "%nospam% et ".invalid" pour me repondre.