Bonjour,
Je sollicite la communauté car j'ai un soucis avec RSYNC.
J'ai une base de données MongoDB qui contient un bon To de données.
Cette base est sauvegardée via "mongodump" toutes les nuits localement sur la machine qui l'héberge (nous l'appellerons "srvMaster" pour faciliter la compréhension).
Je conserve deux dumps : celui du jour précédent et celui du jour J.
Le fichier produit par mongodump est purement binaire.
Le lendemain matin, un deuxième serveur "srvSlave" vient chercher la sauvegarde du jour J la rapatrie en local.
L'arborescence est la suivante :
-
sur srvMaster :
- dernière sauvegarde : /home/backup/mongo/
- sauvegarde J-1 : /home/backup/mongo_prev/
-
sur srvSlave :
- dernière sauvegarde : /home/backup/mongo/
- sauvegarde J-1 : /home/backup/mongo_prev/
Le problème est que RSYNC télécharge l'ensemble des gros fichiers binaires et non le delta. Ma base de données ne fait que de l'insertion (aucun delete, aucun update) donc j'imagine (selon les mécanismes de MongoDB) que les nouvelles données sont toujours en fin de dump.
Au début, je faisais transiter le RSYNC sur un montage NFS mais on me l'a déconseillé. Je me suis donc orienté sur RSYNC over SSH : même soucis.
Les commandes sont toujours exécutées depuis srvSlave donc je tire les données.
Voici quelques essais :
- d'abord des essais en local :
/usr/bin/sudo -u nobody /usr/bin/rsync -av --delete /home/backup/mongo/* /home/backup/mongo/. /usr/bin/sudo -u nobody /usr/bin/rsync -av --stats --delete --partial --inplace --no-whole-file --checksum /home/backup/mongo/* /home/backup/mongo/. - puis à distance :
/usr/bin/sudo -u nobody /usr/bin/rsync -av --stats --delete --partial --inplace --no-whole-file --checksum -e "ssh -o StrictHostKeyChecking=no -i /key/id_rsa_for_backup" backup@srvMaster:/home/backup/mongo/* /home/backup/mongo/. /usr/bin/sudo -u nobody /usr/bin/rsync -av --delete -e "ssh -o StrictHostKeyChecking=no -i /key/id_rsa_for_backup" backup@srvMaster:/home/backup/mongo/* /home/backup/mongo/.J'ai essayé d'autres combinaisons (sans --checksum par exemple) mais j'ai toujours le soucis. Les deux machines sont sur Gentoo ; le shell par défaut est bash ; la version de RSYNC est 3.0.9-r3.
Est-ce que quelqu'un aurait une idée ? En sachant que ça ne vient pas du transfert via le réseau puisqu'en local j'ai également le soucis.
J'ai posé la question sur les forums Gentoo : on m'a juste dit de ne pas transférer via NFS mais le soucis reste le même en passant par SSH.
Je vous remercie d'avance
# gzip
Posté par Old Geek . Évalué à 3.
Hello,
Je sais que gzip à un mode de "compatibilité" rsync
gzip --rsyncable
Si il n'existe pas d'option semblable pour organiser les données par bloc spécifiquement à ton export mongodb, à mon avis c'est mort…
Nicolas
[^] # Re: gzip
Posté par kortex . Évalué à 2.
Donc ça viendrait de rsync qui ne voit pas la modification dans son "block-size" habituel et qui prends la décision de tout synchroniser ?
[^] # Re: gzip
Posté par KiKouN . Évalué à 2.
L'algo de base de rsync est simple.
Si mod-time différent => transfert.
Si mod-time identique et taille différent => reprise de transfert.
Tu peux peux être jouer avec --checksum et --block-size=SIZE de rsync. avec un SIZE assez petit.
[^] # Re: gzip
Posté par kortex . Évalué à 1.
J'ai essayé "--checksum" tout court sans "--block-size=SIZE".
Tu mettrais quoi comme "--block-size" ? Je trouve pas d'information sur son fonctionnement :-/
[^] # Re: gzip
Posté par pralines . Évalué à 5.
à ma connaissance,RSYNC ne transfère que les blocs de fichier qui diffèrent entre le master et le slave
le slave demande un bloc au master, chacun calcule une somme de contrôle de son côté, si les sommes sont différentes ---> transfert du bloc de fichier, et on passe au bloc suivant
mais il ne faut pas s'amuser à compresser ou chiffrer ses fichiers avant le RSYNC, sinon il y a de bonne chances que tous les blocs soient différents (comme dis plus haut, une option de gzip permet de palier ce problème, merci pour l'info :-)
tu dis que tu ne fais que des insert dans ta bdd et tu en déduis que ton dump au format binaire ne diffère que vers la fin, est-ce que tu as vérifié (peut-être que le dump est compressé par défaut) ???
Envoyé depuis mon Archlinux
[^] # Re: gzip
Posté par kortex . Évalué à 1.
J'ai toujours utilisé rsync dans ce but oui… Genre pour des migrations ou tu fais un premier rsync à chaud puis un delta à froid pour redémarrer rapidement.
Mais bizarrement sur des gros fichiers il n'a pas le même comportement.
Non je ne le déduis pas ; je pense que c'est comme ça. Par contre j'ai aucun élément de réponse… :-/
La documentation sur mongodump est light mais j'ai comme l'impression que le dump n'est pas compressé par défaut :
Mais j'ai remarqué ce soucis avec d'autres gros fichiers binaires donc, sauf erreur de ma part, je pense pas que ce soit lié au dump Mongo spécialement :-/
[^] # Re: gzip
Posté par kortex . Évalué à 1.
Je confirme : je viens de faire un test de rsync en prenant un répertoire MySQL bien lourd (base démarrée) et au deuxième rsync, sur les gros fichiers, il sync full :-/
[^] # Re: gzip
Posté par pralines . Évalué à 2. Dernière modification le 20 novembre 2014 à 19:00.
des fichiers de bdd ça bouge beaucoup (un changement de structure, une optimisation, et le fichier est presque entièrement différent)
tu as analysé les différences de fichiers entre 2 rsync (commande cmp par exemple) ?
petite expérience :
prend un de tes gros fichiers, fais un rsync,
puis concatène avec un fichier plus petit,
refait un rsync et observe
si tout le fichier est retransféré il y a effectivement un pb, ou un bug, ou option de rsync pas adaptée (tu n'es pas le premier à constater ce comportement, mais je n'ai encore lu de diagnostic du pb, ni de solution…)
Envoyé depuis mon Archlinux
[^] # Re: gzip
Posté par kortex . Évalué à 1.
Je viens de faire le test suivant :
- copier un fichier de la DB qui tourne vers un répertoire "tmp"
- copier ce fichier de "tmp" vers "src"
- rsync -av --stats --progress src/* cible/. : sync full (normal)
- concaténation d'un petit fichier de DB dans src/fichier_origine
- rsync -av --stats --progress src/* cible/. : à nouveau un sync full :'(
Je ne comprends vraiment pas le problème :-/
[^] # Re: gzip
Posté par pralines . Évalué à 1.
tu as bien un daemon rsync (serveur) qui tourne sur la machine cible capable de répondre à ta commande rsync locale (client) ?
parce que j'ai l'impression que tu ne fais que de la copie entre un répertoire local et un répertoire distant au moyen d'un accès ssh, et dans ce cas, tu auras les mêmes échanges qu'avec un rsync purement local
Envoyé depuis mon Archlinux
[^] # Re: gzip
Posté par kortex . Évalué à 1.
Bonjour,
Effectivement je n'ai pas le daemon rsync (ni sur le serveur source, ni sur le serveur cible). Par contre, quand je fais un rsync purement local (comme celui de mon dernier commentaire), il faut également le daemon ?!
[^] # Re: gzip
Posté par pralines . Évalué à 1. Dernière modification le 21 novembre 2014 à 10:30.
en local, aucun intérêt, rsync n'utilisera pas son algo delta,
cet algo qui permet de transmettre uniquement les différences d'un fichier n'a d'intérêt que lors d'un transfert entre 2 processus RSYNC qui disposent chacun d'un cpu distinct et à travers un réseau dont la bande passante est (très) inférieure aux débits des disques
en local, il y a 1 seul rsync qui tourne, le fichier source va être lu intégralement, et le fichier destination va être aussi créé en totalité,
pas la peine de calculer les différences sur un fichier, c'est du travail superflu
désolé si pas très clair, au boulot, pas trop le temps de développer, mais tu trouveras pleins de tuto et d'explication sur le principe de fonctionnement de RSYNC, faut juste réaliser qu'il y a 2 utilisations (1 RSYNC isolé, ou 2 RSYNC qui causent entre eux)
Envoyé depuis mon Archlinux
[^] # Re: gzip
Posté par yohann (site web personnel) . Évalué à 1.
je ne crois pas (= je sais) que le démon rsync soit nécessaire si on passe par ssh comme le fait kortex.
Concernant le delta, c'est vrai qu'il ne sert a rien local mais en théorie, dans la mesure ou kortex utilise l'option no-whole-file, cela devrait forcer le calcul du delta (même si c'est contre productif, mais on s'en fout c'est pour le test).
dans tout les cas l'algo de delta n'est utilisé que pour les octet à tranférer, dans tout les cas les fichier sont source et destination sont lu, et au moindre bit de différence entre les 2 le fichier de destination est intégralement réécris (j'ai testé avec l'option inplace: le fichier est réécris par dessus l'ancien, mais réécris qd meme).
Le bilan: rsync permet d'optimiser la bande passante au prix des IO disque.
[^] # Re: gzip
Posté par kortex . Évalué à 1.
Du coup ce n'est pas un bug chez moi mais bien un comportement généralisé :/
Yohann comme tu semble avoir les mêmes résultats que moi, est-ce que tu as une solution pour ne copier que le delta ?
Précision tout de même : je n'utilise pas toujours --inplace et/ou --no-whole-file. J'ai fais plusieurs essais donc le classique rsync -av src/* cible/. et même combat :(
Pour résumer, je viens de refaire quelques essais :
je rsync un gros fichier (27 Go)
rsync -av --stats --progress src/* cible/.
je relance le rsync : plus rien à faire (normal)
je concatène un fichier binaire assez léger (12 Ko) à la fin du gros fichier source :
cat binary_12k >> src/gros_fichier
je relance le rsync avec différentes combinaisons :
[^] # Re: gzip
Posté par KiKouN . Évalué à 2.
Je comfirme les résultats avec l'option --checksum.
Par contre, j'ai trouvé un cas où on peut simulée une reprise de transfert.
rsync -avP systemrescuecd-x86-4.3.0.iso moi@localhost:/tmp/site/
cat 10mo >> systemrescuecd-x86-4.3.0.iso
cat 10mo >> systemrescuecd-x86-4.3.0.iso
touch systemrescuecd-x86-4.3.0.iso /tmp/site/systemrescuecd-x86-4.3.0.iso
rsync -avP systemrescuecd-x86-4.3.0.iso moi@localhost:/tmp/site/
J'obtiens alors une reprise de transfert par rsync comme si le fichier original n'avait pas bougé. Je déduis cela de la vitesse de transfert affiché par rsync qui est inhabituellement élévée en début pour finir avec les valeurs habitelles.
[^] # Re: gzip
Posté par yohann (site web personnel) . Évalué à 2.
malheureusement non, comme expliqué, la vocation de rsync est de réduire l'utilisation de la bande passante, pas tellement l'utilisation du disque (ni en terme d'espace, ni en terme d'IO).
par contre les terme sont assez imprécis : si on considérer le fichier A à t0 composé de 1111 et à t1 composé de 1110 et qu'on le transfère en utlisant rsync, voilà ce qui va arrivé dans le cas optimum:
A sur src et A sur dest font ils la meme taille et ont-il la meme date de modification (si non on déclenche le transfert)
On lit A sur src et on calcule son checksum
On lit A sur desc et on calcule son checksum
sont-il identique ? (si non on commence le transfert)
On lit le premier chunk de A: 1 on réalise son checksum
on lit le premier chunk de B: 1 on rélise son checksum
si les checksum son identiques on copie le début du fichier depuis le Fichier A sur dest dans un fichier temporaire (sauf si inplace auquel cas on écrit au début de A sur Dest (oui on remplace 1 par un nouveau 1)
sinon on copie depuis A sur src.
On recommence avec des block de plus en plus gros tant que ça fonctionne.
[^] # Re: gzip
Posté par kortex . Évalué à 1.
Bonjour,
Je te remercie pour l'explication mais malheureusement il y a toujours une chose que je ne comprends pas. Tu dis que RSYNC optimise la bande passante et non les I/O. Mais quand je concatène 12 Ko au bout d'un fichier de 27 Go et qu'il se met à transférer les 27 Go, c'est pas super économe :-/
Du coup par rapport à ton explication j'en déduis que je ne dois pas utiliser "--inplace" mais malgré tout je ne trouve pas LA combinaison qui fait qu'il va syncer un delta.
Ça n'existe pas ?
[^] # Re: gzip
Posté par yohann (site web personnel) . Évalué à 1.
en fait a moins d'être en local il ne transfère pas les 27 GO.
mais de mémoire "l'interface graphique" (le truc qui apparait quand on lance avec --progress) rend ça transparent. (mais affiche des débit largement supérieur à ta BP du coup du comprend qu'il se passe quelque chose de magique).
Et, une fois le transfert terminé, il affiche le nombre d'octet qui a effectivement transité sur le réseau.
[^] # Re: gzip
Posté par kortex . Évalué à 1.
Les tests étaient tellement longs à effectuer que j'ai utilisé l'option "-n" pour simuler ce qu'il se passerait et je me suis fié aux valeurs affichées dans le rapport final ; si ce mode simulation est une image de la réalité, il transfert 100% :-/
Tous les tests que j'ai fais réellement (sans le "-n") ont confirmé ce transfert complet (en local comme à distance).
J'ai quand même du mal d'imaginer que je suis le seul qui ait besoin de transférer un delta de fichiers volumineux :-/
[^] # Re: gzip
Posté par NeoX . Évalué à 2.
il te manquerait pas un --partial pour garder ce qui est deja sur la destination ?
perso je fais mes transferts avec
rsync -aP SRC DST[^] # Re: gzip
Posté par KiKouN . Évalué à 2.
C'est vrai que c'est con. -P est l'alias de "--partial --progress". Je le fous tout le temps pour avoir le --progress. Si bien que j'en oublie qu'il fait aussi --partial.
[^] # Re: gzip
Posté par kortex . Évalué à 1.
D'après le man, "--partial" ne sert qu'à la reprise en cas de coupure du transfert. J'ai essayé --partial avec l'option -n et pareil :
Total file size: 28735205960 bytes
Total transferred file size: 28735205960 bytes
[^] # Re: gzip
Posté par KiKouN . Évalué à 2.
Je ne ferais pas confiance à ce qu'annonce rsync comme débit, taille transfert.
Je pense que le mieux est de faire un dump de ce qui passe et de calcul son poids.
[^] # Re: gzip
Posté par kortex . Évalué à 1. Dernière modification le 28 novembre 2014 à 10:36.
Oui mais je n'ai pas commencé par lui faire confiance aveuglément :-)
Quand je lance réellement le transfert je peux t'assurer qu'il transfert tout (taille en MB/s * temps = la taille du fichier).
Hors, je ne rajoute que 12 Ko à la fin d'un fichier binaire de 27 Go :
bash
cat fichier_binaire_12K >> fichier_binaire_27G
L'option "-n" n'est peut être pas la plus fiable mais dans mon cas je pense qu'elle fonctionne correctement :-/
# rdiff-backup et rdiff-backup-fs
Posté par Space_e_man (site web personnel) . Évalué à 1.
Il me semble que voila ce qu'il te faut :
http://www.nongnu.org/rdiff-backup/
https://code.google.com/p/rdiff-backup-fs/
[^] # Re: rdiff-backup et rdiff-backup-fs
Posté par kortex . Évalué à 1.
Ce soft m'a l'air intéressant effectivement mais dans la mesure ou je ne sauvegarde pas un répertoire mais un dump, est-ce qu'il va réussir à faire le delta ?
Désolé pour la solution de facilité (poser la question au lieu de tester) mais je suis un peu court niveau temps ces jours-ci :-/
# Toujours pas de solution
Posté par kortex . Évalué à 1.
Bonjour,
J'ai mené différents essais ces derniers jours et j'en suis toujours au même point.
Côté RSYNC :
- tests sur Gentoo et Debian wheezy
- avec différentes combinaisons d'options
- avec un daemon RSYNC côté source ET côté cible
- sans daemon RSYNC
- sur montage NFS
- à travers SSH
J'ai toujours le même comportement…
Côté RDIFF-BACKUP : mes premiers essais ne me conviennent pas. Ca n'a pas la souplesse / la simplicité de RSYNC :-/
Avant je travaillais sur Solaris et je migrais des zones locales en deux temps :
- j'amenais un nouveau volume de disques
- je faisais une première synchronisation (groupe de disques actuel => nouveau groupe de disques) pendant que la zone était en exécution
- je coupais la zone
- je faisais une deuxième synchronisation à froid : je n'avais que le delta
Hors, je n'utilisais qu'une commande simple : rsync -av --delete source cible
Pourquoi le rsync de Linux n'a pas ce comportement ?
Si quelqu'un a des idées je suis preneur.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.