问候 ！！！
这是关于我们试图实现的有关rsync的具体要求。 我们试图通过使用各种rsync选项来实现这一点。 但是，我们遇到不同的rsync选项的问题。
背景：•我们有一个进程（在AIX上运行）日志logging在A.log（在日志目录中）。 ？A.log一旦达到100 MB，就会被转到A.CURRENT_DATE_TIME.log，并创build新的A.log。 •我们正在使用rsync将这些日志传输到中央服务器。 我们在完整的日志目录上使用rsync。 •源服务器和目标服务器上的文件的INODE不同。 •一旦日志位于中央服务器中，就意味着通过集中式日志进程读取/索引这些日志，这将从该中央服务器中selectinput。
问题：•尽pipeA.log（目标服务器）作为集中日志进程的input，但它考虑文件的INODE而不是实际的文件名。 所以，当A.log文件被翻转时，新的A.log有一个新的INODE，这个集中过程没有检测到。 当我们在rsync中使用-u -r -t选项时，就发生了这种情况。 所以在这种情况下，文件的INODE随着每次发生rsync而发生变化，并且在发生翻转时也是如此。 因此，该进程停止索引，因为它查找不存在的旧INODE。
•想法是使用rsync和rsync，这些选项不会在rsync时改变文件的INODE，但在A.log旋转到A.CURRENT_DATE_TIME.log时应该在翻转时更改INODE。 所以，为了达到这个目的，我们包含了-inplace选项，并且我们能够在文件旋转时保留rsync和INODE变化的INODE。 但是，现在文件名不变，现在又给了我们一个不同的问题，并始终保持A.log。 所以一旦这个过程完成了A.log的索引，它就会暂停。
如果有人能提出一些可以帮助我们实现上述要求的东西，那将是非常好的。
问候，Puneet辛哈中间件pipe理员
我不build议依靠inode。 只要文件从源文件移动到目标机器，文件就会改变。 如果文件从备份中恢复，它也会改变。 如果日志处理系统依赖inode，如果您从备份中恢复，系统将无法按预期工作。
我的build议是不复制A.log，但只复制A.CURRENT_DATE_TIME.log。 这将简化项目。
我怀疑目标服务器上的日志处理系统正在查看inode，以确定它以前看作A.log的文件是否为A.CURRENT_DATE_TIME.log。 这不会是可靠的。
上面的解决scheme有一个问题：日志文件中的行被生成到集中日志进程处理的时间将增加。 例如，如果A.log需要3天的时间才能增长到100 MB，那么该文件的任何内容都不会进入集中式日志过程长达3天。 如果日志不能被延迟超过2个小时，那么我会每隔1小时轮换日志。 这样你就知道你在2小时内的目标。