If this is the first time you are trying to upgrade OpenMetadata, or you just have some doubts on how the
backup and upgrade process work, this is the place to be. We will cover:
Let’s start with a simplified design review of OpenMetadata. You can find further details here,
but we’ll now focus on the Server & the Database:All the metadata is stored in a MySQL or Postgres instance. The shape of the data is managed using Flyway, and the migration
scripts are handled here.In a nutshell, we have a data model in which we store all of this information. The definition of this model (table names,
schemas,…) is managed using Flyway migrations. In every release, the structure of this data model can change. This means that
the shape of the database is tightly coupled to your OpenMetadata Server version.
You can find all the necessary information on how to run the backups here.
When we backup the data, we are creating an SQL file that follows the shape of the database of a specific version. Thus, if we have
some issues on our instance, and we ever need to restore that data, it will only fit to a database with that same version shape.
We have been explaining how each OpenMetadata Server relies on a specific data model to store the metadata. What happens
when we upgrade from version X to Y?The migration process will take care of getting the data shaped as X and transform it to the Y shape. After the migration is done,
the server in version Y will be able to run properly.