lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zeng Lames <lezhi.z...@gmail.com>
Subject Re: SolrCloud graph status is out of date
Date Fri, 11 Jan 2013 02:56:15 GMT
thanks Mark. looking forward it


On Fri, Jan 11, 2013 at 9:28 AM, Mark Miller <markrmiller@gmail.com> wrote:

> Looks like we are talking about making a release candidate next week.
>
> Mark
>
> Sent from my iPhone
>
> On Jan 10, 2013, at 7:50 PM, Zeng Lames <lezhi.zeng@gmail.com> wrote:
>
> > thanks Mark. may I know the target release date of 4.1?
> >
> >
> > On Thu, Jan 10, 2013 at 10:13 PM, Mark Miller <markrmiller@gmail.com>
> wrote:
> >
> >> It may still be related. Even a non empty index can have no versions (eg
> >> one that was just replicated). Should behave better in this case in 4.1.
> >>
> >> - Mark
> >>
> >> On Jan 10, 2013, at 12:41 AM, Zeng Lames <lezhi.zeng@gmail.com> wrote:
> >>
> >>> thanks Mark. will further dig into the logs. there is another problem
> >>> related.
> >>>
> >>> we have collections with 3 shards (2 nodes in one shard), the
> collection
> >>> have about 1000 records in it. but unfortunately that after the leader
> is
> >>> down, replica node failed to become the leader.the detail is : after
> the
> >>> leader node is down, replica node try to become the new leader, but it
> >> said
> >>>
> >>> =======================
> >>> ShardLeaderElectionContext.runLeaderProcess(131) - Running the leader
> >>> process.
> >>> ShardLeaderElectionContext.shouldIBeLeader(331) - Checking if I should
> >> try
> >>> and be the leader.
> >>> ShardLeaderElectionContext.shouldIBeLeader(339) - My last published
> State
> >>> was Active, it's okay to be the leader.
> >>> ShardLeaderElectionContext.runLeaderProcess(164) - I may be the new
> >> leader
> >>> - try and sync
> >>> SyncStrategy.sync(89) - Sync replicas to
> >>> http://localhost:8486/solr/exception/
> >>> PeerSync.sync(182) - PeerSync: core=exception
> >>> url=http://localhost:8486/solr START
> >>> replicas=[http://localhost:8483/solr/exception/] nUpdates=100
> >>> PeerSync.sync(250) - PeerSync: core=exception
> >>> url=http://localhost:8486/solr DONE.
> >>> We have no versions.  sync failed.
> >>> SyncStrategy.log(114) - Sync Failed
> >>> ShardLeaderElectionContext.rejoinLeaderElection(311) - There is a
> better
> >>> leader candidate than us - going back into recovery
> >>> DefaultSolrCoreState.doRecovery(214) - Running recovery - first
> canceling
> >>> any ongoing recovery
> >>> ========================
> >>>
> >>> after that, it try to recovery from the leader node, which is already
> >> down.
> >>> then recovery + failed + recovery.....
> >>>
> >>> is it related to SOLR-3939 and SOLR-3940? but the index data isn't
> empty.
> >>>
> >>>
> >>> On Thu, Jan 10, 2013 at 10:09 AM, Mark Miller <markrmiller@gmail.com>
> >> wrote:
> >>>
> >>>> It may be able to do that because it's forwarding requests to other
> >> nodes
> >>>> that are up?
> >>>>
> >>>> Would be good to dig into the logs to see if you can narrow in on the
> >>>> reason for the recovery_failed.
> >>>>
> >>>> - Mark
> >>>>
> >>>> On Jan 9, 2013, at 8:52 PM, Zeng Lames <lezhi.zeng@gmail.com>
wrote:
> >>>>
> >>>>> Hi ,
> >>>>>
> >>>>> we meet below strange case in production environment. from the Solr
> >> Admin
> >>>>> Console -> Cloud -> Graph, we can find that one node is in
> >>>> recovery_failed
> >>>>> status. but at the same time, we found that the recovery_failed
node
> >> can
> >>>>> server query/update request normally.
> >>>>>
> >>>>> any idea about it? thanks!
> >>>>>
> >>>>> --
> >>>>> Best Wishes!
> >>>>> Lames
> >>>
> >>>
> >>> --
> >>> Best Wishes!
> >>> Lames
> >
> >
> > --
> > Best Wishes!
> > Lames
>



-- 
Best Wishes!
Lames

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message