福州网站关键词推广,学网站建设语言,举报网站建设运行情况,嘉定网站设计公司何谓重平衡
ElasticSearch为了使数据平均分布在集群节点上#xff0c;重平衡机制会由Master节点决定索引分片具体分配到哪个Data节点以及何时在节点之间迁移分片#xff0c;使分片在数据大小、分片数量的层面上尽可能均匀分布在集群中的所有Data节点#xff0c;充分发挥每个…何谓重平衡
ElasticSearch为了使数据平均分布在集群节点上重平衡机制会由Master节点决定索引分片具体分配到哪个Data节点以及何时在节点之间迁移分片使分片在数据大小、分片数量的层面上尽可能均匀分布在集群中的所有Data节点充分发挥每个数据节点的性能。
原理及概念
ES重平衡的触发条件
初始恢复(initial recovery)副本分配(replica allocation)重新平衡(rebalancing)节点的新增和删除
主分片
索引数据会通过至少一个主分片进行存储通过增加主分片数量使数据平均分散到多个Data节点实现存储的水平扩展查询时由多个节点共同进行以提高查询效率。 注意主分片在索引创建时指定后续想要调整则需要重建索引
副本分片
用于提高数据可用性当一个主分片丢失其副本分片可以Promote成主分片如果索引的副本分片为0一旦节点出现硬件故障时可能造成数据丢失的情况。 副本分片由主分片同步其数量支持动态调整在一定程度上可以提高ES查询的吞吐量
ES查询时计算分片所在节点的路由算法
shard hash(_routing) % number_of_primary_shards
通过Hash算法确保文档均匀分布到分片中默认的_routing值为文档id可在写入数据时为需要分配到同一shard的商品指定_routing值通过算法计算查询的数据存在于哪些分片这也是为什么索引创建出来后不允许调整主分片数量的原因 # 指定_routing值 POST /my-index-000001/_doc?routingmy-routing-value { timestamp: 2099-11-15T13:12:00, message: GET /search HTTP/1.1 200 1070000, user: { id: kimchy } } # 查询时指定_routing值确保查询执行在同个分片 GET /my-index-000001/_search?routingmy-routing-value { query: { match: { user.id: kimchy } } }
ES默认的Query Then Fetch查询
Query阶段默认配置下每个节点都是Coordinating角色负责转发查询请求用户对某个索引发起查询请求到ES节点节点收到请求后以Coordinating节点的身份将请求转发给其他分片这些分片执行查询并排序。每个节点都会返回(FromSize)个排序后的文档ID和排序值给Coordinating节点。Fetch阶段Coordinating节点会将从各个分片收到的信息重新进行排序选取From到(FromSize)个文档的ID以multi get请求的方式到相应的分片获取详细的文档数据最终返回给客户端 重平衡所引发的问题真实案例
出于安全原因客户的基础设施团队每月会进行一次虚拟机安全补丁更新更新过程会批量重启所有虚拟机。
客户的ES集群正好部署在需要重启的多台虚拟机上在更新完安全补丁后所有集群的虚拟机都被正常重启同时ES集群也恢复到Green的状态。
然而客户发现ES的查询延迟比重启前慢了超过10倍
盘云团队介入检查后发现是由于重平衡引起的问题盘云团队对重平衡并发量及传输速率进行优化最终半小时完成了整个ES集群的重平衡用户查询性能得到了显著改善业务也得以恢复。
原因分析
一、重平衡影响ES查询效率
ES进行查询时会将查询请求转发给所有分片进行查询以此确保数据的准确性。 Coordinating节点转发给各个分片的查询请求后会持续等待所有分片返回查询结果当主分片未完全从ALLOCATING状态转为STARTED状态时此分片将无法响应Coordinating节点的请求导致Coordinating节点不能及时将查询结果进行Fetch并响应给客户端。 最终ES因为主分片未完成分配无法完全发挥自身的查询能力。
可通过API查询集群健康状况及分片状态观察是否所有分片正常GET _cluster/health 注意若relocating_shards不为0时说明仍有分片正在重平衡即使status为green也可能出现主分片重平衡情况 GET _cat/shards?v
确认分片状态是否为STARTED 二、重平衡优化配置影响重平衡速度
节点重启触发了ES集群的重平衡如果没有对默认的重平衡配置进行调优 默认的并发分配分片的数量为2 默认的索引数据恢复速率则是根据节点内存决定 Total Memory Default recovery rate ≤ 4 GB 40 MB/s 4 GB and ≤ 8 GB 60 MB/s 8 GB and ≤ 16 GB 90 MB/s 16 GB and ≤ 32 GB 125 MB/s 32 GB 250 MB/s
官方提供的默认配置非常保守所以当单个分片数据过大官方建议单个分片不要超过50Gb时使用默认配置进行重平衡需要耗费大量时间因此分片分配/恢复速度变慢从而拖慢了集群整体的恢复进度。
优化建议 1、注意索引分片大小设计单个分片的数据大小不应大于50Gb单个分片的document数量不应超过2亿条可结合Index Life Management功能控制索引大小 2、Gracefully Rollout Restart重启前停止索引分配关闭集群重平衡关闭服务再重启虚拟机 # 停止索引分配 PUT _cluster/settings { persistent: { cluster.routing.allocation.enable: primaries } } # 执行缓冲区数据刷新同步加速分片恢复 POST _flush/synced # 关闭集群重平衡 PUT _cluster/settings { cluster.routing.rebalance.enable: none, # 调大集群启动时从磁盘读取索引主分片后的分配速度官方不建议调整需酌情增加 cluster.routing.allocation.node_initial_primaries_recoveries: 10 } }
3、cluster settings添加永久设置调高重平衡时的并发分片数量及并发传输数据大小 PUT _cluster/settings { persistent: { # 单个节点上允许并发传入的分片数量 cluster.routing.allocation.node_concurrent_incoming_recoveries: 20, # 单个节点上允许并发传出的分片数量 cluster.routing.allocation.node_concurrent_outgoing_recoveries: 20, #同时配置incoming和outcoming cluster.routing.allocation.node_concurrent_recoveries: 20, # 索引恢复速率 indices.recovery.max_bytes_per_sec: 500mb } } 参考文档
Shard Allocation机制
官方建议的分片设计
Index Life Management
索引恢复参数说明
Cluster Settings 参数详细说明
