复制策略深入探讨

在之前的博客中，我们讨论了复制最佳实践和不同类型的复制，例如批量、站点和存储桶。但是，随着所有这些不同类型的复制类型的出现，人们不得不想知道在哪里使用哪种复制策略？从现有 S3 兼容数据存储迁移数据时，您使用 mc mirror 还是 Batch？在集群之间进行复制时，应该使用站点复制还是存储桶复制？

今天我们将揭开这些不同复制策略的神秘面纱，看看在哪种情况下应该使用哪种策略。

从现有源复制

通常，如果您本地驱动器或现有 S3 兼容存储上已有数据，我们建议您使用以下两种方法之一来复制数据。

批量复制：这必须需要 MinIO 或其他 S3 兼容存储（例如 AWS）的现有源。
使用 mc mirror ：这可以是本地目录或 NFS 挂载等。

在详细介绍之前，让我们先看一下一些先决条件。

在 mc 中为 MinIO 集群创建一个名为 miniostore 的 alias 。

bash 复制代码

mc alias set miniostore

在 miniostore 中创建一个存储桶， olderstore 中的数据将传输到其中。

bash 复制代码

mc mb miniostore/mybucket

在 mc 中为 S3 兼容存储中的现有存储桶创建另一个 alias 。

bash 复制代码

mc alias set olderstore

在这种情况下，我们假设 oldstore 中已经有一个名为 mybucket 的存储桶。

让我们看一下如何使用批量复制将数据从现有的 S3 兼容源迁移到 MinIO 存储桶。

为批量复制配置创建yaml

mc batch generate olderstore/ replicate

您应该看到类似于下面的 replication.yaml 文件， source 是 olderstore ，目标是 miniostore 。

复制代码

使用以下命令执行批量复制

sql 复制代码

mc batch start olderstore/ ./replicate.yaml
Successfully start 'replicate' job `E24HH4nNMcgY5taynaPfxu` on '2024-02-04 14:19:06.296974771 -0400 EDT'

使用上面的复制作业 ID（在本例中为 E24HH4nNMcgY5taynaPfxu ），我们可以找到批处理作业的状态。

lua 复制代码

mc batch status olderstore/ E24HH4nNMcgY5taynaPfxu

您可以列出并查找当前正在运行的所有批处理作业的配置。

mc batch list olderstore/

sql 复制代码

mc batch describe olderstore/ E24HH4nNMcgY5taynaPfxu

例如，如果批处理作业使网络饱和并且您需要稍后在流量最少时恢复它，您也可以取消并启动批处理作业。

mc mirror

让我们快速看一下 mc mirror 在这种情况下如何工作。

bash 复制代码

mc mirror --watch olderstore/mybucket miniostore/mybucket

上面的命令与rsync类似。它不仅会将数据从 olderstore 复制到 miniostore ，还会在 olderstore 上查找传入的较新对象，然后将它们复制到 miniostore

您可以比较两个桶，看看数据是否复制成功。

bash 复制代码

mc diff olderstore/mybucket miniostore/mybucket

就这么简单。

哪个是更好的选择？

虽然 mc mirror 看起来简单明了，但我们实际上推荐使用批量复制方法从现有的S3兼容存储中迁移数据，原因有几个。

批量复制在服务器端运行，而 mc mirror 在客户端运行。这意味着批复制拥有运行 MinIO 服务器来执行批处理作业的全部可用资源。另一方面， mc mirror 受到运行命令的客户端系统的瓶颈，因此您的数据会走更长的路线。换句话说，使用批量复制时，跟踪路由将类似于 olderstore -> miniostore ，但使用镜像时，将类似于 olderstore -> mc mirror -> miniostore 。

批处理作业是一次性过程，允许精细控制复制。例如，在运行复制时，如果您发现网络已饱和，您可以取消批量复制作业，然后在流量最少的非工作时间恢复。如果某些对象无法复制，作业将重试多次，以便最终复制对象。

那么批量复制就没有缺点吗？嗯，不是很多。我们在现实世界中看到的一个可能的问题是，有时批量复制很慢而且不是即时的。根据网络传输和速度，与其他方法相比，您可能会发现速度有些慢。话虽这么说，我们仍然建议批量复制，因为它更稳定，并且我们可以更好地控制数据迁移的方式和时间。

复制到另一个站点

一旦 MinIO 集群中有数据，您需要确保将数据复制到另一个站点的另一个 MinIO 集群，以实现冗余、性能和灾难恢复目的。有多种方法可以做到这一点，但在本例中我们讨论以下两种：

站点复制
桶复制

一旦数据进入 MinIO 对象存储集群，它就提供了多种不同的复制和管理数据的可能性。

第一步是设置 3 个相同的 MinIO 集群，并分别将它们命名为 minio1、minio2 和 minio3。我们假设 site1 已使用批量复制将数据迁移到它。

csharp 复制代码

mc alias set minio1 http:// minioadmin minioadmin

mc alias set minio2 http:// minioadmin minioadmin

mc alias set minio3 http:// minioadmin minioadmin

跨所有 3 个站点启用站点复制

csharp 复制代码

mc admin replicate add minio1 minio2 minio3

验证跨 3 个站点的站点复制设置是否正确

mc admin replicate info minio1

使用以下命令检查当前复制状态

lua 复制代码

mc admin replicate status minio1

启用站点复制后，数据将自动开始在所有站点之间复制。根据要传输的数据量、网络和磁盘速度，跨站点同步对象可能需要几个小时到几天的时间。

如果花费的时间比平时更长，或者您仍然没有看到所有内容都已复制，则可以执行 resync 命令，如下所示

sql 复制代码

mc admin replicate resync start minio1 minio2 minio3

可以使用以下命令检查 status

lua 复制代码

mc admin replicate resync status minio1 minio2 minio3

最终所有数据将被复制到 minio2 和 minio3 站点。

桶复制

桶复制，顾名思义，是基于 ARN 在 MinIO 中的特定桶上设置复制。

设置以下两个MinIO别名

来源：

bash 复制代码

mc alias set minio1

目的地：

bash 复制代码

mc alias set minio2

在 minio2 端设置两个别名后，创建一个复制用户 repluser 并在具有权限的 minio2 端存储桶上为此用户设置用户策略执行本策略中列出的操作作为复制的最低要求。

sql 复制代码

mc admin user add minio2 repluser repluserpwd

设置 repluser 运行复制操作所需的最低策略

复制代码

将上面的 replpolicy 附加到 repluser

shell 复制代码

$ mc admin policy add minio2 replpolicy ./replicationPolicy.json
$ mc admin policy set minio2 replpolicy user=repluser

现在这就是有趣的地方。现在您已经在 minio2 集群上创建了复制用户 (repluser) 和复制策略 (replpolicy)，您需要在 minio1 上实际设置存储桶复制目标。这还没有启动存储桶复制，它只是为稍后我们实际启动该过程时进行设置。

bash 复制代码

$ mc replicate add minio1/srcbucket https:/repluser:repluserpwd@replica-endpoint:9000/destbucket --service "replication" --region "us-east-1"

Replication ARN = 'arn:minio:replication:us-east-1:28285312-2dec-4982-b14d-c24e99d472e6:destbucket'

最后，让我们开始复制过程。

shell 复制代码

$ mc replicate add minio1/srcbucket --remote-bucket https:/repluser:repluserpwd@replica-endpoint:9000/destbucket

现在，上传到源存储桶且满足复制条件的任何对象都将由 MinIO 服务器自动复制到远程目标存储桶。通过禁用配置中的特定规则或完全删除复制配置，可以随时禁用复制。

哪个是更好的选择？

那么，为什么我们不能对所有事情都使用站点到站点复制，而为什么我们需要使用批量复制呢？批量复制提供了对复制过程的更多控制。当您第一次启动站点复制时，请将其视为消防水带，一旦启动，站点复制过程就有可能使用网络上的所有可用网络带宽，达到其他应用程序无法使用网络吞吐量的程度。另一方面，虽然有时批量复制可能很慢，但它不会在初始数据传输期间中断您的现有网络。当您只想复制少数存储桶而不是整个集群时，存储桶复制通常很有用。

好的，那么站点复制呢？批量复制对于连续复制来说并不理想，因为一旦批量作业结束，它就不会复制任何新对象。因此，您必须以一定的时间间隔重新运行批量复制作业，以确保增量复制到 minio2 站点。另一方面，如果您有主动-主动复制设置，站点复制允许将数据从 minio1 复制到 minio2 ，反之亦然。

不可能同时启用存储桶和站点复制，您必须选择其中之一。因此，通常除非您只想复制特定存储桶中的某些存储桶或某些对象，否则我们强烈建议使用站点复制，因为它不仅会复制现有存储桶和对象，还会复制创建的任何新存储桶/对象。此外，无需太多配置，您就可以以分布式方式设置复制，北美可以有 minio1 ，非洲可以有 minio2 ，这样 MENA（中东和北非）区域就会添加数据 minio2 和北美地区将向 minio1 添加数据，并且它们将相互复制。

最后的想法

在这篇文章中，我们深入探讨了存储桶、批量和站点复制类型。虽然没有固定的规则来使用特定的复制策略，但我们 SUBNET 的工程师在处理了无数的集群设置、迁移它们、扩展它们、考虑灾难恢复场景之后，我们的工程师提出了上述复制策略，这应该对大多数人有帮助人们正在考虑将数据迁移到 MinIO。

如果您对复制或最佳实践有任何疑问，请联系我们。