Re: Correct approach to copy index between solr clouds?

write.lock is used whenever a core(replica) wants to, well, write to the index. Each individual replica is sure to only write to the index with one thread. If two threads were to write to an index, there's a very good chance the index will be corrupt, so it's a safeguard against two or more

Re: Correct approach to copy index between solr clouds?

Thanks Erick. Can you explain a bit more on the write.lock file? So far I have been copying it over from B to A and haven't seen issue starting the replica. On Sat, Aug 26, 2017 at 9:25 AM, Erick Erickson wrote: > Approach 2 is sufficient. You do have to insure that you

Re: Correct approach to copy index between solr clouds?

Approach 2 is sufficient. You do have to insure that you don't copy over the write.lock file however as you may not be able to start replicas if that's there. There's a relatively little-known third option. You an (ab)use the replication API "fetchindex" command, see:

Correct approach to copy index between solr clouds?

Hi, In our set up there are two solr clouds: Cloud A: production cloud serves both writes and reads Cloud B: back up cloud serves only writes Cloud A and B have the same shard configuration. Write requests are sent to both cloud A and B. In certain circumstances when Cloud A's update lags