We're simply restoring the master via a backed up snapshot (created using the ReplicationHandler) and then trying to get the slave to replicate it.
On 21 Dec 2011, at 18:09, Erick Erickson wrote: > You can't. But index restoration should be a very rare thing, > or you have some lurking problem in your process. > > Or this is an XY problem, what problem are you trying to > solve? see: http://people.apache.org/~hossman/#xyproblem > > Best > Erick > > On Wed, Dec 21, 2011 at 12:21 PM, Dean Pullen <dean.pul...@semantico.com> > wrote: >> I can't understand, then, how we could ever restore and get replication to >> work without manual intervention! >> >> Dean >> >> On 21 Dec 2011, at 16:37, Dean Pullen wrote: >> >>> I can't see a way, if the slave is on another server. >>> >>> We're going to upgrade solr - as you can delete the index after unloading a >>> core in this way: >>> >>> cores?action=UNLOAD&core=liveCore&deleteIndex=true >>> >>> From v3.3 (I think) >>> >>> On 21 Dec 2011, at 16:11, Dean Pullen wrote: >>> >>>> Thought as much, thanks for the reply. >>>> >>>> Is there an easy way of dropping the index on the slave, or do I have to >>>> manually delta the index files? >>>> >>>> Regards, >>>> >>>> Dean. >>>> >>>> >>>> >>>> On 21 Dec 2011, at 15:54, Erick Erickson wrote: >>>> >>>>> 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 >>>>>> >>>> >>> >>
