You've probably hit it on the head. The slave version is greater than the master version, so replication isn't "necessary". BTW, the version starts life as a timestamp, but then is simply incremented on successive commits, which accounts for what you are seeing.
You should be able to blow the index away on the slave and wait for replication and go from there. Another possibility: How much faith do you have in your slave index? If it's all good, you could simply copy *that* to the master manually and go from there. If you're rebuilding your entire index, just blow the master index away, re-index from scratch and that should work too (be sure to disable replication during the rebuild unless you want a partial index on the slave). Although copying the files *then* deciding not to use them doesn't seem like a good thing. Not sure if 3.x has the same behavior or not... Best Erick On Wed, Dec 21, 2011 at 10:46 AM, Dean Pullen <dean.pul...@semantico.com> wrote: > E.g. I see this in the slave logs: > > 2011-12-21 15:45:27,635 INFO handler.SnapPuller:265 - Master's version: > 1271406570655, generation: 376 > 2011-12-21 15:45:27,635 INFO handler.SnapPuller:266 - Slave's version: > 1271406571565, generation: 1286 > 2011-12-21 15:45:27,636 INFO handler.SnapPuller:267 - Starting replication > process > 2011-12-21 15:45:27,639 INFO handler.SnapPuller:270 - Number of files in > latest index in master: 9 > … > 2011-12-21 15:45:50,997 INFO handler.SnapPuller:286 - Total time taken for > download : 23 secs > 2011-12-21 15:45:51,050 INFO handler.SnapPuller:586 - New index installed. > Updating index properties… > > Yet the index doesn't change! > > > On 21 Dec 2011, at 15:37, Dean Pullen wrote: > >> Hi all, >> >> I have an odd problem locally when attempting replication with solr 1.4 >> >> The problem is, though the master files get copied to a temp directory in >> the slave data directory (I see this happen at runtime), they are then not >> copied over the actual slave index data. >> >> We were wondering if it was due to the index version of the restored master >> data being behind the slave index version after a restore? Any other ideas >> would be appreciated. >> >> Thanks, >> >> Dean Pullen >
