We are facing an issue with OpenMRS platform upgrade from 2.5.x to 2.6.x. Our setup already has OpenMRS running with all the required schema initialised with 2.5.x through the OMRS_CREATE_TABLES environment variable set to true.
Now when we upgrade the version of OpenMRS core to 2.6.x, liquibase migration fails as it tries to create the tables again.
So is it expected that OMRS_CREATE_TABLES should be set to true only during initial startup and later set it back of to false ?
It should be at least somewhat idempotent. OMRS_CREATE_TABLES corresponds to the create_tables key in the initialization script. By itself, it shouldn’t be retriggered on upgrades. The installation script shouldn’t be triggered if there’s an existing openmrs-runtime.properties (or, really, <WEBAPP_NAME>-runtime.properties with valid DB credentials that can connect to a database with any table other than the liquibase infrastructure tables (liquibasechangelog and liquibasechangeloglock), so you shouldn’t need to tweak it at all. However, if any of the above conditions fail, OMRS treats things as a new install, in which case creating the database will fail like you noted).
Is the openmrs-runtime.properties file properly stored for durable use? We recommend mounting the whole $OPENMRS_APPLICATION_DATA_DIRECTORY as a volume in Dockerized setups.