Turning it off cause you're not using it seems reasonable, but I'm surprised it has a big effect on performance. Sequential appends to a file are pretty easy as long as you're not doing so many writes per second that there's contention on the write.
The performance impact depends substantially on whether you've configured it to fsync the binlog on every group commit.
Also, it's important to consider that replication and backups serve different purposes. Backups alone are insufficient for high availability, change data capture, point-in-time recovery / undoing a bad change, etc.
One of the main reasons I use Postgres is I've rarely(never?) seen an article like this posted about it. Every time I've touched MySQL I've found a new footgun.
This is excellent. In the past when replicating via Debezium from a system making heavy use of cascade deletes I’ve had to write a layer that infers these deletes by introspecting the database schema, building a graph of all cascades (sometimes several layers) and identifying rows that should have corresponding delete records. These can then be excluded in whatever downstream system via an anti-join. It works but it will be better to not have to do that and instead have first class support for cascades.
6 comments
[ 3.1 ms ] story [ 21.9 ms ] threadAlso, it's important to consider that replication and backups serve different purposes. Backups alone are insufficient for high availability, change data capture, point-in-time recovery / undoing a bad change, etc.
Is there any LLM with that name?