Issues migrating from v0.46.5 to v0.51.4

I am encountering issues when attempting to migrate from Metabase version v0.46.5 to v0.51.4. The migration process seems to be blocked due to database locks.

I executed the migrate release-locks command as documented, but the problem persists, and the migration remains blocked.

Steps Taken:

Attempted the migration process from v0.46.5 to v0.51.4.
Ran the migrate release-locks command to release any existing database locks.
Observed that the command completed successfully but did not resolve the issue.

Expected Behavior:
The migrate release-locks command should release the locks on the database, enabling the migration to proceed without issues.

Actual Behavior:
Despite running the command, the locks remain unresolved, and the migration cannot proceed.

Environment Details:

Current Metabase Version: v0.46.5
Target Metabase Version: v0.51.4
Java Version: 11.0.25
Running Metabase in a cluster environment.
Database: MariaDB 10.6.15

Logs:2024-11-21 15:03:42,220 ERROR metabase.core :: Metabase Initialization FAILED
liquibase.exception.LockException: La base de datos tiene un bloqueo de migración por lo que no podemos actualizar. Puedes forzar la liberación de estos bloqueos ejecutando java -jar metabase.jar migrate release-locks.
at metabase.db.liquibase$wait_for_migration_lock$fn__45414.invoke(liquibase.clj:233)
at metabase.util.jvm$do_with_auto_retries.invokeStatic(jvm.clj:174)
at metabase.util.jvm$do_with_auto_retries.invoke(jvm.clj:164)
at metabase.util.jvm$do_with_auto_retries.invokeStatic(jvm.clj:181)
at metabase.util.jvm$do_with_auto_retries.invoke(jvm.clj:164)
at metabase.util.jvm$do_with_auto_retries.invokeStatic(jvm.clj:181)
at metabase.util.jvm$do_with_auto_retries.invoke(jvm.clj:164)
at metabase.util.jvm$do_with_auto_retries.invokeStatic(jvm.clj:181)
at metabase.util.jvm$do_with_auto_retries.invoke(jvm.clj:164)
at metabase.util.jvm$do_with_auto_retries.invokeStatic(jvm.clj:181)
at metabase.util.jvm$do_with_auto_retries.invoke(jvm.clj:164)
at metabase.util.jvm$do_with_auto_retries.invokeStatic(jvm.clj:181)
at metabase.util.jvm$do_with_auto_retries.invoke(jvm.clj:164)
at metabase.db.liquibase$wait_for_migration_lock.invokeStatic(liquibase.clj:227)
at metabase.db.liquibase$wait_for_migration_lock.invoke(liquibase.clj:222)
at metabase.db.liquibase$run_in_scope_locked$reify__45449.run(liquibase.clj:333)
at liquibase.Scope.lambda$child$0(Scope.java:186)
at liquibase.Scope.child(Scope.java:195)
at liquibase.Scope.child(Scope.java:185)
at liquibase.Scope.child(Scope.java:164)
at metabase.db.liquibase$run_in_scope_locked.invokeStatic(liquibase.clj:329)
at metabase.db.liquibase$run_in_scope_locked.invoke(liquibase.clj:312)
at metabase.db.liquibase$migrate_up_if_needed_BANG_.invokeStatic(liquibase.clj:360)
at metabase.db.liquibase$migrate_up_if_needed_BANG_.invoke(liquibase.clj:353)
at metabase.db.setup$migrate_BANG_55466__55467$fn__55468.invoke(setup.clj:84)
at metabase.db.liquibase$do_with_liquibase45383__45384$f_STAR___45385.invoke(liquibase.clj:135)
at metabase.db.liquibase$do_with_liquibase45383__45384.invokeStatic(liquibase.clj:138)
at metabase.db.liquibase$do_with_liquibase45383__45384.invoke(liquibase.clj:126)
at metabase.db.setup$migrate_BANG_55466__55467.invokeStatic(setup.clj:73)
at metabase.db.setup$migrate_BANG_55466__55467.doInvoke(setup.clj:55)
at clojure.lang.RestFn.invoke(RestFn.java:428)
at metabase.db.setup$run_schema_migrations_BANG_55493__55494.invokeStatic(setup.clj:149)
at metabase.db.setup$run_schema_migrations_BANG_55493__55494.invoke(setup.clj:144)
at metabase.db.setup$setup_db_BANG_55500__55501$fn__55504$fn__55505.invoke(setup.clj:167)
at metabase.util.jvm$do_with_us_locale.invokeStatic(jvm.clj:238)
at metabase.util.jvm$do_with_us_locale.invoke(jvm.clj:224)
at metabase.db.setup$setup_db_BANG_55500__55501$fn__55504.invoke(setup.clj:161)
at metabase.db.setup$setup_db_BANG_55500__55501.invokeStatic(setup.clj:160)
at metabase.db.setup$setup_db_BANG_55500__55501.invoke(setup.clj:153)
at metabase.db$setup_db_BANG_$fn__55529.invoke(db.clj:86)
at metabase.db$setup_db_BANG_.invokeStatic(db.clj:81)
at metabase.db$setup_db_BANG_.doInvoke(db.clj:68)
at clojure.lang.RestFn.invoke(RestFn.java:424)
at metabase.core$init_BANG__STAR_.invokeStatic(core.clj:121)
at metabase.core$init_BANG__STAR_.invoke(core.clj:102)
at metabase.core$init_BANG_.invokeStatic(core.clj:181)
at metabase.core$init_BANG_.invoke(core.clj:176)
at metabase.core$start_normally.invokeStatic(core.clj:193)
at metabase.core$start_normally.invoke(core.clj:187)
at metabase.core$entrypoint.invokeStatic(core.clj:226)
at metabase.core$entrypoint.doInvoke(core.clj:220)
at clojure.lang.RestFn.invoke(RestFn.java:400)
at clojure.lang.AFn.applyToHelper(AFn.java:152)
at clojure.lang.RestFn.applyTo(RestFn.java:135)
at clojure.lang.Var.applyTo(Var.java:707)
at clojure.core$apply.invokeStatic(core.clj:667)
at clojure.core$apply.invoke(core.clj:662)
at metabase.bootstrap$_main.invokeStatic(bootstrap.clj:31)
at metabase.bootstrap$_main.doInvoke(bootstrap.clj:28)
at clojure.lang.RestFn.invoke(RestFn.java:400)
at clojure.lang.AFn.applyToHelper(AFn.java:152)
at clojure.lang.RestFn.applyTo(RestFn.java:135)
at metabase.bootstrap.main(Unknown Source)
2024-11-21 15:03:42,230 INFO metabase.core :: Metabase Shutting Down ...
2024-11-21 15:03:42,230 INFO metabase.server :: Shutting Down Embedded Jetty Webserver
2024-11-21 15:03:42,250 WARN db.liquibase :: ()
2024-11-21 15:03:42,251 INFO metabase.core :: Metabase Shutdown COMPLETE.

Additional Notes:

SELECT * FROM DATABASECHANGELOGLOCK;

What should I do to update Metabase? To perform the migration in production, how can I avoid this problem?

try releasing the lock manually. Leave the table like this:
image

should be like:
UPDATE databasechangeloglock SET locked=1, lockgranted = null, lockedby=null WHERE ID = 1;

then try again

Thank you for your response.

I stopped the Metabase container, ran the following SQL command:

UPDATE DATABASECHANGELOGLOCK SET LOCKED = 0, LOCKGRANTED = NULL, LOCKEDBY = NULL WHERE ID = 1;

Then, I tried to start the application again, but it continues to throw the same error as before.

Hi,

I repeated the migration process, and this time it worked correctly without modifying anything. However, I'm unsure what could have caused the previous failure. I'm considering deploying these changes to production and want to avoid encountering this error again.

Aside from creating a full database backup, what additional steps should I take to ensure a smooth migration process in production?

Thank you in advance for your guidance.