Quais opções de rsync usar para o cenário mencionado abaixo?

Question

Saudações !!!

Trata-se de um requisito específico sobre o rsync que estamos tentando alcançar. Nós tentamos conseguir isso usando várias opções de rsync. No entanto, estamos encontrando problemas diferentes com diferentes opções de rsync.

Antecedentes: • Temos um processo (em execução no AIX) dos quais os logs estão sendo registrados em A.log (presente no diretório logs). • A.log é rotacionado para A.CURRENT_DATE_TIME.log quando atinge 100 MB e o novo A.log é criado. • Estamos transferindo esses logs para um servidor centralizado usando o rsync. Estamos usando o rsync no diretório de logs completo. • INODE dos arquivos no servidor de origem e no servidor de destino são diferentes. • Uma vez que os logs estão no servidor centralizado, a idéia é fazer com que esses logs sejam lidos / indexados por um processo de registro centralizado que selecionará a entrada desse servidor centralizado.

Problema: • Embora, A.log (servidor de destino) seja dado como entrada para o processo de registro centralizado, ele considera o INODE do arquivo e não o nome do arquivo real. • Assim, quando o arquivo A.log é transferido, o novo A.log tem um novo INODE, que não é detectado pelo processo centralizado. Isso estava acontecendo quando estávamos usando as opções -u –r –t com o rsync. Então, neste caso, o INODE do arquivo estava mudando a cada vez que o rsync acontecia e também quando o rollover acontecia. Assim, o processo pára de indexar à medida que procura o antigo INODE que não está presente.

• A idéia é usar o rsync com uma combinação de opções que não alterariam o INODE do arquivo no momento do rsync, mas deve alterar o INODE no momento da sobreposição quando A.log for rotacionado para A.CURRENT_DATE_TIME.log . Assim, para conseguir isso, incluímos a opção –inplace e podemos manter o INODE nas alterações de rsync e INODE no momento da rotação do arquivo. No entanto, isso nos dá um problema diferente agora, onde o nome do arquivo não muda e sempre permanece A.log. Então, quando o processo é feito indexando o A.log, ele pára.

Seria ótimo se alguém pudesse sugerir algo que pudesse nos ajudar a alcançar os requisitos mencionados.

Atenciosamente, Puneet Sinha Middleware Administrator

    

Answer 1

Eu não recomendo confiar no inode. Ele será alterado sempre que o arquivo for movido da origem para a máquina de destino. Ele também mudará se os arquivos forem restaurados dos backups. Se o sistema de processamento de logs depender do inode, se você restaurar de backups, o sistema não funcionará como esperado.

Minha recomendação é NÃO copiar A.log, mas apenas copiar A.CURRENT_DATE_TIME.log. Isso simplificará o projeto.

Eu suspeito que o sistema de processamento de logs no servidor de destino esteja olhando para o inode para determinar se o arquivo que ele tinha visto anteriormente como A.log agora é A.CURRENT_DATE_TIME.log. Isso não será confiável.

A solução acima tem 1 problema: O tempo que leva para uma linha no arquivo de log a ser gerada quando ela é processada pelo processo de log centralizado aumentará. Por exemplo, se levar 3 dias para o A.log crescer para 100 MB, nada do arquivo entrará no processo de registro centralizado por até 3 dias. Se os logs não puderem ser atrasados em mais de duas horas, eu rotacionaria os logs a cada 1 hora. Dessa forma, você sabe que está dentro do objetivo de 2 horas.