本文主要是介绍【ES实战】ES的CCR对多活支撑的探讨，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
文章目录
- ES的CCR对多活支撑的探讨
- ES CCR的简介
- ES的 Cross-cluster replication（CCR）是什么
- 复制原理的注意点
- 使用要求
- 主要功能
- ES可支持的容灾建设
- 真·多活
- 伪·多活（热备）
- ES的CCR支撑多活的问题
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修复完成后，在提供写的功能。
- 在业务字段中增加区分字段，可以是时间，或版本号。数据补偿写入时进行校验写入。
-
流量控制问题
ES的CCR是基于索引级别配置的，那么在从索引初始化的时候，在占用集群间会产生大量的网络带宽，需要进行流量控制。同理在发生切换后。主从索引关系的变化都会发生大量的数据同步，集群间的流量就会暴涨。需要进行控制。
- 增加主从索引同步个数控制功能，来控制索引同时同步的个数。同时要求索引的大小不宜太大，防止个别索引阻塞整体的数据复制进度，对集群索引健康程度要求较高。
- 标注只读索引，对于只读索引，如果源索引未损坏，就不进行CCR关系的变更。主备集群都可以提供读的服务。
这篇关于【ES实战】ES的CCR对多活支撑的探讨的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
