更快的多站点复制和重新同步

多站点主动-主动复制于 2021 年底首次推出，现已发展成为最具影响力的 MinIO 功能之一。MinIO 很早以前就有能力在 bucket 之间复制以同步对象、删除操作和元数据更改，但是 Multi-site Active-Active Replication 超越了 bucket 复制，可以同步所有 bucket、IAM、安全令牌、服务帐户和 bucket 级别的配置。  

随着企业收集和分析越来越多的数据，他们可能需要在数据中心、云和其他地理位置之间复制数据，这可能是出于安全法规或合规性要求，或者是为了提高数据可访问性和减少延迟。复制必须安全高效，并且不干扰其他集群操作，以便可行。

为此，我们最近改进了重新同步功能，以及主动-主动复制的效率、报告和整体性能。

可以使用 MinIO 控制台或 MinIO 客户端 ( mc replicate) 配置复制。复制需要在源和目标站点/存储桶上启用版本控制。复制将上次修改的系统元数据属性从源对象保留到目标对象。复制是有弹性和自动化的——任何修复失败都会自动修复，因此复制会继续有增无减。应用程序无需修改即可访问任一集群上的数据。有关更多信息，请参阅启用服务器端多站点存储桶复制  

在大多数情况下，MinIO 复制是一劳永逸的，不需要重新同步。MinIO 复制自动同步对象和设置，在后台异步修复和复制对象。重新同步仅在 MinIO 集群不同步时使用，可能是因为硬件故障。重新同步本质上是HEAD在两个集群上处理命令，然后检查元数据版本和时间，最后只复制需要的内容。和replicate resync/或admin replicate resync命令仅在 DR 类型的情况下才需要，因为它们本质上是主动列出和比较对象的昂贵操作。

重新同步和复制在使用多站点复制进行灾难恢复策略时占有重要地位，其中一个集群可能处于活动状态，而另一个集群只是用于故障转移的热备份。在此体系结构中，您从一个活动集群开始，部署另一个集群，然后配置并启动站点复制。这在发生灾难时保持非常高的可用性，负载均衡器配置为自动将流量路由到健康的 MinIO 部署。万一整个站点出现故障，您将部署一个新的 MinIO 集群，然后从热备用/故障转移集群完全重新同步到新集群。  

在您已经在集群之间运行存储桶复制的实例中，如果您选择升级到站点复制，您将首先运行手动重新同步，然后 MinIO 将继续在集群之间同步。  

使用该mc replicate resync命令将远程目标完全重新同步到源（文档）。重新同步根据所有配置的复制规则检查源集群中的所有对象。对于匹配复制规则的每个对象，重新同步过程都会将该对象放入复制队列，而不管该对象的当前复制状态。MinIO 跳过同步那些远程副本与源完全匹配的对象，包括元数据。

我们借此机会尽我们所能提高复制效率和可用性。这是多云企业经常使用的功能，因此我们预计每项改进都会产生巨大影响。

复制现在更频繁地治愈对象。以前，只有当扫描器越过对象所在的名称空间前缀时，复制失败才会得到修复。现在，与复制活动分开，每次 MinIO 运行LIST、GET或 等操作时PUT，都会运行一个修复操作，因此它不必在复制期间运行。我们还提高了复制失败队列的效率。现在，复制故障修复由复制系统主动管理，而不依赖于扫描器活动。

最后，我们改进了复制状态和统计数据的报告。MinIO 现在将所有与内存中复制相关的统计信息保存到磁盘，并在集群重启时读取它，以创建更准确的复制积压情况。这样可以更准确地报告复制统计信息。

复制驱动多云

MinIO 站点复制允许您在部署之间同步数据，从而实现灾难恢复、地理负载平衡和复杂的多云数据处理和分析。在生成或捕获数据的地方（边缘、云端或数据中心）提取数据，并将其复制到对您最有利的地方。在多云模型中，您可以跨云提供商无缝利用同类最佳的应用程序，从您的数据中实现最大价值。复制以构建高可用性架构的冗余。

下载 MinIO并立即开始复制。任何问题？在Slack上联系我们。