Viewing profile — shlomi-noach

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, cance…

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 …

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 mai…

Thank you!

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…

Post author here, happy to answer technical questions.

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% p…

We are not the same. My mistake for writing "OP".

Whoops. I wrote "OP" when I really meant "Post author". I'm a bit rusty with HN notations.

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…

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 fore…

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, s…

Thank you, good idea!

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 col…

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…

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 u…

Engineer at PlanetScale; If you drop columns that are `NOT NULL DEFAULT `, and then you insert some new rows to your newly-versioned table, then you're in a good spot: when you rev…

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. Re…

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 throug…

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, …

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 deploym…

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 …

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…

Heh, and in the MySQL space, we use a "trivial" online schema schema migration (that has no actual schema changes) to avoid table bloat :)

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 b…