I see a message "Migrate your plugin to a V2 database", but don't know what that is
I have googled for it, searched in Railway help, searched in KB, can't find any docs. Would be really nice if there was a link to docs right there inside the "Migrate your plugin to a V2 database" message, so people know what it is.
I'm afraid to click the button, for fear of something breaking, or losing features that I currently enjoy in my current config.
35 Replies
Project ID:
N/AN/A
Hi @VoiceOfSoftware
Clicking that button will open up a modal that will explain what will happen. You can also view the guide here https://docs.railway.app/guides/database-migration-guide
That is good feedback about having a link right in the banner though!
Yes, a button named [Migrate] makes it seem like something is going to happen right away...there's no indication that it's going to present a dialog. Perhaps [Learn More About Migrating]
@jr after migration, my stored procedures don't seem to exist, at least not the way I was calling them before: PROCEDURE railway.GetCalendarBroadcasts does not exist
project b855592c-9156-4020-9543-d41a4e939fde
You mean the MySQL procedures?
MySQL stored procedures, yes
[0] code: 'ER_SP_DOES_NOT_EXIST',
[0] errno: 1305,
[0] sql: "CALL WorksQuery('devas','',false)",
[0] sqlState: '42000',
[0] sqlMessage: 'PROCEDURE railway.WorksQuery does not exist'
let me take a look
the data from the plugin was not removed so the migration might just need to be updated
Seems like the stored procedures exist (when I connect directly to MySQL with TablePlus client), but my NodeJS mysql2 package seems to be unable to call them
Is it this deployment that you are referring to? https://railway.app/project/b855592c-9156-4020-9543-d41a4e939fde/service/77633db6-7ea1-4ef3-9f4a-c12b733ad491?id=965b0312-4d70-4e2a-8410-a3b50b803a5e
Yes, that's my prod environment, and I also have a dev environment that's failing
Oh, my TablePlus may be hitting the old MySQL environment?
OK, now that I'm hitting the new MySQL database, I see no stored procedures there any more
I see I see. I think there may be 2 issues here.
1. You are running into the network initialization issue. To fix this you can add a
sleep 2 && <actual start command> in the package.json start script
2. MySQL routines and procedures were not successfully restored. This is a simple fix that we can do to update the MySQL migration script.Will you be able to migrate the stored procedures for me?
Yes, once the migration script is updated, you can delete newly created "MySQL" service and re-run the migration
I'll let you know once that is good to go
For startup, do you mean this line in package.json?
"start": "node build/index.js",
"start": "sleep 2 && node build/index.js",
Yeah. Can you change it to
yeah perfect
OK, in the meantime, how do I revert back to my old plugin, so my website can run again?
You can press rollback on the deployment from a day ago
OK, phew, that was terrifying. Rolling back now...
Yes sorry about that. The migration will never delete any of the data but I very much understand that downtime is scary. We are working to improve this process as much as possible to minimize downtime and issues like this
Thanks for being available on short notice...
I'd rather migrate now, than wait until the last day in 2024
@jr hmm, my prod environment came back up, but dev crashed after rollback. I'm re-deploying with sleep 2 && to see if that helps
Seems to be back up now
yes absolutely.
You should be able to migrate again. You should delete/rename the service that was first created https://railway.app/project/b855592c-9156-4020-9543-d41a4e939fde/service/50ff3704-3452-4e95-950b-b5c3227bd968
Migrating now...
@jr it seems like the MySQL credentials are wrong now
I can't open the database using TablePlus from my local machine, and logs show this from within my deployed app:
[0] Authentication failed against database server at
roundhouse.proxy.rlwy.net, the provided database credentials for root are not valid.
[0]
[0] Please make sure to provide valid database credentials for the database server at roundhouse.proxy.rlwy.net.dont know if jr is still monitoring this thread, so ill try to answer this.
i think the new database would be using different credentials, you can copy them from the variables tab of the new database service
Last time I migrated, the credentials were copied for me, and my deployed app was using them.
As for TablePlus, I thought I copied the connection string from here https://railway.app/project/b855592c-9156-4020-9543-d41a4e939fde/service/5c25a5b4-ad96-491a-85d8-44f79fc1c618/variables
These variables are quite different from my previous working credentials
i dont work for railway so i cant see anything pertaining to your project, so ill tag @jr back in
Thx, I'm going to get some sleep now, so I'll roll back, and reconnect @jr tomorrow
Rollback failed. Variables like MYSQLHOST are empty string now
Hi @VoiceOfSoftware,
Looks like your rolled back successfully by manually setting the variables?
The mysql migration script has been updated again which should handle the authentication error you were seeing. You are free to migrate whenever you wish
Yes, I manually set the variables. I have an hypothesis about what happened:
1. I migrated, but the old script broke things because it did not copy MySQL stored procedures (you helped me with this)
2. During first migration, my old "MySQL" plugin was renamed "MySQL Legacy", and a new v2 service was added named "MySQL"
3. My viariables used {{MySQL.MYSQLHOST}} macro expansion values
4. After you fixed the scripts, and had me try migration a 2nd time, I ended up with two services both named "MySQL Legacy" -- I'm guessing it renamed the v2 MySQL service to MySQL Legacy?
5. Perhaps the macro variables got confused at this point? They all looked like {{MySQL Legacy-SOME_BIG_GUID}}
6. I deleted the v2 MySQL service. Attempts to rollback failed
7. I renamed my old plugin back to "MySQL", but perhaps the variables got confused at this point? -- now all of my variables are empty
8. Now that I was back to a v1 plugin named "MySQL" I manually went into each variable and cleaned up the macro to look like {{MySQL.MYSQLHOST}}
9. I redeployed my app from my laptop, because at this point, even rollback to 24-hour-old prior functioning builds was failing. Variables seemed very unhappy at this point
@jr why is automod preventing me from writing simple replies?
#🛂｜readme #5
I'll try migrating again in a few minutes
That's almost literally what I tried to send before, but automod denied it
right but you tried to ping a team member, automod is enforcing #5 of the readme
Oh that's weird. I figured we were in the middle of a conversation, but some time had passed, so I wanted to give a status update and make sure jr heard about it
no worries, all good
Anyway, as long as the right people get the message. I was just trying to not leave them hanging on read
OK, I think it worked that time. MySQL queries seem faster, too, although I don't recall reading that would be one of the benefits
Hey sorry @VoiceOfSoftware, I had already signed off last night so missed the message.
Glad it is working now. And thanks for bearing with us while we improve the mysql migration path for everyone.