| Serge Bazanski | 3ea40da | 2023-04-19 14:32:37 +0200 | [diff] [blame] | 1 | Schema/Version compatibility |
| 2 | === |
| 3 | |
| 4 | Live migration |
| 5 | --- |
| 6 | |
| 7 | BMaaS supports live migrating schemas. On startup, every component using the BMaaS |
| 8 | will attempt to migrate the database up to the newest version of the schema it |
| 9 | was built with. |
| 10 | |
| 11 | Components are implemented to support a range of schemas, and operators should |
| 12 | sequence upgrades in the following way: |
| 13 | |
| 14 | 1. Make sure that all components are at the newest possible CL, but not so new |
| 15 | that they ship a newer version of the schema than is currently running. |
| 16 | 2. Upgrade components in a rolling fashion to a CL version that ships the newest |
| 17 | possible schema version which is still compatible with the previous CL |
| 18 | versions of the components. |
| 19 | 3. Repeat from point 1 until the newest wanted CL version is running. |
| 20 | |
| 21 | ^ ID ^ Schema range ^ CL range ^ Notes ^ |
| 22 | | 0 | < 1672749980 | >= 0 | Initial production schema. | |
| 23 | | 1 | >= 1672768890 | >= 1565 | Exponential backoff support. | |
| 24 | |
| 25 | For example, if the cluster is at version 1200, it should first be upgraded to |
| 26 | < 1565 (to reach row 0), then to anything higher than 1565 (to reach row 1). |
| 27 | |
| 28 | Offline migration |
| 29 | --- |
| 30 | |
| 31 | For simple deployments, an offline migration is easiest. To perform an offline migration: |
| 32 | |
| 33 | 1. Turn down all BMaaS components that communicate with the BMDB. |
| 34 | 2. Upgrade all components to the newer version (either newest or otherwise |
| 35 | wanted, but all components have to be at the same CL version). |
| 36 | 3. Turn up a single component of BMaaS torn down in 1., making sure the database is migrated. |
| 37 | 4. Turn up the rest of the components. |
| 38 | |
| 39 | This allows migrating across many incompatible schema migrations, but requires downtime. |