The latest from the MySQL community

When something goes wrong inside MySQL, the server says so in the error log. It's what administrators already watch. Every entry carries a severity and an error code, and you can query it from performance_schema.error_log like any other table. It is the server's place for communicating "something here needs your attention." This is an example of a service that MySQL provides out of the box. Since 8.0, MySQL's component framework has been able to leverage these services, and now the VillageSQL Extension Framework can too.

VillageSQL is a drop-in replacement for MySQL that lets you run your own code inside the server. The VillageSQL Extension Framework (VEF) gives you a channel to expand MySQL via portable extensions written in C++ or Rust, …

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 […]

NOTE: We are back after a summer break! Hope you enjoyed the beach and long summer nights.

As part of building the MySQL Community, we are going to publish a curated overview of MySQL and database news and events that you might have missed over the last period.

If you want to get these updates, just subscribe to the blog.

Enjoy!

MySQL News:

Note: Aggregated MySQL news can be found at Planet for MySQL Community and Planet MySQL (Oracle curated)

More to Explore: What’s New on Planet MySQL
TL;DR - Scott Stroz and team are doing major …

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, […]

Synthetic benchmarks have their place, but I have always preferred working with real data. Not client production data — that stays private — but publicly available datasets that reflect the messy shapes, skewed distributions, and indexing challenges you encounter in the wild.

Synthetic benchmarks have their place, but I have always preferred working with real data. Not client production data — that stays private — but publicly available datasets that reflect the messy shapes, skewed distributions, and indexing challenges you encounter in the wild.

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: …

I recently had the pleasure of presenting Planning your upgrade to MySQL 9.7 at COSCUP 2026 in Taipei, Taiwan. COSCUP (Conference for Open Source Coders, Users and Promoters) is one of the largest open source conferences in Asia, and the community there is always engaged and technically sharp.