Hi there, MB folks! This may seem pretty odd at first, but let me give you a scenario.
Quick info about my setup: metabase running from jar file on EC2.
That said, we’re just finishing our migration from H2 metadata storage to MySQL, and it is running just fine™ (bless your heart, people who made the guide and troubleshooting).
My main concern, for now, is related to updating. Currently, my “update preview” process is to download the new version jar locally, download my production H2, and try metabase. After the migration, I no longer have the H2, and, although Metabase is horizontally scalable (https://github.com/metabase/metabase/issues/2754), that would mean my local version making changes to the production database.
My question is if it is possible to get back the H2 file from the metadata database, so I could do the same testing proccess for new versions.
(PS. Someone in my team already suggested to simply create a new schema in the database and point the local instance to that schema. I’ll probably stick to that option, but I deemed this question worthy nonetheless - hope not to be wrong)
First thing, you never (never ever) want to run multiple instances with different versions connected to the same metadata. It can end in corruption.
Metabase does not support downgrading, so the only way to restore would be from a backup (or a lot of manually trickery by looking at the changesets).
I would not recommend in any way to go back to H2 - even if it just for testing. There are projects for converting MySQL to H2 like mysql2h2-converter (I have never tried it) and several posts on stackoverflow.com
I would do what your co-worker recommended - simply copying the entire database and connecting to that as a test, and delete the database after every test.
Make sure that you firewall/block pulses (email/slack) from the test JAR-file, so the test version is not accidentally sending information out (which could be wrong or duplicate).
If you’re handy, then you could probably code the entire process in a script, so you don’t forget things or accidentally connect to the production metadata database.
Thanks, you could not have been any clearer. Hopefully this post stays as a reference for future readers.