使用 s3cmd 在 2 个 s3 存储桶之间同步不起作用

Question

我正在尝试同步 2 个 s3 存储桶。这是我用来在 2 个 s3 存储桶之间同步的命令。

s3cmd sync s3://source-bucket s3://destination-bucket

我在 crontab 中设置它。我已经指定了 s3cmd 的绝对路径。我正在记录操作，但我的日志文件是空的，但这并没有显示任何错误，也没有同步。什么问题。我该如何解决这个问题。

Answer 1

正如我们在 cmets 中发现的，您的问题的解决方案与 here 描述的相同：您的 s3cmd 版本太旧，无法支持 from-bucket to-bucket，解决方法是升级您的版本s3cmd。我很高兴这很容易解决。

但是，您尝试使用此工具执行的操作存在两个非常重要的问题。

s3cmd 实用程序不适合在 cronjob 中用于定期同步两个存储桶，原因有两个：

首先，您需要考虑到工具运行时间过长，以至于 cron 作业在下次到期时再次触发；您在这里遇到的问题是，您可能同时运行 2 个或多个 s3cmd 副本，以尝试同步相同的两个存储桶。在某个时候，随着第二个实例发现越来越多已经同步的东西，它可能会赶上第一个实例，以至于它们都将重新同步大约相同的文件，从而使您将要进行的传输次数增加一倍.

时间线可能如下所示：

...A发现文件不存在，开始同步文件

......B发现文件不存在，也开始同步文件

.........A 完成同步文件

............B 完成同步文件。

假设您没有在存储桶中使用版本化对象，您的数据会很好，但您需要为两倍的请求和两倍的带宽付费。

至少，您的 cron 作业需要调用管理锁定文件的 bash 脚本，以防止多个并发运行。

其次，更严重的是，s3cmd 将无法在此环境中扩展，因为它似乎没有“记忆”每个存储桶中的内容。

例如，我有一个包含 800 万个对象的存储桶。如果我想使用 s3cmd 从存储桶到存储桶进行一次性复制，那没问题。问题是，s3cmd 不会“记住”它之前在您的存储桶中看到的内容，因此第二次以及随后的每一次，它都必须发现并检查一个存储桶中的所有 800 万个文件，然后验证它们是否重新在另一个存储桶中并（可能）验证它们是否是相同的文件，方法是在两个方向上针对每个对象发送HEAD 请求。因此，这种方法无法扩展，并且最终可能会在对 S3 的不必要请求中产生大量成本。

对于我自己的内部系统，我维护存储桶中对象的本地数据库。当我将对象添加到存储桶时，我会在传输成功后使用对象的大小、md5 和其他属性更新数据库。然后，我将所有存储桶都设置为日志记录（进入不同的通用存储桶）。我的系统获取日志文件，解析它们，对于其他进程上传的任何对象（根据日志），我也获取它们的元数据并将其存储在本地数据库中......所以我有一个本地表示S3 中的内容仅延迟了几分钟（日志到达和被发现的等待时间）。

然后，当我需要将存储桶与文件系统或彼此同步时，我可以使用本地数据库来比较内容并决定需要同步哪些文件。当然，我也有一些进程可以审计数据库与 S3 的一致性。

如果您要定期同步两个存储桶，我建议您需要一个比 s3cmd 更复杂的解决方案。

Answer 2

其中一个选项是将两个存储桶挂载为本地目录（例如使用 RiofS）并运行您喜欢的工具来同步两个文件夹。