同步存储服务器

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

当检查一个或两个文件属性时，Rsync可能会花费很多时间检查所有文件中的更改。

我们做了类似的事情，但规模要小得多，要在两台服务器之间同步照片。 我写了一个bash脚本，它维护一个文件的sortingregistry，连同文件创build时间和文件大小。 每次脚本运行时，它都会检查我们从源服务器同步的服务器，并生成与创build时间和文件大小连接的文件的sorting列表。 然后我使用comm命令来比较这两个registry，并只打印出现在源服务器上的条目。 这是必须同步到新服务器的文件列表。

然后我只是scp新的文件。 我有一些陷阱，locking和节stream在那里，所以它不会压倒东西，但它的工作原理和相当快。

好的是，如果你已经在这两个地方都有很多的文件，你不必同步所有的东西。 只要在目标服务器上创build一个初始registry，然后cron了脚本，它就会开始同步。 如果您最终需要同步一个您从来没有想过的文件，那么您只需在源服务器上触摸它（更改date信息），并在下一次计划运行时同步。

所以对于一个如下所示的目录：

-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 

这个列表被脚本转换成一个如下所示的registry文件：

 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 

我将该registry（源服务器的文件）存储在目标服务器上。 每当cron作业在目标服务器上运行时，我都会使用相同的格式创build源服务器上当前文件的列表。 假设列表中出现了一些新的文件，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 

当前的文件registry将如下所示：

 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 

对旧的registry和当前的registry运行comm ，并切出第一个字段（需要复制的文件），如下所示：

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

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

 10.JPG 11.JPG 

然后通过一个循环来处理文件列表。

上面的comm命令基本上是说给我看第一个文件中只存在的所有东西。 它做的比较也非常快。 毕竟它只是比较文本文件中的行; 即使该文件非常大。 幸运的是，你已经使用一些关于你的文件的基本元数据填充了这个文本文件，并且通过通讯来快速地比较这些数据。

将元数据填充到列表中的好处是，它将允许文件在同步之间发生变化的情况。 说出现新版本的文件，或者旧版本出现问题。 该文件的名称将存在于旧的registry中，但其元数据（文件创build时间戳和大小）将不同。 所以目前的文件registry将显示差异和通信比较将说，该信息只存在于第一个文件。 当您创build要复制的文件列表时，该文件名将位于此处，并且您的复制命令将覆盖具有相同名称的过期文件。

其余的只是细节：

• 使用文件locking/信号量，以便如果上次运行的脚本下次运行时没有运行，则脚本不会运行。
• 使用临时文件来存储您当前的文件列表和您的进程列表，然后使用陷阱清理脚本退出。
• 完成后，将当前文件列表复制到旧文件列表中，以备下一次比较，但只有在registry中有文件时才执行此操作（否则，您将复制空白registry并同步所有下次）。

希望有所帮助。 这很适合我们的情况，但是和所有的事情一样，在你的组织或者设置的约束下可能不起作用。 祝你好运，至less它可以给你一些想法。

以下是一些可供select的选项。

如果您不需要同时访问两个副本，请查看DBRD 。 这是由于文件系统的限制，而不是DBRD的限制，如果需要的话，有几个解决方法可以访问二进制副本。 但是这个项目最近被纳入了内核，所以对这个前进的支持应该是非常简单的。

另一种select是像GlusterFS这样的文件系统。 可以设置2个节点的复制configuration 。 我认为这将是理想的，因为它应该允许更好的故障转移和可扩展性。 MondoDB对于使用GridFS的这种东西也很有趣，但是它有点新。