科技回声

11 条评论

darkwater大约 3 年前

If you are using MySQL I also recommend Percona's Online Schema Change [1] which is basically a robust implementation of this post's algorithm, handles more edge-cases, has been existing for at least 10 years now and works better out of the box with AWS RDS than Gh-ost. (if you have production experience on 100s of millions rows tables with Gh-ost on RDS please share your experience/tricks, I'd love to hear them!)[1] <a href="https://www.percona.com/doc/percona-toolkit/3.0/pt-online-schema-change.html" rel="nofollow">https://www.percona.com/doc/percona-toolkit/3.0/pt-online-sc...</a>

评论 #31270191 未加载

评论 #31273483 未加载

harryvederci大约 3 年前

Something I'm doing in my CV application is using 1 SQLite DB file per user.When a user logs in, a check is done: "Does this user's DB file have the latest migration?" If not, the migrations are applied. That way, you only get a slight delay as a user when a migration is needed. None of the other users their DB files are affected. More technical details are in the FAQ: <a href="https://withoutdistractions.com/cv/faq" rel="nofollow">https://withoutdistractions.com/cv/faq</a>In terms of the article: I'm only changing 1 tire at a time at 100mph, not all of them.PS: I recently did a "Show HN" about the app, it got some interesting feedback: <a href="https://news.ycombinator.com/item?id=31246696" rel="nofollow">https://news.ycombinator.com/item?id=31246696</a>

评论 #31271569 未加载

评论 #31273524 未加载

评论 #31271513 未加载

jbverschoor大约 3 年前

I dunno.. people seem to like 0 downtime migrations, but really, for most companies a little bit of downtime or degraded functionality doesn't matter. Most applications aren't even large enough for the downtime to be more than a couple of minutes.Having some scheduled downtime saves you a lot of complexity of writing, monitoring, and finalizing these migrations. It also makes it a lot easier to have a consistent state in terms of code+data.The article doesn't mention how to deal with different datamodels / constraints etc.

评论 #31271625 未加载

评论 #31272080 未加载

评论 #31271532 未加载

评论 #31281600 未加载

antoncohen大约 3 年前

MySQL has some robust tooling in this space. Some of the tools use triggers to copy to a new table. GitHub's gh-ost[1] is probably the state of the art, and uses the binary log stream to replicate the data.[1] <a href="https://github.com/github/gh-ost" rel="nofollow">https://github.com/github/gh-ost</a>

评论 #31269812 未加载

fabianlindfors大约 3 年前

Anybody interested in this subject might also be interested in a tool for Postgres I’ve been working on, Reshape: <a href="https://github.com/fabianlindfors/reshape" rel="nofollow">https://github.com/fabianlindfors/reshape</a>. It aims to fully automate away all the pain and manual steps zero-downtime migrations normally requires :)

yakkomajuri大约 3 年前

> Now the most challenging part: explaining to Product why their seemingly small request took 3x longer than expected. If it helps you can send them this article. Good luck!We had to solve this problem in a way that also took our self-hosted users into account. Essentially "changing Tires at 100mph" in environments we don't control. Still polishing it but will plug a post about it here if anyone finds it relevant:<a href="https://posthog.com/blog/async-migrations" rel="nofollow">https://posthog.com/blog/async-migrations</a>

stalluri大约 3 年前

I think PlanetScale folks have blogged well about how schema migration tools work and their traffic splitting, rewinding abilities are very nice.<a href="https://docs.planetscale.com/learn/how-online-schema-change-tools-work" rel="nofollow">https://docs.planetscale.com/learn/how-online-schema-change-...</a><a href="https://planetscale.com/blog/its-fine-rewind-revert-a-migration-without-losing-data" rel="nofollow">https://planetscale.com/blog/its-fine-rewind-revert-a-migrat...</a>

kasey_junk大约 3 年前

When I was first starting out writing applications it was very common for the DBA in charge of a database to require all writes to go to a stored procedure and all reads to go through views. It was at times onerous but it made migrations like these a snap. With most migrations/rdms it could even be atomic.

tzahifadida大约 3 年前

I thought of another trick. Haven"t tried it, should work though. Where applicable put tenants on multi schema. If the tables are now very small in comparison then a write lock is not that important. Simply migrate. Do a blue green deployment between code versions. Done.One downside is the downgrade part. If you still want it you have to do it as in the article.

ewuhic大约 3 年前

Side Question - could anyone suggest a tool for db cloning in context of on-commit preview environments?I am only aware of this tool: <a href="https://github.com/postgres-ai/database-lab-engine" rel="nofollow">https://github.com/postgres-ai/database-lab-engine</a>But it looks like too much manual work to do.

jfk13大约 3 年前

Ah, it's about databases... the title here immediately made me think of a much more hardcore "migration" effort: <a href="https://www.amusingplanet.com/2019/10/an-incredible-move-indiana-bell.html" rel="nofollow">https://www.amusingplanet.com/2019/10/an-incredible-move-ind...</a>

Zero downtime migrations

11 条评论

Zero downtime migrations

11 条评论