ElasticSearch的gateway分析

        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方法。代码如下：