gh-ost
skeema
Our great sponsors
gh-ost | skeema | |
---|---|---|
32 | 7 | |
11,982 | 1,228 | |
0.9% | 1.1% | |
7.4 | 8.2 | |
5 days ago | 11 days ago | |
Go | Go | |
MIT License | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
gh-ost
- "At GitHub we do not use foreign keys, ever, anywhere"
-
How Modern SQL Databases Are Changing Web Development - #3 Better Developer Experience
I’ve been through multiple incidents where everything worked fine in the testing environment but ended up locking the production database for minutes when deployed. A category of open-source tools called OSC (Online Schema Change) exists to mitigate such pain, like gh-ost used by GitHub and OSC used by Meta. They work by creating a set of "ghost tables" to apply the migrations, copy over old data from the original tables, and catch up with new writes simultaneously. When all old data is migrated, you can trigger a cutover to make the "ghost tables" production. Check the post below for a great introduction and comparison:
-
We migrated to SQL. Our biggest learning? Don't use Prisma
Sounds like it's basically explained in the gh-ost readme https://github.com/github/gh-ost#how
I think it amounts to "use views to decouple access to the table with a fixed interface" and "use triggers for migrating data between tables"
-
Ask HN: Is PostgreSQL better than MySQL?
Gh-ost is the new hotness. Simple to use and lots of great features: https://github.com/github/gh-ost
-
My Green/blue AWS db deployment strategy for avoiding data loss due to table locks
If the performance of the db is a concern during migrations (locking, high cpu consumption for large writes) there are tools that can help and do similiar to what your describing but with the benefit that they are battle tested tools. This one spring to mind https://github.com/github/gh-ost there are other options as well and its worth reading the trade off docs
-
Changing column from longtext to mediumtext taking over 2 hours
Not sure which version of MySQL you're using, but one approach would be to use a tool like pt-online-schema-change (from Percona) or g-host -- which will create a duplicate table and then swap it in place of the original table. It's a safer approach when operating in production environments. Here's a good comparison of the tools many people use https://planetscale.com/docs/learn/online-schema-change-tools-comparison
-
Ask HN: Do you use foreign Keys in Relational Databases
No, especially on large tables with billions of records. They make online schema changes impossible. More details: https://github.com/github/gh-ost/issues/331#issuecomment-266...
-
Migrating a production database without any downtime
Tip #4: Consider slow-running migrations. Some tables can be so large that the traditional migration way is simply not a viable option for them. In such cases, you can consider embedding the data migration code right into your application, or use a special utility like GitHub's online schema migration for MySQL. A slow-running migration can work in production for days or even weeks. It gradually converts the data by small chunks, so you can carefully balance the load on the database while making sure that it doesn't cause slowness or downtime.
-
How do you handle RDS schema migrations?
GitHub gh-ost
-
Changing Tires at 100mph: A Guide to Zero Downtime Migrations
Actually I never tried but I was scared by the small print of GH not using RDS themselves [1] and Ghost relying on lower-level features that might be not easily available in RDS. Also I had the impression you have to setup a normal non-RDS replica attached to your RDS master?
skeema
-
Features I wish PostgreSQL had as a developer
If a tool blindly drops columns, that's just a bad tool! It doesn't mean the concept is flawed.
Thousands of companies successfully use declarative schema management. Google and Facebook are two examples at a large scale, but it's equally beneficial at smaller scales too. As long as the workflow has sufficient guardrails, it's safe and it speeds up development time.
Some companies use it to auto-generate migrations (which are then reviewed/edited), while others use a fully declarative flow (no "migrations", but automated guardrails and human review).
I'm the author of Skeema (https://github.com/skeema/skeema) which has provided declarative flow for MySQL and MariaDB since 2016. Hundreds of companies use it, including GitHub, SendGrid, Cash App, Wix, Etsy, and many others you have likely heard of. Safety is the primary consideration throughout all of Skeema's design: https://www.skeema.io/docs/features/safety/
Meanwhile a few declarative solutions that support Postgres include sqldef, Migra, Tusker (which builds on Migra), and Atlas.
-
Ask HN: Startup Devs -What's your biggest pain while managing cloud deployments?
I’d argue the obvious answer is address the lack of great answers for declarative schema migration in PostgreSQL. There is Skeema https://github.com/skeema/skeema but it doesn’t support Postgres and Prisma iirc forces you into an ORM, atlas looks perfect but has a nonstandard license.
-
How Meta Built the Infrastructure for Threads
Ahh I see now, you've founded https://github.com/skeema/skeema which is great!
Keep it up!
-
Russ Cox: Go Testing by Example
Using tmpfs for MySQL/MariaDB's data directory helps tremendously. If you're using Docker natively on Linux, use `docker run --tmpfs /var/lib/mysql ...` and that'll do the trick. Only downside is each container restart is slightly slower due to having to re-init the database instance from scratch.
Tuning the database server settings can help a lot too. You can add overrides to the very end of your `docker run` command-line, so that they get sent as command-line args to the database server. For example, use --skip-performance-schema to avoid the overhead of performance_schema if you don't need it in your test/CI environment.
For MySQL 8 in particular, I've found a few additional options help quite a lot: --skip-innodb-adaptive-hash-index --innodb-log-writer-threads=off --skip-log-bin
A lot of other options may be workload-specific. My product Skeema [1] can optionally use ephemeral containerized databases [2] for testing DDL and linting database objects, so the workload is very DDL-heavy, which means the settings can be tuned pretty differently than a typical DML-based workload.
-
Automagically generate migrations for GORM
Atlas hasn’t made it on my radar until now — surprising considering how many stars it has. Based on the description, it looks like it can do something similar to skeema except it isn’t limited to one flavor of sql like skeema. I’m looking forward to trying it out in my next postgres project.
-
Database character sets and collations explained – why utf8 is not UTF-8
VARCHAR(N) can store N characters. So with utf8mb3, that's a max of 3N bytes worst-case. But with utf8mb4, it's now 4N bytes, which (with a high N) may exceed internal limits such as maximum length of an index key.
IIRC, there were additional problems in older versions of MySQL, situations where sort buffers were sized to a fixed length equal to the value's worst-case size or something like that. So sorting a large number of utf8mb4 values would use a lot more memory than utf8mb3 values (again, iirc, I might be wrong on this).
So the safer and more backwards-compatible approach was to introduce utf8mb4 as a new separate charset, and allow users to choose. MySQL 8 is now transitioning towards deprecating utf8mb3, and will finally make the utf8 alias point to utf8mb4 sometime in the near future.
That said, there are still a bunch of unpleasant uses of utf8mb3 internally in things like information_schema. I develop schema management tooling and recently lost a week to some of the more obscure ones in https://github.com/skeema/skeema/commit/bf38edb :)
-
Are entity framework tools typically avoided with MySQL & Go and are there alternatives for migration script tooling that version control the entire schema like SSDT?
I realize my paradigm on schema driven projects comes probably from my background. I found a very similar tool by chance when reading through my latest feeds and found this tool: https://github.com/skeema/skeema
What are some alternatives?
pg-online-schema-change - Easy CLI tool for making zero downtime schema changes and backfills in PostgreSQL [Moved to: https://github.com/shayonj/pg-osc]
sql-migrate - SQL schema migration tool for Go.
doctrine-test-bundle - Symfony bundle to isolate your app's doctrine database tests and improve the test performance
migrate - Database migrations. CLI and Golang library.
squawk - 🐘 linter for PostgreSQL, focused on migrations
noms - The versioned, forkable, syncable database
pg_squeeze - A PostgreSQL extension for automatic bloat cleanup
go-mysql-elasticsearch - Sync MySQL data into elasticsearch
hub - A command-line tool that makes git easier to use with GitHub.
tidb - TiDB is an open-source, cloud-native, distributed, MySQL-Compatible database for elastic scale and real-time analytics. Try AI-powered Chat2Query free at : https://tidbcloud.com/free-trial
Jenkins - Jenkins automation server
atlas - A modern tool for managing database schemas