擦除码计算器 
参考硬件 复制策略深入探讨
在之前的博文中，我们讨论了复制最佳实践以及不同类型的复制，例如批量、站点和桶。但是，面对这么多不同的复制类型，人们不禁要问，在什么情况下应该使用哪种复制策略？从现有的 S3 兼容数据存储迁移数据时，您是使用mc mirror还是批量复制？在集群之间复制时，应该使用站点复制还是桶复制？
今天，我们将揭开这些不同复制策略的神秘面纱，看看在哪些场景下应该使用哪种策略。
从现有源复制
通常，如果您已经拥有现有的数据（无论是在本地驱动器上还是在现有的 S3 兼容存储中），我们建议使用以下两种方法之一来复制数据。
- 批量复制：此方法需要一个现有的源，该源可以是 MinIO 或其他 S3 兼容存储（例如 AWS）。
- 使用
mc mirror：这可以是本地目录或 NFS 挂载等。
在我们详细介绍之前，让我们先了解一些先决条件。
在mc中为 MinIO 集群创建一个名为miniostore的别名。
在miniostore中创建一个桶，将来自olderstore的数据传输到该桶。
在mc中为 S3 兼容存储中现有的桶创建另一个别名。
在本例中，我们将假设olderstore中已经存在一个名为mybucket的桶。
批量复制
让我们看看如何使用批量复制将数据从现有的 S3 兼容源迁移到 MinIO 桶。
创建批量复制配置的 yaml 文件
您应该会看到一个类似于以下内容的replication.yaml文件，source是olderstore，target是miniostore。
使用以下命令执行批量复制
使用上面的复制作业 ID（在本例中为E24HH4nNMcgY5taynaPfxu），我们可以找到批量作业的状态。
您可以列出并查找当前正在运行的所有批量作业的配置。
您也可以取消和启动批量作业，例如，如果它使网络饱和，并且您需要在流量最少的时候恢复它。
Mc Mirror
让我们快速了解一下在这种情况下mc mirror是如何工作的。
以上命令类似于 rsync。它不仅会将数据从olderstore复制到miniostore，还会查找olderstore上出现的较新对象，然后将它们复制到miniostore。在版本化和非版本化桶上，批量作业有一些细微差别。如果源/目标之一是 S3 兼容源，则批量作业的工作方式与 mirror 相同，并且仅复制最新版本。但是，版本 ID 将不会保留。
您可以比较这两个桶，以查看数据是否已成功复制。
就这么简单。
哪个选项更好？
虽然mc mirror看起来简单直观，但我们实际上建议使用批量复制方法从现有的 S3 兼容存储迁移数据，原因有很多。
批量复制在服务器端运行，而 `mc mirror` 在客户端运行。这意味着批量复制可以使用 MinIO 服务器运行的所有资源来执行其批处理作业。另一方面，`mc mirror` 受运行该命令的客户端系统的限制，因此您的数据将走更长的路线。换句话说，使用批量复制，跟踪路由将类似于 `olderstore -> miniostore`，但使用镜像则类似于 `olderstore -> mc mirror -> miniostore`。
批处理作业是一次性进程，允许对复制进行精细控制。例如，在运行复制时，如果您发现网络正在饱和，则可以取消批量复制作业，并在稍后在流量最少的时间（例如非高峰时段）恢复。如果某些对象复制失败，该作业将重试多次，以便最终复制这些对象。
那么批量复制没有缺点吗？其实也没有很多。我们在现实世界中看到的一个可能的问题是，有时批量复制速度很慢，不是即时的。根据网络传输和速度，您可能会看到与其他方法相比的一些缓慢。即便如此，我们仍然推荐使用批量复制，因为它更稳定，我们对数据迁移的方式和时间有更多控制。
复制到另一个站点
将数据放入您的 MinIO 集群后，您可能希望确保将数据复制到另一个站点的另一个 MinIO 集群，以实现冗余、性能和灾难恢复的目的。有多种方法可以做到这一点，但在本例中，让我们讨论以下两种方法。
- 站点复制
- 桶复制
站点复制
一旦数据位于 MinIO 对象存储集群中，它就会打开多种不同的可能性来复制和管理您的数据。
第一步是设置 3 个相同的 MinIO 集群，并分别命名为 minio1、minio2 和 minio3。我们将假设站点 1 已经使用批量复制将数据迁移到其中。
启用跨所有 3 个站点的站点复制
验证站点复制是否在 3 个站点之间正确设置
使用以下命令检查当前复制状态
启用站点复制后，数据将自动开始在所有站点之间复制。根据要传输的数据量、网络和磁盘速度，对象可能需要几个小时到几天才能在站点之间同步。
如果花费的时间比平时长，或者您仍然没有看到所有内容都已复制，则可以执行以下 `resync` 命令
可以使用以下命令检查 `status`
最终，所有数据都将复制到 `minio2` 和 `minio3` 站点。
桶复制
桶复制顾名思义，是根据 ARN 在 MinIO 中的特定桶上设置复制。
设置以下两个 MinIO 别名
源
目标
在 `minio2` 端设置好两个别名后，创建一个复制用户 `repluser`，并在 `minio2` 端的桶上为该用户设置用户策略，该桶具有此策略中列出的操作权限，作为复制的最低要求。
设置 `repluser` 运行复制操作所需的最小策略
将上述 `replpolicy` 附加到 `repluser`
现在事情变得有趣了。现在您已在 `minio2` 集群上创建了复制用户 (repluser) 和复制策略 (replpolicy)，您需要在 `minio1` 上实际设置桶复制目标。这并不会立即启动桶复制，而只是为以后我们实际启动该过程做好准备。
最后，让我们开始复制过程。
现在，上传到源桶中符合复制条件的任何对象都将由 MinIO 服务器自动复制到远程目标桶。可以通过禁用配置中的特定规则或完全删除复制配置来随时禁用复制。
哪个选项更好？
那么，为什么我们不能将站点到站点复制用于所有情况，而需要使用批量复制呢？批量复制提供了对复制过程的更多控制。可以将站点复制想象成一个消防水带，当你第一次启动它时，一旦启动，站点复制过程可能会使用网络上所有可用的网络带宽，以至于其他应用程序无法使用网络吞吐量。另一方面，虽然有时批量复制可能速度较慢，但在初始数据传输期间不会中断您现有的网络。当您只想复制少数几个存储桶而不是整个集群时，存储桶复制通常很有用。
好的，那么站点复制呢？批量复制不适合持续复制，因为批处理作业结束后不会复制任何新对象。因此，您必须以一定的间隔重新运行批量复制作业，以确保增量数据被复制到minio2站点。另一方面，站点复制允许数据从minio1复制到minio2，反之亦然，如果您设置了活跃-活跃复制。
无法同时启用存储桶复制和站点复制，您必须选择其中一个。因此，通常情况下，除非您只想复制特定存储桶或特定存储桶中的某些对象，否则我们强烈建议使用站点复制，因为它不仅会复制现有的存储桶和对象，还会复制创建的任何新存储桶/对象。此外，无需过多配置，您就可以设置分布式复制，例如，您可以在北美部署minio1，在非洲部署minio2，这样中东和北非地区就可以将数据添加到minio2，北美地区就可以将数据添加到minio1，它们之间会相互复制。
最终思考
在这篇文章中，我们深入探讨了存储桶、批量和站点复制类型。虽然没有固定的规则来使用特定的复制策略，但是我们SUBNET的工程师在设置无数个集群、迁移它们、扩展它们以及考虑灾难恢复方案后，提出了上述复制策略，这些策略应该可以帮助大多数考虑将数据迁移到MinIO的人。