我已经完成了创build两个CentOS 7服务器的任务，不仅数据库将被复制，还有文件。 现在我的问题是，如果不是从几千字节到大约1千兆字节的大小不等的一百万个文件，那么将会有成千上万个文件。
我读过
现在我想问你的经验，如果你一直在使用它或正在使用它们。 性能如何与文件更改有关的复制和删除？ 我非常害怕使用任何rsync，因为我的经验是它有很多小文件不是很快，所以我不能真正使用它来进行实时文件复制。 还是我错了？ 请certificate我错了。 🙂
或者，也许我需要第三和第四台服务器作为文件服务器？ 如果是，那么问题仍然存在：如何在两台服务器之间实时复制文件？
干杯!
如果你的服务器在同一个局域网上，那么集群文件系统（即：GlusterFS）或共享存储解决scheme（即：通过NFS）应该是更好的select。
如果您的服务器位于不同的位置，只有WAN连接，上述解决scheme将无法正常工作。 在这种情况下， 如果您只需要单向复制 （即：从活动服务器到备份服务器），则lsyncd是一个很好的解决scheme。 另一个解决scheme是csync2 。 最后，另一种可能性是使用DRBD + DRBD Proxy （请注意，它的代理组件是一个商业插件）。
最后，如果你的服务器只有WAN连通性，并且需要双向复制 （即：两个服务器同时处于活动状态），基本上不存在银弹。 我会列出一些可能性，但是我远不是推荐一个类似的设置：
psync ，我正是为了解决类似的问题而写的（但是请注意，它有它自己的特性，我不支持它） syncthing （但它有很大的局限性，即它不保留ACL，也不保存文件的所有者/组） 我使用ZFS文件系统，并利用zfs发送/接收框架来利用其块级复制。
我使用一个称为syncoid的便捷脚本，根据需要，以15秒到每小时或每天的间隔执行文件系统的定期同步。
对于您所说的数据集，块级复制将比rsync更干净，更准确。
根据我的经验，分布式文件系统为应用程序提供了简单的复制机制 但是，当目录变得非常大且小文件过多时，它们的性能不佳。 这是预期的，因为他们需要处理来自多个位置/机器的locking/共享访问。
在一些情况下，类似于Rsync的方式提供可接受的复制，并有一些延迟。 它们在读取/写入复制文件夹时不会影响应用程序的性能。
我认为更好的解决scheme是提供从一台服务器访问共享存储（当负担得起）。 另一台备用服务器准备好在第一台服务器出现故障时挂载共享文件夹。 不需要在服务器之间复制任何数据。
欢呼的想法。 我已经检查和testing了所有，我坚持lsyncd。
原因：