After migrating to railway's new database, we are having an issue
Hello, we migrated to the new MYSQL database from the old MYSQL database. I was told we had until the end of the month to do so. Everything seemed to work, but one of our Queries went from taking .08 seconds to taking 43 seconds. Can you please help me understand what could cause this?
27 Replies
Project ID:
e714d78b-eec7-4c60-b35e-746bd164eccb
are you connecting to it via the private network?
e714d78b-eec7-4c60-b35e-746bd164eccb/service/84d87493-d5fd-405b-bb9e-03cf3e331390?id=23772f52-afe2-4771-8eef-617b24d6793e
I don't know what that means. We are connected, and the majority of our queries are working without issue.
please gives this docs section a read and get back to me https://docs.railway.app/guides/mysql#connect
We are not connecting privately
Why would the new database be so slow with this query compared to the old one?
could it be in the wrong region?
I guess that's possible. We have not changed anything. How would I know?
The other queries are working quickly though
you can check the region from within the database's settings
It's in Oregon, I believe the previous DB was as well, and I believe our server is too.
That still doesn't make sense, because the database retrieval is what is taking so long. So far, this is the only one of our queries that we've discovered an issue with.
the new database is postgres 15, the old database was postgres 13, would the newer version cause issues with your app?
We are using MYSQL
my bad, the legacy mysql database and v2 mysql database both use the same version as far as i can tell
can you try connecting to it over the private network?
I wouldn't know how to connect mysql workbench to it over the private network.
sorry im asking you to configure your app on railway to connect to the database over the private network
Also, I am connecting to it. If I comment out some of the lines, it runs more efficiently. Is it possible that some of the indexing was lost? I don't understand why the execution would take a longer time.
I understand. I tried, and had a hard time connecting it that way. Since it is connecting, and it is working over the public, and the only issue is the length it is taking queries to return, I don't see how the connection could be the issue.
can you regenerate the indexing?
How would I do that?
im sorry but i wouldnt know, as that would be something to do with your app / project
Yes, but this clearly is a result of migrating... Do we have to migrate? Can I continue to use the database that is working?
you do need to migrate, legacy databases are going to be shut down on jan 31st
The migration is breaking my database. Do you have suggestions for how I should handle this?
was the migration successful?
I do not believe so. It seems like some data was lost, as the row count is not the same for certain tables. Also, there is the whole issue of this thread.
you might want to do a manual migration with mysql workbench
ok, I will try that next. Hopefully that will fix the issue, thank you.
To be sure I understand, I'm going to data import with a dump file?
with the use of mysql workbench, export the data from the legacy database, then import it into the new database
Cool, thanks
I think we have things stable again. This was very stressful and our team had to work late into the night to revert to the database before the migration, while keeping all of the data that changed after the migration. It seems a data dump and data import was a more reliable way to handle the migration than using the tool provided by railway. If other customers are having this issue, you should give them a heads up. Thank you for your help.