rsync是故障转移实现(非常大的数据集)的良好候选者吗？

发布时间：2020-12-13 16:52:49 所属栏目：Linux 来源：网络整理

导读：我有一大堆数据(100 GB),可以存储到文件中.大多数文件将在5k-50k范围内(80％),然后是50k-500k(15％)和 500k(5％).文件的最大预期大小为50 MB.如有必要,可以将大文件拆分为较小的文件.文件也可以在目录结构中组织. 如果必须修改某些数据,我的应用程序会复制,

我有一大堆数据(100 GB),可以存储到文件中.大多数文件将在5k-50k范围内(80％),然后是50k-500k(15％)和> 500k(5％).文件的最大预期大小为50 MB.如有必要,可以将大文件拆分为较小的文件.文件也可以在目录结构中组织.

如果必须修改某些数据,我的应用程序会复制,修改它,如果成功,则将其标记为最新版本.然后,删除旧版本.这是安全的(可以这么说).

我需要实现故障转移系统以保持这些数据的可用性.一种解决方案是使用主从数据库系统,但这些系统很脆弱并且强制依赖于数据库技术.

我不是系统管理员,但我读到了rsync指令.它看起来很有趣.我想知道是否设置一些故障转移节点并从我的主站使用rsync是一个负责任的选项.有没有人在成功之前试过这个？

i)如果是,我应该拆分我的大文件吗？ rsync是否智能/高效地检测要复制/删除的文件？我应该实现特定的目录结构来使这个系统高效吗？

ii)如果主站崩溃并且从站接管了一个小时(例如),那么让主站再次更新就像运行rsync一样简单(从站到主站)？

iii)奖金问题：是否有可能使用rsync实现多主系统？或者只有主奴隶可能吗？

我正在寻找建议,提示,经验等…谢谢！

解决方法

Is rsync smart/efficient at detecting which files to copy/delete?

Rsync在检测和更新文件方面非常有效.根据文件的更改方式,您可能会发现较少数量的大文件比大量小文件更容易同步.根据您选择的选项,在每次运行时,它将转到stat()两侧的每个文件,然后在文件不同时传输更改.如果只有少量文件正在更改,那么查找已更改文件的此步骤可能非常昂贵.关于rsync需要多长时间,有很多因素可以发挥作用.如果你认真考虑这个,你应该对真实数据进行大量测试,看看事情是如何运作的.

If the master crashes and a slave takes over for an hour (for example),is making the master up-to-date again as simple as running rsync the other way round (slave to master)?

应该.

Is there any possibility of implementing multi-master systems with rsync?

使用rsync库的Unison允许双向同步.它应该允许任何一方的更新.使用正确的选项,它可以识别冲突并保存任何在两端进行更改的文件的备份.

如果不了解更多有关具体细节的信息,我无法自信地告诉你,这是要走的路.您可能需要查看DRBD或其他一些将在较低级别同步事物的集群设备/文件系统方法.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!