lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Au" <bill.w...@gmail.com>
Subject Re: Replication broken.. no helpful errors?
Date Fri, 07 Sep 2007 14:38:40 GMT
As I had pointed out in my first reply to this thread, you had a directory
named temp-snapshot.20070816120113
in your data directory on the slave.  Snapinstaller was mistakenly treating
that as the lastest snapshot and was installing that every time it was
called.  Snapinstaller didn't trigger a commit since the same snapshot had
already been installed.

> latest snapshot /opt/solr/data/temp-snapshot.20070816120113 already
> installed

I have open a bug to improve snapinstaller:

http://issues.apache.org/jira/browse/SOLR-346

Bill


On 9/6/07, Matthew Runo <mruno@zappos.com> wrote:
>
> Well, I've been playing around with it (removed all the snapshots,
> restarted tomcat) and it seems like it works now.. maybe.
>
> I was noticing that search2 and search3, the slaves, had searchers
> that had been opened several days ago - when we do several 100
> commits and 2 optimizes on search1, the master, every day.
>
> +--------------------------------------------------------+
>   | Matthew Runo
>   | Zappos Development
>   | mruno@zappos.com
>   | 702-943-7833
> +--------------------------------------------------------+
>
>
> On Sep 6, 2007, at 12:37 PM, Yonik Seeley wrote:
>
> > On 9/6/07, Matthew Runo <mruno@zappos.com> wrote:
> >> The thing is that a new searcher is not opened if I look in the
> >> stats.jsp page. The index version never changes.
> >
> > The index version is read from the index... hence if the lucene index
> > doesn't change (even if a ew snapshot was taken), the version won't
> > change even if a new searcher was opened.
> >
> > Is the problem on the master side now since it looks like the slave is
> > pulling a temp-snapshot?
> >
> > -Yonik
> >
>
>

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