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

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部署的负载而有所不同。由于这些变量，总的完成时间通常是不可预测的。

MinIO 建议配置负载均衡器或代理以仅将流量定向到运行状况良好的集群，直到同步完成。 以下命令可以深入了解重新同步状态：

• 在源端执行 mc replicate resync status 以跟踪重新同步的进度。

• 在源端和远程端执行 mc replicate status 以跟踪正常的复制数据。

• 对源端和远程端分别运行以下命令 mc ls -r --versions ALIAS/BUCKET | wc -l 以验证每个端上对象和对象版本的总数。

1) 列出运行状况良好的源上配置的复制目标

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

mc replicate ls SOURCE/BUCKET --json

• 将 SOURCE 替换为源 MinIO 部署的 alias。

• 将 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

• 将 --remote-bucket 的值替换为 TARGET MinIO 部署上不健康的 BUCKET 的 ARN。

• 将 SOURCE 替换为源 MinIO 部署的 别名。

• 将 BUCKET 替换为健康 SOURCE MinIO 部署上的存储桶 名称。

该命令返回一个重新同步作业 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

一旦重新同步过程完成，Status 更新为 Completed。

4) 下一步

• 如果 TARGET 存储桶的损坏扩展到了复制规则，您必须重新创建这些规则以匹配之前的复制配置。请参阅 启用双向服务器端桶复制 以获取更多指导。

• 执行基本验证，确保复制配置中的所有存储桶对于命令如 mc ls 和 mc stat 的结果显示类似。

• 在恢复任何复制规则并验证了站点之间的复制后，您可以配置反向代理、负载均衡器或其他网络控制平面，以恢复将流量发送到已重新同步的部署。