2 votes

Quelles sont les options rsync à utiliser pour le scénario mentionné ci-dessous ?

Salutations ! !!

Il s'agit d'une exigence spécifique de rsync que nous essayons d'atteindre. Nous avons essayé d'y parvenir en utilisant diverses options rsync. Cependant, nous rencontrons différents problèmes avec les différentes options rsync.

Antécédents : - Nous avons un processus (fonctionnant sous AIX) dont les journaux sont enregistrés dans A.log (présent dans le répertoire logs). - A.log fait l'objet d'une rotation vers A.CURRENT_DATE_TIME.log lorsqu'il atteint 100 Mo et un nouveau A.log est créé. - Nous transférons ces logs vers un serveur centralisé en utilisant rsync. Nous utilisons rsync sur le répertoire complet des logs. - L'INODE des fichiers sur le serveur source et le serveur de destination sont différents. - Une fois que les logs sont dans le serveur centralisé, l'idée est de faire lire/indexer ces logs par un processus de log centralisé qui prendra l'entrée de ce serveur centralisé.

Problème : - Bien que A.log (serveur de destination) soit donné en entrée au processus centralisé de journalisation, il considère l'INODE du fichier et non le nom de fichier réel. - Ainsi, lorsque le fichier A.log est transféré, le nouveau A.log a un nouveau INODE qui n'est pas détecté par le processus centralisé. Cela se produisait lorsque nous utilisions les options -u -r -t avec rsync. Donc dans ce cas, l'INODE du fichier changeait à chaque fois que rsync se produisait et aussi lorsque le roulement se produisait. Par conséquent, le processus arrête l'indexation car il recherche l'ancien INODE qui n'est pas présent.

- L'idée est d'utiliser rsync avec une combinaison d'options qui ne changerait pas l'INODE du fichier au moment de rsync mais devrait changer l'INODE au moment du rollover quand A.log tourne vers A.CURRENT_DATE_TIME.log. Donc, pour y parvenir, nous avons inclus l'option -inplace et nous sommes en mesure de conserver l'INODE au moment de la rsync et les changements d'INODE au moment de la rotation du fichier. Cependant, cela nous donne un problème différent maintenant où le nom du fichier ne change pas et reste toujours A.log. Donc, une fois que le processus a fini d'indexer le A.log, il s'arrête.

Ce serait formidable si quelqu'un pouvait suggérer quelque chose qui pourrait nous aider à répondre aux exigences mentionnées.

Salutations, Puneet Sinha Administrateur Middleware

1voto

Anatidaus Points 2549

Je ne recommande pas de se fier à l'inode. Il changera à chaque fois que le fichier passera de la machine source à la machine de destination. Il changera également si les fichiers sont restaurés à partir de sauvegardes. Si le système de traitement des journaux dépend de l'inode, si jamais vous restaurez à partir de sauvegardes, le système ne fonctionnera pas comme prévu.

Ma recommandation est de NE PAS copier A.log, mais seulement de copier A.CURRENT_DATE_TIME.log. Cela simplifiera le projet.

Je soupçonne que le système de traitement des journaux sur le serveur de destination regarde l'inode pour déterminer si le fichier qu'il avait précédemment vu comme A.log est maintenant A.CURRENT_DATE_TIME.log. Cela ne va pas être fiable.

La solution ci-dessus présente un problème : le temps nécessaire pour qu'une ligne du fichier journal soit générée jusqu'au moment où elle est traitée par le processus centralisé de journalisation augmentera. Par exemple, s'il faut 3 jours pour que A.log atteigne 100 Mo, rien de ce fichier n'entrera dans le processus de journalisation centralisé avant 3 jours. Si les journaux ne peuvent pas être retardés de plus de 2 heures, alors je ferais une rotation des journaux toutes les 1 heure. De cette façon, vous savez que vous êtes dans l'objectif de 2 heures.

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:

X