PlanetScale offers undo button to reverse schema migration without losing data
(2022/03/24)
- Reference: 1648144812
- News link: https://www.theregister.co.uk/2022/03/24/planetscale_undo_button/
- Source link:
Distributed transaction database biz PlanetScale has introduced an "undo" button it says can reverse schema changes, allowing devs to avoid embarrassing disasters by reverting to the original design without losing data within a 30-minute window.
[1]Based on YouTube-developed distributed relational database Vitess, PlanetScale is a proprietary database-as-a-service designed to make life easier for developers than the open-source system. Based on MySQL, Vitess is used by the likes of Slack, Airbnb, and GitHub for its horizontal, globally scalable online transaction processing (OLTP) architecture. It has added SoundCloud, Solana, and MyFitnessPal as customers since it [2]launched .
With the latest announcement, PlanetScale introduces an "Easy Button" to undo schema migrations that enables users to recover in seconds from changes that break production databases. Dubbed Rewind, the feature lets users "almost instantly" revert changes to the previous healthy state without losing any of the data that was added, modified, or otherwise changed in the interim.
[3]
It says the feature is an industry-first. Other databases claiming undo features only revert to snapshots while losing all of the data that had been ingested since the new schema was introduced, the company said.
[4]
[5]
PlanetScale VP of engineering Nick van Wiggeren told The Register Vitess contributors had built tools to make managing MySQL "really easy."
"We've built Rewind on top of a Vitess technology called V replication, which is like MySQL replication on steroids," he said. "It lets you do all kinds of... very impressive behind-the-scenes work to mung MySQL data the way that you want it. In short, Rewind works by leveraging Vitess V replication technology to tell MySQL to have two views of the world. You have a view of the world from before the schema change, you have a view of the world after the schema change, and it will actually kind of materialize both views of the world while you're writing data, because you [might] need to switch between the new and the old view of the world."
[6]IBM Cloudant pulls plan to fund new foundational layer for CouchDB
[7]MongoDB to terminate Russian SaaS accounts
[8]DataStax updates K8ssandra to help Cassandra operate worldwide
[9]DBAs massively over-provision Oracle to protect themselves: Microsoft
Van Wiggeren argued that 30 minutes was plenty of time to realize there was a problem with a schema migration. "I've worked at GitHub and plenty of other companies that use databases. In my experiences, when you have a bad schema migration, you know within about 30 seconds. Someone Slacks you and says the website down, or you hit refresh on your application monitoring system and there are thousands of error messages."
He said there was no appreciable impact on performance from using the features.
[10]
Andy Pavlo, associate professor of databaseology at Carnegie Mellon University, said PlanetScale had introduced a feature that would matter to developers.
"People often focus solely on performance metrics when evaluating database systems," he said. "This is a mistake because most applications are boring and they don't need sub-millisecond query latencies. But almost everyone will have to make schema changes in their applications, and this is where things can go horribly wrong.
"PlanetScale has done a good job prioritizing features in their database service that make it easier for app developers to maintain their applications. Along with their previously announced branch and [11]non-blocking schema change features , the ability to quickly rollback a schema change makes it provide developers with an important escape hatch without losing data." ®
Get our [12]Tech Resources
[1] https://www.theregister.com/2021/05/18/planetscale_promises_vitess_dbaas/
[2] https://www.theregister.com/2021/05/18/planetscale_promises_vitess_dbaas/
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/databases&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Yjz4H134aP1LXDX9PMVG@QAAAAs&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/databases&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Yjz4H134aP1LXDX9PMVG@QAAAAs&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/databases&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Yjz4H134aP1LXDX9PMVG@QAAAAs&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[6] https://www.theregister.com/2022/03/15/ibm_cloudant_couchdb/
[7] https://www.theregister.com/2022/03/15/mongodb_terminates_russian_saas/
[8] https://www.theregister.com/2022/03/08/datastax_k8ssandra_update/
[9] https://www.theregister.com/2022/03/07/oracle_cloud_migration_microsoft_advice/
[10] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/databases&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Yjz4H134aP1LXDX9PMVG@QAAAAs&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[11] https://docs.planetscale.com/concepts/nonblocking-schema-changes
[12] https://whitepapers.theregister.com/
[1]Based on YouTube-developed distributed relational database Vitess, PlanetScale is a proprietary database-as-a-service designed to make life easier for developers than the open-source system. Based on MySQL, Vitess is used by the likes of Slack, Airbnb, and GitHub for its horizontal, globally scalable online transaction processing (OLTP) architecture. It has added SoundCloud, Solana, and MyFitnessPal as customers since it [2]launched .
With the latest announcement, PlanetScale introduces an "Easy Button" to undo schema migrations that enables users to recover in seconds from changes that break production databases. Dubbed Rewind, the feature lets users "almost instantly" revert changes to the previous healthy state without losing any of the data that was added, modified, or otherwise changed in the interim.
[3]
It says the feature is an industry-first. Other databases claiming undo features only revert to snapshots while losing all of the data that had been ingested since the new schema was introduced, the company said.
[4]
[5]
PlanetScale VP of engineering Nick van Wiggeren told The Register Vitess contributors had built tools to make managing MySQL "really easy."
"We've built Rewind on top of a Vitess technology called V replication, which is like MySQL replication on steroids," he said. "It lets you do all kinds of... very impressive behind-the-scenes work to mung MySQL data the way that you want it. In short, Rewind works by leveraging Vitess V replication technology to tell MySQL to have two views of the world. You have a view of the world from before the schema change, you have a view of the world after the schema change, and it will actually kind of materialize both views of the world while you're writing data, because you [might] need to switch between the new and the old view of the world."
[6]IBM Cloudant pulls plan to fund new foundational layer for CouchDB
[7]MongoDB to terminate Russian SaaS accounts
[8]DataStax updates K8ssandra to help Cassandra operate worldwide
[9]DBAs massively over-provision Oracle to protect themselves: Microsoft
Van Wiggeren argued that 30 minutes was plenty of time to realize there was a problem with a schema migration. "I've worked at GitHub and plenty of other companies that use databases. In my experiences, when you have a bad schema migration, you know within about 30 seconds. Someone Slacks you and says the website down, or you hit refresh on your application monitoring system and there are thousands of error messages."
He said there was no appreciable impact on performance from using the features.
[10]
Andy Pavlo, associate professor of databaseology at Carnegie Mellon University, said PlanetScale had introduced a feature that would matter to developers.
"People often focus solely on performance metrics when evaluating database systems," he said. "This is a mistake because most applications are boring and they don't need sub-millisecond query latencies. But almost everyone will have to make schema changes in their applications, and this is where things can go horribly wrong.
"PlanetScale has done a good job prioritizing features in their database service that make it easier for app developers to maintain their applications. Along with their previously announced branch and [11]non-blocking schema change features , the ability to quickly rollback a schema change makes it provide developers with an important escape hatch without losing data." ®
Get our [12]Tech Resources
[1] https://www.theregister.com/2021/05/18/planetscale_promises_vitess_dbaas/
[2] https://www.theregister.com/2021/05/18/planetscale_promises_vitess_dbaas/
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/databases&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Yjz4H134aP1LXDX9PMVG@QAAAAs&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/databases&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Yjz4H134aP1LXDX9PMVG@QAAAAs&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/databases&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Yjz4H134aP1LXDX9PMVG@QAAAAs&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[6] https://www.theregister.com/2022/03/15/ibm_cloudant_couchdb/
[7] https://www.theregister.com/2022/03/15/mongodb_terminates_russian_saas/
[8] https://www.theregister.com/2022/03/08/datastax_k8ssandra_update/
[9] https://www.theregister.com/2022/03/07/oracle_cloud_migration_microsoft_advice/
[10] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/databases&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Yjz4H134aP1LXDX9PMVG@QAAAAs&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[11] https://docs.planetscale.com/concepts/nonblocking-schema-changes
[12] https://whitepapers.theregister.com/
Re: sounds neat
Nate Amsden
thought about it more and I'm sure I would of pointed the app against the read only standby DB, then I could blow away the primary DB and restore the updated data, then update app to point to the primary DB, restart it, then rebuild the standby. basically just a few seconds of downtime.
Sound handy in a pinch, but never tell your boss about it.
Anonymous Coward
This is the sort of thing that could save the day once in a while, but it could also get organizations in trouble as it requires a fairly deep insight into the underlying data and your implementation to ensure it's safe. If management starts to think that they can push poorly planned schema and business rule changes on a regular basis and wave a magic wand to "fix" it they are gonna blow their foot off. A feature that gives a PHB the idea their entitled to make bad/risky decisions is dangerous indeed.
For a 30 min window to work, you probably need to have a tested plan B on deck to handle the exceptions or cleanly shunt operations. Without that a 30min window is just someone whistling the Jeopardy theme in your ear while you try to improvise an unplanned fix as a tractor slowly rolls over you.
sounds neat
But performance is usually much more important than schema changes, I mean people have been doing schema changes for a long time and generally they get tested quite a bit and it's a known problem to deal with if a schema change goes badly.
I had one situation at a company ~15 years ago with MySQL, we had to do a schema change but the production MySQL server lacked the disk space needed to re-write out the entire table again(at the time maybe it was 100-300GB I don't remember). Fortunately it wasn't our OLTP database(which was Oracle) but rather an data store that didn't have to be updated too often(the data inside was job search results). Ironically enough I was trying to justify the need for a SAN at the time to leverage shared storage and make it available to more hosts. I already had a "demo" SAN installed on site, though I had it installed at our HQ not at our co-location. I did this purposely because the vendor said pretty much every customer that deployed their system ended up buying the demo unit because they had to rush it into production for some critical need, I wanted to avoid that trap.
So here we are, critical need for this SAN. So I came up with a crazy plan. We stopped the app(s) that updated the MySQL database, we may of even put the database in readonly mode I don't recall. The app continued to function fine, users were unaffected other than newer things weren't getting into the DB(the only thing that updated the DB was the app itself, users could never update that DB).
I took a USB drive, drove it to the data center, hooked it up, copied the DB over, drove it back to the office, copied it onto our demo SAN, did the schema migration, then copied the DB back to USB, drove it back to the data center and copied it back into place again. I assume we had to take an outage on that MySQL DB for copying the data back into place, but really wasn't a big deal. Fortunately our colo was only about a 45min drive away. These days my colo is 2,000 miles away.
Manager was convinced at that point we really could benefit from shared storage so we bought that demo unit after all and had the vendor move it to our colo.