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

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

例如，考虑如下所示的 MinIO 活动-活动复制配置

Active-Active Replication synchronizes data between two remote deployments.

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

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

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

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

社区用户可以在MinIO 社区 Slack 上寻求支持。社区支持仅为尽力而为，并且没有关于响应能力的 SLA。

要求

MinIO 部署必须在线

重新同步要求源部署和目标部署都处于联机状态，并且能够接受读写操作。源端*必须*与远程端之间具有完整的网络连接。

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

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

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

使用 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 行为启用对象锁定。然后，您可以随时配置对象保留规则。在开始此过程*之前*，在不健康的 target 存储桶上配置必要的规则。

注意事项

重新同步需要时间

重新同步是一个后台进程，它会持续检查源 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

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

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

4) 下一步

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