Error upgrading : Migration failed

seohaus · April 10, 2024, 10:25am

Hello folks,

when upgrading my Metabase database upon starting it fails.

I get the following errors:

Caused by: liquibase.exception.LiquibaseException: liquibase.exception.MigrationFailedException: Migration failed for changeset migrations/000_legacy_migrations.yaml::166::camsaul:
     Reason: liquibase.exception.DatabaseIncapableOfOperation: Using a TIMESTAMP data type with a fractional precision of 6 is not supported on mysql: A timestamp datatype with 6 fractional digits was requested, but MySQL only supports 0 digits.

I have searched for a solution and found out that this should only be a problem on older MySQL versions. We are using MariaDB 11.3.x which has the feature of fractional precision. So why does this error happen?

Can I modify or overwrite the migrations locally? How do I solve this?

I am thankful for any clues.

Regards

TonyC · April 12, 2024, 9:23am

Can you share the upgrade process you did ... Also how are you deploying metabase and what version where you on and to which where you upgrading

seohaus · April 15, 2024, 9:13am

Hello TonyC,

thanks for getting back!

I do not know the previous version. I just downloaded the newest one (Metabase v0.49.3) and started it.

So far that always worked flawlessly.

I have no deployment process. I just wrote a short bash script to start Metabase.

Basically I just export the necessary values like MB_DB_CONNECTION_URI and then start Metabase with this:

java -jar /opt/metabase/metabase.jar

TonyC · April 15, 2024, 10:05am

Strange cause the failing migration is related to version 35

github.com

metabase/metabase/blob/9184ddaa7e3b12babc6b8efe9eafc648232c9579/resources/migrations/000_legacy_migrations.yaml#L6755


      
                              nullable: false
                  - sql:
                      sql: update metabase_field set database_position = id
          
          # Change field_values.updated_at and query_cache.updated_at from datetime to timestamp [with time zone] to get >
          # second resolution on MySQL.
          #
          # query_cache.updated_at was originally converted to a timestamp in 161, but we used `timestamp` instead of
          # `timestamp(6)`. It is converted correctly here.
          
            - changeSet:
                id: 166
                author: camsaul
                comment: Added 0.36.0/1.35.4
                changes:
                  - modifyDataType:
                      tableName: metabase_fieldvalues
                      columnName: updated_at
                      newDataType: ${timestamp_type}
                  - modifyDataType:
                      tableName: query_cache

Did you perform something manually at DP level?

seohaus · April 15, 2024, 10:07am

I have not really dived that deep into Metabase so no I just updated my Metabase versions like described above once in a while.

Where does Metabase get the migrations from? Are they pulled remotely or how does that work? Do you know? Can I overwrite them manually somehow?

TonyC · April 16, 2024, 2:14pm

They are in the build itself so the only way to overwrite them would be to fork metabase (won't recommend for this issue)

Maybe you have a timestamp value in the metabase_fieldvalues table that is problematic, can you have a look if you find anything strange