Saludos !!!
Esto se refiere a un requisito específico sobre rsync que estamos tratando de lograr. Hemos intentado lograr esto utilizando varias opciones de rsync. Sin embargo, nos encontramos con diferentes problemas con diferentes opciones de rsync.
Antecedentes: • Tenemos registros de un proceso (que se ejecuta en AIX) que se registran en A.log (presente en el directorio de registros). • A.log se rota a A.CURRENT_DATE_TIME.log una vez que alcanza los 100 MB y se crea un nuevo A.log. • Estamos transfiriendo estos registros a un servidor centralizado usando rsync. Estamos usando rsync en el directorio de registros completo. • El INODE de los archivos en el servidor de origen y el servidor de destino son diferentes. • Una vez que los registros están en el servidor centralizado, la idea es hacer que estos registros sean leídos/indexados por un proceso de registro centralizado que recogerá la entrada de este servidor centralizado.
Problema: • Aunque A.log (servidor de destino) se proporciona como entrada al proceso de registro centralizado, considera el INODE del archivo y no el nombre de archivo real. • Entonces, cuando el archivo A.log se renueva, el nuevo A.log tiene un nuevo INODE que no es detectado por el proceso centralizado. Esto sucedía cuando usábamos las opciones -u –r –t con rsync. Entonces, en este caso, el INODE del archivo cambiaba cada vez que ocurría rsync y también cuando ocurría la transferencia. Por lo tanto, el proceso deja de indexar mientras busca el antiguo INODE que no está presente.
• La idea es usar rsync con una combinación de opciones que no cambiarían el INODE del archivo en el momento de rsync pero deberían cambiar el INODE en el momento de la transferencia cuando A.log gira a A.CURRENT_DATE_TIME.log. Entonces, para lograr esto, incluimos la opción –inplace y podemos retener el INODE en el rsync y los cambios de INODE en el momento de la rotación del archivo. Sin embargo, ahora nos da un problema diferente donde el nombre del archivo no cambia y siempre permanece A.log. Entonces, una vez que el proceso termina de indexar A.log, se detiene.
Sería fantástico si alguien pudiera sugerir algo que pudiera ayudarnos a lograr los requisitos mencionados.
Saludos, Administrador de middleware Puneet Sinha
Respuesta1
No recomiendo confiar en el inodo. Cambiará cada vez que el archivo se mueva desde la máquina de origen a la de destino. También cambiará si los archivos se restauran a partir de copias de seguridad. Si el sistema de procesamiento de registros depende del inodo, si alguna vez restaura desde copias de seguridad, el sistema no funcionará como esperaba.
Mi recomendación es NO copiar A.log, sino solo copiar A.CURRENT_DATE_TIME.log. Esto simplificará el proyecto.
Sospecho que el sistema de procesamiento de registros en el servidor de destino está mirando el inodo para determinar si el archivo que había visto anteriormente como A.log ahora es A.CURRENT_DATE_TIME.log. Eso no será confiable.
La solución anterior tiene un problema: aumentará el tiempo que tarda en generarse una línea en el archivo de registro hasta que es procesada por el proceso de registro centralizado. Por ejemplo, si A.log tarda 3 días en crecer hasta 100 MB, nada de ese archivo ingresará al proceso de registro centralizado por hasta 3 días. Si los registros no se pueden retrasar más de 2 horas, los rotaría cada 1 hora. De esa manera sabrás que estás dentro del objetivo de 2 horas.