Hello,
For those of us running Metabase on AWS ElasticBeanstalk, where can we find the download for the patch upgrade for v44 ?
If you have a backup with a previous version of Metabase then I suggest roll back to that known good state.
From there you can follow this guide to migrate from H2 and reference this Docker compose config. You can try this locally on your own machine so that you're not exposing a vulnerable instance of Metabase to the public internet.
Once you have the data safely in postgres and working at the previous version then perform the upgrade to v0.46.6.2 and redeploy to the production environment. Hope that helps!
The rolling back to a good state is what I need help with.
I bring up a fresh container with 0.46.5 (not exposed to internet) and start with a fresh H2 and perform the "load-from-h2" (from h2 to h2) resulting in the error I showed.
When I create 0.46.5 (or 0.46.4) with volume containing the backup DB I get error when logging in:
Column "CORE_USER.GOOGLE_AUTH" not found;
because you upgraded to 47 and then downgraded. If you do that spin up 47 and do a "java -jar metabase.jar migrate down" and then spin up 46. That command will adapt the app do to a lower version
I guess I am not understanding it correctly.
I have a fresh install of v0.46.5 (the version used for my v0.46.5 DB backup), i.e. removed the metabase container, and docker compose up for v0.46.5, and using data volume (./data:/metabase-data) containing my backup data I used with v0.46.5 (last updated July 12). So, don't think I'm using v47.
When I run migrate down, I see in the log "rolling back app database schema to version 45". And errors e.g. "no rollback for: DeleteAbandonmentEmailTask" resulting in liquibase.exceptions.
With my fresh v0.46.5 install (using backup data for v0.46.5), when I set export MB_DB_AUTOMIGRATE=false I see in the log the details for manually applying changeset migration v46.00-090 .
BTW. when I have fresh install for v0.46.6.2 (with backup data for v0.46.5), when I run migrate down I also get: rolling back app database schema to version 45. And same liquibase exception.
if you got the "rolling back app database schema to version 45" message you need to either start a v45 connected to that DB or a 46 and let Metabase apply migrations
Again, using fresh install of v0.46.5 with my v0.46.5 DB backup volume and letting metabase apply migrations.
Was only mentioning what happens when I want to migrate down per your suggestion (which is to v45 which is not wanted), or what happens when I don't apply migrations (to show what migration would be applied).
Am I wrong with trying to perform fresh install of v0.46.5 and pointing to volume containing v0.46.5 H2 DB?
with all due respect, if you're setting up a new Metabase from scratch, do it with a decent and proven database like postgres, do not use H2 which will break in the short term
Building on what @Luiggi has said – also make daily/hourly backups that are complete snapshots or images of the virtual machine (VM) or filesystem that you are running from to restore from. That way when you roll back you can immediately get back to a known working system including data and configuration with minimal data loss. Or you can spin up a new VM from the backup image to work from.
...or pay for Metabase Cloud so that the infrastructure support is taken care of for you...
Sorry for the confusion. Originally I did not understand Luiggi's comment about v47. I did not realize I was running v0.47-RC2. Loaded that one (and downgraded and migrated to MySQL). All is good. Thanks everyone.
# local h2
java -jar metabase_0.47-RC2.jar migrate down
# connected to fresh MySQL install
java -jar metabase_0.46.6.4.jar load-from-h2 ./metabase.db