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

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

例如，考虑一个类似于以下配置的MinIO主动-主动复制设置：

Active-Active Replication synchronizes data between two remote deployments.

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

重新同步是按存储桶进行的流程。对于远程站点上遭受部分或全部数据丢失的每个存储桶，您都必须重复执行重新同步操作。

BC/DR运营期间的专业支持

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

社区用户可以在以下平台寻求支持：MinIO Community Slack社区支持仅提供尽力而为的服务，不保证响应时间的服务等级协议。

需求

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 Server。

要配置任意 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.Bucketfield specifies the ARN for a given rule on the bucket. 确定您要重新同步对象的存储桶的正确ARN。

2) 启动再同步程序

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

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

替换--remote-bucket值为不健康实例的ARNBUCKET在TARGETMinIO 部署。
已替换SOURCE随着别名源 MinIO 部署的。
替换BUCKET使用存储桶的名称在健康状态下SOURCEMinIO 部署。

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

The状态更新Completed一旦重新同步过程完成。

4) 后续步骤

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