Not sure about that. I have read that the replication handler actually issues a commit() on itself once the index is downloaded.
But probably a better way for Markus' case is to hook the prune job on the master, writing to another core (myIndexPruned). Then you replicate from that core instead, and you also get the benefit of transferring a smaller index across the network. -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com On 8. nov. 2010, at 23.50, Shalin Shekhar Mangar wrote: > On Fri, Nov 5, 2010 at 2:30 PM, Jan Høydahl / Cominvent > <jan....@cominvent.com> wrote: >> >> How about hooking in Andrzej's pruning tool at the postCommit event, >> literally removing unused fields. I believe a "commit" is fired on the slave >> by itself after every successful replication, to put >> the index live. You could execute a script which prunes away the dead meat >> and then call a new commit? > > Well, I don't think it will work because a new commit will cause the > index version on the slave to be ahead of the master which will cause > Solr replication to download a full index from the master and it'd go > in an infinite loop. > > -- > Regards, > Shalin Shekhar Mangar.
