The latest from the MySQL community

We all know that when using a cluster based on Galera (Codership) such as Percona XtraDB Cluster (PXC), it is recommended to deploy an odd number of nodes.

The generic answer to this recommendation is that otherwise the risk of having an inconsistent cluster (like split-brain) is higher.  (see Get started with Percona XtraDB Cluster – Percona XtraDB Cluster ) 

As a reminder, when split-brain occurs, a cluster will stop accepting queries, which is what a safe solution should do while waiting for the DBA to review and decide which of the two nodes is the leader. I do not even want to describe the infamous wsrep_provider_options=”pc.ignore_sb = yes”, which has been the cause of many, many nights spent trying to …

It’s Thursday afternoon, and a developer has an idea.

Nothing complicated. They are working on a new application feature and want to test an idea before committing to a larger implementation. A quick prototype is already running locally. So far, so good. Next, they want to deploy the application to a shared environment so their colleagues can try it out. The application needs a database too, but it needs to be accessible from the shared environment, not just their laptop. And that’s where things get more complicated.

Now they need to submit a request to the infrastructure team, wait for an environment to be provisioned, or spend the afternoon working through Kubernetes configurations. What should have been a quick experiment becomes another task on somebody else’s backlog.

This is a common problem for engineering teams. Getting a database running in a shared environment shouldn’t require extensive coordination or …

Shopify, GitHub, and Uber run on MySQL, yet, as Dominic Preuss puts it, the hype, innovation, and investment historically went to PostgreSQL. Inside the Silicon Mind published Firas Sozan's interview with Dominic, co-founder and CEO of VillageSQL, about why that happened, what Oracle is doing to address it, and how VillageSQL plans to bring innovation back to MySQL.

Dominic covers how MySQL went from a Swedish startup to Oracle, why Oracle is now opening MySQL development to the community, including AWS and Google, and why he started a company on MySQL when everyone was running in the direction of PostgreSQL.

Watch more VillageSQL talks on the Talks page, or get started at villagesql.com.

In Part 1 we ran analytical reports in DuckDB on a DBTrail copy instead of on MySQL. This time I want to look at a different question: what if the application does not need to know the copy exists?

Most MySQL servers have a few queries that make someone wait. The monthly report that aggregates a whole table. Page 5,000 of a sorted list. The screen that reads years of history. MySQL is built for many small reads and writes, and these queries are a different kind of work.

So what happens to them with DBTrail next to the server? The same 14 reports ran for a day on a Percona Server for MySQL replica and on the copy of the same database that DBTrail keeps.

Short answer: twelve were faster on the copy, and the slowest went from 225 seconds to 7.94 seconds.

Not …

A plugin started the fire, the M-ecosystem picked it up, the hyperscalers went native, and now the benchmark wars have begun.

Not long ago, if you asked about vector search in MySQL, you got a polite smile and a link to pgvector. Even after MySQL 9 added a VECTOR column type, the obvious next questions had no answer. Where is the index? Where is the distance function? For a while the honest answer was “use something else.”

This week the MySQL Contributor Summit (Nov 4–5, online) opened its technical program with vector search. The first discussion block, AI & Cloud, had four vector and AI proposals back to back from Oracle, Google, Percona and Intel. It was the clearest sign yet of how far vector search in MySQL has come.

Looking back, vector …

MySQL and DuckDB

Unlike row-oriented databases, which store data for a single record sequentially on disk, favoring single-row lookups, columnar databases store all the values from a column contiguously in storage, allowing only the selected column to be read from disk.

The default MySQL engine is InnoDB, which is ACID-compliant and great for OLTP (Online Transaction Processing) workloads. That said, OLAP (Online Analytical Processing) queries are built differently; they scan, group, and summarize millions or billions of rows to produce reports. In these cases, the InnoDB engine can be slow to process such queries. This has been a debt in MySQL over the years; it was common to setup ETL/CDC pipelines to export or stream the data to another engine, usually a columnar database system, to run reporting and BI queries on it.

DuckDB is a portable analytical database system, designed to be fast and reliable, similar to SQLite. …

A recent post on the MariaDB Foundation Blog has the impressive title How MariaDB 11.8 became about 3× faster on some in-memory workloads, fixing a regression dating back to 10.5.  The claim is technically correct when viewed in isolation, but I believe it becomes misleading when the broader context is taken into account.  The details are below.

The post mentions a benchmark on 11.8

When a commercial entity says they are working on an open source database, community members fairly ask what that means to them. They also ask if the same rules apply to everyone or just the company’s employees. Can an outsider see what's planned? Does a pull request from a stranger go through the same process as one from an employee? This blog post explores how VillageSQL approaches open source by stepping through how we are operating the VillageSQL Server project. VillageSQL Server is the open source tracking fork of MySQL that adds an extension framework to enable permissionless innovation on MySQL. 

GPLv2, inherited from MySQL

VillageSQL Server is licensed under the GNU General Public License version 2 (GPLv2), because that is how upstream MySQL is licensed and VillageSQL inherits that due to the copy left nature of GPLv2. The …

Every MySQL schema that’s been around for a few years collects indexes nobody remembers adding. Some were for a report that was retired. Some came from an ORM migration. A few were added “just in case” and never used. They all cost something: extra writes on every INSERT and UPDATE, increased buffer pool pressure, larger backups, and slower schema changes.

MySQL makes it look easy to find them. Since 5.7, the sys schema ships a view called sys.schema_unused_indexes, and one query gives you a list of indexes with zero reads since the server started. It’s tempting to turn that list straight into DROP INDEX statements.

In an earlier post, How to Find Duplicate, Unused, and Invisible Indexes in MySQL, I showed how to use that view on a single server. This post covers what that approach misses once replicas are involved.

Percona Operator for MySQL 1.3.0 is out. This release moves three things forward for teams running MySQL on Kubernetes: the operator now tunes MySQL for you based on the pod resources, async clusters can fail over without losing data in flight, and point-in-time recovery works on clusters where binary logs are encrypted at rest.

The headline features in this post are automatic MySQL configuration tuning, zero data loss failover for asynchronous clusters, and encrypted binary logs for point-in-time recovery. Each of them removes a step that teams were doing by hand, or a case they had to accept as a known gap.

As with every operator release, most of what shipped came from what the community asked for on forums.percona.com and in …