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