追随领导者：Elasticsearch 中的跨集群复制简介
众望所盼
这项将数据从一个 Elasticsearch 集群原生复制到另一个 Elasticsearch 集群的功能是备受期待的功能，也是我们用户渴望已久的一项功能。经过工程团队多年的努力 - 奠定必要的基础、在 Lucene 中构建新基础技术以及迭代和优化初始设计，我们很高兴地宣布，现已在 Elasticsearch 6.7.0 中提供跨集群复制 (CCR) 功能并可用于生产。我们围绕此主题设计了一个博文系列。本文是第一篇文章，将简要介绍我们业已实施的内容，以及 CCR 的一些技术背景。在以后的博文中，我们将深入介绍 CCR 的具体用例。
Elasticsearch 中的跨集群复制支持 Elasticsearch 和 Elastic Stack 中的各种任务关键型用例：
- 灾难恢复 (DR) / 高可用性 (HA)：对于许多任务关键型应用程序，都需要能够承受住数据中心或区域服务中断的影响。以前，此要求在 Elasticsearch 中通过其他技术得到了满足，但这会增加额外的复杂性和管理开销。现在，通过 Elasticsearch 中的原生功能即可满足跨数据中心的 DR/HA 要求，且无需其他技术。
- 数据本地化：在 Elasticsearch 将数据复制到更靠近用户或应用程序服务器的位置，可以减少延迟，降低成本。例如，可以将产品目录或参考数据集复制到全球 20 个或更多数据中心，最大限度地缩短数据与应用程序服务器之间的距离。另一个用例是一家在伦敦和纽约都设有办公室的股票交易公司。伦敦办公室的所有交易均在本地写入，并复制到纽约办公室，纽约办公室的所有交易也本地写入，并复制到伦敦办公室。两个办公室都可以全局查看所有交易。
- 集中式报告：将数据从大量较小型集群复制回集中式报告集群。当跨大型网络进行查询的效率较低时，此功能就可派上用场。例如，一家大型全球银行可能在世界各地拥有 100 个 Elasticsearch 集群，每个集群位于一个不同的银行分支机构内。我们可以使用 CCR 将全球所有 100 个分支银行的事件复制回中心集群，在此对事件进行本地分析和聚合。
在 Elasticsearch 6.7.0 版本之前，这些用例可以部分通过第三方技术来解决，但这种做法很繁琐，会带来大量的管理开销，而且有很大的缺点。通过将跨集群复制原生集成到 Elasticsearch 中，我们让用户摆脱了管理复杂解决方案的负担和缺点，并能提供现有解决方案所不具备的优势（例如，全面错误处理）。我们还提供了 Elasticsearch API 和 Kibana UI 来管理和监测 CCR。
请持续关注后续博文，以更详细地了解每个用例。
跨集群复制入门
请访问我们的下载页面，获取最新版本的 Elasticsearch 和 Kibana，并深入了解入门指南。
CCR 是一项白金级功能，可通过 30 天试用许可证获取；该许可证既可通过 start trial API 激活 ，也可以直接从 Kibana 激活。
跨集群复制技术简介
CCR 围绕主动-被动索引模型设计。一个 Elasticsearch 集群中的索引可以配置为从另一个 Elasticsearch 集群中的索引复制更改。复制更改的索引称为“追随者索引”，被复制的索引称为“领导者索引”。追随者索引是被动的，它可以服务于读取请求和搜索，但不能接受直接写入，只有领导者索引可随时接受直接写入。由于 CCR 在索引级别进行管理，因此，集群可以包含领导者索引和追随者索引。采用这种方式，您可以按某一方向（例如，从美国集群复制到欧洲集群）复制部分索引，并按另一方向（从欧洲集群复制到美国集群）复制其他索引，以此来解决部分主动-主动用例。
复制在分片级别完成；追随者索引中的每个分片将从领导者索引中的相应分片拉取更改，这意味着追随者索引的分片数量与领导者索引相同。追随者会复制所有操作，以便复制创建、更新或删除文档的操作。复制是几乎实时完成的；一旦分片上的全局检查点前进，操作即可被追随分片复制。追随分片可批量高效地拉取操作和创建索引，并且能够并行执行拉取更改的多个请求。这些读取请求可以由主分片及其副本提供服务，除了从分片读取之外，不要对领导者施加额外的负载。此设计能够使 CCR 随生产负载进行扩展，以便您可以持续尽享在 Elasticsearch 中体会到的（和预期的）高吞吐量索引编制速率。
CCR 支持新建的索引和现有索引。最初配置追随者索引时，它会从领导者索引复制底层文件，以便从领导者索引启动自身，这类似于副本从主数据中恢复的过程。此恢复过程完成后，CCR 将从领导者复制任何其他操作。映射和设置更改将根据需要自动从领导者索引进行复制。
有时 CCR 可能会遇到错误场景（例如网络故障）。CCR 能够自动将这些错误分类为可恢复错误和致命错误。发生可恢复错误时，CCR 即进入重试循环，一旦导致故障的情况得到解决，CCR 将立即继续复制。
复制状态可以通过专用 API 进行监控。通过此 API，您可以监控追随者跟踪领导者的紧密程度，查看有关 CCR 性能的详细统计信息，并跟踪需要您注意的任何错误。
我们已将 CCR 与 Kibana 中的监测和管理应用进行了集成。监测 UI 可使您查看 CCR 进度和错误报告。
Kibana 中的 Elasticsearch CCR 监测 UI
管理 UI 可使您配置远程集群，配置追随者索引，以及管理自动追随者模式，以实现自动复制索引。
Kibana 中的 Elasticsearch CCR 管理 UI
追随最新的索引
很多用户都有需要定期创建新索引的工作负载。例如，Filebeat 推送的日志文件中的每日索引，或索引生命周期管理自动滚动更新的索引。我们已将自动追随功能直接构建到 CCR 中，从而无需手动创建追随者索引来从源集群复制这些索引。此功能允许您将索引模式配置为自动从源集群中复制。CCR 将监测源集群中与这些模式匹配的索引，并将追随索引配置为复制这些匹配的领导者索引。
此外，我们还集成了 CCR 和 ILM，以使 CCR 可以复制基于时间的索引，并通过 ILM 在源和目标集群中进行管理。例如，ILM 了解 CCR 何时复制领导者索引，因此，会小心管理破坏性操作（如缩小和删除索引），直到 CCR 完成复制。
不了解历史记录的用户
为了使 CCR 能够复制更改，我们需要有领导者索引分片上的操作历史记录，以及每个分片上的指针，以了解可以安全复制的操作。此操作历史记录按序列 ID 控制，指针称为全局检查点。不过这其中有一定的复杂性。在 Lucene 中更新或删除一个文档时，Lucene 将做一些标记，以记录该文档已删除。该文档将保留在磁盘上，直到未来的合并操作合并已删除的文档。如果 CCR 在合并删除内容之前复制此操作，则一切顺利。但是，合并发生在其自己的生命周期内，这意味着在 CCR 有机会复制该操作前，可能会合并已删除的文档。如果无法控制何时合并已删除的文档，则 CCR 可能会遗漏操作，且无法完全将操作历史记录复制到追随者索引。在 CCR 设计阶段早期，我们原计划使用 Elasticsearch 事务日志作为这些操作历史记录的源，这将有助于避开这一问题。但我们很快意识到，事务日志并不适用于 CCR 高效执行所需的访问模式。我们考虑了在事务日志之上及旁边放置额外的数据结构，以实现我们所需的性能，但此方法有一些限制。首先，它可能会增加系统中某个最重要组件的复杂性，这有悖于我们的工程原则。其次，它会束缚我们打算基于操作历史记录构建的未来更改，这样我们需要强制限制可以对操作历史记录执行的搜索类型，或基于事务日志重新实现所有 Lucene。凭借这种洞察力，我们意识到需要在 Lucene 中原生构建，使我们能够控制何时合并已删除文档的功能，从而高效地将操作历史记录推送到 Lucene 中。我们称这种技术为“软删除”。这项对 Lucene 的投资需要数年才能获得回报，因为不仅 CCR 是基于其构建的，我们还在修改基于软删除的复制模型，而且即将进行的更改 API 也将基于它们实现。领导者索引需要能够支持软删除。
接下来，当在领导者上合并软删除的文档时，追随者将能够施加影响。为此，我们引入了分片历史记录保留租约。通过分片历史记录保留租约，追随者可以在其当前所在的历史记录中对领导者的操作历史记录进行标记。领导者分片知道该标记之下的操作可以安全地合并，但在该标记之上的任何操作都必须保留，直到追随者有机会复制它们为止。这些标记可确保在追随者临时脱机的情况下，领导者将保留尚未复制的操作。由于保留此历史记录需要在领导者上有额外存储，因此，这些标记仅在限定期限内有效，此期限后标记将过期，领导者分片就可自由合并历史记录。您可以根据在追随者脱机时要保留的额外存储大小，以及您希望在追随者必须从领导者重新启动之前接受追随者脱机多长时间来调整这一期限。
总结
我们很高兴您试用 CCR 并与我们分享有关此功能的反馈。我们乐享构建，更希望您乐享使用。请持续关注此系列的后续博文，我们将继续卷起袖子加倍努力，并详细解释 CCR 中的一些功能以及 CCR 所针对的用例。如果您对 CCR 有任何问题，请访问讨论论坛。
与此博文相关的缩略图图像版权归 NASA 所有，依据 CC BY-NC 2.0 许可证获得授权。与此博文相关的横幅图像版权归 Rawpixel Ltd 所有，依据 CC BY 2.0 许可证获得授权，基于原图裁剪而得。