从远程副本重新同步存储桶
此页面上的过程使用健康的复制远程端来重新同步 MinIO 存储桶的内容。重新同步支持在副本配置中 MinIO 部署的部分或完全数据丢失后的恢复。
例如,考虑如下所示的 MinIO 主动-主动复制配置
重新同步允许使用参与的 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
将
--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
存储桶损坏扩展到复制规则,则必须重新创建这些规则以匹配以前的复制配置。有关其他指导,请参阅启用双向服务器端存储桶复制。在恢复任何复制规则并验证站点之间的复制后,您可以配置反向代理、负载均衡器或管理连接的其他网络控制平面,以恢复将流量发送到重新同步的部署。