[ovs-dev] [PATCH] ovsdb-server: Allow replication from older schema version servers.
nusiddiq at redhat.com
Wed Oct 16 11:30:21 UTC 2019
On Wed, Oct 16, 2019 at 3:21 AM Ben Pfaff <blp at ovn.org> wrote:
> On Wed, Oct 16, 2019 at 12:20:48AM +0530, nusiddiq at redhat.com wrote:
> > From: Numan Siddique <nusiddiq at redhat.com>
> > 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.
> > 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,
> > 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
> > version mismatch.
> > This patch addresses this issue by allowing replication even if there is
> > schema version mismatch only if
> > - The standby ovsdb-servers's local db schema version is greater than
> > 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.
> 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.
More information about the dev