The latest from the MySQL community

MySQL's string matching is precise by design. LIKE '%shirt%' finds "shirt." It won't find "shrt" or "shrit" or anything a user actually typed when they meant "shirt." Handling that in MySQL means regex patterns that grow unwieldy or full-text search that doesn't rank results by closeness. Usually it means punting the whole problem to the application layer.

Two VillageSQL extensions bring fuzzy matching into SQL: vsql-trgm for character-level similarity, and vsql-fuzzystrmatch for edit distance and phonetic matching. They solve different problems — knowing which to reach for is half the work. VillageSQL is a drop-in replacement for MySQL — if you're running MySQL, you can swap it in and install extensions without changing your application.

Trigrams: when strings look …

On April 21st, 2026, we released MySQL 9.7.0, the latest Long-Term Support release. As always, we are grateful to the MySQL community for helping improve MySQL with bug reports, patches, pull requests, and continued feedback. Community contributions help make MySQL better for everyone, and we are happy to recognize the contributors whose work was included […]

Understanding the New Cadence: Quarterly CPUs, Targeted CSPUs, and Transitioning to Calendar Versioning MySQL is updating its release model to make releases easier to understand, plan for, and follow: The goal is not simply to change the number on a release. The goal is to give users, DBAs, developers, Linux distributions, cloud platforms, and ecosystem […]

Managing data retention policies is one of the most common operational tasks in MySQL.

Applications continuously generate transactional, audit, logging, telemetry, and event data. Over time, these tables can grow to billions of rows, causing:

• Larger backups
• Longer recovery times
• Reduced buffer pool efficiency
• Slower index maintenance
• Increased storage costs
• Degraded query performance

To address these problems, organizations typically implement retention policies based on dates or timestamps. Examples include deleting events older than 90 days or purging session data older than 30 days and so forth. The deleted data can then eventually be archived somewhere else, like in another DBMS or on external files.

One of the most widely used tools for implementing these policies in MySQL ecosystems is pt-archiver, part of the Percona Toolkit. …

If you have a typical MySQL production setup using MySQL 8.0 (EOL) with replication, you can take advantage of VillageSQL extensions to generate AI responses directly with your source data with no impact on your production setup or existing application software.

If you have a typical MySQL production setup using MySQL 8.0 (EOL) with replication, you can take advantage of VillageSQL extensions to generate AI responses directly with your source data with no impact on your production setup or existing application software.

This blog post is about installing Ghost 5 CMS on Ubuntu 26.04 OS with MySQL and Caddy. Ghost is a ...

Read More

The post How to Install Ghost 5 CMS on Ubuntu 26.04 with MySQL and Caddy appeared first on RoseHosting.

It is time to talk again about Flow control and group replication. This time with a special eye on the use of Group Replication in the Kubernetes context. In this article we will dig a bit on how it works and what are the various side effects. 

The problem

Recently I was refining the calculation I use in the MySQL calculator for Operator given I was constantly encountering a very serious problem with the Percona Server Operator.

The problem is that when the deployment was/is serving a high level of traffic, it will, no matter what, end up in getting OMMKill by the K8 system. 

This because the pod was gradually consuming more and more memory, reaching the memory limit set in the CR specification. 

Now let me clarify a few things, to get straight to the facts.

…

Let’s be honest: migrating a relational database to Kubernetes sounds fantastic in a whiteboard meeting, but the reality of day-two operations is a completely different story.

When moving MySQL to Kubernetes, the ultimate goal is simple: identify a safe, performant set of configuration values for your database pods. But where do you start? Usually, you look at your overall node resources say, a machine with 16 CPUs and 64GB of RAM.

In the old bare-metal days, you'd apply the standard rules of thumb:

• Set innodb_buffer_pool_size to 60-80% of total RAM to maximize caching.

• Allocate 1 innodb_buffer_pool_instances per 1GB of buffer pool.

• Match innodb_io_capacity to your drive speeds.

If you try applying these legacy rules in Kubernetes, your pod won't survive. …

Overview

When building high-availability MySQL environments, the choice between MySQL Group Replication (GR) and Percona XtraDB Cluster (PXC) often comes down to how they handle the eternal database dilemma: data consistency versus performance.       

While both provide "synchronous-like" replication, they approach the problem of stale reads—reading data that has been committed on one node but not yet applied on another—in distinct ways. Understanding these differences, and the performance penalties associated with fixing them, is critical for any production environment.

Technology Overviews

MySQL Group Replication (GR)

Group Replication is the native, albeit more recent, high-availability solution built by Oracle for MySQL. It is based on a distributed state machine architecture and uses the Paxos consensus protocol.

• Mechanism: When a …