我们有2台Drupal服务器可以read/write同一文件夹的副本（对于那些对Drupal有一些了解的人来说，这些sites/default/files夹就是sites/default/files夹）。 这两个文件夹应该同步。 我一直在寻找一些select，这是我发现的：
选项1：Rsync两种方式：不是一个选项
您将需要运行rsync两种方式，因为这两个文件夹被修改。 只要文件被修改，一切正常，因为你可以使用-u标志检查更新时间，只修改源是否比目标更新。 但是，因为rsync没有保存被删除的文件的历史logging，当rsync不知道如何处理被删除的文件时，是否应该保留在另一边，因为最近更新或丢弃以及。
选项2：networking共享：正常，但I / O等待性能问题
一种select是设置networking共享，消除同步的需要。 缺点是I / O等待，因为两个服务器都将在同一个磁盘上read/write 。
选项3：具有主副本的第三台服务器：正常，但潜在的性能/竞争条件问题另一种select是让第三台服务器保留该文件夹的主副本。 每当在一台Drupal服务器上进行更改时，Drupal服务器文件夹就会被rsync到主副本，从而避免了选项1中出现的问题。但是，为了实现这个function，需要按照顺序将更改同步到主副本在Drupal服务器上发生，提出了以下问题：
– P1 ：如果您同步到每个更改所做的更改和频繁更改您的服务器可以安静繁忙的同步过程
– P2 ：即使您按顺序启动同步作业，由于各种元素（进程的执行速度，networking延迟等），您不能保证文件最终将在主副本上同步。
Q1：如何解决问题P1和P2？
问题2：是否有其他方法来保持2个远程文件夹同步？
附加信息：
server OS: Ubuntu server 10.04 LTS Drupal v: Drupal 6.X Size of sites/default/files: 4.5G
我testing了Unison ，它不能像我期望的删除文件一样工作：
[1]build立目录
FOLDER1 FOLDER2 file1 (new) (empty)
[2]运行Unison（ unison FOLDER1 FOLDER2 ）
FOLDER1 FOLDER2 file ----> file1
=> file1从FOLDER1复制到FOLDER2
[3]更新目录
FOLDER1 FOLDER2 file1 (removed) file1 (modified)
[4]再次运行Unison（ unison FOLDER1 FOLDER2 ）
FOLDER1 FOLDER2 deleted <-?-> changed file1 [] No default command [type '?' for help]
此时， Unison不知道是否应从FOLDER2删除file1或将其复制到FOLDER1 。 我希望Unison做后者：
-at [2]我们知道两个文件夹中file1的最后修改/访问时间，并将它们复制到Unison存档中。
在文件[4]中，我们看到file1从文件FOLDER1丢失，因此删除的时间应该是存档的最后可用时间（即在[2]中获得的时间）。
-at [4]我们也看到FOLDER2中file1最后修改/访问时间大于FOLDER2 [2]，所以file1应该从FOLDER2复制到FOLDER1 。
我一直在尝试使用不同的开关，例如-auto （自动接受默认动作）和-batch （批处理模式：根本不要问），但Unison无法自行做出决定。
问：根据我所描述的行为，是否有办法让Unison或其他工具执行？
是否需要使用2份Drupal？ Drupal对每个页面请求做了很多查询，多个Drupal前端共享一个远程数据库后端可能是一个相当大的性能损失。
你有没有考虑使用多个caching前端和单个drupal +数据库后端？ Pressflow是Drupal的增强版，内置了memcached和Varish（caching前端）。
我认为你过分复杂的问题。 所有你需要的是有像NFS一样的东西。 所以，一台服务器将在本地访问该文件夹，另一台服务器将通过NFS远程访问它。 我不认为NFS是如此慢，特别是如果两个服务器在相同的子网内相邻。
另一个select是在磁盘级别上使用复制，如DRBD 。
使用这样的解决scheme，您可以消除以两种方式手动同步更改的需要。
要解决您的两个问题，请使用unison。 基于rsync并解决了删除文件的问题。
我们在类似的情况下使用Gluster （Ruby应用程序，而不是Drupal）。 在你的情况下，这两台机器将是gluster服务器和客户端。 Drupal安装将指向共享，如客户端configuration所示。 共享上的文件操作在整个群集中传播，并且应该对一个节点失败具有恢复能力。
是的，gluster的I / O性能不会像物理上那么好，但是我不确定在给定你的设置的情况下你将如何解决这个问题。
正如@Khaled简要介绍的那样，您可以使用DRBD来做到这一点。
每个节点都有自己的数据本地副本（所以读取速度与本地磁盘一样快）; 您可以对其进行configuration，以便写入阻塞，直到数据写入其他节点上的磁盘（因此存在延迟取决于networking的速度，但所有客户端都将看到文件的一致视图）。