疲劳是最舒适的枕头,努力工作吧。

这段ES英文如何正确的理解啊?

Elasticsearch | 作者 Charele | 发布于2023年07月24日 | 阅读数:1269

222.PNG

 
英文nice的看下,能理解它的意思的。
我看了几下,还没明白。所以代码也不知所云,,,
 
 
你的问题补充太简单了,一个详细的问题描述能够让大家更快的帮助你,请继续完善问题描述!
已邀请:

Charele - Cisco4321

赞同来自: kin122

经过好久痛苦地摸索,好像明天了其中的道理,只是还不能确认。
记录一下以备自己更深理解。看看其它人有没有不同的看法,指出其中的错误。
 
比如分片现在是如下场景:现在分片中有如下数据,
1 绿色的,已经flush过的,都是安全的
2 黄色的,已经sync过的,日志存盘了,数据还在内存中
3 红色的,不安全,日志和数据都没存
111.PNG

 
假设现在有a,b,c,x4个节点处于这种状态,
主分片在x上,x挂了,a选为新主分片。
a会把红色这一段日志,发给b,c去执行一下
 
1 哪怕没有红色这一段,就是日志为0,这个流程也会走一下
2 为什么要发红色一段给b,c执行,(因为b,c上原来就有这一段数据的)
开始没想明白,后来觉得可能a是新主,一切要以主为准。
而那些已经持久化的(绿色和黄色),让它留着
 
 
通常我们写文档,是“先写主,后写副”,
 这里这个过程就是上面英文里说的“主/副 re-sync“,走的也是写文档同样的流程,
只是实现不一样,它是“不写主,后写副”,
因为红色数据本来就是a上面的,没必要重复写

kin122

赞同来自:

您这是哪段源码呢?

Charele - Cisco4321

赞同来自:

222.PNG
 
因为a(上的分片)提升为新主,所以它的primaryTerm加+1,
副分片在收到主分片转过来的写请求时(先主后副的规则)

会检查primaryTerm是不是有变化。如果有变化,会进行两种动作
1 黄色的,(可以理解为,没有上面红色数据),只是简单的切换一下日志
 
2 红色的,就是上楼图中标的两个箭头不一致的时候,
这种情况下,它会重置分片的engine,重置只能恢复到最后flush时的状态,
内部会replay黄色的那段数据,(因为sync过了,有日志)
 
所以就是恢复到“全局检查点"位置。所以它的方法叫"resetEngineToGlobalCheckpoint"
 
等于副分片自己红色的那块数据就作废丢掉了。
 
副分片上等重置完成后(也就是"primaryTerm不一致"这个异常处理完后)
,就会replay上楼中a发过来的红色数据,这样数据就完整了,跟主分片一致。

Charele - Cisco4321

赞同来自:

333.PNG

上面说的,是正常情况下,新主a的情况,就是下面紫色执行的。
 
 
原始问题,那段英文描述的是:现在a在执行紫色时又挂了,又选出了新主b,
新主b要怎么做呢?

要回复问题请先登录注册