I have tried all the options described in the docs and other community posts. Can someone please take a look at this topic?
We’re currently trying to go to production with Fly using a production organisation, and we’re setting up a process to regularly copy production data to dev for proper scenario testing.
What’s the recommended way to do this?
Hi… People have reported success with the Flycast approach that you linked. Could you say more about what went wrong when you tried?
Hi @mayailurus thanks for the quick response.
I was able to go through the process and it says the import is successful, but I don’t see the database in the new cdb afterwards.
Here are the dbs in the source cdb
But after running through the process (with voxcape_api) as the cdb used in the source-uri, I don’t see it in the new db
It’s quite frustrating
Hm… That really is frustrating…
Overall, there is good news and bad news. The good news is that fly pg import is just a thin wrapper around pg_dump, so you guys could make your own script that does the same thing it does. (I.e., dump from the source-uri, and restore into local.)
The bad news is that all of the fly pg commands as well as the postgres-flex images themselves are officially deprecated now, so there will generally be rougher and rougher sailing, as time goes on.
How large is the voxcape_api database? Also, how beefy are the Machines in the two Postgres apps?
@mayailurus it’s only a few hundred MBs actually, so not so big for now.
Was able to fix it by attaching public ipv4s to both db apps and used pg_dump + psql to copy from one to another. I added extra flags like ON_ERROR_CONTINUE=on to the psql part so it keeps running if any CREATE statement fails, but this is completely optional.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.
