Schema/Version compatibility

Live migration

BMaaS supports live migrating schemas. On startup, every component using the BMaaS will attempt to migrate the database up to the newest version of the schema it was built with.

Components are implemented to support a range of schemas, and operators should sequence upgrades in the following way:

1. Make sure that all components are at the newest possible CL, but not so new that they ship a newer version of the schema than is currently running.
2. Upgrade components in a rolling fashion to a CL version that ships the newest possible schema version which is still compatible with the previous CL versions of the components.
3. Repeat from point 1 until the newest wanted CL version is running.

^ ID ^ Schema range ^ CL range ^ Notes ^ | 0 | < 1672749980 | >= 0 | Initial production schema. | | 1 | >= 1672768890 | >= 1565 | Exponential backoff support. |

For example, if the cluster is at version 1200, it should first be upgraded to < 1565 (to reach row 0), then to anything higher than 1565 (to reach row 1).

Offline migration

For simple deployments, an offline migration is easiest. To perform an offline migration:

1. Turn down all BMaaS components that communicate with the BMDB.
2. Upgrade all components to the newer version (either newest or otherwise wanted, but all components have to be at the same CL version).
3. Turn up a single component of BMaaS torn down in 1., making sure the database is migrated.
4. Turn up the rest of the components.

This allows migrating across many incompatible schema migrations, but requires downtime.