腾讯云elasticsearch（腾讯云游戏start）

本文目录一览：

• 1、PB级大规模Elasticsearch集群运维与调优实践
• 2、腾讯云Logstash实战5-读取COS中的日志文件并写入到Elasticsearch
• 3、腾讯云Logstash实战4-使用Logstash消费kafka数据并写入到Elasticsearch
• 4、腾讯云Logstash实战1-同步两个Elasticsearch集群中的数据
• 5、Elasticsearch数据迁移与集群容灾

PB级大规模Elasticsearch集群运维与调优实践

某中型互联网公司的游戏业务，使用了腾讯云的Elasticsearch产品，采用ELK架构存储业务日志。因为游戏业务本身的日志数据量非常大(写入峰值在100w qps)，在服务客户的几个月中，踩了不少坑，经过数次优化与调整，把客户的ES集群调整的比较稳定，避免了在业务高峰时客户集群的读写异常，并且降低了客户的资金成本和使用成本。下面把服务客户过程中遇到的典型问题进行梳理，总结经验，避免再次踩坑。

解决方案架构师A: bellen, XX要上线一款新游戏，日志存储决定用ELK架构，他们决定在XX云和我们之间二选一，我们首先去他们公司和他们交流一下，争取拿下！

bellen: 好，随时有空！

。。。

和架构师一起前往该公司，跟负责底层组件的运维部门的负责人进行沟通。

XX公司运维老大：不要讲你们的PPT了，先告诉我你们能给我们带来什么！

bellen: 。。。呃，我们有很多优势。。。比如灵活地扩容缩容集群，还可以一键平滑升级集群版本，并且提供有跨机房容灾的集群从而实现高可用。。

XX公司运维老大：你说的这些别的厂商也有，我就问一个问题，我们现在要存储一年的游戏日志，不能删除数据，每天就按10TB的数据量算，一年也得有个3PB多的数据，这么大的数量，都放在SSD云盘上，我们的成本太高了，你们有什么方案既能够满足我们存储这么大数据量的需求，同时能够降低我们的成本吗？

bellen: 我们本身提供的有冷热模式的集群，热节点采用SSD云硬盘，冷节点采用SATA盘，采用ES自带的ILM索引生命周期管理功能定期把较老的索引从热节点迁移到冷节点上，这样从整体上可以降低成本。另外一方面，也可以定期把更老的索引通过snapshot快照备份到COS对象存储中，然后删除索引，这样成本就更低了。

XX公司运维老大：存储到COS就是冷存储呗，我们需要查询COS里的数据时，还得再把数据恢复到ES里？这样不行，速度太慢了，业务等不了那么长时间，我们的数据不能删除，只能放在ES里！你们能不能给我们提供一个API, 让老的索引数据虽然存储在COS里，但是通过这个API依然可以查询到数据，而不是先恢复到ES， 再进行查询？

bellen: 。。。呃，这个可以做，但是需要时间。是否可以采用hadoop on COS的架构，把存量的老的索引数据通过工具导入到COS，通过hive去查询，这样成本会非常低，数据依然是随时可查的。

XX公司运维老大：那不行，我们只想用成熟的ELK架构来做，再增加hadoop那一套东西，我们没那么多人力搞这个事!

bellen: 好吧，那可以先搞一个集群测试起来，看看性能怎么样。关于存量数据放在COS里但是也需要查询的问题，我们可以先制定方案，尽快实施起来。

XX公司运维老大：行吧，我们现在按每天10TB数据量预估，先购买一个集群，能撑3个月的数据量就行，能给一个集群配置的建议吗？

bellen: 目前支持单节点磁盘最大6TB, cpu和内存的话可以放到8核32G单节点，单节点跑2w qps写入没有问题，后面也可以进行纵向扩容和横向扩容。

XX公司运维老大：好，我们先测试一下。

N 天后，架构师A直接在微信群里反馈："bellen, 客户反馈这边的ES集群性能不行啊，使用logstash消费kafka中的日志数据，跑了快一天了数据还没追平，这是线上的集群，麻烦紧急看一下吧。。"

我一看，一脸懵, 什么时候已经上线了啊，不是还在测试中吗？

XX公司运维小B: 我们购买了8核32G*10节点的集群，单节点磁盘6TB, 索引设置的10分片1副本，现在使用logstash消费kafka中的数据，一直没有追平，kafka中还有很多数据积压，感觉是ES的写入性能有问题。

随后我立即查看了集群的监控数据，发现cpu和load都很高，jvm堆内存使用率平均都到了90%，节点jvm gc非常频繁了，部分节点因为响应缓慢，不停的离线又上线。。

经过沟通，发现用户的使用姿势是filebeat+kafka+logstash+elasticsearch, 当前已经在kafka中存储了有10天的日志数据，启动了20台logstash进行消费，logstash的batch size也调到了5000，性能瓶颈是在ES这一侧。客户8核32G*10节点的集群，理论上跑10w qps没有问题，但是logstash消费积压的数据往ES写入的qps远不止10w，所以是ES扛不住写入压力了，所以只能对ES集群进行扩容，为了加快存量数据的消费速度，先纵向扩容单节点的配置到32核64GB，之后再横向增加节点，以保证ES集群能够最大支持100w qps的写入(这里需要注意的是，增加节点后索引的分片数量也需要调整)。

所以一般新客户接入使用ES时，必须要事先评估好节点配置和集群规模，可以从以下几个方面进行评估：

上述场景2遇到的问题是业务上线前没有对集群配置和规模进行合理的评估，导致上线后ES集群负载就很高，通过合理的扩容处理，集群最终抗住了写入压力。但是又有新的问题出现了。

因为kafka积压的数据比较多，客户使用logstash消费kafka数据时，反馈有两个问题：

经过分析客户logstash的配置文件，发现问题出现的原因主要是：

分析后，对kafka和logstash进行了如下优化：

通过上述优化，最终使得logstash机器资源都被充分利用上，很快消费完堆积的kafka数据，待消费速度追平生成速度后，logstash消费kafka一直稳定运行，没有出现积压。

另外，客户一开始使用的是5.6.4版本的logstash，版本较老，使用过程中出现因为单个消息体过长导致logstash抛异常后直接退出的问题:

通过把logstash升级至高版本6.8避免了这个问题(6.x版本的logstash修复了这个问题，避免了crash)。

客户的游戏上线有一个月了，原先预估每天最多有10TB的数据量，实际则是在运营活动期间每天产生20TB的数据，原先6TB*60=360TB总量的数据盘使用率也达到了80%。针对这种情况，我们建议客户使用冷热分离的集群架构，在原先60个热节点的基础上，增加一批warm节点存储冷数据，利用ILM(索引生命周期管理)功能定期迁移热节点上的索引到warm节点上。

通过增加warm节点的方式，客户的集群磁盘总量达到了780TB， 可以满足最多三个月的存储需求。但是客户的需求还没有满足：

XX公司运维老大：给我们一个能存放一年数据的方案吧，总是通过加节点扩容磁盘的方式不是长久之计，我们得天天盯着这个集群，运维成本很高！并且一直加节点，ES会扛不住吧？

bellen: 可以尝试使用我们新上线的支持本地盘的机型，热节点最大支持7.2TB的本地SSD盘，warm节点最大支持48TB的本地SATA盘。一方面热节点的性能相比云盘提高了，另外warm节点可以支持更大的磁盘容量。单节点可以支持的磁盘容量增大了，节点数量就不用太多了，可以避免踩到因为节点数量太多而触发的坑。

XX公司运维老大：现在用的是云盘，能替换成本地盘吗，怎么替换？

bellen: 不能直接替换，需要在集群中新加入带本地盘的节点，把数据从老的云盘节点迁移到新的节点上，迁移完成后再剔除掉旧的节点，这样可以保证服务不会中断，读写都可以正常进行。

XX公司运维老大：好，可以实施，尽快搞起来！

云盘切换为本地盘，是通过调用云服务后台的API自动实施的。在实施之后，触发了数据从旧节点迁移到新节点的流程，但是大约半个小时候，问题又出现了：

XX公司运维小B: bellen, 快看一下，ES的写入快掉0了。

bellen: 。。。

通过查看集群监控，发现写入qps直接由50w降到1w，写入拒绝率猛增，通过查看集群日志，发现是因为当前小时的索引没有创建成功导致写入失败。

紧急情况下，执行了以下操作定位到了原因：

经过了这次扩容操作，总结了如下经验：

在稳定运行了一阵后，集群又出问题了。。

XX公司运维小B: bellen, 昨晚凌晨1点钟之后，集群就没有写入了，现在kafka里有大量的数据堆积，麻烦尽快看一下？

bellen: 。。。

通过cerebro查看集群，发现集群处于yellow状态，然后发现集群有大量的错误日志：

然后再进一步查看集群日志，发现有"master not discovered yet..."之类的错误日志，检查三个master节点，发现有两个master挂掉，只剩一个了，集群无法选主。

登陆到挂了了master节点机器上，发现保活程序无法启动es进程，第一直觉是es进程oom了；此时也发现master节点磁盘使用率100%， 检查了JVM堆内存快照文件目录，发现有大量的快照文件，于是删除了一部分文件，重启es进程，进程正常启动了；但是问题是堆内存使用率太高，gc非常频繁，master节点响应非常慢，大量的创建索引的任务都超时，阻塞在任务队列中，集群还是无法恢复正常。

看到集群master节点的配置是16核32GB内存，JVM实际只分配了16GB内存，此时只好通过对master节点原地增加内存到64GB(虚拟机，使用的腾讯云CVM， 可以调整机器规格，需要重启)，master节点机器重启之后，修改了es目录jvm.options文件，调整了堆内存大小，重新启动了es进程。

3个master节点都恢复正常了，但是分片还需要进行恢复，通过GET _cluster/health看到集群当前有超过10w个分片，而这些分片恢复还需要一段时间，通过调大"cluster.routing.allocation.node_concurrent_recoveries"， 增大分片恢复的并发数量。实际上5w个主分片恢复的是比较快的了，但是副本分片的恢复就相对慢很多，因为部分副本分片需要从主分片上同步数据才能恢复。此时可以采取的方式是把部分旧的索引副本数量调为0， 让大量副本分片恢复的任务尽快结束，保证新索引能够正常创建，从而使得集群能够正常写入。

总结这次故障的根本原因是集群的索引和分片数量太多，集群元数据占用了大量的堆内存，而master节点本身的JVM内存只有16GB(数据节点有32GB)， master节点频繁full gc导致master节点异常，从而最终导致整个集群异常。所以要解决这个问题，还是得从根本上解决集群的分片数量过多的问题。

目前日志索引是按照小时创建，60分片1副本，每天有24*60*2=2880个分片，每个月就产生86400个分片，这么多的分片可能会带来严重的问题。有以下几种方式解决分片数量过多的问题：

和客户沟通过后，客户表示可以接受方式1和方式2，但是方式3和4不能接受，因为考虑到存在磁盘故障的可能性，必须保留一个副本来保证数据的可靠性；另外还必须保证所有数据都是随时可查询的，不能关闭。

在场景5中，虽然通过临时给master节点增加内存，抗住了10w分片，但是不能从根本上解决问题。客户的数据是计划保留一年的，如果不进行优化，集群必然扛不住数十万个分片。所以接下来需要着重解决集群整体分片数量过多的问题，在场景5的最后提到了，用户可以接受开启shrink以及降低索引创建粒度(经过调整后，每两个小时创建一个索引)，这在一定程度上减少了分片的数量，能够使集群暂时稳定一阵。

辅助客户在kibana上配置了如下的ILM策略：

在warm phase, 把创建时间超过360小时的索引从hot节点迁移到warm节点上，保持索引的副本数量为1，之所以使用360小时作为条件，而不是15天作为条件，是因为客户的索引是按小时创建的，如果以15天作为迁移条件，则在每天凌晨都会同时触发15天前的24个索引一共24*120=2880个分片同时开始迁移索引，容易引发场景4中介绍的由于迁移分片数量过多导致创建索引被阻塞的问题，所以以360小时作为条件，则在每个小时只会执行一个索引的迁移，这样把24个索引的迁移任务打平，避免其它任务被阻塞的情况发生。

同时，也在warm phase阶段，设置索引shrink，把索引的分片数缩成5个，因为老的索引已经不执行写入了，所以也可以执行force merge, 强制把segment文件合并为1个，可以获得更好的查询性能。

另外，设置了ILM策略后，可以在索引模板里增加index.lifecycle.name配置，使得所有新创建的索引都可以和新添加的ILM策略关联，从而使得ILM能够正常运行。

客户使用的ES版本是6.8.2， 在运行ILM的过程中， 也发现一些问题：

这是因为shrink操作需要新把索引完整的一份数据都迁移到一个节点上，然后在内存中构建新的分片元数据，把新的分片通过软链接指向到几个老的分片的数据，在ILM中执行shrink时，ILM会对索引进行如下配置：

问题是索引包含副本，而主分片和副本分片又不能在同一个节点上，所以会出现部分分片无法分配的情况(不是全部，只有一部分)，这里应该是触发了6.8版本的ILM的bug，需要查看源码才能定位解决这个bug，目前还在研究中。当前的workaround是通过脚本定期扫描出现unassigned shards的索引，修改其settings:

优先保证分片先从hot节点迁移到warm节点，这样后续的shrink才能顺利执行(也可能执行失败，因为60个分片都在一个节点上，可能会触发rebalance, 导致分片迁移走，shrink的前置条件又不满足，导致执行失败)。要完全规避这个问题，还得在ILM策略中设置，满足创建时间超过360个小时的索引，副本直接调整为0，但是客户又不接受，没办法。

在场景5和6中，介绍了10w个分片会给集群带来的影响和通过开启shrink来降低分片数量，但是仍然有两个需要重点解决的问题：

可以估算一下，按小时建索引，60分片1副本，一年的分片数为24*120*365=1051200个分片，执行shrink后分片数量24*10*350 + 24*120*15 = 127200(15天内的新索引为了保障写入性能和数据可靠性，仍然保持60分片1副本，旧的索引shrink为5分片1副本), 仍然有超过10w个分片。结合集群一年总的存储量和单个分片可以支持的数据量大小进行评估，我们期望集群总体的分片数量可以稳定为6w~8w，怎么优化？

可以想到的方案是执行数据冷备份，把比较老的索引都冷备到其它的存储介质上比如HDFS，S3，腾讯云的COS对象存储等，但是问题是这些冷备的数据如果也要查询，需要先恢复到ES中才可查，恢复速度比较慢，客户无法接受。由此也产生了新的想法，目前老的索引仍然是1副本，可以把老索引先进行冷备份，再把副本调为0，这样做有以下几点好处：

经过和客户沟通，客户接受了上述方案，计划把老索引冷备到腾讯云的对象存储COS中，实施步骤为：

其中步骤1的实施可以通过脚本实现，本案例中采用腾讯云SCF云函数进行实施，方便快捷可监控。实施要点有：

在实施完步骤1之后，就可以批量把对索引进行过备份的索引副本数都调为0， 这样一次性释放了很多磁盘空间，并且显著降低了集群整体的分片数量。

接下来实施步骤2，需要每天执行一次快照，多创建时间较久的索引进行备份，实施比较简单，可以通过crontab定时执行脚本或者使用腾讯云SCF执行。

步骤2实施之后，就可以修改ILM策略，开启cold phase, 修改索引副本数量为0:

此处的timing是创建时间20天后，需要保证步骤2中对过去老索引数据备份先执行完成才可以进入到cold phase.

通过老索引数据冷备并且降低索引副本，我们可以把集群整体的分片数量维持在一个较低的水位，但是还有另外一个问题待解决，也即shrink失败的问题。刚好，我们可以利用对老索引数据冷备并且降低索引副本的方案，来彻底解决shrink失败的问题。

在场景5中有提到，shrink失败归根接地是因为索引的副本数量为1， 现在我们可以吧数据备份和降低副本提前，让老索引进入到ILM的warm phase中时已经是0副本，之后再执行shrink操作就不会有问题了；同时，因为副本降低了，索引从hot节点迁移到warm节点迁移的数据量也减少了一半，从而降低了集群负载，一举两得。

因此，我们需要修改ILM策略，在warm phase就把索引的副本数量调整为0， 然后去除cold phase。

另外一个可选的优化项是，对老的索引进行冻结，冻结索引是指把索引常驻内存的一些数据从内存中清理掉(比如FST, 元数据等)， 从而降低内存使用量，而在查询已经冻结的索引时，会重新构建出临时的索引数据结构存放在内存中，查询完毕再清理掉；需要注意的是，默认情况下是无法查询已经冻结的索引的，需要在查询时显式的增加"ignore_throttled=false"参数。

经过上述优化，我们最终解决了集群整体分片数量过多和shrink失败的问题。在实施过程中引入了额外的定时任务脚本实施自动化快照，实际上在7.4版本的ES中，已经有这个功能了，特性名称为 SLM (快照生命周期管理)，并且可以结合ILM使用，在ILM中增加了"wait_for_snapshot"的ACTION, 但是却只能在delete phase中使用，不满足我们的场景。

在上述的场景4-7中，我们花费大量的精力去解决问题和优化使用方式，保证ES集群能够稳定运行，支持PB级别的存储。溯本回原，如果我们能有一个方案使得客户只需要把热数据放在SSD盘上，然后冷数据存储到COS/S3上，但同时又使冷数据能够支持按需随时可查，那我们前面碰到的所有问题都迎刃而解了。可以想象得到的好处有：

而这正是目前es开源社区正在开发中的Searchable Snapshots功能，从 Searchable Snapshots API 的官方文档上可以看到，我们可以创建一个索引，将其挂载到一个指定的快照中，这个新的索引是可查询的，虽然查询时间可能会慢点，但是在日志场景中，对一些较老的索引进行查询时，延迟大点一般都是可以接受的。

所以我认为，Searchable Snapshots解决了很多痛点，将会给ES带了新的繁荣！

经历过上述运维和优化ES集群的实践，我们总结到的经验有：

从一开始和客户进行接触，了解客户诉求，逐步解决ES集群的问题，最终使得ES集群能够保持稳定，这中间的经历让我真真正正的领悟到"实践出真知"，只有不断实践，才能对异常情况迅速做出反应，以及对客户提的优化需求迅速反馈。

腾讯云Logstash实战5-读取COS中的日志文件并写入到Elasticsearch

在某些业务场景中，业务服务端的日志或者是云上组件的日志会归档存储到对象存储COS中，在需要进行查询的时候需要从COS中获取并查询日志，此时可以借助于 腾讯云Logstash 自动地读取COS中指定bucket的日志文件，然后写入到Elasticsearch中，再使用Kibana可视化组件进行查询和分析。

在“管道管理”页面，点击“新建管道”按钮，创建一个管道：

进入管道配置页面，点击“引用模板”按钮，同时引用“input-s3”和“output-elasticsearch”两个模板：

在管道配置中，分别针对“input-s3”和“output-elasticsearch”进行配置，一些关键的配置参数说明如下：

查看更多参数，可以参考 input-s3

查看更多参数，可以参考 output-elasticsearch

在配置完管道后，点击“保存并部署”创建一个管道并自动部署:

在控制台查看Logstash的运行日志，如果没有ERROR级别的日志，则说明管道运行正常：

进入到output-elasticsearch中定义的输出端的ES集群对应的kibana页面，在Dev tools工具栏里查看索引是否存在，以及索引的文档数量是否正确：

腾讯云Logstash实战4-使用Logstash消费kafka数据并写入到Elasticsearch

Logstash的一个典型应用场景，就是消费kafka中的数据并且写入到Elasticsearch, 使用 腾讯云Logstash 产品，可以通过简单的配置快速地完成这一过程。

在“管道管理”页面，点击“新建管道”按钮，创建一个管道：

进入管道配置页面，点击“引用模板”按钮，同时引用“input-kafka”和“output-elasticsearch”两个模板：

在管道配置中，分别针对“input-kafka”和“output-elasticsearch”进行配置，一些关键的配置参数说明如下：

查看更多参数，可以参考 input-kafka

查看更多参数，可以参考 output-elasticsearch

在配置完管道后，点击“保存并部署”创建一个管道并自动部署:

在控制台查看Logstash的运行日志，如果没有ERROR级别的日志，则说明管道运行正常：

进入到output-elasticsearch中定义的输出端的ES集群对应的kibana页面，在Dev tools工具栏里查看索引是否存在，以及索引的文档数量是否正确：

腾讯云Logstash实战1-同步两个Elasticsearch集群中的数据

使用Logstash也可以完成同步两个Elasticsearch集群中的数据，比如把数据从自建的Elasticsearch集群同步到腾讯云上的Elasticsearch集群，或者同步两个腾讯云上的Elasticsearch集群中的数据。本文介绍如何使用 腾讯云Logstash 产品，同步两个Elasticsearch集群中的数据。

在“管道管理”页面，点击“新建管道”按钮，创建一个管道：

进入管道配置页面，点击“引用模板”按钮，同时引用“input-elasticsearch”和“output-elasticsearch”两个模板：

在管道配置中，分别针对“input-elasticsearch”和“output-elasticsearch”进行配置，一些关键的配置参数说明如下：

查看更多参数，可以参考 input-elasticsearch

查看更多参数，可以参考 output-elasticsearch

在配置完管道后，点击“保存并部署”创建一个管道并自动部署:

在控制台查看Logstash的运行日志，如果没有ERROR级别的日志，则说明管道运行正常：

进入到output-elasticsearch中定义的输出端的ES集群对应的kibana页面，在Dev tools工具栏里查看索引是否存在，以及索引的文档数量是否正确：

Elasticsearch数据迁移与集群容灾

本文讨论如何跨集群迁移ES数据以及如何实现ES的同城跨机房容灾和异地容灾。

在ES的生产实践中，往往会遇到以下问题：

根据业务需求，存在以下场景：

如果是第一种场景，数据迁移过程中可以停止写入，可以采用诸如elasticsearch-dump、logstash、reindex、snapshot等方式进行数据迁移。实际上这几种工具大体上可以分为两类：

如果是第二种场景，数据迁移过程中旧集群不能停止写入，需要根据实际的业务场景解决数据一致性的问题：

下面介绍一下在旧集群可以停止写入的情况下进行数据迁移的几种工具的用法。

elasticsearch-dump是一款开源的ES数据迁移工具，github地址:

以下操作通过elasticdump命令将集群x.x.x.1中的companydatabase索引迁移至集群x.x.x.2。注意第一条命令先将索引的settings先迁移，如果直接迁移mapping或者data将失去原有集群中索引的配置信息如分片数量和副本数量等，当然也可以直接在目标集群中将索引创建完毕后再同步mapping与data

logstash支持从一个ES集群中读取数据然后写入到另一个ES集群，因此可以使用logstash进行数据迁移，具体的配置文件如下：

上述配置文件将源ES集群的所有索引同步到目标集群中，当然可以设置只同步指定的索引，logstash的更多功能可查阅logstash官方文档 logstash 官方文档 .

reindex是Elasticsearch提供的一个api接口，可以把数据从一个集群迁移到另外一个集群。

snapshot api是Elasticsearch用于对数据进行备份和恢复的一组api接口，可以通过snapshot api进行跨集群的数据迁移，原理就是从源ES集群创建数据快照，然后在目标ES集群中进行恢复。需要注意ES的版本问题：

如果旧集群不能停止写入，此时进行在线数据迁移，需要保证新旧集群的数据一致性。目前看来，除了官方提供的CCR功能，没有成熟的可以严格保证数据一致性的在线数据迁移方法。此时可以从业务场景出发，根据业务写入数据的特点选择合适的数据迁移方案。

一般来说，业务写入数据的特点有以下几种：

下面来具体分析不同的写入数据的特点下，该如何选择合适的数据迁移方式。

在日志或者APM的场景中，数据都是时序数据，一般索引也都是按天创建的，当天的数据只会写入当前的索引中。此时，可以先把存量的不再写入的索引数据一次性同步到新集群中，然后使用logstash或者其它工具增量同步当天的索引，待数据追平后，把业务对ES的访问切换到新集群中。

具体的实现方案为：

add only的数据写入方式，可以按照数据写入的顺序(根据_doc进行排序，如果有时间戳字段也可以根据时间戳排序)批量从旧集群中拉取数据，然后再批量写入新集群中；可以通过写程序，使用用scroll api 或者search_after参数批量拉取增量数据，再使用bulk api批量写入。

使用scroll拉取增量数据：

上述操作可以每分钟执行一次，拉起前一分钟新产生的数据，所以数据在旧集群和新集群的同步延迟为一分钟。

使用search_after批量拉取增量数据：

上述操作可以根据需要自定义事件间隔执行，每次执行时修改search_after参数的值，获取指定值之后的多条数据；search_after实际上相当于一个游标，每执行一次向前推进，从而获取到最新的数据。

使用scroll和search_after的区别是：

另外，如果不想通过写程序迁移旧集群的增量数据到新集群的话，可以使用logstash结合scroll进行增量数据的迁移，可参考的配置文件如下：

使用过程中可以根据实际业务的需求调整定时任务参数schedule以及scroll相关的参数。

业务场景如果是写入ES时既有追加，又有存量数据的更新，此时比较重要的是怎么解决update操作的数据同步问题。对于新增的数据，可以采用上述介绍的增量迁移热索引的方式同步到新集群中。对于更新的数据，此时如果索引有类似于updateTime的字段用于标记数据更新的时间，则可以通过写程序或者logstash，使用scroll api根据updateTime字段批量拉取更新的增量数据，然后再写入到新的集群中。

可参考的logstash配置文件如下：

实际应用各种，同步新增(add)的数据和更新(update)的数据可以同时进行。但是如果索引中没有类似updateTime之类的字段可以标识出哪些数据是更新过的，目前看来并没有较好的同步方式，可以采用CCR来保证旧集群和新集群的数据一致性。

如果业务写入ES时既有新增(add)数据,又有更新(update)和删除(delete)数据，可以采用6.5之后商业版X-pack插件中的CCR功能进行数据迁移。但是使用CCR有一些限制，必须要注意：

具体的使用方式如下：

如果业务是通过中间件如kafka把数据写入到ES， 则可以使用如下图中的方式，使用logstash消费kafka的数据到新集群中，在旧集群和新集群数据完全追平之后，可以切换到新集群进行业务的查询，之后再对旧的集群下线处理。

使用中间件进行同步双写的优点是：

当然，双写也可以使用其他的方式解决，比如自建proxy，业务写入时向proxy写入，proxy把请求转发到一个或者多个集群中，但是这种方式存在以下问题：

随着业务规模的增长，业务侧对使用的ES集群的数据可靠性、集群稳定性等方面的要求越来越高，所以要比较好的集群容灾方案支持业务侧的需求。

如果是公司在自建IDC机房内，通过物理机自己搭建的ES集群，在解决跨机房容灾的时候，往往会在两个机房 部署两个ES集群，一主一备，然后解决解决数据同步的问题；数据同步一般有两种方式，一种方式双写，由业务侧实现双写保证数据一致性，但是双写对业务侧是一个挑战，需要保证数据在两个集群都写成功才能算成功。另外一种方式是异步复制，业务侧只写主集群，后台再把数据同步到备集群中去，但是比较难以保证数据一致性。第三种方式是通过专线打通两个机房，实现跨机房部署，但是成本较高。

因为数据同步的复杂性，云厂商在实现ES集群跨机房容灾的时候，往往都是通过只部署一个集群解决，利用ES自身的能力同步数据。国外某云厂商实现跨机房部署ES集群的特点1是不强制使用专用主节点，如上图中的一个集群，只有两个节点，既作为数据节点也作为候选主节点；主分片和副本分片分布在两个可用区中，因为有副本分片的存在，可用区1挂掉之后集群仍然可用，但是如果两个可用区之间网络中断时，会出现脑裂的问题。如下图中使用三个专用主节点，就不会存在脑裂的问题了。

但是如果一个地域没有三个可用区怎么办呢，那就只能在其中一个可用区中放置两个专用主节点了，如国内某云厂商的解决方案：

但是重建节点的过程还是存在问题的，如上图中，集群本身的quorum应该为2，可用区1挂掉后，集群中只剩一个专用主节点，需要把quorum参数(discovery.zen.minimum_master_nodes)调整为1后集群才能够正常进行选主，等挂掉的两个专用主节点恢复之后，需要再把quorum参数(discovery.zen.minimum_master_nodes)调整为2，以避免脑裂的发生。

当然还是有可以把无法选主和脑裂这两个可能发生的问题规避掉的解决方案，如下图中国内某云厂商的解决思路：

创建双可用区集群时，必须选择3个或者5个专用主节点，后台会在一个隐藏的可用区中只部署专用主节点；方案的优点1是如果一个可用区挂掉，集群仍然能够正常选主，避免了因为不满足quorum法定票数而无法选主的情况；2是因为必须要选择三个或5个专用主节点，也避免了脑裂。

想比较一主一备两个集群进行跨机房容灾的方式，云厂商通过跨机房部署集群把原本比较复杂的主备数据同步问题解决了，但是，比较让人担心的是，机房或者可用区之间的网络延迟是否会造成集群性能下降。这里针对腾讯云的双可用区集群，使用标准的benchmark工具对两个同规格的单可用区和双可用区集群进行了压测，压测结果如下图所示：

从压测结果的查询延时和写入延时指标来看，两种类型的集群并没有明显的差异，这主要得益与云上底层网络基础设施的完善，可用区之间的网络延迟很低。

类似于同城跨机房容灾，异地容灾一般的解决思路是在异地两个机房部署一主一备两个集群。业务写入时只写主集群，再异步地把数据同步到备集群中，但是实现起来会比较复杂，因为要解决主备集群数据一致性的问题，并且跨地域的话，网络延迟会比较高；还有就是，当主集群挂掉之后，这时候切换到备集群，可能两边数据还没有追平，出现不一致，导致业务受损。当然，可以借助于kafka等中间件实现双写，但是数据链路增加了，写入延迟也增加了，并且kafka出现问题，故障可能就是灾难性的了。

一种比较常见的异步复制方法是，使用snapshot备份功能，定期比如每个小时在主集群中执行一次备份，然后在备集群中进行恢复，但是主备集群会有一个小时的数据延迟。以腾讯云为例，腾讯云的ES集群支持把数据备份到对象存储COS中，因为可以用来实现主备集群的数据同步，具体的操作步骤可以参考 。

在6.5版本官方推出了CCR功能之后，集群间数据同步的难题就迎刃而解了。可以利用CCR来实现ES集群的异地容灾：

CCR是类似于数据订阅的方式，主集群为Leader, 备集群为Follower, 备集群以pull的方式从主集群拉取数据和写请求；在定义好Follwer Index时，Follwer Index会进行初始化，从Leader中以snapshot的方式把底层的segment文件全量同步过来，初始化完成之后，再拉取写请求，拉取完写请求后，Follwer侧进行重放，完成数据的同步。CCR的优点当然是因为可以同步UPDATE/DELETE操作，数据一致性问题解决了，同步延时也减小了。

另外，基于CCR可以和前面提到的跨机房容灾的集群结合，实现两地多中心的ES集群。在上海地域，部署有多可用区集群实现跨机房的高可用，同时在北京地域部署备集群作为Follwer利用CCR同步数据，从而在集群可用性上又向前走了一步，既实现了同城跨机房容灾，又实现了跨地域容灾。

但是在出现故障时需要把集群的访问从上海切换到北京时，会有一些限制，因为CCR中的Follwer Index是只读的，不能写入，需要切换为正常的索引才能进行写入，过程也是不可逆的。不过在业务侧进行规避，比如写入时使用新的正常的索引，业务使用别名进行查询，当上海地域恢复时，再反向的把数据同步回去。

现在问题就是保证上海地域集群数据的完整性，在上海地域恢复后，可以在上海地域新建一个Follower Index，以北京地域正在进行写的索引为Leader同步数据，待数据完全追平后，再切换到上海地域进行读写，注意切换到需要新建Leader索引写入数据。

数据同步过程如下所示：

1.上海主集群正常提供服务，北京备集群从主集群Follow数据

2.上海主集群故障，业务切换到北京备集群进行读写，上海主集群恢复后从北京集群Follow数据