On 1/25/22 18:47, Han Zhou wrote:
>
>
> On Sun, Dec 19, 2021 at 6:09 AM Ilya Maximets <[email protected]
> <mailto:[email protected]>> wrote:
>>
>> Even though relays can be scaled to the big number of servers to
>> handle a lot more clients, lack of transaction history may cause
>> significant load if clients are re-connecting.
>> E.g. in case of the upgrade of a large-scale OVN deployment, relays
>> can be taken down one by one forcing all the clients of one relay to
>> jump to other ones. And all these clients will download the database
>> from scratch from a new relay.
>>
>> Since relay itself supports monitor_cond_since connection to the
>> main cluster, it receives the last transaction id along with each
>> update. Since these transaction ids are 'eid's of actual transactions,
>> they can be used by relay for a transaction history.
>>
>> Relay may not receive all the transaction ids, because the main cluster
>> may combine several changes into a single monitor update. However,
>> all relays will, likely, receive same updates with the same transaction
>> ids, so the case where transaction id can not be found after
>> re-connection between relays should not be very common. If some id
>> is missing on the relay (i.e. this update was merged with some other
>> update and newer id was used) the client will just re-download the
>> database as if there was a normal transaction history miss.
>>
>> OVSDB client synchronization module updated to provide the last
>> transaction id along with the update. Relay module updated to use
>> these ids as a transaction id. If ids are zero, relay decides that
>> the main server doesn't support transaction ids and disables the
>> transaction history accordingly.
>>
>> Using ovsdb_txn_replay_commit() instead of ovsdb_txn_propose_commit_block(),
>> so transactions are added to the history. This can be done, because
>> relays has no file storage, so there is no need to write anything.
>>
>> Relay tests modified to test both standalone and clustered database
>> as a main server. Checks added to ensure that all servers receive the
>> same transaction ids in monitor updates.
>>
>> Signed-off-by: Ilya Maximets <[email protected] <mailto:[email protected]>>
>> ---
>> NEWS | 3 +++
>> lib/ovsdb-cs.c | 1 +
>> lib/ovsdb-cs.h | 1 +
>> ovsdb/ovsdb-server.c | 8 +++++---
>> ovsdb/relay.c | 28 ++++++++++++++++++++++-----
>> ovsdb/transaction.c | 9 +++++----
>> tests/ovsdb-server.at <http://ovsdb-server.at> | 44
>> +++++++++++++++++++++++++++++++------------
>> 7 files changed, 70 insertions(+), 24 deletions(-)
>>
<snip>
>> @@ -1548,12 +1554,26 @@ m4_define([OVSDB_CHECK_EXECUTION],
>> diff stdout dump${i}])
>> done
>>
>> + dnl Check that transaction ids in notifications are the same on all
>> relays.
>> + last_id_pattern='s/\(.*"monid","[[a-z]]*".,"\)\(.*\)\(",{".*\)/\2/'
>> + AT_CHECK([grep 'received notification, method="update3"'
>> ovsdb-server2.log dnl
>> + | sed $last_id_pattern > txn_ids2])
>> + for i in $(seq 3 ${n_servers}); do
>> + AT_CHECK([grep 'received notification, method="update3"'
>> ovsdb-server$i.log dnl
>> + | sed $last_id_pattern > txn_ids$i])
>> + AT_CHECK([diff txn_ids2 txn_ids$i])
>> + done
>> +
>
> Thanks Ilya! Shall we ensure that the last_id is not zero when the server1 is
> cluster mode?
> Otherwise it looks good to me.
>
> Acked-by: Han Zhou <[email protected] <mailto:[email protected]>>
Thanks, Mike an Han!
I added the check for the transaction ids to be non-zero in the clustered
case and applied the patch.
Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
