On Wed, Oct 16, 2019 at 3:21 AM Ben Pfaff <[email protected]> wrote: > 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.) >
Thanks for the comments. I think the alternative suggested by you makes more sense and more robust. I will go with this. Both schemas will be available. So I don't see any issues. Thanks Numan > > 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
