Usually, EKM, WKD, and FES updates don’t involve schema changes. But sometimes an update can be shipped with a schema change. In such cases, this information will be stated in the release notes.
Automatic schema change (easier)
When running the service with the default store.postgres.update.schema=true property, and if the configured Postgres user has privileges to make schema changes, you may use automatic schema change replacing the older jar with the new one and restarting the service.
The newer jar will recognize that the schema needs an update, and will update it during the startup process.
In multi-instance high-availability setups, the previous instances may start returning errors for some requests, until they are updated. If you’d like to avoid these possible errors, you may first bring all the old instances down before starting new instances one by one.
Manual schema change (more control)
When running the store.postgres.update.schema=false property on instances that serve requests, you should take the following steps to perform updates. These steps should be taken service by service:
- Make a copy of the properties file, and name it
schema-update.properties. - Edit the new copy to change the
store.postgres.update.schema=trueproperty and change the Postgres user to one that has schema update privileges. - Replace old jars with new version jars.
- Stop all running instances of that service.
- Manually run the updated jar with the
--config schema-update.properties --test-store-connectionsys args. - Observe the log output. You should see a line similar to the
INFO liquibase.changelog.ChangeSet - ChangeSet db/changelog/ekm/changes/changelog-2022-06.yaml::13::jb ran successfully in 6393ms. This indicates that the schema has been updated successfully. - Start all regular instances using new jars.