如果必须修改某些数据,我的应用程序会复制,修改它,如果成功,则将其标记为最新版本.然后,删除旧版本.这是安全的(可以这么说).
我需要实现故障转移系统以保持这些数据的可用性.一种解决方案是使用主从数据库系统,但这些系统很脆弱并且强制依赖于数据库技术.
我不是系统管理员,但我读到了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或其他一些将在较低级别同步事物的集群设备/文件系统方法.
