[
https://issues.apache.org/jira/browse/OAK-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14976040#comment-14976040
]
Marcel Reutegger commented on OAK-2106:
---------------------------------------
Thanks for the patch.
I think even with a single measurement the read can be directed to a secondary
when it actually should go to a primary. Let's say the estimator measures a lag
of 2 seconds at time T. That is, secondaries have synced up to T-2s. At T+5s
the secondaries still lag behind at T-2s. Now, IIUC when a read comes in at
T+5s with a request for a document with maxCacheAge of 5 seconds, the
implementation would read it from a secondary, because replication lag is 2
seconds and the requested document can be 5 seconds old.
I'm also a bit concerned about introducing a dependency from MongoDocumentStore
to classes like UnmergedBranches and UnsavedModifications.
I would rather like to see a solution where the client of the DocumentStore can
express how fresh the document needs to be when it reads from the store. I
think this also means the decision whether a read can be directed to a
secondary must not depend on the lag as a duration, but should rather calculate
a time when it is safe to read from a secondary. The tricky part here is how to
handle time differences on the machines where the Oak cluster nodes are running
and the MongoDB replica set. Each change on a document is associated with a
revision, where the timestamp of the revision is tied to the local clock where
the revision was created. The oplog timestamp on the other hand is derived from
the primary replica set member clock, I assume.
> Optimize reads from secondaries
> -------------------------------
>
> Key: OAK-2106
> URL: https://issues.apache.org/jira/browse/OAK-2106
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, mongomk
> Reporter: Marcel Reutegger
> Assignee: Marcel Reutegger
> Labels: performance, scalability
>
> OAK-1645 introduced support for reads from secondaries under certain
> conditions. The current implementation checks the _lastRev on a potentially
> cached parent document and reads from a secondary if it has not been
> modified in the last 6 hours. This timespan is somewhat arbitrary but
> reflects the assumption that the replication lag of a secondary shouldn't
> be more than 6 hours.
> This logic should be optimized to take the actual replication lag into
> account. MongoDB provides information about the replication lag with
> the command rs.status().
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
