从远程副本重新同步存储桶

此页面上的过程使用健康的复制远程重新同步 MinIO 存储桶的内容。重新同步支持在副本配置中在 MinIO 部署部分或全部数据丢失后恢复。

例如，考虑类似以下内容的 MinIO 活动-活动复制配置

Active-Active Replication synchronizes data between two remote deployments.

重新同步允许使用参与的 MinIO 部署之一上的健康数据作为重建另一个部署的来源。

重新同步是一个按存储桶进行的过程。您必须对远程上每个部分或全部数据丢失的存储桶重复重新同步。

BC/DR 操作期间的专业支持

MinIO SUBNET 用户可以登录并创建一个与重新同步相关的新问题。通过 SUBNET 与 MinIO 工程团队协调可以确保成功重新同步和恢复正常操作，包括性能测试和健康诊断。

社区用户可以在 MinIO 社区 Slack 上寻求支持。社区支持仅基于尽力而为的原则提供，没有关于响应时间的 SLA。

要求

MinIO 部署必须在线

重新同步要求源部署和目标部署都在线，并且能够接受读写操作。源必须与远程拥有完整的网络连接。

远程部署可能“不健康”，因为它部分或全部数据丢失。只要源和目标都保持连接，重新同步就可以解决数据丢失问题。

重新同步需要现有的复制配置

重新同步要求健康的源部署对不健康的目标存储桶拥有现有的复制配置。此外，重新同步仅适用于使用现有对象复制选项创建的那些复制规则。

使用 mc replicate ls 查看健康的源存储桶的配置的复制规则和目标。

复制需要匹配的对象加密设置

MinIO 支持复制使用 SSE-KMS 和 SSE-S3 加密的对象。

对于使用 SSE-KMS 加密的对象，MinIO要求目标存储桶支持使用与在源存储桶上加密对象时使用的相同密钥名称的 SSE-KMS 对象加密。
对于使用 SSE-S3 加密的对象，MinIO要求目标存储桶也支持 SSE-S3 对象加密，无论密钥名称如何。

作为复制过程的一部分，MinIO解密源存储桶上的对象，并将未加密的对象通过网络传输。然后，目标 MinIO 部署使用目标的加密设置重新加密对象。因此，MinIO强烈建议在源部署和目标部署上都启用 TLS，以确保对象在传输过程中的安全性。

MinIO不支持复制客户端加密的对象 (SSE-C)。

复制需要 MinIO 部署

MinIO 服务器端复制仅在 MinIO 部署之间工作。源部署和目标部署必须运行具有匹配版本的 MinIO 服务器。

要配置任意 S3 兼容服务之间的复制，请使用 mc mirror.

复制需要版本控制

MinIO 依赖于版本控制提供的不变性保护来支持复制和重新同步。

使用 mc version info 来验证源存储桶和目标存储桶的版本控制状态。使用 mc version enable 命令在必要时启用版本控制。

如果在源存储桶中从版本控制中排除前缀或文件夹，MinIO 无法复制该文件夹或前缀中的对象。

复制需要匹配的对象锁定状态

MinIO 支持复制在 WORM 锁定下保存的对象。两个复制存储桶都 *必须* 启用对象锁定，MinIO 才能复制锁定对象。对于活跃-活跃配置，MinIO 建议在两个存储桶上使用 *相同* 的保留规则，以确保跨站点的一致行为。

您必须按照 S3 行为在创建存储桶期间启用对象锁定。然后，您可以随时配置对象保留规则。在开始此过程 *之前*，在不健康的的目标存储桶上配置必要的规则。

注意事项

重新同步需要时间

重新同步是一个后台进程，它会持续检查源 MinIO 存储桶中的对象，并在需要时将它们复制到目标存储桶。复制完成所需的时间可能会有所不同，具体取决于对象的数量和大小、到远程 MinIO 部署的吞吐量以及源 MinIO 部署的负载。由于这些变量，完成的总时间通常是不可预测的。

MinIO 建议配置负载均衡器或代理，仅将流量定向到健康的集群，直到同步完成。以下命令可以提供有关重新同步状态的见解

mc replicate resync status 在源服务器上跟踪重新同步进度。
mc replicate status 在源服务器和目标服务器上跟踪正常的复制数据。
对源服务器和目标服务器都运行 mc ls -r --versions ALIAS/BUCKET | wc -l 来验证每个服务器上的对象总数和对象版本。

数据丢失后重新同步对象

此过程使用现有的 MinIO 复制配置将丢失的数据恢复到参与该配置的 MinIO 部署之一。具体来说，一个健康的 MinIO 部署（SOURCE）将其现有数据同步到不健康的 MinIO 部署（TARGET）。

此过程假设存在 SOURCE 的现有别名，它具有必要的权限来配置复制。

您可以对每个需要重新同步的存储桶重复此过程。您最多可以对每个存储桶运行一个复制作业。

1) 列出健康源服务器上的配置复制目标

运行 mc replicate ls 命令来列出健康 SOURCE 部署上为需要重新同步的 BUCKET 配置的远程目标。

mc replicate ls SOURCE/BUCKET --json

用 SOURCE 替换源 MinIO 部署的别名。
用 BUCKET 替换要作为重新同步源使用的存储桶的名称。

输出类似于以下内容

{
   "op": "",
   "status": "success",
   "url": "",
   "rule": {
      "ID": "cer1tuk9a3p5j68crk60",
      "Status": "Enabled",
      "Priority": 0,
      "DeleteMarkerReplication": {
         "Status": "Enabled"
      },
      "DeleteReplication": {
         "Status": "Enabled"
      },
      "Destination": {
         "Bucket": "arn:minio:replication::UUID:BUCKET"
      },
      "Filter": {
         "And": {},
         "Tag": {}
      },
      "SourceSelectionCriteria": {
         "ReplicaModifications": {
            "Status": "Enabled"
         }
      },
      "ExistingObjectReplication": {
         "Status": "Enabled"
      }
   }
}

输出中的每个文档都代表一个配置的复制规则。 Destination.Bucket 字段指定存储桶上给定规则的 ARN。确定要从中重新同步对象的存储桶的正确 ARN。

2) 启动重新同步过程

运行 mc replicate resync start 命令开始重新同步过程

mc replicate resync start --remote-bucket "arn:minio:replication::UUID:BUCKET" SOURCE/BUCKET

用不健康的 BUCKET 在 TARGET MinIO 部署上的 ARN 替换 --remote-bucket 值。
用源 MinIO 部署的别名替换 SOURCE。
用健康 SOURCE MinIO 部署上的存储桶名称替换 BUCKET。

该命令返回一个重新同步作业 ID，指示该过程已开始。

3) 监控重新同步

在源服务器上使用 mc replicate resync status 命令来跟踪接收到的复制数据

mc replicate resync status ALIAS/BUCKET

输出类似于以下内容

mc replicate resync status /data
Resync status summary:
● arn:minio:replication::6593d572-4dc3-4bb9-8d90-7f79cc612f01:data
   Status: Ongoing
   Replication Status | Size (Bytes)    | Count
   Replicated         | 2.3 GiB         | 18
   Failed             | 0 B             | 0

重新同步过程完成后，状态更新为 Completed。

4) 后续步骤

如果 TARGET 存储桶损坏扩展到复制规则，您必须重新创建这些规则以匹配之前的复制配置。有关更多指导，请参阅启用双向服务器端存储桶复制。
执行基本验证，以确保复制配置中的所有存储桶都显示类似的结果，例如 mc ls 和 mc stat。
在恢复任何复制规则并验证站点之间的复制后，您可以配置反向代理、负载均衡器或其他管理连接的网络控制平面，以恢复将流量发送到重新同步的部署。