[deleted]
It’s fine, Rewind: Revert a migration without losing data
31–39 of 39 posts
Re: It’s fine, Rewind: Revert a migration without losing data
#32"We are giving away limited-edition, retro Rewind t-shirts to the first 100 people that successfully revert a schema change." they are encouraging people to record videos of making schema changes and reverting them, in order to win a t-shirt does this seem unnecessarily risky or in really poor taste to anyone else?
I think that's the point. Schema migration is traditionally a _very_ risky thing but they're trying to make it come off as "safe", if you're a PlanetScale customer.
yeah but half the risk is on the application side, completely independent of planetscale! not all applications can handle some schema change occurring and then suddenly reversing. someone may get fired just trying to win a shirt
also their exact wording, "successfully", so if it fails your db is broken AND you do not get a shirt?
Re: It’s fine, Rewind: Revert a migration without losing data
#33Earlier quoted context omitted.
If you drop a 'title' column from a users table, for example, you can revert and have the title column reappear with the dropped data, new users added during this time (while the column was dropped) will not have a title.
Just to clarify my understanding - If we extend that scenario a bit to dropping a title column and at the same time adding a foo column. Then add rows with data in foo. Then revert. Do you lose the foo data? Alternatively, can we separate those actions out? Drop columns in one migration. Add columns in another. Add rows and data. Then revert only the migration where columns were dropped, keeping the more recent adds?
Right. So if you're both adding one column and removing another, then the revert will lose your new column and will regain your old column. Normally, you deploy DB and app in steps. E.g. if your migration adds a new column, your app is not yet aware of the column (or else your app would break). The moment the migration completes, your app is still on the not-knowing state. It takes an app deployment to actually start utilizing the new column. If you do that, and then want to revert -- you will lose any new data you've added to the new column.
In my experience, when a schema migration goes wrong, it goes wrong with a bang. It takes seconds to maybe one minute until pagers are alarming. So I'd say in a common scenario you will not get to deploy your app with the new column awareness, because you'll have realized the migration was bad right away.
> Alternatively, can we separate those actions out? Drop columns in one migration.
If you choose to do that, then you're on safer grounds; it costs you some wall clock time, because migrations do take a while to complete on medium to large tables.
Do note that Rewind only lets you rewind your most recent deployment (PlanetScale's app will not let you run the next migration before you've committed to, or have rewinded, the previous one).
Re: It’s fine, Rewind: Revert a migration without losing data
#34I’m not really the target audience for PlanetScale, but this is still pretty damn cool. This is the link where they go into detail about the mechanism that enables this feature. https://vitess.io/docs/13.0/reference/vreplication/vreplicat... Maybe GitHub should look into migrating to PlanetScale for their mysql1 cluster that keeps going down this week? Unless PlanetScale uses GitHub and that would introduce a circula…
They already do. Not for that cluster, but large tranches of data are being logically separated fr there then physically moved to separate Vitess-based clusters. It takes a lot of engineering time to safely separate the data.
Re: It’s fine, Rewind: Revert a migration without losing data
#35Does it support migrations that affect more than one table?
Re: It’s fine, Rewind: Revert a migration without losing data
#36Does it only work if no data has been written to the new structure? E.g. drop a column, and new record comes in without that column? What then?
Engineer at PlanetScale here: it _does_ work if data has been written to the new structure! In your scenario, you drop a column, populate some new rows in the new structure. Then, you regret the migration and rewind. You get the column back with all the pre-dropped values, AND you get to keep all the new rows which you've inserted. The values for the now-restored column for the newly inserted rows is the DEFAULT valu…
And now I have a follow-up!
So what if you upgrade your data structure, add a new required column and a record is inserted. You then roll back, removing the column, in order to fix a bug. When you roll forward again, is that removed/readded column's data for the inserted record still there?
Re: It’s fine, Rewind: Revert a migration without losing data
#37"We are giving away limited-edition, retro Rewind t-shirts to the first 100 people that successfully revert a schema change." they are encouraging people to record videos of making schema changes and reverting them, in order to win a t-shirt does this seem unnecessarily risky or in really poor taste to anyone else?
They don't say it needs to be a production system.
Re: It’s fine, Rewind: Revert a migration without losing data
#38Earlier quoted context omitted.
Engineer at PlanetScale here: it _does_ work if data has been written to the new structure! In your scenario, you drop a column, populate some new rows in the new structure. Then, you regret the migration and rewind. You get the column back with all the pre-dropped values, AND you get to keep all the new rows which you've inserted. The values for the now-restored column for the newly inserted rows is the DEFAULT valu…
And now I have a follow-up! So what if you upgrade your data structure, add a new required column and a record is inserted. You then roll back, removing the column, in order to fix a bug. When you roll forward again, is that removed/readded column's data for the inserted record still there?
So what you are describing here is Rewind-the-Rewind. We have built the support for this in OSS Vitess, and the answer would be "yes", you would roll forward and regain the new column with data again. But this is not (yet?) supported in PlanetScale.
Re: It’s fine, Rewind: Revert a migration without losing data
#39Earlier quoted context omitted.
Engineer at PlanetScale; it will let you go back to safety without data loss, and without making your database inconsistent. If you will indulge a realistic story; I've been through this process multiple times in production. You change a large table via ALTER TABLE; you possibly change a data type, or drop a column, or modify an index. The change takes 5 hours to complete - and things go bad. Testing in staging was g…
This is a really clear description of the problem and solution. Thanks! I recommend amending the blog (or maybe making a new post) with this exact content. I regularly run SQL databases for smaller projects but was not able to immediately conceptualize how I would use this feature from just the blog post. Maybe your target audience would be able to? But I don't see the downside in just spelling it out clearly!
Thank you, good idea!