On Wed, Oct 16, 2019 at 12:20:48AM +0530, [email protected] wrote: > From: Numan Siddique <[email protected]> > > Presently, replication is not allowed if there is a schema version mismatch > between > the schema returned by the active ovsdb-server and the local db schema. This > is > causing failures in OVN DB HA deployments during uprades. > > In the case of OpenStack tripleo deployment with OVN, OVN DB ovsdb-servers are > deployed on a multi node controller cluster in active/standby mode. During > minor updates or major upgrades, the cluster is updated one at a time. If > a node A is running active OVN DB ovsdb-servers and when it is updated, > another > node B becomes active. After the update when OVN DB ovsdb-servers in A are > started, > these ovsdb-servers fail to replicate from the active if there is a schema > version mismatch. > > This patch addresses this issue by allowing replication even if there is a > schema version mismatch only if > - The standby ovsdb-servers's local db schema version is greater than that > of the active. The version x should match with the active and the version > y > should be greater than that of the active. > - If all the active ovsdb-server schema tables are present in the > local db schema. > > This should not result in any data loss.
This is interesting. >From a database design perspective, I believe that this introduces the first place where the database itself looks at version numbers. Until now, the database has carried the version number and validated that it has the right form, but the database server itself has not attached any meaning to the version number. With this change, the version number has some significance to the database server, at least when replication is in use. This change is noteworthy. It should be mentioned in the documentation. Probably some small note should be added in places that claim OVSDB does not enforce a particular version numbering schema (e.g. ovsdb/ovsdb-schemas.man, Documentation/ref/ovsdb.7.rst), since this is still *mostly* true but not entirely. There is a possible alternate way to do this. The code could actually compare the two schemas. If the newer schema would accept everything that the older schema does, then it could accept the substitution. (This would only work if both schemas were actually available; I'm not sure that's true.) I didn't really review the patch itself. It looks like it adds some new code for ad hoc parsing of versions. It would be better to use struct ovsdb_version and use ovsdb_parse_version() instead. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
