我有一大堆可存储到文件中的数据（+ 100 GB）。 大部分文件将在5k-50k范围内（80％），然后是50k-500k（15％）和> 500k（5％）。 文件的最大预期大小是50 MB。 如有必要，可以将大文件分割成更小的块。 文件也可以组织在目录结构中。
如果一些数据必须修改，我的应用程序会复制，修改它，如果成功，将其标记为最新版本。 然后，旧版本被删除。 它是安全的（可以这么说）。
我需要实现一个故障转移系统来保存这些数据。 一种解决scheme是使用主 – 从数据库系统，但是这些系统是脆弱的，并且依赖于数据库技术。
我不是系统pipe理员，但我读了关于rsync指令。 它看起来很有趣。 我想知道是否设置一些故障转移节点，并从我的主人使用rsync是一个负责任的select。 有没有人试过这个成功？
如果是的话，我应该分割我的大文件吗？ 是rsync智能/高效地检测哪些文件复制/删除？ 我应该实现一个特定的目录结构，使这个系统高效？
ii）如果主服务器崩溃并且一个从服务器接pipe了一个小时（例如），那么是否使主服务器再次像最新一样运行rsync（从服务器到主服务器）那么简单？
iii）奖金问题：是否有可能使用rsync实现多主系统？ 或者只有主人奴隶可能？
我正在寻找build议，提示，经验等…谢谢！
是rsync智能/高效地检测哪些文件复制/删除？
Rsync在检测和更新文件方面非常高效。 根据您的文件如何更改 ，您可能会发现较小数量的大文件更容易同步，然后很多小文件。 根据您select的选项，在每次运行时，它将stat（）两端的每个文件，然后在文件不同时传输更改。 如果只有less数文件正在更改，那么查找更改文件的步骤可能会相当昂贵。 有很多因素影响了rsync需要多长时间。 如果你认真对待这个问题，你应该对真实的数据进行大量的testing，看看事情是如何工作的。
如果主服务器崩溃，并且从服务器接pipe了一个小时（例如），那么是否使主服务器再次像最新一样运行rsync（从服务器到主服务器）那么简单？
应该。
有使用rsync实现多主系统的可能性吗？
Unison，使用rsync库允许双向同步。 它应该允许任何一方更新。 有了正确的选项，它可以识别冲突并保存在两端进行更改的任何文件的备份。
在不了解细节的情况下，我不能完全明确地告诉你，这是要走的路。 您可能需要查看DRBD，或其他一些集群设备/文件系统方法，这些方法可以在较低级别同步事物。
我应该分割我的大文件吗？
rsync是智能的，但是非常大的文件可能会大大降低同步的效率。 原因如下：
如果只有文件的一部分发生变化，那么rsync足够聪明，只能发送该部分。 但要确定要发送哪个部分，必须将该文件划分为X个字节的逻辑块，为每个块build立校验和（在两边），比较块，发送差异，然后重新构造文件接收端。
另一方面，如果你有一堆没有改变的小文件，date和大小将会匹配，rsync会跳过校验和步骤，只是假定文件没有改变。 如果我们谈论的是很多GB的数据，那么你会跳过很多IO，节省很多时间。 因此，即使比较更多的文件需要额外的开销，但仍然会less于实际读取文件和比较校验和所需的时间。
所以，尽可能less的文件需要，你也想要足够的文件，这样你就不会浪费大量的IO工作在不变的数据上。 我build议根据您的应用程序使用的逻辑边界来分割数据。
使主机再次如同运行rsync一样简单
从文件系统的angular度来看，是的。 但是，您的应用程序可能有其他要求，使事情复杂化。 而且，当然，你将恢复到最近的一个检查点，在这个检查点你同步到你的奴隶。
有使用rsync实现多主系统的可能性吗？
技术上是的，但是走下去的路是疯狂的。 假设一切都很好，那么一切都会好的。 但是当打嗝的时候，你可能会开始遇到改变（ 特别是删除 ）同步错误的方向，用不好的方法覆盖你的好文件，或者删除你插入的文件，或者重新出现被删除文件的鬼魂。 大多数人都反对，但是如果你喜欢，你可以试试。
build议，提示，经验
如果你正在寻找一个主动/主动设置与即时同步，我build议DRBD。 build立和维护起来要复杂得多，但function要强大得多。 它会对磁盘本身进行块级别的同步，而不是其上的文件。 要做到这一点“在线”，你需要一个可以容忍这种types的同步的文件系统，如GFS。
Rsync比连续同步系统更像快照系统。