db migration
The postgres db migration is not moving past step one for with this error log in the new db service
project id- 8255344d-43ae-4e2a-ade0-557ac96ab17e
project id- 8255344d-43ae-4e2a-ade0-557ac96ab17e
25 Replies
Project ID:
8255344d-43ae-4e2a-ade0-557ac96ab17ered doesn't always mean an error happened, how long has the migration been going on for?
20mins
would you say you have a lot of data?
not that much, but it's stuck in the step 1 itself so thought of creating the ticket
okay gonna tag in @jr here
Hey @Vampo, I gave it a kick and it is progressing as normal now
The data looks to be all migrated now and the service was just redeployed
Although you may be running into the network initialization issue with prisma
Hey @jr, so we're in a little problem here
the db was successfully migrated at 7:05 my local time same as when you did these messages, but I saw it back later and didn't actually updated the envs + deleted the legacy dbs a few mins back
and unfortunately realised all the data in these hrs was stored in the old legacy db, it's not in the new one and old db I have deleted
is there any way we can get this old data of today from legacy db to new one?
didn't really realize this edge case, as the post migration guide only mentioned to test app with new envs, but the time between will update data in new db wasn't told and we didn't have any way to double check if the new db is up to date with the old one
the guide does say to manually verify the data in the new database before you delete the old database
im not sure how much the team can do for you here as you deleted the database yourself
got it, would be helpful to know if the team can do something in the current scenerio
generally railway wouldn't restore a database if they weren't at fault
but cant hurt to ask - @jr
would be great to get this favor just once haha
yeah i get where your coming from, but you did delete the database yourself when the guide mentioned twice (or more) to verify the data yourself
Oh no that is not good. How were you connecting to the plugin? The migration should switch over any variable references to use the new database.
We normally don't provide database restoration in cases like this, but if you provide me the timestamps of what happened I can check with our team and see if there is anything we do. Assuming it went something like this?
- Migrate database
- App runs for a bit assuming it is connected to the new db
- Delete legacy plugin
?
The migration should switch over any variable references to use the new database.I was expecting same and it did switch the env in our cron service from plugin but not in the server deployment (the env names were same) Yes, the workflow was this, the db was successfully migrated at around 7:05 my local time (same as when you did the message in chat that it's done) after that almost 16 hrs later at around 22:50 my local time, I updated the env of db url in server deployment and data started storing in the new plugin
I just need data which was updated in these 16 hrs in the db, which was stored in legacy plugin and not the new one
Was the URL hardcoded as an environment variable?
yeah it was hardcoded in the server deployment
ah okay that was it then. We only switch over variable references. I'll update the guide with that information
As for restoring the data, it is unlikely. We take snapshots of our hosts every 24 hours so there is a good chance that some data would be lost anyway. I can still check but it won't be for a few hours/until tomorrow
When was the plugin deleted?
around 22:50 my local time, so approx 2 hrs ago
Do you have the old database url? I just need the containers-*** part
fortunately I do, shall I send in DMs?
sent a friend req
accepted
sent the whole url
Moving convo to DBs