I may be missing something but let me go back to your original statements:
1) You build the index once per week from scratch
2) You replicate this from master to slave.
My understanding of the way replication works is that it's meant to only
send along files that are new and if any files named
So just a hunch... but when the slave downloads the data from the master,
doesn't it do a commit to force solr to recognize the changes? In so doing,
wouldn't that increase the generation number? In theory it shouldn't matter
because the replication looks for files that are different to determine
On Feb 13, 2013, at 1:17 PM, Amit Nithian anith...@gmail.com wrote:
doesn't it do a commit to force solr to recognize the changes?
yes.
- Mark
Okay so then that should explain the generation difference of 1 between the
master and slave
On Wed, Feb 13, 2013 at 10:26 AM, Mark Miller markrmil...@gmail.com wrote:
On Feb 13, 2013, at 1:17 PM, Amit Nithian anith...@gmail.com wrote:
doesn't it do a commit to force solr to recognize the
OK then index generation and index version are out of count when it comes
to verify that master and slave index are in sync.
What else is possible?
The strange thing is if master is 2 or more generations ahead of slave then it
works!
With your logic the slave must _always_ be one generation
Now this is strange, the index generation and index version
is changing with replication.
e.g. master has index generation 118 index version 136059533234
and slave has index generation 118 index version 136059533234
are both same.
Now add one doc to master with commit.
master has index
Hi list,
after upgrading from solr4.0 to solr4.1 and running it for two weeks now
it turns out that replication has problems and unpredictable results.
My installation is single index 41 mio. docs / 115 GB index size / 1 master / 3
slaves.
- the master builds a new index from scratch once a week
