Hi Muneeb, I fear you'll have no chance: replicating an index will use more disc space on the slave nodes. Of course, you could minimize disc usage AFTER the replication via the 'optimize-hack'.
But are you sure the reason for the slave-node die, is due to disc limitations? Try to observe the slave indices e.g. via jvisualvm ... maybe it is due to RAM or CPU limitations, because a replicating index will do autowarming (requires some more RAM) and will do this in parallel to the old searcher which handles the requests (requires some more CPU). If RAM usage is the point try to reduce the caches (which could negativly effect query time!) and/or autowarming. Especially the filterCache requires some RAM. So: measure before hacking :-) ! Regards, Peter. > Well I do have disk limitations too, and thats why I think slave nodes died, > when replicating data from master node. (as it was just adding on top of > existing index files). > > :: What do you mean here? Optimizing is too CPU expensive? > > What I meant by avoid playing around with slave nodes is that doing anything > (including optimization on slave nodes) that may effect the live search > performance, unless I have no option. > > :: Do you mean increase to double size? > > yes, as it did before on replication. But I didn't get a chance to run the > indexer yesterday. > > >
