ES的CCR对多活支撑的探讨
ES CCR的简介
ES的 Cross-cluster replication(CCR)是什么
跨集群复制 (CCR) 功能可以将远程集群中的索引复制到本地集群。
此功能可用于一些常见的生产用例:
- 主集群发生故障时的灾难恢复。 辅助集群可以作为热备份
- 地理位置邻近,以便可以在本地提供读取服务
复制原理的注意点
-
复制关系是在索引级别配置的。(理解为主从复制关系。)
-
对于每个配置的复制关系,都有一个称为leader index的复制源索引和一个称为follower index的复制目标索引。(理解为为主从索引。)
-
复制模型,采用的主从式Pull模型,由从索引读取主索引中的数据。
-
主从索引之间的数据是以分片级别进行读取统计的。
-
主索引的字段的变更,可以自动同步到从索引;对于副本分片的变更,需要在从索引上手动配置。(理解为,主索引部分变更会同步至从索引,整体需要在索引校验更正。)
-
主索引支持读写操作,从索引只支持读操作。
-
从索引初始化的时候,是采用基于snapshot&restore的远程恢复功能,从主索引的主分片处请求文件块,默认支持同时请求5个大小为
1mb
的文件块。(文件块,理解为Lucene
的物理文件,在实践中,确实发现从索引的这些文件与主索引的绝大部分一致,跟快照场景类似)远程恢复的动态配置
-
ccr.indices.recovery.max_bytes_per_sec
:限制每个节点上的入站和出站远程恢复流量总量。由于此限制适用于每个节点,但可能会有很多节点同时执行远程恢复,因此远程恢复字节的总量可能会远远高于此限制。如果将此限制设置得过高,那么正在进行的远程恢复将有可能消耗过多的带宽(或其他资源),从而导致群集不稳定。主索引集群和从索引集群都使用此设置。例如,如果将主索引集群的带宽设置为20MB
,那么即使从索引集群请求并能接受60MB/s
的带宽,主索引集群也只会向从索引集群发送20MB/s
的带宽。默认为40MB
。 -
ccr.indices.recovery.max_concurrent_file_chunks
:控制每次恢复可并行发送的文件块请求数量。由于多个远程恢复可能已在并行运行,因此只有在单个分片的远程恢复未达到ccr.indices.recovery.max_bytes_per_sec
配置的入站和出站远程恢复总流量时,增加此专家级设置才会有帮助。默认为5
。允许的最大值为10
。 -
ccr.indices.recovery.chunk_size
:控制文件传输过程中跟随者请求的块大小。默认为1MB
。 -
ccr.indices.recovery.recovery_activity_timeout
:控制恢复活动的超时。该超时主要适用于主索引集群。主索引集群必须打开内存中的资源,以便在恢复过程中向跟随者提供数据。如果领导集群在这段时间内没有收到从属集群的恢复请求,就会关闭资源。默认为60
秒。 -
ccr.indices.recovery.internal_action_timeout
:控制远程恢复过程中单个网络请求的超时。单个操作超时会导致恢复失败。默认为60
秒。
-
使用要求
- ES CCR的集群都是6版本以上且集群之间的版本应该相同。
- 主索引的需要开启软删除的配置项。
- 主索引的拥有优秀健康程度(非大分片,非大量更新数据,增量式,多读少写)
主要功能
- 创建主从索引,进行复制
- 支持主从复制的暂停,恢复,终止。
- 按分片粒度进行的统计复制情况。
ES可支持的容灾建设
真·多活
不同机房的集群,同时承接着流量,只不过承接流量的负载可能不同。
数据进行双向复制同步。不同机房都拥有全量的数据。此多活场景用来在故障时,保障业务的高连续性和数据的高完整性。
多活要求效果图
伪·多活(热备)
同时在不同机房都建立服务,机房之间建立数据同步。平时A机房承担所有业务流量,数据由A机房复制进B机房。当A挂之后,流量切换至B机房,B机房开始承担业务,数据由B机房复制进A机房。数据复制采用实时或近实时同步,故障时,机房的数据应该在0损失与微量损失的范围内。
此场景用来在故障时,保障数据的高完整性和较高的业务连续性。
热备要求效果图
ES的CCR是一个单向的复制。最多支撑起热备的场景。
ES的CCR支撑多活的问题
以下是实现热备场景的问题
-
复制延迟问题
ES的CCR,使用pull模型。那么肯定是存在pull的周期。尽管pull的周期很短,但是由于主索引变更的数据量和频率的差异。数据的完整性是存疑的。需要通过重跑增量数据和业务补偿来保障数据完整性的。
-
机房网络延迟问题
基础服务,依赖网络情况。
-
数据冲突问题
当A集群发生故障,将读写切换至B集群之后,此时的AB集群上的主从索引复制关系是终止的。回切时方案
- 查询出差异数据,增量式重写入A集群。请求流量切回A集群。删除B的索引,重建从索引。(需要考虑如果保障增量数据的顺序写入,防止数据冲突)
- A集群修复完成后,删除所有A集群的主索引,建立B->A的主从复制索引。将B的数据全量复制回A。当复制完成后,在切换流量至A集群。业务补偿后,确保A集群的数据完整。重建A->B的所有主从索引。(在做业务数据补偿的时候,需要考虑数据的冲突)。
解决数据冲突的常用方式
- 核心数据禁止写,只提供读。等集群A修复完成后,在提供写的功能。
- 在业务字段中增加区分字段,可以是时间,或版本号。数据补偿写入时进行校验写入。
-
流量控制问题文章来源:https://www.toymoban.com/news/detail-764324.html
ES的CCR是基于索引级别配置的,那么在从索引初始化的时候,在占用集群间会产生大量的网络带宽,需要进行流量控制。同理在发生切换后。主从索引关系的变化都会发生大量的数据同步,集群间的流量就会暴涨。需要进行控制。文章来源地址https://www.toymoban.com/news/detail-764324.html
- 增加主从索引同步个数控制功能,来控制索引同时同步的个数。同时要求索引的大小不宜太大,防止个别索引阻塞整体的数据复制进度,对集群索引健康程度要求较高。
- 标注只读索引,对于只读索引,如果源索引未损坏,就不进行CCR关系的变更。主备集群都可以提供读的服务。
到了这里,关于【ES实战】ES的CCR对多活支撑的探讨的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!