We are 2 on the same boat. No customer support I need to pull the information off that database though there is nobody willing to solve. And yes I have re started, re deploy, re do everything and dont work.

Your data is safe. When you upgraded MySQL from 9.4.0 to 9.6.0, a new empty volume was created and mounted instead of your original one. The original volume with all your data still exists, it's just detached.

To restore access, you'll need to remount the original volume to your MySQL service at /var/lib/mysql. You can do this by going to your MySQL service settings, removing the current volume, then attaching the original volume (you should see it listed as an existing volume in your project). Before redeploying, I'd also recommend reverting the MySQL image back to 9.4.0 to match the version your data was created with.

Let us know if you need help with the remount process.

If you aren't able to solve your problem as well, please open a separate thread and we will be glad to help you. Be sure to include link to the MySQL service you are having trouble with.

Hey! Thanks for the response. I tried mounting the other volumes before exploring other avenues, they were empty (barring the one that has backup data), so I left that one mounted and ended up attempting to restore it to no avail. After attempting to run the service with 9.6.0, the logs state that I cannot revert back to 9.4.0 from this version..

I understand how frustrating this must be, especially when it started with an issue on our end. I'm sorry for the trouble the incident caused.

Unfortunately, once data within a volume has been modified or overwritten, we don't have a way to recover previous contents on our side. The volume itself is intact and correctly mounted, but the data changes that occurred during or after the incident are beyond what we're able to reverse.

If you didn't already try it, I'd suggest creating a 9.4.0 Postgres instance and mounting the original volume - like you had originally.

Going forward, I'd strongly recommend setting up regular backups for your database so you have a recovery point if anything like this happens again. Railway offers a built-in backup feature that can help with this: https://docs.railway.com/reference/backups

Again, I'm really sorry we can't do more here. Please don't hesitate to reach out if you have any other questions.

I've tried using mysqldump over SSH on the service but I keep coming up against authentication issues using the credentials in the environment, it feels like they've been rotated without updating the service.. The dashboard itself reports: ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES), can we regenerate the credentials?

I'm unable to restart the process to skip the grant tables, just for the sake of regaining access. I've tried making a new service and attaching the volume to it but I experience the same issue regardless of whether it's on the new or existing service.

Since I can see there is backup data on the volume, is there any chance we can get a dump from your end?

We don't have the ability to access or dump data from MySQL databases on our end - MySQL authentication is handled entirely within the container, and we don't have access to those credentials. The ERROR 1045 you're seeing suggests the credentials in your environment variables don't match what's stored in the MySQL user tables on the volume.

Since you mentioned one volume has backup data, you could try mounting that volume to a fresh MySQL 9.4.0 service to see if the credentials there still work. If the backup was created before any credential changes, authentication should succeed.

That's unfortunate, I wasn't sure what kind of access you had to these containers or the data associated with them..
The backup was created well before the incident, however it still has the same results (Access Denied), on both a new and existing service

So sorry to hear that. I wish we could do something to help.

just sorries, re do, re start and couldve done better... bla