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 threads
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 don't copy
> over the wri
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:
https://cwiki.apache.org/conf
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 be