Hmmm, it almost seems like you're better off turning off replication entirely. Your "master" becomes a machine used as a source for rapidly spinning up a new slave or resetting a slave.
I have no hard data to back up my misgivings about committing to the slaves then having replication overwrite them, but that just seems fraught with danger. And since you're talking about sending the updates to them anyway..... What NRT patches are you applying? Mostly asking for curiosity.. Best Erick On Thu, Aug 11, 2011 at 9:53 AM, eks dev <eks...@yahoo.co.uk> wrote: > Thinking aloud and grateful for sparing .. > > I need to support high commit rate (low update latency) in a master > slave setup and I have a bad feelings about it, even with disabling > warmup and stripping everything down that slows down refresh. > > I will try it anyway, but I started thinking about "backup plan", like > NRT on slaves. > > An idea is to have Master working on disk, doing commits in throughput > friendly manner (e.g. every 5-10 minutes), but let slaves do the same > updates with softCommit > > I am basically going to let slaves "possibly run out of sync" with > master, by issuing the same updates on all slaves with softCommit ... > every now and than syncing with Master. > > Could this work? the trick is, index is big (can fit in Ca. 16-20G > Ram), but update rate is small and ugly distributed in time (every > couple of seconds a few documents), one hard commit on master + slave > update would probably cost much more than add(document) with > softCommit on every slave (2-5 of them) > > So all in all, master remains real master and is there to ensure: > a ) seeding if slave restarts > b) authoritative index master, if slaves run out of sync (small diff > is ok if they get corrected once a day) > > In general, do you find such idea wrong for some reason, should I be > doing something else/better to achieve low update latency in master > slave (for low update throughput)? > > Anything I can do to make standard master slave latency better apart > from disabling warmup? Would loading os ramdisk (tmpfs forced in ram) > on slaves bring much. > > I am talking about Ca. 1 second (plus/minus) update latency target > from update to search on slave... But not more than 0.5 - 2 updates > every second. And what I so far understood how solr works, this is > going to be possible only with NRT on slaves (Analysis in my case is > fast, so not an issue)... >
