lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "MOIS Martin (MORPHO)" <martin.m...@morpho.com>
Subject Replication and soft commits for NRT searches
Date Mon, 12 Oct 2015 08:01:41 GMT
Hello,

I am running Solr 5.2.1 in a cluster with 6 nodes. My collections have been created with replicationFactor=2,
i.e. I have one replica for each shard. Beyond that I am using autoCommit/maxDocs=10000 and
autoSoftCommits/maxDocs=1 in order to achieve near realtime search behavior.

As far as I understand from section "Write Side Fault Tolerance" in the documentation (https://cwiki.apache.org/confluence/display/solr/Read+and+Write+Side+Fault+Tolerance),
I cannot enforce that an update gets replicated to all replicas, but I can only get the achieved
replication factor by requesting the return value rf.

My question is now, what exactly does rf=2 mean? Does it only mean that the replica has written
the update to its transaction log? Or has the replica also performed the soft commit as configured
with autoSoftCommits/maxDocs=1? The answer is important for me, as if the update would only
get written to the transaction log, I could not search for it reliable, as the replica may
not have added it to the searchable index.

My second question is, does rf=1 mean that the update was definitely not successful on the
replica or could it also represent a timeout of the replication request from the shard leader?
If it could also represent a timeout, then there would be a small chance that the replication
was successfully despite of the timeout.

Is there a way to retrieve the replication factor for a specific document after the update
in order to check if replication was successful in the meantime?

Thanks in advance.

Best Regards,
Martin Mois
#
" This e-mail and any attached documents may contain confidential or proprietary information.
If you are not the intended recipient, you are notified that any dissemination, copying of
this e-mail and any attachments thereto or use of their contents by any means whatsoever is
strictly prohibited. If you have received this e-mail in error, please advise the sender immediately
and delete this e-mail and all attached documents from your computer system."
#

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message