现象：
今天web开发人员反馈，在腾讯云对某一个客户的某表数据执行相同的查询结果，有时候不返回数据；
我们是按周区分索引的，数据量不大，去掉时间条件执行查询发现会交替出现 命中21980和命中的8999结果；
解决：
1.首先简单查询其他的表或者其他的集群有没有类似的问题，排除大环境问题；
2.查看今天的日志并没有发现报错；不过发现了一些WARN 日志，大概的意思主副本数据同步告警，如下：
[2023-05-04T07:17:16,497][WARN ][o.e.i.f.SyncedFlushService] [chates02] [indexName_2023-05-01][4] can't to issue sync id [dGHQ0df6Tw6cLThlfwRFMg] for out of sync replica [[indexName_2023-05-01][4], node[qg1VO946RB2JJZZneBn8ZA], [R], s[STARTED], a[id=ePOFKvq8S7K83nWlAQRG4Q]] with num docs [8077]; num docs on primary [19131]
3.执行命令查询主副本主片和副本的doc数发现个别主片和副本的doc数不一致，命令如下
因为es查询每次是随机选择主片和副本的数据返回，所以会出现每次查询结果不一样的问题；
当查询到这里其实已经可以通过重建副本解决当前问题现象。
4. 为什么会出现这个问题？为什么只有本周的索引有问题，以前的索引验证了没有此问题？以后万一在重要的es集群再出现类似的问题，损失就太大了。
es写数据的流程是先写主片然后主片同步给副本，主片和副本是分布在不同的节点。隐隐约约猜测主副数据不一致 可能是脑裂或者节点间的通讯有异常；
5.继续判断前几天的日志，发现有一个一个WARN 日志，节点之间的通信超过30s，
对应的 配置为discovery.zen.ping_timeout: 30s，但是30s 已经很长了；
[2023-05-02T14:29:53,355][WARN ][o.e.d.z.UnicastZenPing ] [chates02] failed to send ping to [{chates01}{qg1VO946RB2JJZZneBn8ZA}{XBBKiDAMS_2vj-c57D0HzQ}{esIp}{esIp:9300}{ml.machine_memory=33566519296, ml.max_open_jobs=20, xpack.installed=true, ml.enabled=true}]
org.elasticsearch.transport.ReceiveTimeoutTransportException: [chates01][esIp:9300][internal:discovery/zen/unicast]
6. 继续查看配置 discovery.zen.minimum_master_nodes：1
这是master选举的规则，我们这个集群是局部业务的小集群，数据量很少，只有两个节点；由此可以推断是 节点间通信断开，而又符合 master选举机制>=1,导致集群脑裂；
7. 优化：通知运维增加到数奇数个节点数，master 选举规则设置为 (节点数/2)+1 ，由此该问题现象解决。
8.导致节点通信断开的原因是什么？这个集群的数据量非常小，负载很低；猜测 有可能是当时内存占满了影响通信或者是云厂商的网络有问题
查看当时的内存占用，并没有占满，这个以后再说吧
