[
https://issues.apache.org/jira/browse/OAK-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14974024#comment-14974024
]
Tomek Rękawek commented on OAK-2106:
------------------------------------
The implementation is ready to review at
[github|https://github.com/apache/jackrabbit-oak/pull/41]. The patch file can
be downloaded from [here|https://github.com/apache/jackrabbit-oak/pull/41.diff].
*ReplicationLagEstimator*
This new class reads the last 10 differences between optime on PRIMARY and each
SECONDARY. Then it computes a separate average for each SECONDARY and returns
the maxmimum lag value. In case there's something odd about the statistics (eg.
the last heartbeat for the SECONDARY is before the optime on PRIMARY), the
configured value of {{maxReplicationLagMillis}} will be returned (by default =
6h).
There's also a new test for this.
*Branch*, *Commit*
I added a BloomFilter containing list of the modified paths to each *Branch*
object. It's required to know these paths in order to use PRIMARY for the
branch reads.
*MongoDocumentStore*, *UnmergedBranchesAware*, *UnsavedModificationsAware*
I created two marker interfaces, so the document node store can pass
UnmergedBranches and UnsavedModifications objects back to the
MongoDocumentStore.
I extended the ReadPreferenceIT with two cases described in two comments above
(unsaved modifications and unmerged branches).
> 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)
