4 months ago
Hello Railway Team,
We recently migrated a customer database of approximately 4 GB to Railway and were surprised to find that the import process took nearly 24 hours to complete.
Could you please confirm whether this duration is normal for a database of this size, or if there may have been an issue related to the Railway environment or our import process?
We're trying to understand what to expect for future customer migrations so we can plan appropriately and minimize business downtime. If database imports of this size are expected to take this long, it would significantly impact how we schedule migrations for our customers.
We would appreciate any insight into what may have caused the delay and any recommendations for improving import performance.
Thank you for your assistance.
Best regards,
Pinned Solution
4 months ago
I'm not 100% sure. This number can vary due to network latency and other factors if the migration was done via your local MySQL shell.
It would most likely be much faster if the migration was done by downloading the dump and uploading the file into the volume, then restoring it directly within the instance.
8 Replies
4 months ago
This thread has been opened as a public bounty so the community can help solve it. The thread and any further activity are now visible to everyone.
Status changed to Open Railway • 4 months ago
0x5b62656e5d
How did you perform the migration?
4 months ago
I did the migration through mysql shell to dump the data , through mysql -h host -P port -u
4 months ago
It might be faster if you downloaded the dump into a file, then uploaded the file via the console tab by clicking on your service, then restoring from the dump via console.
0x5b62656e5d
It might be faster if you downloaded the dump into a file, then uploaded the file via the console tab by clicking on your service, then restoring from the dump via console.
4 months ago
instead of dumping it through local host
0x5b62656e5d
It might be faster if you downloaded the dump into a file, then uploaded the file via the console tab by clicking on your service, then restoring from the dump via console.
4 months ago
.
0x5b62656e5d
It might be faster if you downloaded the dump into a file, then uploaded the file via the console tab by clicking on your service, then restoring from the dump via console.
4 months ago
Ok
0x5b62656e5d
It might be faster if you downloaded the dump into a file, then uploaded the file via the console tab by clicking on your service, then restoring from the dump via console.
4 months ago
Thanks for the suggestion.
Just to clarify, our migration involved importing a MySQL database of approximately 4 GB and the process took nearly 24 hours.
Would you expect a significant reduction in migration time if we first generated a dump file and restored it from within Railway as you described? For example, would a migration of this size typically take hours, minutes, or still close to a day?
We're trying to estimate downtime for future customer migrations.
4 months ago
I'm not 100% sure. This number can vary due to network latency and other factors if the migration was done via your local MySQL shell.
It would most likely be much faster if the migration was done by downloading the dump and uploading the file into the volume, then restoring it directly within the instance.
Status changed to Solved 0x5b62656e5d • about 1 month ago