Document upgrade and downgrade processes

[zamazan4ik]

Hi.

After reading the documentation it is not clear for me, how upgrade and downgrade processes should be performed over the solution. Could you please describe somewhere in the documentation:

• How to upgrade comdb2 to the newer version (hopefully with no downtime)
• How to downgrade comdb2 to the older version (hopefully with no downtime)
• Maybe some compatibility policies and notes between versions

Thanks in advance!

P.S. Will be great if you enable built-in search over the documentation :)

[mponomar]

There's always compatibility between two major versions of the database. You can take down nodes in a cluster, and bring up nodes running a new version, one node at a time, until all the nodes are running the new version. Same for downgrade. Any format changes are gated behind options - you'd have to enable them in a new version explicitly, because it breaks compatibility. On the next major release, those options become defaults.

Here's a concrete example: https://github.com/bloomberg/comdb2/pull/3177/files

This is a change in how we indicate which file a log record applies to. It's off by default. When we deploy a version that understands the new format for all database nodes, we can turn on the setting that enables it (but once we do, we can't roll back to an older version).

We always do this for any file/log/network changes. No changes to Comdb2 will ever require downtime to upgrade to.

So in other words, you'll have compatibility between 7.0 and 8.0, unless you explicitly turn on incompatible options. When we start on 9.0, it may not be compatible with 7.0, but will be compatible with 8.0, etc.

[zamazan4ik]

@mponomar could you please add this information into the documentation?