shlomi-noach

7 ms·

1.
by shlomi-noach 2y ago
Vitess maintainer here. While Vitess can still use gh-ost, the recommended way is to use Vitess' internal VReplication mechanism. With this, your can throttle, pause, resume, cancel, retry, revert a migration, as well as auto-resume fr
2.
by shlomi-noach 3y ago
We've all been there and have been hit hard by rolling back data as well as by not rolling back data. What we do with PlanetScale Reverts, though, is to preserve your data through the rollback. There aren't three classes of data,
3.
by shlomi-noach 3y ago
Valid points! In my experience, when someone has foreign key constraints in their database, they tend to develop their apps in "trusting" way. Meaning, the app trusts the DB to maintain referential integrity. When you do the three
4.
by shlomi-noach 3y ago
Thank you!
5.
by shlomi-noach 3y ago
Yes, you got that right! If you drop a foreign key constraint from a child table, and then follow up to INSERT/DELETE rows on parent and child in such way that is incompatible with foreign key constraints, and then revert, then the chi
6.
by shlomi-noach 3y ago
Post author here, happy to answer technical questions.
7.
by shlomi-noach 3y ago
Vitess maintainer here. I feel like the discussion was about 100% feature (queries/protocol/...) compatibility and that somehow it shifted to 100% performance compatibility? 100% performance compatibility is trivially not somethin
8.
by shlomi-noach 3y ago
We are not the same. My mistake for writing "OP".
9.
by shlomi-noach 3y ago
Whoops. I wrote "OP" when I really meant "Post author". I'm a bit rusty with HN notations.
10.
by shlomi-noach 3y ago
Like the issues I mention in my post: modifying the data type of a column that is used by a foreign key; otherwise the fact you can't run Online DDL on a table that participates in foreign key relationship ; that INSTANT does not suppo
11.
by shlomi-noach 3y ago
OP. I agree! RESTRICT is by far the best rule to use, and makes the most sense. Perhaps to balance my post a bit, and for what it's worth, I don't advocate for "don't ever use foreign keys" as a blanket statement.
12.
by shlomi-noach 4y ago
Author here. Thank you for your thoughts! Some comments: > How does the author suggest non-blocking DDL is actioned? Online DDL is done in MySQL using one of the 3rd party tools, such as pt-online-schema-change, gh-ost, or now via Vites
13.
by shlomi-noach 5y ago
Thank you, good idea!
14.
by shlomi-noach 5y ago
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?) suppor
15.
by shlomi-noach 5y ago
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
16.
by shlomi-noach 5y ago
It's not like that -- that BTW is super simple to achieve with either of the existing online schema change tools (pt-online-schema-change, gh-ost, facebook's OSC) -- they all end up with your old table renamed away, and which you
17.
by shlomi-noach 5y ago
Engineer at PlanetScale; If you drop columns that are `NOT NULL DEFAULT <something>`, and then you insert some new rows to your newly-versioned table, then you're in a good spot: when you revert, those columns will get the DEFAUL
18.
by shlomi-noach 5y ago
Engineer at PlanetScale -- It is not similar; so temporal tables are about getting a table's dataset at a given point in time in the past, sort of a time machine for your table. Rewind is about undoing a (bad) structural schema change
19.
by shlomi-noach 5y ago
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 chan
20.
by shlomi-noach 5y ago
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
21.
by shlomi-noach 5y ago
Online schema change solutions have been around for over the past decade and are commonly used to ALTER TABLE with no downtime (or with minimal interruption) on the largest deployments of MySQL today. The two most common solutions are pt-on
22.
by shlomi-noach 5y ago
Since I feel injustice done here, I'd like to point out that harshit164 is a Vitess maintainer who is my go-to person of reference for these exact topics, and who is authoritative about this database technology.
23.
by shlomi-noach 5y ago
I really appreciate your feedback. I'll pass on the documentation advice, it's good to have your user perspective. I hear you on cut-over, and - it's indeed on our radar! I hope to bring good news.
24.
by shlomi-noach 5y ago
Heh, and in the MySQL space, we use a "trivial" online schema schema migration (that has no actual schema changes) to avoid table bloat :)
25.
by shlomi-noach 5y ago
Thank you! Please first see my comments to parent, as they describe how online schema change work within the same server; with PlanetScale branching, we do give you a development branch with which you can play as much as you want, without a
26.
by shlomi-noach 5y ago
> why not layer it on top of Git? ... Many orgs and integration tools already have similar workflows Indeed. See my writeup on skeefree, which we developed at GitHub: https://github.blog/2020-02-14-automating-mysql-schema
27.
by shlomi-noach 5y ago
Again, thank you for the questions. I am estimating that your database space isn't MySQL, which is just fine of course. Reason I'm asking/guessing, is that in the MySQL space, online schema change toold have been around for o
28.
by shlomi-noach 5y ago
PlanetScale engineer and Vitess contributor here. As a brief history, Vitess was originally developed as an open source project in YouTube, and then handed over to CNCF. PlanetScale was created by authors of Vitess, and employs a team of Vi
29.
by shlomi-noach 5y ago
Hi, engineer at PlanetScale and maintainer for Vitess here. Appreciate your thoughtful comment, a couple answers: > is something that sounds like I could do ... from Git platforms themselves Git is very bad at analyzing SQL diffs. It ca
30.
by shlomi-noach 5y ago
Good take. "Fortunately" if your database becomes a monster you'll need to run some schema changes to clean it up and optimize :) In seriousness, if we learn anything from code deployments, it's that we should aim for ea

More ›