Hi, I am trying to do a new instance of metabase container using a postgresql restored database.
I already included environment variables such as MB_DB_HOST and MB_DB_NAME etc. but when I try to check the metabase instance I cannot see the Datamarts and users/permissions and configs from what the other metabase instance currently has.
I have a question regarding that is restoring a postgresql database backup is sufficient to replicate another instance? like pg_dump the metabase database and then restore in using pg_restore? Any help would be appreciated. been stuck for 2 days.
Hi @rafs
Yes, you just use the regular Postgres tools to migrate from one Postgres instance to another.
And then you just need to change the environment variables to point to the new Postgres location and start Metabase.
Are you sure you are migrating the correct Metabase metadata? Could it be that the other Metabase instance is storing it’s metadata somewhere else (like in the default H2)?
You should be able to see a lot of information in the Metabase log - like which database is being used for metadata.
Can you post the Diagnostic Info from Admin > Troubleshooting?
Thank you so much for responding to my question, I really appreciate it.
I think I’ve already pointed the right metabase database I’ve restored using MB_DB_NAME and other environment variables in a postgresql pod (I am using kubernetes).
I see that you brought up metadata here, is that separate from the postgresql database that I am talking about? I didn’t saw something like that in the docs.
Where should I run the diagnostic info Admin > Troubleshooting? In the metabase instance that I am replicating? Thanks so much again. Hope you’ll reply soon.
@rafs
Which version are Metabase are you using?
Remember to use the same version, since switching between versions can corrupt the metadata (metadata aka application data aka where Metabase stores it’s information).
I think you need to post your Docker run-commands (redact where needed).
@flamber we’re planning to upgrade to the latest which is 0.33.4 that’s why we’re trying to up the same configs to the new metabase that I am currently doing. We’re far behind the 0.31-ish version.
Do you think that the switching of version is the common culprit of this kind of tasks?
Make sure that you do not upgrade and migrate at the same time - it can cause problems with the schema, so first upgrade, then migrate.
As for mixing different versions using the same metadata - that will lead to corruption, since an older or newer version of Metabase might be saving data to metadata in a different way.
Metabase does not support downgrade - only upgrade - so always make backups before starting big operations like that.
For figuring out why you cannot see the correct metadata after you changed to the new server. That makes be think that you either did not copy the correct data, when migrating between the Postgres, or are using the wrong MB_DB_..., so instead of using the existing data, it creates an empty new setup.
It’s going to be difficult for me to debug this, since I don’t know your setup.
How I would debug this:
Look in the table activity, query_execution and view_log on PostgresOld to see if it’s actually the correct data (check the timestamps).
Stop MetabaseOld
Then copy the database to PostgresNew - using pg_dump or whatever you like.
Stop PostgresOld, so you don’t connect to it by accident.
Configure MetabaseNew to connect to PostgresNew
Start MetabaseNew
I’m not sure why you are migrating to a new Postgres. If you just want to upgrade Metabase, then backup the Postgres (in case something goes wrong), and upgrade Metabase.
Note, I haven’t played with Helm yet, so I’m not sure what the process is for upgrading containers.