[ovs-dev] [PATCH] ovsdb-server: Allow replication from older schema version servers.
blp at ovn.org
Tue Oct 15 18:22:44 UTC 2019
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. 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
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.
More information about the dev