此时我预测结果为 "_version" : 3 "_seq_no" : 7 结果为 "_version" : 3 "_seq_no" : 5 这和我预料的并不一样啊 再看看第三个文档的信息 我们还记得插入时为 "_version" : 1 "_seq_no" : 2 GET /lts/_doc/3 那我预测信息不变 运行看一下结果 这次我的预测是正确的了 现在插入第四个文档
6.x 版本之后引入了 seqNo,恢复会涉及到 seqNo+translog,这也是6.x提升恢复速度的一大改进。我们重点关注流程中第 2、4、5、7、10、12 步骤中的远程调用,它们的作用分别是: 第2步:分片分配的目标节点向源节点(一般是主分片)发起分片恢复请求,携带起始 seqNo 和 syncId。 第4步:发送数据文件信息,告知目标...
_seq_no 和 _primary_term 是用来并发控制,和_version不同,_version属于当前文档,而_seq_no属于整个index。 _seq_no & _primary_term _seq_no:索引级别的版本号,索引中所有文档共享一个_seq_no。 _primary_term:primary_term是一个整数,每当Primary Shard发生重新分配时,比如节点重启,Primary选举或重新分配等p...
_primary_term:文档所在主分区,这个可以跟_seq_no字段搭配实现乐观锁 文档数据示例: { "_index": "mtr", "_type": "_doc", "_id": "1", "_version": 2, "_seq_no": 1, "_primary_term": 1, "_source": { "id": 1, "mtr_id": 1, "mtr_name": "test.mp4", "url": "这是一个...
{"_index":"products","_type":"_doc","_id":"sjfYnXwBVVbJgt24PlVU","_version":1,"result":"created","_shards":{"total":1,"successful":1,"failed":0},"_seq_no":3,"_primary_term":1} 2、查询文档 代码语言:javascript 代码运行次数:0 ...
1.插入测试数据 此时 _version 为 1 修改成功 此时 _version 为 2 http://192.168.1.200:9200/my_doc/_doc/10/_update if_seq_no与if_primary_term 模拟并发请求 从结果可以看出 kangxi222被更新成功
step2 更新数据的时候,是在 step1 的获取已写入文档的 if_seq_no=0 和 if_primary_term=1 基础上完成的。 这样能有效避免冲突。 6.3 批量更新和批量删除忽略冲突实现 如下是在开篇的基础上加了:conflicts=proceed。 conflicts 默认值是终止,而 proceed...
primary_term:primary_term也和_seq_no一样是一个整数,每当Primary Shard发生重新分配时,比如重启,Primary选举等,_primary_term会递增1 found:查询的ID正确那么ture, 如果 Id 不正确,就查不到数据,found字段就是false。 _source:文档的原始JSON数据,这才是我们储存在ES中的业务数据。
step2 更新数据的时候,是在 step1 的获取已写入文档的 if_seq_no=0 和 if_primary_term=1 基础上完成的。 这样能有效避免冲突。 6.3 批量更新和批量删除忽略冲突实现 如下是在开篇的基础上加了:conflicts=proceed。 conflicts 默认值是终止,而 proceed 代表继续。
"_seq_no" : 3, "_primary_term" : 1, "found" : true, "_source" : { "name" : "jack_2", "age" : "100" }} 删除id 为 1 的数据。curl -XDELETE -u elastic:test123 \http://11.8.36.25:8000/index-1/_doc/1 查询索引 index-1 ,此时两个集群上 id 为 1 的文档都已经删除。GET...