Why doesn’t proxy get read version directly from master, but need to broadcast all other proxies?
1 Like
My guess will be, because master is single for whole cluster and fdb needs to reduce the load on it. This way read-only transactions does not bother master at all, and for write transactions master is called only once per batch and not per single transaction.
The proxy needs to give out a read version which is greater than or equal to the largest commit version that has been send to a client. This is needed so that a client will see the result of previous commits that have happened.
If proxy A commits a transaction, and then we ask proxy B for a read version, we need the read version to be larger than the version committed by proxy A. The only way to get this information is by asking proxy A for its largest committed version.
The master gives out versions to proxies to be committed, but the master does not know when the versions it gives out are durable on the transaction logs. Therefore it is not safe to do reads at the largest version the master has provided because that version might be rolled back in the event of a failure, so you could end up reading data that was never committed.
Hi @Evan
According to sigmod 21 paper Section 2.4.1, it says:
The proxy then asks the Sequencer for a read version that is guaranteed to be no less than any previously issued transaction commit version
So for the present, which one is right ?
maybe it depends on fdb version, for master branch, it gets grv from master link. But for release 6.3, it gets grv from proxies link
Yes, that’s correct. The logic changed in the upcoming 7.0 release. This doesn’t come for free though. So until 6.3 proxies would collect the read version from all other proxies. In 7.0 proxies will need to let the sequencer/master know about committed write versions before they acknowledge a commit back to a client.
This means, that commits are getting slightly more expensive but GRVs are getting significantly cheaper. In our testing this is a good trade-off (mostly because we have a higher win for GRV than we have a loss for commits and while GRVs are executed for all transactions commits are only executed for transactions that write something).