同步存储服务器

如果您只是使用手卷脚本检查文件创建时间（可能还有大小）并将其与已同步到备份服务器的文件列表（或注册表）进行比较，您可能会看到性能有所提高。

当检查一个或两个文件属性可能就足够时，Rsync 可能会花费大量时间检查所有文件中的更改。

我们做了类似的事情，但规模要小得多，以在两台服务器之间同步照片。我编写了一个 bash 脚本，该脚本维护一个排序的文件注册表，这些注册表与文件创建时间和文件大小连接在一起。每次脚本运行时，它都会检查我们从中同步的服务器（源服务器）并生成一个排序的文件列表，其中包含创建时间和文件大小。然后，我使用comm命令比较这两个注册表并仅打印出现在源服务器上的那些条目。这是必须同步到新服务器的文件列表。

然后我只是 scp 新文件。我有一些陷阱，锁定和节流，这样它就不会压倒东西，但它可以工作并且非常快。

好消息是，如果您在两个地方都已经有很多文件，则不必同步所有内容即可开始。只需在目标服务器上创建一个初始注册表，然后 cron 启动脚本，它将从该点开始同步。如果您最终需要同步一个您从未想过的文件，您所要做的就是在源服务器上触摸它（更改日期信息），它将在下一次计划运行时同步。

所以对于一个看起来像这样的目录：

-rw-r----- 1 example example  38801 2010-01-21 11:45 1.JPG
-rw-r----- 1 example example  38801 2010-01-21 11:45 2.JPG
-rw-r----- 1 example example 757638 2010-01-21 11:45 3.JPG
-rw-r----- 1 example example  16218 2010-01-22 15:07 9.JPG

此列表由脚本转换为如下所示的注册表文件：

1.JPG_2010-01-21_11:45_38801
2.JPG_2010-01-21_11:45_38801
3.JPG_2010-01-21_11:45_757638
9.JPG_2010-01-22_15:07_16218

我将该注册表（源服务器的文件）存储在目标服务器上。每次 cron 作业在目标服务器上运行时，我都会使用相同格式创建源服务器上当前文件的列表。假设列表中出现了一些新文件，10.JPG 和 11.JPG。

-rw-r----- 1 example example  38801 2010-01-21 11:45 1.JPG
-rw-r----- 1 example example  38801 2010-01-21 11:45 2.JPG
-rw-r----- 1 example example 757638 2010-01-21 11:45 3.JPG
-rw-r----- 1 example example  16218 2010-01-22 15:07 9.JPG
-rw-r----- 1 example example  16218 2010-02-24 11:00 10.JPG
-rw-r----- 1 example example  16218 2010-02-24 11:00 11.JPG

当前文件注册表将如下所示：

1.JPG_2010-01-21_11:45_38801
2.JPG_2010-01-21_11:45_38801
3.JPG_2010-01-21_11:45_757638
9.JPG_2010-01-22_15:07_16218
10.JPG_2010_02_24_11:00_16218
11.JPG_2010_02_24_11:00_16218

对旧注册表和当前注册表运行comm并删除第一个字段（需要复制的文件），如下所示：

comm -23 ${CURRENT_REG} ${OLD_REG} | cut -d'_' -f1 > ${SYNC_LIST}

将生成需要复制（我使用 scp）到备份（目标）服务器的文件列表（每行一个）：

10.JPG
11.JPG

然后，您只需通过循环处理该文件列表。

上面的comm命令基本上是在告诉我只存在于第一个文件中的所有内容。它进行的比较也非常快。毕竟只是比较文本文件中的行。即使该文件非常大。幸运的是，您已经使用有关文件的一些基本元数据填充了该文本文件，并且通过comm非常快速地比较了这些数据。

将元数据填充到列表中的好处在于，它将允许文件在同步之间发生更改的情况。假设有新版本的文件出现，或者旧版本有问题。文件的名称将存在于旧注册表中，但其元数据（文件创建时间戳和大小）会有所不同。因此，当前文件注册表将显示该差异，并且comm比较将表明该信息仅存在于第一个文件中。当您创建要复制的文件列表时，该文件名将在那里，并且您的复制命令将覆盖具有相同名称的过时文件。

剩下的只是细节：

• 使用文件锁定/信号量，这样如果上次运行的脚本在下次运行时没有完成，您就不会让脚本自行运行。
• 使用临时文件存储当前文件列表和进程列表，然后在脚本退出时使用陷阱清理它们。
• 完成后，将当前文件列表复制到旧文件列表上，以便为下一次比较做好准备，但只有在注册表中有文件时才这样做（否则，您将复制一个空注册表并同步所有内容下次）。

希望有帮助。这非常适合我们的情况，但与所有事情一样，在您的组织或设置的限制下可能无法正常工作。祝你好运，至少它可能会给你一些想法。

以下是一些可供研究的选项。

如果您不需要同时访问两个副本，请查看DBRD 。这是由于文件系统限制而不是 DBRD 的限制，如果需要，有一些变通方法可以访问第二个副本。但是该项目最近被内核接受，因此对它的支持应该非常简单。

另一种选择是文件系统，例如GlusterFS。可以设置一个 2 节点复制配置。我认为这将是理想的，因为它应该允许更好的故障转移和可扩展性。MondoDB 也对使用他们的 GridFS 的这类东西感兴趣，但它有点新。