3 votes

Namnodorel avatar

Rsync --inplace ne lit pas le fichier cible?

Demandé el 22 de Janvier, 2013
Quand la question a-t-elle été
2490 affichage
Nombre de visites la question a
2 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

Je tente d'optimiser la sauvegarde quotidienne d'un instantané LVM d'une grande base de données MySQL. Cela fonctionne assez bien lorsque je me contente de cp les fichiers (RAID local vers un autre RAID local), avec une vitesse moyenne d'environ 100 Mo/s. Mais comme les fichiers de la base de données (600 Go, la plupart étant dans deux fichiers de 350 Go et 250 Go) ne changent pas beaucoup au cours d'une journée, j'ai pensé qu'il serait plus efficace de ne copier que les blocs modifiés.

Je suis en train d'utiliser

rsync --safe-links --inplace -crptogx -B 8388608 /source/ /destination/

Cela a fonctionné, mais c'était plus lent que la simple copie, et je n'ai pas vu d'activité de lecture sur le disque cible. Je pensais que rsync lirait des blocs (8 Mo) à partir de la source et de la destination, comparerait leurs sommes de contrôle et ne copierait le bloc source dans le fichier cible que s'il avait changé. Me trompé-je ici ? Pourquoi est-ce que je ne vois pas rsync lire à partir de la destination pour déterminer si les blocs ont changé ?

Voici quelques graphiques :

Utilisation du disque : vous voyez que rsync --inplace (seulement fait pour le plus gros fichier le dernier jour) a réduit le "creux" dans l'utilisation du disque de /mnt/backup, ce qui signifie qu'il a effectivement mis à jour le fichier existant sur place.

Stats IO : la sauvegarde est faite de sda vers sdb. En quelque sorte, il y a un pic énorme de lectures à partir de la source, suivi de l'activité normale de lecture(source)+écriture(cible). Je m'attendais à des lectures simultanées à partir des deux périphériques avec peu d'activité d'écriture sur la cible.

description de l'image

Demandé el 22 de Janvier, 2013 par Namnodorel

Réponses

Trop de publicités?

2voto

the-wabbit avatar
the-wabbit Points 40039

Ce que vous voyez probablement est dû à la manière dont vos fichiers sont modifiés et comment rsync calcule les sommes de contrôle. La page de manuel de rsync concernant --inplace a une explication de base :

          o      L'efficacité de l'algorithme de transfert delta de rsync peut être
                 réduite si certaines données dans le fichier de destination sont écrasées
                 avant de pouvoir être copiées à une position ultérieure dans le fichier. 
                 Cela ne s'applique pas si vous utilisez `--backup`, puisque
                 rsync est assez intelligent pour utiliser le fichier de sauvegarde comme base
                 pour le transfert.

Vous ne devriez probablement pas utiliser --inplace ou utilisez --backup pour conserver l'ancienne copie du fichier. Cela étant dit, rsync semble gérer les gros fichiers de manière plutôt inefficace, donc ce n'est peut-être pas le meilleur outil pour le travail.

Si vous utilisez LVM et que vous voulez vraiment transférer des données d'instantané, vous ne voudrez peut-être pas exécuter rsync qui est assez intensif en calcul et en I/O des deux côtés, mais plutôt copier les données CoW de l'instantané sur la machine de destination en utilisant lvmsync à la place - cela vous épargnerait l'I/O et les cycles CPU au prix d'une taille de transfert probablement plus importante.

Une autre approche du problème consisterait à faire des sommes de contrôle "brutes" du bloc de données (par exemple, avec MD5) et transférer des blocs différenciés comme dans cette réponse ici sur ServerFault ou dans le script blocksync.py (j'ai lié le fork le plus récemment actif). Cela ne dépendrait pas du tout des instantanés, mais évidemment vous voudriez en créer un pour le moment de la copie afin de garantir la cohérence de vos données.

Si vous vous inquiétez des performances d'écriture de votre base de données avec des instantanés actifs, vous pourriez également jeter un œil à ddsnap qui contient plusieurs optimisations pour la prise d'instantanés et la réplication de volumes, contournant efficacement vos préoccupations.

Répondu el 22 de Janvier, 2013 par the-wabbit (40039 Points )

0 votes

Avatar de Namnodorel

Utiliser --backup n'est pas une option, car je n'ai de l'espace que pour une seule copie. Ne pas utiliser --inplace signifie que je peux juste utiliser cp comme avant. Et c'est un fichier de données InnoDB, donc il ne devrait avoir que des changements basés sur les blocs. De plus, j'utilise la méthode de "snapshot temporaire", ce qui signifie que je prends un instantané, copie les fichiers, puis supprime l'instantané. Laisser l'instantané pendant les opérations quotidiennes entraînerait une trop grande pénalité de performance.

Commenté el 22 de Janvier, 2013 par Namnodorel

0 votes

Avatar de the-wabbit

@StefanSeidel J'ai voulu ajouter le lien vers lvmsync dans mon message, mais je l'ai oublié. Je pense que ce serait une bien meilleure approche pour résoudre votre problème que d'utiliser rsync. En ce qui concerne le problème de rsync, vous pourriez vouloir prendre d'autres mesures. En particulier, rsync lui-même indique combien de données ont été transférées sur la ligne à la fin du transfert - pouvez-vous confirmer que l'intégralité du fichier de base de données passe par le réseau ?

Commenté el 22 de Janvier, 2013 par the-wabbit

0 votes

Avatar de Namnodorel

Mais lvmsync signifie que je dois garder l'instantané LVM actif tout le temps, n'est-ce pas? Ce n'est pas possible à cause des performances. J'ai ajouté le graphique IO qui montre exactement que rsync ne lit pas de quantité significative de données du périphérique de destination.

Commenté el 22 de Janvier, 2013 par Namnodorel
Afficher 2 autres commentaires

0voto

Curly avatar
Curly Points 65

Je crois que vous voulez --inplace --no-whole-file. Notez que pour les systèmes de fichiers locaux, --whole-file est supposé (voir la page man de rsync). Voir un petit test sympa sur unix.SE. Notez les commentaires.

Répondu el 10 de Décembre, 2017 par Curly (65 Points )

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X