如何知道复制是否已更新？

客户可以在需要快速、弹性、可扩展的对象存储的任何地方运行 MinIO。MinIO 包含多种类型的复制，以确保所有应用程序无论运行在哪里，都能使用最新数据。我们已经在之前的文章中详细介绍了可用的各种复制选项及其最佳实践，例如 批量复制、站点复制 和 桶复制。 

复制几乎总是能够成功完成，但在生产环境中，仍然需要通过使用 指标 跟踪和绘制复制操作来确保其完成，我们将在以后的文章中更深入地探讨这方面。

• MinIO 保持一个复制队列来管理多个并发复制。
• MinIO 监控队列，在扫描新的对象时进行复制或删除对象。 
• MinIO 会尝试最多复制一个对象三次，然后在该失败对象上取消排队复制操作。 

请注意，这些情况并不常见。如果发生，最常见的原因是物理硬件、WAN 网络或其他物理基础设施问题。但在日常一般操作中，这不是问题。

MinIO 可以轻松地复制许多桶和对象，但如何确定复制是否按预期运行并跟踪它？如何确定是否存在需要复制的任何挂起对象？在您启动另一个云中运行的 ML 算法之前，如何知道复制已更新？

在这篇文章中，我们将了解对象在复制过程中的各种状态以及如何尽快恢复并运行，以及其他一些技巧，让您在复制的第二天拥有愉快体验。

复制状态

MinIO 支持两种类型的复制：异步复制和同步复制。

异步复制： MinIO 只要发出复制对象的请求，就会立即返回成功响应。它不会等待对象成功复制才返回响应。这是默认设置，但为什么呢？有时，对象可能太大，两个集群之间的 WAN 网络可能很慢，或者可能有一些原因导致对象需要几分钟才能复制。我们对 MinIO 复制的弹性性质非常有信心，因此我们设置了检查以确保复制队列中的对象能够成功复制。使用这种类型的复制，进程无需等待数据复制完成，就可以将更多对象添加到队列中。需要注意的是，这种类型的复制可能会导致陈旧或丢失的对象，同时减轻写入操作缓慢的问题。

同步复制： 当对象同步复制时，MinIO 会等待整个对象复制完成才返回成功响应。这确保对象已成功复制到远程集群，并且没有丢失任何对象。缺点是，对于每个对象，可能需要额外的开销来确定该对象是否已完成复制，并移至下一个对象，而不仅仅是将其设置为队列并忽略它。

换句话说，可以将同步复制视为 TCP 协议握手，其中发送的初始数据包在传输其他数据包（例如应用程序流量）之前会被确认。对象从一个 MinIO 服务器发送到另一个服务器（SYN），接收服务器确认对象已复制（SYN-ACK），然后客户端响应确认（ACK）。虽然 TCP 更健壮，但来回“对话”会导致网络上的大量流量。另一方面，可以将异步复制视为 UDP 协议（例如 SNMP），其中对象被发送到接收方，而无需等待 SYN-ACK。在数据量很大，必须等待对象之间的 ACK 会导致大量不利的开销，不利于运行高效复制的情况下，以这种方式进行复制非常有用。

因此，在使用 mc admin bucket remote add 命令添加标志配置远程目标时，必须显式启用同步复制。

为了了解对象的实际状态，MinIO 会根据对象的复制状态设置 X-Amz-Replication-Status 元数据字段。您可以使用 mc stat 检查这一点。

对象可能处于以下状态之一

PENDING：对象尚未复制。如果对象符合桶上的某个已配置复制规则，则 MinIO 会应用此状态。MinIO 不断扫描尚未在复制队列中的 PENDING 对象，并在有空间时将其添加到队列中。

对于多站点复制，对象将保持在 PENDING 状态，直到复制到该桶或桶前缀的所有已配置的远程位置。

COMPLETED：当对象已成功复制到远程集群时。

FAILED：MinIO 不断扫描尚未在复制队列中的 FAILED 对象，并在有空间时将其添加到队列中。这是对象无法复制到远程集群时的状态。 

REPLICA：如果对象是从另一个远程集群复制的，则会分配 REPLICA 状态，以将其与客户端直接添加到集群中的对象区分开来。

复制过程通常具有以下流程之一

PENDING -> COMPLETED

PENDING -> FAILED -> COMPLETED

复制对象

通常建议从一开始就设置复制，以消除初始对象传输可能导致的大量开销。当在包含数据的现有集群上启用复制时，MinIO 不会复制现有数据，因此 DevOps 工程师可以控制如何以及何时复制数据。他们会根据数据和访问数据的应用程序的性质，随着时间的推移手动复制数据。 

MinIO 提供了复制现有对象的选项。对于新的复制规则，将“existing-objects”添加到为 mc replicate add --replicate 指定的复制功能列表中。对于现有的复制规则，使用 mc replicate update --replicate 将“existing-objects”添加到现有复制功能列表中。在编辑复制规则时，必须指定所有所需的复制功能。

复制现有对象的速度取决于许多因素，例如网络、网络速度、磁盘速度和对象数量（尤其是在第一次复制期间）——以及其他因素。MinIO 对现有对象也使用相同的扫描程序和队列，没有针对不同对象的单独“QoS”，所有对象都必须排队。也就是说，您可以使用 MINIO_SCANNER_SPEED 环境变量或 scanner speed 配置设置来调整 MinIO 如何平衡扫描程序性能和读写操作。如果在配置桶复制时以前没有启用版本控制，则现有对象将具有 versionid = null。这些对象会复制。

MinIO 对等站点可以代理对对象的 GET/HEAD 请求到其他对等站点以检查其是否存在。这允许一个正在修复或落后于其他对等站点的站点仍然返回持久到其他站点的对象。对于删除标记复制，MinIO 在删除操作创建删除标记后开始复制过程。MinIO 使用 X-Minio-Replication-DeleteMarker-Status 元数据字段来跟踪删除标记复制状态。MinIO 需要显式启用版本化删除和删除标记复制。使用 mc replicate add --replicate 字段指定 delete 和 delete-marker，分别启用版本化删除和删除标记复制。

这可以通过一个例子来说明

• 客户端向站点 1 发出 GET("data/invoices/january.xls") 请求
• 站点 1 找不到该对象
• 站点 1 将请求代理到站点 2
• 站点 2 返回请求对象的最新版本
• 站点 1 将代理的对象返回给客户端

对于不包含唯一版本 ID 的 GET/HEAD 请求，代理请求将返回对等站点上该对象的最新版本。这可能会导致检索到对象的非当前版本，例如，如果响应的对等站点也正在经历复制延迟。

运行以下命令以检查所有站点的复制是否已成功启用

设置复制后，您可以定期检查其状态

灾难恢复支持

了解复制的基本性能以及其他复制规则如何影响彼此的性能至关重要。有时可能会出现一些意想不到的问题，例如复制许多小对象可能运行良好，但数据密集型复制会超出一些最大网络管道的容量和能力。MinIO 运行速度与底层硬件允许的速度一样快 - MinIO 集群中延迟最常见的原因之一不是磁盘，而是网络延迟。您可以拥有世界上最快的 NVMe 磁盘，但如果网络性能低下或出现小而频繁的故障，则整个集群的性能将受到影响。企业客户会收到一个名为性能测试的工具来运行对他们集群的检查，以确保基本性能符合预期，并且在复制过程中出现任何问题时，可以与过去的数据进行比较以进行进一步分析。

MinIO 建议将负载均衡器配置为不将流量路由到脱机的集群和节点。如果需要，重新同步过程可能需要很长时间，具体取决于对象的数量和大小以及网络速度，因此通过将流量路由到仅运行正常的节点/集群，客户端操作将不会出现任何停机时间。 

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

如果您对 MinIO 复制有任何疑问，请随时联系我们，加入 Slack!