Hi devs, I presented pr-2069[1] for ZOOKEEPER-1675[2] to make sync behave like a quorum operation. I believed that there was consensus once before in reading mailing threads[3][4] and ZOOKEEPER-2136[5]. But there are still concerns in reviewing, so raise it once again to reach consensus on direction.
Currently, the problem of `sync` is that `sync` + `read` could get not up-to-date data in case of leader change. ZOOKEEPER-2137[6] reported this before. And we documented this in "Consistency Guarantees"[7]. pr-2069[1] try to make sync behave like a quorum operation to solve this. 1. It bumps the quorum protocol version to make changes compatible with rolling upgrade. This is because `sync` is a public API. The whole cluster must function normally in rolling upgrade. `sync` will behave like a quorum operation once all forwarding followers are upgraded to the new version. 2. It issues a quorum operation in case of no outstanding proposals. For summary, pr-2069[1] makes sync behave like a quorum operation and introduces no choice for clients and admins to rollback to old behaviors. I roaded to this after discussion with @ctubbsii in pr reviewing. There are concerns about potential increasing load to the cluster. I think it is probably acceptable for us to make sync behave like a quorum since: 1. `sync` is rare compared to `getData`, `setData` etc. . 2. pr-2069[1] issues quorum operation only when there is no outstanding proposal which is probably a sign that the cluster is not in heavy loading. 3. `sync` + `read` cares more about up-to-date view than operation latency and cluster load. 4. The circumvent of this(e.g. `write` + `read`) requires both a quorum and a write unconditionally. One candidate for us is introducing a new API/option for client's choose ? But I doubt why people intentionally want `sync` + `read` in case they know `quorumSync` + `read` and the fault(not up-to-date data) of `sync` + `read` ? I think it is a bug for `sync` + `read` to read not up-to-date data. This led me to pr-2069[1]. [1]: https://github.com/apache/zookeeper/pull/2069 [2]: https://issues.apache.org/jira/browse/ZOOKEEPER-1675 [3]: https://lists.apache.org/thread/vvxopbhwb18fqhpr4fb6jhv3cxwcy4cz [4]: https://lists.apache.org/thread/74og9tmtnjg0440lgmwz3z8p1xmwts6j [5]: https://issues.apache.org/jira/browse/ZOOKEEPER-2136 [6]: https://issues.apache.org/jira/browse/ZOOKEEPER-2137 [7]: https://zookeeper.apache.org/doc/r3.9.0/zookeeperInternals.html#sc_consistency
