On 5/10/21 1:38 PM, Dumitru Ceara wrote: > On 5/1/21 2:55 AM, Ilya Maximets wrote: >> Current version of ovsdb replication allows to scale out read-only >> access to the primary database. However, many clients are not >> read-only but read-mostly. For example, ovn-controller. >> >> In order to scale out database access for this case ovsdb-server >> need to process transactions that are not read-only. Replica is >> not allowed to do that, i.e. not allowed to modify the database, >> but it can act like a proxy and forward transactions that includes >> database modifications to the primary server and forward replies >> back to client. At the same time it may serve read-only transactions >> and monitor requests by itself greatly reducing the load on primary >> server. >> >> To support that new command line option '--enable-txn-forward' added >> to ovsdb-server. >> >> This configuration will slightly increase transaction latency, but >> it's not very important for read-mostly use cases. >> >> With this change instead of creating a trigger to commit the >> transaction, ovsdb-server will create a trigger for transaction >> forwarding. Later, replication_run() will send all new transactions >> to the replication source. Once transaction reply received from the >> replication source, replication module will update the state of the >> transaction forwarding with the reply. After that, trigger_run() >> will complete the trigger and jsonrpc_server_run() will send the >> reply back to the client. Since transaction reply from the replication >> source will be received after all the updates, client will receive >> all the updates before receiving the transaction reply as it is in >> a normal scenario without transaction forwarding. >> >> Signed-off-by: Ilya Maximets <[email protected]> >> --- > > Hi Ilya, > > I have a tiny nit below, except for that the code looks OK to me. > > What I'm not very sure about is the fact that a replication server will > service read-only transactions locally while other transactions are > forwarded. > > A client might generate two transactions, in this order: > > T1: insert in table X > T2: select from table X (read-only) > > If the client doesn't wait for the result of T1, with txn forwarding > enabled, it will potentially get a stale value from X at T2. > > Arguably, this is a problem in the client because it's not waiting for > T1 to complete, but should we worry about it? Or should we at least > document this change in behavior somewhere?
This is the same behavior as if if you're performing these transactions over the the follower of a clustered database. And this is documented in 'Understanding Cluster Consistency' section of ovsdb(7). I also pointed to that in the relay service model documentation in v2. > > Regards, > Dumitru _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
