Elasticsearch 多种跨机房灾备方案对比与实战解读
简介： 本文将会介绍几种 Elasticsearch 常见的灾备方案，同时提供了 Demo 案例方便大家动手体验。
1 引言
Elasticsearch 集群的高可用，保证服务的连续性是企业最关注的需求。通常当企业达到一定规模时，不管是在云上还是线下都会有多个机房做异地灾备，确保在某个机房不可用时，还能持续对外提供业务。本文将会介绍几种 Elasticsearch 常见的灾备方案，同时提供了 Demo 案例方便大家动手体验。
2 方案概要
| 方案 | 定期快照 | 跨机房部署集群 | 应用双写 | 借助消息队列实现双写 | CCR 跨集群复制 | 极限网关 |
|---|---|---|---|---|---|---|
| 描述 | 定期将索引备份到外部存储，例如 S3，HDFS。备份的数据可以在备集群中恢复。 | 一个集群中的节点分布在不同的机房。 | 应用程序同时将数据写入两个集群。 | 应用程序先将数据写入消息队列，然后由下游的消费者消费并写入集群。 | Elasticsearch 官方的跨集群复制功能，基于文档操作实现订阅复制。 | 写请求交给网关，网关实时写入主集群，然后异步写备集群。 |
| 优点 | 1.一致性高。2.成本低。3.即使主集群和备集群都崩溃，仍然通过快照将数据恢复到新集群中。 | 1.部署简单。2.成本低。3.一致性高。 | 1.应用端灵活可控，开发简单。 | 1.数据可靠性高，不易丢失。 | 1.一致性高。2.设置简单。3.延迟低。4.提供完善的 API ，可以监控同步进度。 | 1.无缝透明，应用程序无需任何调整。2.网关自动处理故障情况。3.随时可以进行主备切换。4.一致性高，通过校验任务确保数据完全一致。 |
| 缺点 | 1.数据不是实时备份，通过快照恢复时，延迟可能导致数据丢失。2.无法实时切换到备集群。 | 1.对网络带宽和延迟要求较高，仅适用于同城灾备。2.可能由于机房间网络中断造成脑裂问题。 | 1.一致性差。2.集群故障时数据会丢失。3.延迟高。 | 1.引入额外的消息队列组件，维护成本高，开发难度大。2.延迟高。 | 1.切换复杂，需要手动操作，并且切换的时候可能会丢数据。2.属于 Elastic Stack 的白金版（PLATINUM）付费功能，需要额外付费。3.从 Elasticsearch v6.7 版本开始才可以使用。4.集群之间拉取数据会增加额外的负载并影响磁盘和网络性能。 | 无 |
3、方案
CCR 跨集群复制
应用双写
借助消息队列实现双写
极限网关
相关文章：
Elasticsearch 多种跨机房灾备方案对比与实战解读
为者常成，行者常至
自由转载-非商用-非衍生-保持署名（创意共享3.0许可证）
