Replication large files can be bad for OS page cache as files being written are also written to the page cache. Search latency can grow due to I/O for getting the current index version back into memory. Also, Solr cache warming can casue a doubling of your heap usage.
Frequent replication in an environment with large files and high query load is something one should measure before going in production. > Thanks - that sounds like what I was hoping for. So the I/O during > replication will have *some* impact on search performance, but > presumably much less than reindexing and merging/optimizing? > > -Mike > > > Master/slave replication does this out of the box, easily. Just set the > > slave to update on Optimize only. Then you can update the master as much > > as you want. When you are ready to update the slave (the search > > instance), just optimize the master. On the slave's next cycle check it > > will refresh itself, quickly, efficiently, minimal impact to search > > performance. No need to build extra moving parts for swapping search > > servers or anything like that. > > > > -- > > View this message in context: > > http://lucene.472066.n3.nabble.com/how-to-do-offline-adding-updating-ind > > ex-tp2923035p2924426.html Sent from the Solr - User mailing list archive > > at Nabble.com.
