- A+
对于索引分片数量,我们一般在模板中统一定义,在数据规模比较大的集群中,索引分片数一般也大一些,在我的集群中设置为 24。但是,并不是所有的索引数据量都很大,这些小数据量的索引也同样有较大的分片数。在 elasticsearch 中,主节点管理分片是很大的工作量,降低集群整体分片数量可以降低 recovery 时间,减小集群状态的大小。很多时候,冷索引不会再有数据写入,此时,可以使用 shrink API 缩小索引分配数。缩小完成后,源索引可删除。
shrink API 是 es5.0之后提供的新功能,他并不对源索引进行操作,他使用与源索引相同的配置创建一个新索引,仅仅降低分配数。由于添加新文档时使用对分片数量取余获取目的分片的关系,原分片数量是新分片倍数。如果源索引的分片数为素数,目标索引的分片数只能为1.
我们跟随一个例子,分析缩小过程。
准备源索引
创建索引: my_source_index,5个主分片,1个副分片,并写入几条测试数据
通过下面的命令,将索引标记为只读,且所有分片副本都迁移到名为node-idea的节点上。
注意,“所有分片副本”不指索引的全部分片,无论主分片还是副分片,任意一个就可以。分配器也不允许将主副分片分配到同一节点。
curl -XPUT 'localhost:9200/my_source_index/_settings?pretty' -H 'Content-Type: application/json' -d' { "settings": { "index.routing.allocation.require._name": "node-idea", "index.blocks.write": true } } '
选项:
index.blocks.write
设置为 true 来禁止对索引的写操作。但索引的 metadatra 可以正常写。
缩小索引
执行shrink:
curl -XPOST 'localhost:9200/my_source_index/_shrink/my_target_index?pretty' -H 'Content-Type: application/json' -d' { "settings": { "index.number_of_replicas": 1, "index.number_of_shards": 1, "index.codec": "best_compression" }, "aliases": { "my_search_indices": {} } } '
这将创建含义一个主分片和一个副分片的目的索引:my_target_index
shrink 工作过程
引用官方手册对 shrink 工作过程的描述:
- First, it creates a new target index with the same definition as the source index, but with a smaller number of primary shards.
- Then it hard-links segments from the source index into the target index. (If the file system doesn’t support hard-linking, then all segments are copied into the new index, which is a much more time consuming process.)
- Finally, it recovers the target index as though it were a closed index which had just been re-opened.
创建新索引
第一点,使用旧索引的配置创建新索引,新索引的 shard 同样需要与源索引一样,所有副本都分配到相同节点,否则无法执行硬链接
创建硬链接
从源索引到目的索引创建硬链接。如果操作系统不支持硬链接,就拷贝lucene 分段。
在 linux 下通过 strace 命令跟踪硬链接创建过程,能清晰看到内部过程:
图中基本信息:
JYglvWRnSqmNgA3E1CahZw 为源索引
RvDP65d-QD-QTpwOCaLWOg 为目的索引
_0.cfe,_0.si,_0.cfs 类型的文件为 lucene 编号为 0 的 segment,编号依次类推
链接过程:
从源索引的 shard[0] 开始,遍历所有 shard,将所有 segment 链接到目的索引,目的索引的 segment 从 0 开始命名,依次递增。在本例中,由于源索引的 shard[0] 没有数据,因此从 shard[1] 开始链接
为什么一定要硬链接,不使用软链接?
文件系统由两部分组成,inode 和 block。block用于存储用户数据,inode 用于记录元数据,系统通过 inode 定位唯一的文件。
硬链接:文件有相同的 inode 和 block
软链接:文件有独立的 inode 和 block,block 内容为目的文件路径名
那么为什么一定要硬链接过去呢?如果软链接过去,删除源索引,目的索引的数据也会被删除,硬链接则不会。满足下面条件时操作系统才真正删除文件:
文件被打开的 fd 数量为0且硬链接数量为0
使用硬链接,删除源索引,只是将文件的硬链接数量减1
由于使用了硬链接,也因为硬链接的特性带来一些限制:不能交叉文件系统或分区进行硬链接的创建,因为不同分区和文件系统有自己的 inode。
不过,既然都是链接,shrink 完成后,修改源索引,目的索引会变吗?答案是不会。虽然链接到了源分段,shrink 期间索引只读,目标索引能看到的只有源索引的当前数据,shrink 完成后,由于 lucene 中分段的不变性,源索引新写入的数据随着 refrensh 会生成新分段,而新分段没有链接,在目标索引中是看不到的。如果源索引进行 merge,源分段被删除,硬链接数量减1,目标索引仍然不受影响。因此,shrink 完毕后最终的效果就是,两个索引的数据看起来是完全独立的
目的索引 recovery
经过链接过程之后,主分片已经就绪了,副分片还是空的,通过 recovery 将主分片数据拷贝到副分片。recovery 如何触发的?就是通过内部对索引的_close 再_open 操作
事实上,硬链接也是走的 recovery 流程,下面看一下相关实现代码
硬链接过程源码分析
硬链接过程在目标索引 my_target_index 的恢复流程中,入口:IndexShard#startRecovery,有下列几中类型的recovery:
- EXISTING_STORE 主分片从 translog恢复
- PEER 副分片从主分片远程拉取
- SNAPSHOT 从快照恢复
- LOCAL_SHARDS 只有 shrink 用到?
此时的恢复类型为 LOCAL_SHARDS,执行 storeRecovery.recoverFromLocalShards在 addIndices中,调用 lucene 中的 org.apache.lucene.store.HardlinkCopyDirectoryWrapper实现硬链接。
addIndices 将整个源索引的全部 shard 链接到目标路径。
addIndices(RecoveryState.Index indexRecoveryStats, Directory target, Directory... sources)
本例中源索引由5个分片,sources 的值为:
0 = "(store(mmapfs(/V/idea/nodes/0/indices/-Puacb8gSQG4UAvr-vNopQ/0/index)))" 1 = "(store(mmapfs(/V/idea/nodes/0/indices/-Puacb8gSQG4UAvr-vNopQ/1/index)))" 2 = "(store(mmapfs(/V/idea/nodes/0/indices/-Puacb8gSQG4UAvr-vNopQ/2/index)))" 3 = "(store(mmapfs(/V/idea/nodes/0/indices/-Puacb8gSQG4UAvr-vNopQ/3/index)))" 4 = "(store(mmapfs(/V/idea/nodes/0/indices/-Puacb8gSQG4UAvr-vNopQ/4/index)))"
target 值为:
store(mmapfs(/Volumes/RamDisk/idea/nodes/0/indices/Dcfi3m9kTW2Dfc2zUjMOoQ/0/index))
|
参考
http://cwiki.apachecn.org/pages/viewpage.action?pageId=4882799
https://lucene.apache.org/core/6_1_0/misc/org/apache/lucene/store/HardlinkCopyDirectoryWrapper.html
https://www.elastic.co/guide/en/elasticsearch/reference/master/indices-shrink-index.html
https://www.elastic.co/guide/en/elasticsearch/reference/5.5/indices-update-settings.html
- 安卓客户端下载
- 微信扫一扫
- 微信公众号
- 微信公众号扫一扫