The latest from the MySQL community

The common practice is to size the Galera Cache based on write volume measured during peak load, but often it is more of a guesswork. The writeset cache capacity planning is crucial to shorten the maintenance time and avoid long state transfers while the cluster runs with reduced compute power. Now, if you could understand what’s exactly inside the cache, wouldn’t the planning be more aware as compared to only calculating the best size based on wsrep_received/replicated_bytes variables?

Similarly, while dealing with various incidents occurring in Percona XtraDB Cluster or MariaDB Galera Cluster environments, how many times did you stumble upon the fact that the GCache file (galera.cache) is a black box and you can’t inspect it in a meaningful way? 

In some scenarios, having the opportunity to see what exactly ended up in the cache file(s) could help us understand the write workload impact or what happened …

Choosing how to upgrade a MySQL database is rarely just a question of source and target versions. The best approach can depend on database size, storage engines, replication topology, available infrastructure, acceptable downtime, backup readiness, application compatibility, and rollback requirements. A small standalone database with a long maintenance window may be a good candidate for […]

MySQL HeatWave now offers more control and transparency around maintenance. With Deferred Maintenance and Maintenance Events, customers can better align database maintenance with their business schedules and operational processes to reduce disruption. Customers can now temporarily disable disruptive maintenance which requires system reboots. To ensure the ongoing security of customer environments, zero-downtime security patches will continue to be applied regularly.  Additionally, […]

Planet MySQL has always been about discovering what’s happening across the MySQL community. Now, there’s even more to explore. We’ve added new ways to discover the projects and products that make up the broader MySQL ecosystem, find upcoming MySQL events, and search the wealth of content shared by the community. At the center of these […]

Our first post showed MySQL 9.7 with one change: mark a table ENGINE=DuckDB and its analytical queries run in DuckDB instead of InnoDB. The question we kept getting after that was about replication. Can you keep a normal InnoDB primary for the writes, and run a replica where the big tables are ENGINE=DuckDB? Then the heavy reports run on a column store, and ordinary MySQL replication keeps it current. No export job. No second database to sync by hand.

So we tried it. The first run failed, and it failed in a way that is easy to miss: the replica took every transaction, reported success, and stored nothing. We tracked down why, fixed it, and the whole test suite passes now. This post is what we tested, how we checked it, the bug we found, and where it stands.

It’s still an experiment, not production software. The code and the test harness are on GitHub under GPLv2: …

We ran DuckDB MySQL storage engine at scale factor 500. It is around 500 GB of raw TPC-H, three billion lineitem rows  on an 80-core server with 187 GB of RAM. Three engines on the same box: InnoDB, our MySQL+DuckDB engine, and plain DuckDB as the reference.

Here is what came out. InnoDB finished 18 of the 22 queries and spent more than 28 hours of query time on them. Four never finished. Our engine ran all 22 in about three minutes. It loaded the data 25 times faster than InnoDB, and it used 5 times less disk. On the queries it stays close to plain DuckDB, and on a few it is ahead.

It’s still an experiment, not production software. Code and the benchmark harness are on GitHub under GPLv2: https://github.com/Percona-Lab/ducksdb-mysql-engine.

The machine, and how we ran it

• One server, 80 cores, 187.5 GB RAM.
…

This article is also available in Chinese: 中文版. Browse all English articles.

Have you ever run into a mysqld process that has been starting for a long time and still won’t come up? When that happens, you can use perf top to check what the MySQL process is mainly doing. If what you see looks like the figure below — the MySQL main thread (the one starting from mysqld_main) spending the vast majority of its time rolling back transactions — then you are very likely hitting a large-transaction rollback.

The most common way to get here is a large transaction that fills up the disk while writing its binlog, crashing the instance. The largest binlog file I have run into was over 114GB. Since the Binlog Cache’s …

Henrik IngoMySQL Community Architect In May we hosted the first MySQL Contributor Summit 2026. We arrange such Summits every quarter, and it’s a forum where contributors come together and make proposals, and then discuss them, on what they wish to work on, or see someone else work on, in future MySQL versions.  All of the presentations are now […]

The MySQL Community team will continue to be active across conferences, user group meetups, open source events, and regional community activities throughout August, September, and October 2026.  While some of our August events were featured in our previous event update, we’ve included them here again with the latest information. Whether you’re interested in learning about MySQL 9.7 LTS, exploring the latest features in […]

The July 2026 MySQL releases are now available, including: MySQL 26.7.0 is the first generally available Innovation release following MySQL 9.7 LTS and the first MySQL release to use the new calendar-versioning model. MySQL 9.7.2 and MySQL 8.4.11 continue the quarterly maintenance cadence for the current MySQL Long-Term Support release lines. A new calendar-versioning model […]