Título: Metabase no inicia después de una actualización: la base de datos ya fue modificada por la migración
Hola a todos,
Estamos experimentando un problema con una instancia de Metabase que se ejecuta sobre Kubernetes (AKS) y agradeceríamos orientación antes de realizar nuevos cambios en la aplicación o en la base de datos.
Entorno
-
Metabase: ejecutándose sobre Kubernetes / AKS
-
Base de datos de aplicación: PostgreSQL
-
Base de datos: Azure Database for PostgreSQL Flexible Server
-
Versión objetivo: latest
-
Despliegue: Kubernetes
¿Qué ocurrió?
Recientemente realizamos una actualización de nuestro clúster de AKS.
Después de la actualización comenzamos a tener problemas con el despliegue de Metabase.
El punto más importante es que la base de datos de aplicación de Metabase al parecer ya fue modificada por el proceso de migración de Metabase.
Por lo tanto, la base de datos ya no se encuentra necesariamente en el mismo estado de esquema que tenía antes de iniciar la actualización.
Debido a esto, nos preocupa simplemente restaurar un backup antiguo de la base de datos o hacer un downgrade de Metabase, ya que esto podría generar incompatibilidades entre el esquema actual de la base de datos y la versión de Metabase utilizada, e incluso provocar pérdida de información.
Situación actual
Nuestra principal pregunta es:
¿Existe una forma segura de continuar utilizando la base de datos PostgreSQL actual y solucionar el problema de Metabase para que la nueva versión pueda iniciar correctamente?
Preferiríamos solucionar el problema utilizando la base de datos actual, en lugar de restaurarla a un estado anterior, ya que la instancia PostgreSQL contiene múltiples bases de datos, por lo que restaurar la instancia completa no es una solución para nosotros.
Lo que hemos revisado
Hemos revisado la configuración del deployment de Kubernetes y la configuración de la imagen de Metabase.
También estamos revisando los logs de inicio de Metabase para determinar si el problema está relacionado con la migración de la base de datos o con algún otro problema a nivel de aplicación.
Una de nuestras principales preocupaciones es que la migración ya haya modificado el esquema de la base de datos de Metabase. Por esta razón, no queremos continuar cambiando versiones de Metabase sin tener claridad sobre el estado actual de la base de datos.
Preguntas
-
Si la migración de Metabase ya modificó el esquema de PostgreSQL, ¿cuál es el procedimiento recomendado para recuperar la instancia cuando la nueva versión no logra iniciar?
-
¿Existe alguna forma recomendada de verificar el estado actual de las migraciones de la base de datos de Metabase?
-
el deployment esta apuntando a la version latest, ¿es seguro permitir que el proceso de migración continúe o vuelva a intentarlo?
-
¿Qué logs o tablas de la base de datos deberíamos revisar para determinar exactamente qué migración fue aplicada y en qué punto está fallando el proceso de inicio?
-
Si vemos los logs del pod al momento de levantar se ven muchas lineas de “migrations”
2026-09-08 16:27:22,065 INFO liquibase.changelog :: Reading resource: migrations/063/20260714_field_fk_target_field_id_fk.yaml
2026-09-08 16:27:22,113 INFO liquibase.changelog :: Reading resource: migrations/063/20260717_delete_destination_db_permissions.yaml
2026-09-08 16:27:22,146 INFO liquibase :: Parsed changelog file 'liquibase.yaml'
2026-09-08 16:27:22,360 INFO app-db.encryption :: Database encrypted and MB_ENCRYPTION_SECRET_KEY correctly configured
2026-09-08 16:27:22,361 INFO app-db.setup :: Running Database Migrations...
2026-09-08 16:27:22,361 INFO app-db.setup :: Setting up Liquibase...
2026-09-08 16:27:22,413 INFO liquibase.database :: Set default schema name to public
2026-09-08 16:27:22,435 INFO liquibase.changelog :: Reading resource: migrations/001_update_migrations.yaml
2026-09-08 16:27:22,764 INFO liquibase.changelog :: Reading resource: migrations/056_update_migrations.yaml…..
…..
at metabase.core.bootstrap$_main.doInvoke(bootstrap.clj:63)
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.core.bootstrap.main(Unknown Source)
2026-09-08 16:27:28,139 INFO liquibase.util :: UPDATE SUMMARY
2026-09-08 16:27:28,139 INFO liquibase.util :: Run: 0
2026-09-08 16:27:28,139 INFO liquibase.util :: Previously run: 1218
2026-09-08 16:27:28,139 INFO liquibase.util :: Filtered out: 67
2026-09-08 16:27:28,140 INFO liquibase.util :: -------------------------------
2026-09-08 16:27:28,140 INFO liquibase.util :: Total change sets: 1286
2026-09-08 16:27:28,140 INFO liquibase.util :: FILTERED CHANGE SETS SUMMARY
2026-09-08 16:27:28,140 INFO liquibase.util :: DBMS mismatch: 67
2026-09-08 16:27:28,146 INFO liquibase.util :: Update summary generated
2026-09-08 16:27:28,149 INFO liquibase.command :: Update command encountered an exception.
2026-09-08 16:27:28,151 INFO liquibase.logging :: Successfully released change log lock
2026-09-08 16:27:28,152 INFO liquibase.command :: Logging exception.
2026-09-08 16:27:28,153 INFO liquibase.command :: Command execution complete
2026-09-08 16:27:28,224 ERROR core.core :: Metabase Initialization FAILED: liquibase.exception.LiquibaseException: liquibase.exception.MigrationFailedException: Migration failed for changeset migrations/058_update_migrations.yaml::v58.2026-09-03T00:00:04::ranquild:
Reason: clojure.lang.ExceptionInfo: Expected an encrypted value but the stored value is not encrypted. {:type :metabase.util.encryption/not-encrypted, :toucan2/context-trace [["resolve connection" {:toucan2.connection/connectable org.postgresql.jdbc.PgConnection}] ["resolve connection" {:toucan2.connection/connectable nil}]]}
2026-09-08 16:27:28,225 INFO core.core :: Metabase Shutting Down ...
2026-09-08 16:27:28,225 INFO server.instance :: Shutting Down Embedded Jetty Webserver
2026-09-08 16:27:28,239 INFO analytics.prometheus :: Prometheus web-server shut down
2026-09-08 16:27:28,243 INFO notification.send :: Shutting down notification dispatchers... {mb-dispatcher-count=2}
2026-09-08 16:27:28,247 INFO notification.send :: Starting notification thread pool with 3 threads {mb-dispatcher-count=2}
2026-09-08 16:27:28,248 INFO notification.send :: Gracefully shutting down notification dispatcher with 0 pending notifications to process {mb-dispatcher-count=2}
2026-09-08 16:27:29,249 INFO notification.send :: Notification worker shut down successfully {mb-dispatcher-count=2}
2026-09-08 16:27:29,249 INFO notification.send :: Starting notification thread pool with 5 threads {mb-dispatcher-count=2}
2026-09-08 16:27:29,250 INFO notification.send :: Gracefully shutting down notification dispatcher with 0 pending notifications to process {mb-dispatcher-count=2}
2026-09-08 16:27:30,250 INFO notification.send :: Notification worker shut down successfully {mb-dispatcher-count=2}
2026-09-08 16:27:30,251 INFO notification.send :: All notification workers shut down successfully {mb-dispatcher-count=2}
2026-09-08 16:27:30,252 WARN app-db.liquibase :: ()
2026-09-08 16:27:30,253 INFO core.core :: Metabase Shutdown COMPLETE
Podemos proporcionar los logs completos de inicio de Metabase y el error específico de la migración si son necesarios.
Agradecemos cualquier orientación sobre cómo proceder sin tener que revertir la base de datos actual de Metabase, si es posible.
PD: mi deployment siempre ha tenido la variable “MB_ENCRYPTION_SECRET_KEY”
¡Muchas gracias!