[
https://issues.apache.org/jira/browse/SOLR-14581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17141299#comment-17141299
]
David Smiley commented on SOLR-14581:
-------------------------------------
Thanks for improving Solr's documentation!
For reference, your patch is simply the following:
bq. +TIP: Each node has its own auto commit timer which starts upon receipt of
an update. While Solr promises eventual consistency, leaders will generally
receive updates *before* replicas; it is therefore possible for replicas to lag
behind somewhat.
> TIP:
If this is a tip then... well.... what is the advise you are offering? Perhaps
"NOTE:" is better. (see `about-this-guide.adoc`) is better.
> Each node has its own auto commit timer
No, each *core* (replica) has one. Nodes can host many cores which act
independently.
I'd like to propose the following new language. I thought about your approach
of including some rationale but I think it's way more important to point out
the consequences than the causes.
bq. +NOTE: Using auto soft commit or commitWithin requires the client app to
embrace the realities of "eventual consistency". Solr will make documents
searchable at _roughly_ the same time across NRT replicas of a collection but
there are no hard guarantees. Consequently, in rare cases, it's possible for a
document to show up in one search only for it not to appear in a subsequent
search occurring immediately after when the second is routed to a different
replica. Also, documents added in a particular order (even in the same batch)
might become searchable out of order of submission when there is sharding.
CC [~erickerickson]
> Document the way auto commits work in SolrCloud
> -----------------------------------------------
>
> Key: SOLR-14581
> URL: https://issues.apache.org/jira/browse/SOLR-14581
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation, SolrCloud
> Affects Versions: master (9.0)
> Reporter: Bram Van Dam
> Priority: Minor
> Attachments: SOLR-14581.patch
>
>
> The documentation is unclear about how auto commits actually work in
> SolrCloud. A mailing list reply by Erick Erickson proved to be enlightening.
> Erick's reply verbatim:
> {quote}Each node has its own timer that starts when it receives an update.
> So in your situation, 60 seconds after any give replica gets it’s first
> update, all documents that have been received in the interval will
> be committed.
> But note several things:
> 1> commits will tend to cluster for a given shard. By that I mean
> they’ll tend to happen within a few milliseconds of each other
> ‘cause it doesn’t take that long for an update to get from the
> leader to all the followers.
> 2> this is per replica. So if you host replicas from multiple collections
> on some node, their commits have no relation to each other. And
> say for some reason you transmit exactly one document that lands
> on shard1. Further, say nodeA contains replicas for shard1 and shard2.
> Only the replica for shard1 would commit.
> 3> Solr promises eventual consistency. In this case, due to all the
> timing variables it is not guaranteed that every replica of a single
> shard has the same document available for search at any given time.
> Say doc1 hits the leader at time T and a follower at time T+10ms.
> Say doc2 hits the leader and gets indexed 5ms before the
> commit is triggered, but for some reason it takes 15ms for it to get
> to the follower. The leader will be able to search doc2, but the
> follower won’t until 60 seconds later.{quote}
> Perhaps the subject deserves a section of its own, but I'll attach a patch
> which includes the gist of Erick's reply as a Tip in the "indexing in
> SolrCloud"-section.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
