导航菜单
路很长,又很短
博主信息
昵   称:Cocodroid ->关于我
Q     Q:2531075716
博文数:360
阅读量:2225653
访问量:259911
至今:
×
云标签 标签球>>
云标签 - Su的技术博客
Tags : Solr,源码分析发表时间: 2016-01-31 19:58:27

题记:

       我们在使用SolrCloud中会经常发现会有备份的shard出现状态Recoverying,这就表明SolrCloud的数据存在着不一致性,需要进行Recovery,这个时候的SolrCloud建索引是不会写入索引文件中的(每个shard接受到update后写入自己的ulog中)。关于Recovery的内容包含三篇,本文是第一篇介绍Recovery的原因以及总体流程。solr_logo1

1. Recovery的起因

     Recovery一般发生在以下三个时候:

  • SolrCloud启动的时候,主要由于在建索引的时候发生意外关闭,导致一些shard的数据与leader不一致,那么在启动的时候刚起的shard就会从leader那里同步数据。
  • SolrCloud在进行leader选举中出现错误,一般出现在leader宕机引起replica进行选举成leader过程中。
  • SolrCloud在进行update时候,由于某种原因leader转发update至replica没有成功,会迫使replica进行recoverying进行数据同步。

     前面两种情况暂时不介绍,本文先介绍下第三种情况。大致原理如下图所示:

042330106863130

    之前在<Solr4.8.0源码分析(15) 之 SolrCloud索引深入(2)>中讲到,不管update请求发送到哪个shard 分片中,最后在solrcloud里面进行分发的顺序都是从Leader发往Replica。Leader接受到update请求后先将document放入自己的索引文件以及update写入ulog中,然后将update同时转发给各个Replica分片。这就流程在就是之前讲到的add的索引链过程。

    那么在索引链的add过程完毕后,SolrCloud会再依次调用finish()函数用来接受每一个Replica的响应,检查Replica的update操作是否成功。如果一旦有一个Replica没有成功,就会向update失败的Replica发送RequestRecovering命令强迫该分片进行Recoverying。

 1 private void doFinish() {
 2     // TODO: if not a forward and replication req is not specified, we could
 3     // send in a background thread
 4 
 5     cmdDistrib.finish();
 6     List<Error> errors = cmdDistrib.getErrors();
 7     // TODO - we may need to tell about more than one error...
 8     
 9     // if its a forward, any fail is a problem - 
10     // otherwise we assume things are fine if we got it locally
11     // until we start allowing min replication param
12     if (errors.size() > 0) {
13       // if one node is a RetryNode, this was a forward request
14       if (errors.get(0).req.node instanceof RetryNode) {
15         rsp.setException(errors.get(0).e);
16       } else {
17         if (log.isWarnEnabled()) {
18           for (Error error : errors) {
19             log.warn("Error sending update", error.e);
20           }
21         }
22       }
23       // else
24       // for now we donx27t error - we assume if it was added locally, we
25       // succeeded 
26     }
27    
28     
29     // if it is not a forward request, for each fail, try to tell them to
30     // recover - the doc was already added locally, so it should have been
31     // legit
32 
33     for (final SolrCmdDistributor.Error error : errors) {
34       if (error.req.node instanceof RetryNode) {
35         // we donx27t try to force a leader to recover
36         // when we cannot forward to it
37         continue;
38       }
39       // TODO: we should force their state to recovering ??
40       // TODO: do retries??
41       // TODO: what if its is already recovering? Right now recoveries queue up -
42       // should they?
43       final String recoveryUrl = error.req.node.getBaseUrl();
44       
45       Thread thread = new Thread() {
46         {
47           setDaemon(true);
48         }
49         @Override
50         public void run() {
51           log.info("try and ask " + recoveryUrl + " to recover");
52           HttpSolrServer server = new HttpSolrServer(recoveryUrl);
53           try {
54             server.setSoTimeout(60000);
55             server.setConnectionTimeout(15000);
56             
57             RequestRecovery recoverRequestCmd = new RequestRecovery();
58             recoverRequestCmd.setAction(CoreAdminAction.REQUESTRECOVERY);
59             recoverRequestCmd.setCoreName(error.req.node.getCoreName());
60             try {
61               server.request(recoverRequestCmd);
62             } catch (Throwable t) {
63               SolrException.log(log, recoveryUrl
64                   + ": Could not tell a replica to recover", t);
65             }
66           } finally {
67             server.shutdown();
68           }
69         }
70       };
71       ExecutorService executor = req.getCore().getCoreDescriptor().getCoreContainer().getUpdateShardHandler().getUpdateExecutor();
72       executor.execute(thread);
73       
74     }
75

 

 

2. Recovery的总体流程

      Replica接收到来自Leader的RequestRecovery命令后就会开始进行RecoveryStrategy线程,然后进行Recovery。总体流程如下图索引:

042342510302708

  • 在RequestRecovery请求判断中,我例举了一部分(不是全部)请求命令,这是正常的索引链过程。
  • 如果接受到的是RequestRecovery命令,那么本分片就会启动RecoveryStrategy线程来进行Recovery。
1       // if true, we are recovering after startup and shouldnx27t have (or be receiving) additional updates (except for local tlog recovery)
2       boolean recoveringAfterStartup = recoveryStrat == null;
3 
4       recoveryStrat = new RecoveryStrategy(cc, cd, this);
5       recoveryStrat.setRecoveringAfterStartup(recoveringAfterStartup);
6       recoveryStrat.start();
7       recoveryRunning = true;

 

 

 

  • 分片会设置分片的状态recoverying。需要指出的是如果一旦检测到本分片成为了leader,那么Recovery过程就会退出。因为Recovery是从leader中同步数据的。
1         zkController.publish(core.getCoreDescriptor(), ZkStateReader.RECOVERING);

 

 

 

  • 这里要判断下firsttime是否为true(在重启分片的时候会检查之前是否进行replication且没做完就被关闭了),firsttime是控制是否先进入PeerSync Recovery策略的,如果为false则跳过PeerSync进入Replicate。
 1     if (recoveringAfterStartup) {
 2       // if wex27re recovering after startup (i.e. we have been down), then we need to know what the last versions were
 3       // when we went down.  We may have received updates since then.
 4       recentVersions = startingVersions;
 5       try {
 6         if ((ulog.getStartingOperation() & UpdateLog.FLAG_GAP) != 0) {
 7           // last operation at the time of startup had the GAP flag set...
 8           // this means we were previously doing a full index replication
 9           // that probably didnx27t complete and buffering updates in the
10           // meantime.
11           log.info("Looks like a previous replication recovery did not complete - skipping peer sync. core="
12               + coreName);
13           firstTime = false; // skip peersync
14         }
15       } catch (Exception e) {
16         SolrException.log(log, "Error trying to get ulog starting operation. core="
17             + coreName, e);
18         firstTime = false; // skip peersync
19       }
20     }

 

 

  • 最后进行选择进入是PeerSync策略和Replicate策略,在<Solr In Action 笔记(4) 之 SolrCloud分布式索引基础>中简单提到过两者的区别。关于具体的不同将在后面两节详细介绍。

     

     

    • Peer sync, 如果中断的时间较短,recovering node只是丢失少量update请求,那么它可以从leader的update log中获取。这个临界值是100个update请求,如果大于100,就会从leader进行完整的索引快照恢复。
    • Replication, 如果节点下线太久以至于不能从leader那进行同步,它就会使用solr的基于http进行索引的快照恢复。
  • 最后设置分片的状态为active。并判断是否是sucessfulrrecovery,如果否则会多出尝试Recovery。

 

总结:

      本文主要介绍了Recovery的起因以及Recovery过程,由于是简述所以内容较简单,主要提到了两种不同的Recovery策略,后续两文种将分别详细介绍。

 

转载 http://www.cnblogs.com/rcfeng/
...阅读原文
文章来源:itd4j 类别:搜索引擎| 阅读(1727)
推荐文章