ElasticSearch的gateway功能,官方上的解释为时间机器。当集群整体down掉的时候,就好比时间机器一样进行数据的恢复。因此ElasticSearch的gateway模块就是为了集群的整体数据恢复服务的。
在上篇博客ElasticSearch的shard迁移中简单讲到了ElasticSearch的数据迁移,其实它算是当集群中有部分节点down掉后的局部恢复功能。本篇博客简要分析整体数据恢复gateway功能模块,主要针对的是Local方式。
仔细分析ElasticSearch生成的数据,会发现包括三方面的数据:state、index、translog。其中state存储的是集群中的状态信息,index是lucene的索引文件,而translog是ElasticSearch为lucene添加的日志文件。在上篇博客中,数据迁移只用到了index和translog。这里面讲到的gateway功能这三种数据全部用到了。
Lucene的索引恢复是比较简单的,只是将IndexWriter的打开模式设置为append即可。然而ElasticSearch是分布式的系统,它将数据打碎了分配到不同的shard上,这种数据恢复就很有难度了。
这里我认为的难点:
1) Elasticsearch 如何恢复路由信息,将旧的shard数据一一对应上。(否则数据是不可用的)
2) Elasticsearch如何保证的主副本数据的一致性。(在数据迁移的时候也有这方面的问题,上篇博客没有讲清楚,有遗漏点,后期补充。)
3) Elasticsearch是如何利用translog里面的数据的,它的读取时机是什么时候。
首先简要提下state文件是如何写入的。这里可以参考LocalGateway、LocalGatewayMetaState和LocalGatewayShardsState类,注意到它们都是ClusterStateListener的实现类。因此是当集群状态有变化时会自动存储的。
调试代码可以发现:global文件中的信息是对应的MetaData对象。Index的state文件信息是存储的IndexMetaData对象。而shard的state文件存储的是ShardStateInfo对象。经过分析发现这些对象中都是没有存储集群的路由表信息的。那么Elasticsearch是如何恢复路由信息的?下面引出Elasticsearch恢复路由信息的具体过程。
在Elasticsearch节点启动的时候,会执行InternalNode的start方法。代码如下: