Skip to main content
Version: 1.20.x.x Java 8 ELS

General upgrade and patching instructions

General

Install the new nevisMeta release as documented in the reference guide of nevisMeta.

Configuration files

The required changes to the nevisMeta configuration files are documented for each new version. If there are changes, the configuration files have to be patched manually. Refer to the reference guide for detailed information on specific configuration parameters.

Database

MariaDB

The database schema can evolve over time. By default, the user has to update the database schema manually. If you set the property database.migration.automatic to "true", nevisMeta will automatically update the database schema (see also "Server configuration properties").

It is strongly recommended that you back up the database before you upgrade nevisMeta. This is because earlier versions of nevisMeta may not be able to connect to the database anymore after the completion of the automated migration.

You can use the following commands to update the database schema:

CommandArgument(s)UsageWhen to use
nevismeta database-migration-infoNonePrints the details and status information about all migrations.To check the schema history including the status of your migrations (which migrations were successful, which are pending, etc.).
nevismeta database-migrateNoneMigrates the database schema to the latest version.To apply the pending migration files, as shown in the schema history.
nevismeta database-migration-repairNoneRepairs the schema migration history.To correct the schema history after an error occurred, either because a migration file failed to run or because an applied migration file has been modified.
nevismeta database-migration-validateNoneVerifies that the migrations applied to the database match the ones available locally.To validate all applied migrations against those marked as "success" in the schema history. The goal is to detect accidental changes. The validation fails if:- An applied migration file has been modified, and as a consequence there are differences in migration name, type, or checksum between the applied migration file and the corresponding entry in the history schema.- An applied migration file has been (accidentally) removed but the schema history still contains an entry with the same file name, marked as "resolved". The schema history includes many entries marked as "resolved"/"success", but there are no physical migration files with names matching the entries in the schema history. This can happen when you import a database with another schema history from another nevisMeta instance.
nevismeta database-migration-baselinebaseline versionBaselines an existing database, excluding all migrations up to and including the provided baseline version value.In case you have made some changes to the database that were not managed by nevisMeta. In such a situation, you can use this command to set a baseline at a specific version, and instruct nevisMeta to only apply migration files created after this baseline.

PostgreSQL

The database schema can evolve over time. By default, the user has to update the database schema manually. If you set the property database.migration.automatic to "true", nevisMeta will automatically update the database schema (see also "Server configuration properties").

It is strongly recommended that you back up the database before you upgrade nevisMeta. This is because earlier versions of nevisMeta may not be able to connect to the database anymore after the completion of the automated migration.

You can use the following commands to update the database schema:

CommandArgument(s)UsageWhen to use
nevismeta database-migration-infoNonePrints the details and status information about all migrations.To check the schema history including the status of your migrations (which migrations were successful, which are pending, etc.).
nevismeta database-migrateNoneMigrates the database schema to the latest version.To apply the pending migration files, as shown in the schema history.
nevismeta database-migration-repairNoneRepairs the schema migration history.To correct the schema history after an error occurred, either because a migration file failed to run or because an applied migration file has been modified.
nevismeta database-migration-validateNoneVerifies that the migrations applied to the database match the ones available locally.To validate all applied migrations against those marked as "success" in the schema history. The goal is to detect accidental changes. The validation fails if:- An applied migration file has been modified, and as a consequence there are differences in migration name, type, or checksum between the applied migration file and the corresponding entry in the history schema.- An applied migration file has been (accidentally) removed but the schema history still contains an entry with the same file name, marked as "resolved". The schema history includes many entries marked as "resolved"/"success", but there are no physical migration files with names matching the entries in the schema history. This can happen when you import a database with another schema history from another nevisMeta instance.
nevismeta database-migration-baselinebaseline versionBaselines an existing database, excluding all migrations up to and including the provided baseline version value.In case you have made some changes to the database that were not managed by nevisMeta. In such a situation, you can use this command to set a baseline at a specific version, and instruct nevisMeta to only apply migration files created after this baseline.