在之前的博客中，咱们评论了仿制最佳实践和不同类型的仿制，例如批量、站点和存储桶。可是，随着一切这些不同类型的仿制类型的呈现，人们不得不想知道在哪里运用哪种仿制战略？从现有 S3 兼容数据存储搬迁数据时，您运用 mc mirror 还是 Batch？在集群之间进行仿制时，应该运用站点仿制还是存储桶仿制？
今日咱们将揭开这些不同仿制战略的神秘面纱，看看在哪种情况下应该运用哪种战略。
从现有源仿制
一般，假如您本地驱动器或现有 S3 兼容存储上已有数据，咱们建议您运用以下两种办法之一来仿制数据。
-
批量仿制：这有必要需求 MinIO 或其他 S3 兼容存储（例如 AWS）的现有源。
-
运用 mc mirror ：这能够是本地目录或 NFS 挂载等。
在详细介绍之前，让咱们先看一下一些先决条件。
在 mc 中为 MinIO 集群创立一个名为 miniostore 的 alias 。
mc alias set miniostore
在 miniostore 中创立一个存储桶， olderstore 中的数据将传输到其间。
mc mb miniostore/mybucket
在 mc 中为 S3 兼容存储中的现有存储桶创立另一个 alias 。
mc alias set olderstore
在这种情况下，咱们假定 oldstore 中已经有一个名为 mybucket 的存储桶。
让咱们看一下如何运用批量仿制将数据从现有的 S3 兼容源搬迁到 MinIO 存储桶。
为批量仿制装备创立yaml
mc batch generate olderstore/ replicate
您应该看到类似于下面的 replication.yaml 文件， source 是 olderstore ，方针是 miniostore 。
运用以下指令履行批量仿制
mc batch start olderstore/ ./replicate.yaml
Successfully start 'replicate' job `E24HH4nNMcgY5taynaPfxu` on '2024-02-04 14:19:06.296974771 -0400 EDT'
运用上面的仿制作业 ID（在本例中为 E24HH4nNMcgY5taynaPfxu ），咱们能够找到批处理作业的状态。
mc batch status olderstore/ E24HH4nNMcgY5taynaPfxu
您能够列出并查找当前正在运转的一切批处理作业的装备。
mc batch list olderstore/
mc batch describe olderstore/ E24HH4nNMcgY5taynaPfxu
例如，假如批处理作业使网络饱满而且您需求稍后在流量最少时康复它，您也能够取消并发动批处理作业。
mc mirror
让咱们快速看一下 mc mirror 在这种情况下如何作业。
mc mirror --watch olderstore/mybucket miniostore/mybucket
上面的指令与rsync类似。它不只会将数据从 olderstore 仿制到 miniostore ，还会在 olderstore 上查找传入的较新方针，然后将它们仿制到 miniostore
您能够比较两个桶，看看数据是否仿制成功。
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 已运用批量仿制将数据搬迁到它。
mc alias set minio1 http:// minioadmin minioadmin
mc alias set minio2 http:// minioadmin minioadmin
mc alias set minio3 http:// minioadmin minioadmin
跨一切 3 个站点启用站点仿制
mc admin replicate add minio1 minio2 minio3
验证跨 3 个站点的站点仿制设置是否正确
mc admin replicate info minio1
运用以下指令查看当前仿制状态
mc admin replicate status minio1
启用站点仿制后，数据将自动开端在一切站点之间仿制。依据要传输的数据量、网络和磁盘速度，跨站点同步方针或许需求几个小时到几天的时间。
假如花费的时间比平时更长，或者您依然没有看到一切内容都已仿制，则能够履行 resync 指令，如下所示
mc admin replicate resync start minio1 minio2 minio3
能够运用以下指令查看 status
mc admin replicate resync status minio1 minio2 minio3
终究一切数据将被仿制到 minio2 和 minio3 站点。
桶仿制
桶仿制，顾名思义，是根据 ARN 在 MinIO 中的特定桶上设置仿制。
设置以下两个MinIO别号
来历：
mc alias set minio1
意图地：
mc alias set minio2
在 minio2 端设置两个别号后，创立一个仿制用户 repluser 并在具有权限的 minio2 端存储桶上为此用户设置用户战略履行本战略中列出的操作作为仿制的最低要求。
mc admin user add minio2 repluser repluserpwd
设置 repluser 运转仿制操作所需的最低战略
将上面的 replpolicy 附加到 repluser
$ mc admin policy add minio2 replpolicy ./replicationPolicy.json
$ mc admin policy set minio2 replpolicy user=repluser
现在这便是有趣的当地。现在您已经在 minio2 集群上创立了仿制用户 (repluser) 和仿制战略 (replpolicy)，您需求在 minio1 上实践设置存储桶仿制方针。这还没有发动存储桶仿制，它只是为稍后咱们实践发动该进程时进行设置。
$ 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'
最终，让咱们开端仿制进程。
$ 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。
假如您对仿制或最佳实践有任何疑问，请联系咱们。
