We have a farm of several Master-Slave pairs all managing a single very large "logical" index sharded across the master-slaves. We notice on the slaves, after an rsync update, as the index is being committed that all queries are blocked sometimes resulting in unacceptable service times. I'm looking at ways we can manage these "update burps".
Question #1: Anything obvious I can tweak in the configuration to mitigate these multi-second blocking updates? Our Indexes are 40GB, 20M documents each. RSync updates are every 5 minutes several hundred KB per update. Question #2: I'm considering setting up each slave with multiple Solr cores. The 2 indexes per instance would be nearly identical copies but "A" would be read from while "B" is being updated, then they would swap. I'll have to figure out how to rsync these 2 indexes properly but if I can get the commits to happen to the offline index then I suspect my queries could proceed unblocked. Is this the wrong tree to be barking up? Any other thoughts? Thanks in advance, Jim -- View this message in context: http://www.nabble.com/Index-updates-blocking-readers%3A-To-Multicore-or-not--tp19843098p19843098.html Sent from the Solr - User mailing list archive at Nabble.com.
