: > This is a relatively safe assumption in most cases, but one that couples the : > master update policy with the performance of the slaves - if the master gets : > updated (and committed to) frequently, slaves might face a commit on every : > 1-2 poll's, much more than is feasible given new searcher warmup times.. : > In effect what this comes down to it seems is that i must make the master : > commit frequency the same as i'd want the slaves to use - and this is : > markedly different than previous behaviour with which i could have the : > master get updated(+committed to) at one rate and slaves committing those : > updates at a different rate.
: I see , the argument. But , isn't it better to keep both the mster and : slave as consistent as possible? There is no use in committing in : master, if you do not plan to search on those docs. So the best thing : to do is do a commit only as frequently as you wish to commit in a : slave. i would advise against thinking that when designing anything rlated to replication -- people should call commit based on when they want the documents they've added to be available for consumers -- for a single box setup, your consumers are people executing searchers, but for a multi-tier setup your consumers are the slaves replicating from you (the master) -- but your consumers may not all have equal concerns about frehness. some of the slaves may want to poll to get new updates from you as fast as possible and have the freshest data atthe expense of lower cache hit rates and increases network IO, others may be happier with stale data in return for better cache hit rates or lower network IO (even in a realtime search situation, you may also be replicating to a slave in a remote data center with a small network pipe who only wants one snappull a day for backend analytics and an extremely consistent view of hte index for a long durration of analysis. the point being: we shouldn't assume/expect that slaves will always want updates as fast as possible, or that all slaves of a single master will want all updates with equal urgency ... individual slaves need to be able to choose. -Hoss
