没有合适的资源?快使用搜索试试~ 我知道了~
研究 elasticsearch_217实用知识库分享
1.该资源内容由用户上传,如若侵权请联系客服进行举报
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
2.虚拟产品一经售出概不退款(资源遇到问题,请及时私信上传者)
版权申诉
0 下载量 23 浏览量
2023-11-05
22:27:43
上传
评论
收藏 7.39MB PDF 举报
温馨提示
试读
227页
资源研究 elasticsearch_217实用知识库分享知识分享
资源推荐
资源详情
资源评论
研究 elasticsearch_217
目录
研究 elasticsearch_217 1
第1篇 Elasticsearch 源码探究 ——故障探测和恢复机制 2
第2篇 Elasticsearch 8.X 节点角色划分深入详解 19
第3篇 干货 | Elasticsearch 8.X 节点角色划分深入详解 28
第4篇 深度探索 Elasticsearch 8.X:function_score 参数解读与实战案例分析 37
第5篇 Elasticsearch 架构原理 48
第6篇 Elasticsearch的基本概念及工作原理 65
第7篇 ElasticSearch的基本概念和集群分布式底层实现 69
第8篇 ElasticSearch入门与原理浅析 78
第9篇 分布式搜索引擎Elasticsearch解析 92
第10篇 从400+节点ElasticSearch集群的运维中,我们总结了这些经验 105
第11篇 Elasticsearch 8.X 集群无响应,怎么办? 112
第12篇 Elasticsearch最基础的原理 118
第13篇 Elasticsearch分布式原理初探 155
第14篇 Elasticsearch文档原理 160
第15篇 一份热乎的笔记:Elasticsearch搜索引擎 180
第16篇 源码详解 Elasticsearch refresh 机制 200
第17篇 图解elasticsearch的写入流程(包含对refresh、fsync、flush操作的理解) 209
第18篇 elasticsearch中的Translog详解 及其参数与调优 212
第19篇 Elasticsearch数据复制介绍 214
第20篇 Elasticsearch系列---并发控制及乐观锁实现原理 221
Elasticsearch 源码探究 ——故障探测和恢复机制
1、Elasticsearch 故障探测及熔断背景
探究Elasticsearch7.10.2 节点之间的故障探测以及熔断故障是怎么做的,思考生产上的最佳实
践。
服务端故障场景:
单个master挂掉
除了断点断网,状态同步异常,主master也会认为自己已经失败,会退出,然后选举
新的master
Elasticsearch 是一种基于点对点的系统,其中节点直接相互通信。主节点的职责是
维护全局集群状态并在节点加入或离开集群时重新分配分片。每次集群状态更改时,
新状态都会发布到集群中的所有节点。
主master挂掉
备master挂掉
单个datanode挂掉
单个datanode 和active master 同时挂掉
服务端发生熔断
从服务端如何应对这些场景以及客户端如何应对这些场景。
2、集群故障探测认知
Elasticsearch 故障监测官方文档地址:
https://www.elastic.co/guide/en/elasticsearch/reference/7.10/cluster-fault-detection.
html
leader check 和 follower check
第1篇 Elasticsearch 源码探究 ——故障探测和恢复机制
第 1 页 /共
225 页
leader check 和 follower check 实际上都是线程,由 same 线程池执行,same 线程池是一种
DIRECTl类型的线程池,当某个任务不需要在独立的线程执行,又想被线程池管理时,于是诞生了
这种特殊类型的线程池:
在调用者线程中执行任务,这个same线程池是对用户不可见的,所以通过_cat/thread_pool看不
到这个线程池。
map.put(Names.SAME, ThreadPoolType.DIRECT);
static final ExecutorService DIRECT_EXECUTOR = EsExecutors.
newDirectExecutorService();
executors.put(Names.SAME, new ExecutorHolder(DIRECT_EXECUTOR, new Info(Names.SAME,
ThreadPoolType.DIRECT)));
关于DirectExecutorService的关键定义:
@Override
public void execute(Runnable command) {
command.run(); //
rethrowErrors(command);
}
第1篇 Elasticsearch 源码探究 ——故障探测和恢复机制
第 2 页 /共
225 页
follower check
选出的主节点会定期检查集群中的每个节点,以确保它们仍然保持连接且健康
对应实现在org.elasticsearch.cluster.coordination.FollowersChecker.
FollowerChecker#handleWakeUp
leader检查
集群中的每个节点也会定期检查选出的主节点的健康状况
对应实现在:org.elasticsearch.cluster.coordination.LeaderChecker.
CheckScheduler#handleWakeUp
相关配置
Elasticsearch 允许这些检查偶尔失败或超时而不采取任何行动。只有在连续多次检查失败后,
才认为节点出现故障。
cluster.fault_detection.
settings 相关配置如下:
cluster.fault_detection.follower_check.interval
静态
设置follower_checker的间隔, 默认1s一次
cluster.fault_detection.follower_check.timeout
静态
follower_checker的超时时间,默认10s
cluster.fault_detection.follower_check.retry_count
静态
follower_check 失败多少次会认为follower 检测失败, 默认3次, 超过这个次数之
后,当选的主节点认为该节点出现故障并将其从集群中删除
cluster.fault_detection.leader_check.interval
静态
设置leader_checker的间隔, 默认1s一次
cluster.fault_detection.leader_check.timeout
静态
leader_checker的超时时间,默认10s
cluster.fault_detection.leader_check.retry_count
静态
leader_check 失败多少次会认为leader检测失败, 默认3次, 超过这个次数之后,
节点认为当选的主节点有故障并尝试查找或选举新的主节点
注意事项:
选出的主节点检测到某个节点已断开连接,这种情况会被立即认为是故障,主节点绕过超时和重
试设置值并尝试从集群中删除节点。
类似地,如果节点检测到选出的主节点已断开连接,则这种情况将被视为立即故障。节点绕过超
时和重试设置并重新启动其发现阶段以尝试查找或选举新的主节点。
3、选举认知
因为 master节点挂掉的时候,可能有两种情况, 主master挂掉和备master挂掉。如果主master
挂掉就会触发选举。
所以分析一下相关选举配置如下:
discovery.cluster_formation_warning_timeout
静态
多久没选举完成就会打印出”master not discovered”
discovery.find_peers_interval
第1篇 Elasticsearch 源码探究 ——故障探测和恢复机制
第 3 页 /共
225 页
剩余226页未读,继续阅读
资源评论
北极象
- 粉丝: 1w+
- 资源: 345
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功