我有一大组数据（+100 GB），可以将其存储到文件中。大多数文件大小在 5k-50k 范围内（80%），然后是 50k - 500k（15%）和 >500k（5%）。文件的最大预期大小为 50 MB。如有必要，可以将大文件拆分成较小的部分。文件也可以按目录结构进行组织。
如果必须修改某些数据，我的应用程序会复制一份，修改它，如果成功，则将其标记为最新版本。然后，旧版本将被删除。它可以防止崩溃（可以这么说）。
我需要实现一个故障转移系统来保证这些数据可用。一种解决方案是使用主从数据库系统，但这些系统很脆弱，而且会强制依赖数据库技术。
我不是系统管理员，但我读过有关 rsync 指令的文章。它看起来非常有趣。我想知道设置一些故障转移节点并从我的主节点使用 rsync 是否是一个负责任的选择。有人曾经成功尝试过吗？
i) 如果是，我应该拆分大文件吗？rsync 在检测要复制/删除哪些文件方面是否智能/高效？我是否应该实现特定的目录结构以使此系统高效？
ii) 如果主服务器崩溃并且从服务器接管一个小时（例如），那么让主服务器再次更新是否像反向运行 rsync 一样简单（从从服务器到主服务器）？
iii) 附加问题：是否有可能使用 rsync 实现多主系统？还是只能实现主从？
我正在寻找建议、技巧、经验等...谢谢！！！
答案1
rsync 是否可以智能/高效地检测要复制/删除哪些文件？
Rsync 在检测和更新文件方面非常高效。 取决于你的文件如何变化，您可能会发现，与大量小文件相比，少量大文件更容易同步。根据您选择的选项，每次运行时，它都会对两端的每个文件执行 stat()，然后如果文件不同，则传输更改。如果只有少量文件发生变化，那么查找已更改文件的这一步骤可能会非常昂贵。很多因素都会影响 rsync 所需的时间。如果您真的想尝试一下，您应该对真实数据进行大量测试，以了解其工作原理。
如果主服务器崩溃并且从服务器接管一个小时（例如），那么让主服务器再次保持最新状态是否像反向运行 rsync 一样简单（从从服务器到主服务器）？
应该。
是否有可能使用 rsync 实现多主系统？
Unison 使用 rsync 库，允许双向同步。它应该允许任一端进行更新。使用正确的选项，它可以识别冲突并保存两端发生更改的任何文件的备份。
在不了解具体细节的情况下，我无法自信地告诉你这是可行的方法。你可能需要看看 DRBD，或者一些其他集群设备/文件系统方法，它们将在较低级别同步事物。
答案2
我应该分割我的大文件吗？
rsync 很智能，但同步非常大的文件时效率会大大降低。原因如下：
如果文件只有一部分发生变化，那么 rsync 会非常智能地只发送这一部分。但要确定要发送哪一部分，它必须将文件划分为 X 字节的逻辑块，为每个块（两侧）建立校验和，比较这些块，发送差异，然后在接收端重建文件。
另一方面，如果您有一堆不变的小文件，那么日期和大小将匹配，rsync 将跳过校验和步骤，并假设文件没有改变。如果我们谈论的是许多 GB 的数据，那么您将跳过大量 IO，并节省大量时间。因此，即使比较更多文件会产生额外开销，但它仍然比实际所需的时间要少读文件并比较校验和。
因此，虽然您希望文件数量尽可能少，但您也希望文件数量足够多，这样您就不会在处理未改变的数据时浪费大量 IO。我建议按照应用程序使用的逻辑边界拆分数据。
让 master 再次保持最新状态就像反向运行 rsync 一样简单
从文件系统的角度来看，是的。但是您的应用程序可能有其他要求，这会使事情变得复杂。当然，您将恢复到您 rsync 到从属服务器的最新检查点。
是否有可能使用 rsync 实现多主系统？
从技术上讲是的，但这样做很疯狂。假设一切顺利，那么一切都会好起来。但是当出现问题时，您可能会开始遇到更改问题（并特别删除) 同步方向错误，用坏文件覆盖好文件，或者删除插入的文件，或者删除的文件的影子再次出现。大多数人建议不要这样做，但如果你愿意，你可以尝试一下。
建议、提示、经验
如果您正在寻找具有即时同步功能的 master/master 设置，我推荐 DRBD。它的设置和维护要复杂得多，但功能更强大。它对磁盘本身进行块级同步，而不是对磁盘上的文件进行同步。要“在线”执行此操作，您需要一个可以容忍此类同步的文件系统，例如 GFS。
Rsync 更像是一个快照系统，而不是持续同步系统。