怎么又是你

另类的ES的快照知识

Elasticsearch | 作者 Charele | 发布于2022年10月04日 | 阅读数:2188

其实这些东西,对大多人数没用。
 但如果你想知道,当创建快照,背后究竟发生了什么?
或者恢复照快时,究竟是怎么一个流程?
 
一下子解决不了这些复杂的疑问,
但这个文章可以当作这些疑问背后的初步认识吧。
 
建一个苍库repo1,建了一个索引a,然后对这个索引建了一个快照ss1
它会生成下面几个文件,首先得认识这些它们,
 
苍库里的结构很简单,分为:根目录 ---> 索引目录 ---> 分片目录,这三层
文件按作用放在不同的目录里
2222.png


 
 
 
已邀请:

Charele - Cisco4321

赞同来自:

这些文件差不多就是ES中"快照"的全部了
大致分为4类,用颜色区分。
 
 A 红色的,就是你可能在网上文章中看到的index-N文件
它可以说明苍库总管,是一切苍库操作的起点,
因为是核心,所以这个文件是最后才写的(因为要等到别的文件都确定下来了)
 
B 黄色的,index.latest
这个文件是可有可无的,可以忽略
 
C 蓝色的,
就是最复杂的和难理解的元数据文件,分为五种。
本来他们都是Json形式的,只是ES在写用文件的时候,
用了Lucene格式写入,所以用记事打开是乱码。
 
  按编号大概说一下,(编号,也是代码里生成这些文件的顺序,不一定是实际写文件的顺序,因为多线程)
  1> 元数据1
这个文件是5个中最复杂的,它是“这个分片相关的所有快照的文件信息(物理的和逻辑的)
作用是什么呢?举个一个例子,都说 ES的备份是增量备份,
这个“增量”如何确定的呢?就是靠这个文件来判断的,
666.png
 
  
2> 元数据2
这个文件说明了某个快照和哪些文件相关。
作用是什么呢?比如恢复时,就从这个读出要恢复的文件信息,
然后恢复
555.png

 
  
上面两个,是存在苍库里的分片目录里的,由数据节点写入
下面三个,是在所有分片都处理完后,由master写入的。
====================================================================
 
 3> 元数据3
这个好理解一点,就是ES的全局元数据,
和这个参数相关
333.png

要说注意的是:即使你用"include_global_state": false, 显式不要全局元数据,但还会生成此文件。
只是生成的文件内容有区别。
  
 4> 元数据4
这个文件在索引目录里,就是索引的元数据。
这个奇特在于,当你新建快照时,这类文件不一定会新增。这也是难理解的地方。
 
5> 元数据5
这个快照一些描述信息,通过这个贴图,一目了然
当你用这个api查看快照信息时,结果就是从这个文件中读出的
333.png
 
D 绿色部分,就是实际的数据文件备份了,
右边是es的数据文件,备份到苍库里就是左边的,
物理文件和逻辑文件,是一一对应的。(会压缩,但肯定不会合并!)
你可以看到实际有5个数据文件,但仓库里只有2个,另外3个去哪了呢?
 
 
快照的创建,删除,克隆,cleanUp等操作,
就是对苍库里这些文件做相应的调整,
快照恢复,不会对苍库产生影响,只是读而已
 
 
 
 

Charele - Cisco4321

赞同来自:

上面说到,index-N文件是总管,
它是一个Json格式的文件,所以你可用记事本打开看到内容。
 这个文件可以理解为“苍库里有哪些东西”,这么一个概念
 
一切操作以它为准则,每个操作会生成一的新的index-N(删除旧的)
所有东西都是从index-N出发,找到的(所以说它是大总管)
 
 
 在我这个最简单的场景里,关系如下: 
这些关系看起来乱七八糟的,
理解这些关系,才能理解快照操作是如何进行的
1111.png

 
有一个有意思的问题,
开始我以为创建快照要建这些形形色色的文件,比较复杂。
而删除快照只是删除相应的文件,应该比较简单。
 
但实际上,删除快照的操作比创建快照(和恢复快照)复杂得多!
我还没有搞清楚:-(

要回复问题请先登录注册