[ovs-dev] [PATCH] ovsdb-server: Allow replication from older schema version servers.

Numan Siddique 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.
> 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.
>


More information about the dev mailing list