I recently troubleshoot an interesting MySQL crash, and I think it is worth sharing (with the related bugs). MySQL crashed when the disk was full, you can see the free disk graph below. The Y-axis is in the tens of GiB scale and the X-axis is in the hour scale. Can you guess what happened ?
As I wrote in a LinkedIn post, I am working on a blog post related to binary logging of big transactions. I thought I would split this post in two, so here is the first part where I cover the recent binary logging optimization in MariaDB and its unspoken advantage.
While doing benchmarks on 5.7 and 8.0, I came across a performance regression in MySQL 8.0 over 5.7 and opened a bug (Bug #111353 : 3x Performance Regression from 5.7 to 8.0 on ALTER TABLE FORCE). There has been recent activity on this bug, showing an easy workaround. This, even if it is known since 16 July 2024, has not been talked about much, so this deserves a blog post.
I just submitted a MySQL Contribution and I would like to gather feedback about it. Depending on the received feedback, I might submit an updated contribution. The contribution is Counters for Slow InnoDB Sync Reads, and its goal is to make MySQL easier to operate on “complex” IO subsystems (like network drives in the cloud).
The bug report / feature request Bug #117740 : Please consider adding Slow IO Counters contains all the details about the contribution and the problem this is solving, including what is a sync read. If you prefer looking at a PR over a patch file, you can check the Contrib / RFC Fake PR : Bug #117740 - Counters for Slow InnoDB Sync Reads (and if you want to know what is a Fake PR, it is also detailed in there). If you have thoughts or questions about this, feel free to comment below or in the Contrib Fake PR.
Thanks in advance for any feedback you might have : this will allow me to make the contribution and MySQL even better !
