我如何知道我的MinIO集群复制是最新的？

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

复制在绝大多数情况下都成功完成，但有时可能需要确定复制操作是否已完成。MinIO 维护一个复制队列来管理多个并发复制。MinIO 监视队列以复制或删除对象，同时扫描较新的对象。MinIO 尝试复制对象最多三次，然后再对失败的对象执行出列复制操作。请注意，这些情况并不经常发生，当它们发生时，是物理硬件、WAN 网络、数十亿个对象和站点之间的巨大距离的问题。但对于日常的一般运营来说，这并不是我们绝大多数客户关心的问题。

但是，由于跨多个站点有多个存储桶，如何确定复制是否按预期运行并对其进行跟踪？如何判断是否有任何需要复制的待处理对象？在启动在另一个云中运行的 ML 算法之前，您如何知道复制是最新的？

复制状态

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

异步复制 ：一旦发出复制对象的请求，MinIO 将首先返回成功的响应。这不会等待对象成功复制后再返回响应。这是默认设置，但为什么呢？有时，对象可能太大，两个群集之间的 WAN 网络可能很慢，或者可能有多种原因需要几分钟才能复制对象。我们对 MinIO 复制的弹性非常有信心，因此我们进行了适当的检查，以确保复制队列中的对象能够成功复制。使用这种类型的复制，进程无需等待数据被复制，然后再向队列添加更多对象。对于这种类型的复制，需要注意的一点是，它可能会导致对象过时或丢失，同时缓解缓慢的写入操作。

同步复制： 同步复制对象时，MinIO 会等待整个对象复制完毕后再返回成功响应。这可确保对象已成功复制到远程集群，而不会丢失对象。缺点是，对于每个对象，确定该对象是否已完成复制并移动到下一个对象，而不仅仅是设置它并将其遗忘在队列中，会产生额外的开销。

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

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

为了了解对象的实际状态，MinIO 会根据对象的复制状态设置 X-Amz-Replication-Status 元数据字段，该状态可以是以下状态之一：

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，以分别启用版本化删除和删除标记复制。

$ /opt/minio-binaries/mc admin replicate add minio1 minio2


Requested sites were configured for replication successfully.
1
2
3
4
5

这可以通过一个例子来最好地说明：

• 客户端向站点 1 发出 GET（“data/invoices/january.xls”）

• Site1 无法找到对象

• Site1 将请求代理给 Site2

• Site2 返回所请求对象的最新版本

• Site1 将代理对象返回给客户端

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

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

/opt/minio-binaries/mc admin replicate info minio1


SiteReplication enabled for:


Deployment ID                    	| Site Name   	| Endpoint

f96a6675-ddc3-4c6e-907d-edccd9eae7a4 | minio1      	| http://

0dfce53f-e85b-48d0-91de-4d7564d5456f | minio2      	| http://
1
2
3
4
5
6
7
8
9
10
11

设置复制后，可以持续检查状态

/opt/minio-binaries/mc admin replicate status minio1


Bucket replication status:

No Buckets present


Policy replication status:

●  5/5 Policies in sync


User replication status:

No Users present


Group replication status:

No Groups present
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

指标监控

仅站点复制的指标仅填充到具有站点复制配置的部署上。对于具有存储桶或批处理配置的部署，这些指标将改为填充在存储桶指标终端节点下。

下面是可以收集用于监视站点复制的众多指标中的几个。

灾难恢复支持

了解复制的基准性能以及其他复制规则如何影响彼此的性能至关重要。有时可能会出现不可预见的问题，例如，复制许多小对象可能会顺利进行，但数据密集型复制会推动一些最大的网络管道的容量和功能。MinIO 的运行速度与底层硬件允许的速度一样快——MinIO 集群中最常见的延迟原因之一不是磁盘，而是网络延迟。您可以拥有世界上最快的 NVMe 磁盘，但如果网络低于标准，则整个集群的性能将受到影响。企业客户会收到一个名为“性能测试”的工具，用于对其集群运行检查，以确保基准性能符合预期，如果复制出现任何问题，可以将其与过去的数据进行比较以进行进一步分析。

NetPerf: ✔


NODE RX TX

http://minio1:9000 1.5 GiB/s 1.3 GiB/s

http://minio2:9000 1.6 GiB/s 1.6 GiB/s

http://minio3:9000 1.6 GiB/s 1.5 GiB/s

http://minio4:9000 1.4 GiB/s 1.7 GiB/s


DrivePerf: ✔


NODE PATH READ WRITE

http://minio1:9000 /disk1 445 MiB/s 150 MiB/s

http://minio1:9000 /disk2 451 MiB/s 150 MiB/s

http://minio3:9000 /disk1 446 MiB/s 149 MiB/s

http://minio3:9000 /disk2 446 MiB/s 149 MiB/s

http://minio2:9000 /disk1 446 MiB/s 149 MiB/s

http://minio2:9000 /disk2 446 MiB/s 149 MiB/s

http://minio4:9000 /disk1 445 MiB/s 149 MiB/s

http://minio4:9000 /disk2 447 MiB/s 149 MiB/s


ObjectPerf: ✔


THROUGHPUT IOPS

PUT 461 MiB/s 7 objs/s

GET 1.1 GiB/s 17 objs/s


MinIO 2023-02-27T18:10:45Z, 4 servers, 8 drives, 64 MiB objects, 6 threads
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

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

如果需要关于分布式存储和对象存储的商业支持，请联系MinIO 。