[CONTROLLER-1063] Clustering : Add support to allow reads from followers Created: 11/Dec/14 Updated: 25/Jul/23 |
|
| Status: | Confirmed |
| Project: | controller |
| Component/s: | clustering |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | ||
| Reporter: | Moiz Raja | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| Issue Links: |
|
||||||||
| Description |
|
The Clustered Data Store ensures that all reads are consistent by routing reads to the Shard Leader. This obviously has an adverse impact on application performance. We need to provide a mechanism in the API or via configuration so that application developers and/or administrators can choose to allow reads from a follower. It goes without saying that applications that choose to use this mechanism will have to deal with the situation where a ReadTransaction following a WriteTransaction may not see the data written by the WriteTransaction. Also the support to read from a follower cannot be implemented when transactions occur on a TransactionChain. |
| Comments |
| Comment by Moiz Raja [ 25/Aug/15 ] |
|
No clear use case so moving it out of Be |
| Comment by Moiz Raja [ 17/Nov/15 ] |
|
There is a way to currently do this - it's a bit convoluted but it would work. The way is to register a DataChangeListener. The Listener should be of type ClusteredDataChangeListener. When the Listener is registered it sends an initial notification with all the pertinent data from the local replica. After the initial notification is received the data can be read from the CreatedData map and the listener can be unregistered. This effectively gives us a mechanism to read data from the follower. |
| Comment by Robert Varga [ 26/May/16 ] |
|
An alternative is to provide an interface extension in the DOMDataTreeProducer (or consumer) contract, which will backchannel the request. Frontend implementation can then satisfy the read either from its replica (if present), or by establishing an internal consumer, or via explicit read. |
| Comment by Ravit Peretz [ 05/Jan/17 ] |
|
please see below mail threads for more info on proposed implementation: https://lists.opendaylight.org/pipermail/mdsal-dev/2016-December/000881.html |
| Comment by Robert Varga [ 05/Jan/17 ] |
|
I think there is a semantic mismatch between this issue and the request discussed in the referenced thread. The assumption in this issue is that the follower is located on the current node and if not, the read will go to the master. The discussion in the mailing thread is about a cache, which is initially populated from wherever and is being maintained going forward. The difference is that this issue makes an assumption on follower locality, while the cache does not. This is an important distinction in clusters where there is no shard presence (leader/follower) on some nodes. |
| Comment by Michael Vorburger [ 09/Jan/17 ] |
|
> mismatch between this issue and the request discussed in the referenced thread ==> |