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
On Tue, Nov 9, 2010 at 12:33 AM, Jan Høydahl / Cominvent
jan@cominvent.com wrote:
Not sure about that. I have read that the replication handler actually issues
a commit() on itself once the index is downloaded.
That was true with the old replication scripts. The Java based
replication just
Cool, thanks for the clarification, Shalin.
--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
On 9. nov. 2010, at 15.12, Shalin Shekhar Mangar wrote:
On Tue, Nov 9, 2010 at 12:33 AM, Jan Høydahl / Cominvent
jan@cominvent.com wrote:
Not sure about that. I have
Hi,
I've got an ordinary master/slave replication set up. The master contains
several fields that are not used by the slaves but are used by processes that
interact with the master. Removing the fields from the master is not an option.
Well, to save disk space i'd figure i create an `ignored`
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
Thanks for the pointer!
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
