The latest from the MySQL community

The latest release of the Percona Operator for MySQL, 1.1.0, is here. It brings point-in-time recovery, incremental backups, zstd backup compression, configurable asynchronous replication retries, and a set of stability fixes. This post walks through the highlights and how they help your MySQL deployments on Kubernetes.

Percona Operator for MySQL 1.1.0

Running stateful databases on Kubernetes means your backup and recovery story has to be airtight. A full nightly backup is fine, until the DBA drops a table at 2 PM and you’re looking at 14 hours of lost work. Or until your storage bill grows faster than your actual data because every backup is a …

Having a separate DR cluster for production databases is a modern day requirement or necessity for tech and other related businesses that rely heavily on their database systems. Setting up such a [DC -> DR] topology for Percona XtraDB Cluster (PXC), which is a virtually- synchronous cluster, can be a bit challenging in a complex Kubernetes environment.

Here, Percona Operator for MySQL comes in handy, with a minimal number of steps to configure such a topology, which ensures a remote side backup or a disaster recovery solution.

So without taking much time, let’s see how the overall setup and configurations look from a practical standpoint.

PXC Cross-Site/Disaster Recovery

DC Configuration

1) Here we have a three-node PXC cluster running on the DC side.

shell> kubectl get pods -n pxc
NAME                                               READY   STATUS …

April 19, 2026

It took three release candidates and more CI tweaks than I’d like to admit, but v1.7.0 is finally tagged GA. Here’s what actually changed and why it matters.

The thing I kept getting asked about: add_connection

Almost every multi-database user hits the same wall: you configure your connections at startup, and that’s it. Want to point Claude at a different instance mid-session? Restart the server. Not great.

add_connection fixes that. Enable it with MYSQL_MCP_EXTENDED=1 and MYSQL_MCP_ENABLE_ADD_CONNECTION=1, and Claude can register a new named connection on the fly — DSN validation, duplicate-name rejection, and a hard block on the root MySQL user all happen before the connection is accepted. Once it’s in, use_connection it works as usual.

It’s intentionally opt-in behind two flags. Allowing …

Starting with version 1.1.0, the Percona Kubernetes Operator for MySQL now supports incremental backups. This feature lets you backup only the changed data since the last backup, instead of copying your entire dataset each time. The result is dramatically smaller backup sizes, faster backup windows, and lower cloud storage costs.

In this post, we’ll walk through how the feature works under the hood, how to configure it, and what to keep in mind when designing your backup strategy.

How Incremental Backups Work in Percona XtraBackup

The foundation of this feature is Percona XtraBackup (PXB), an open source backup tool for MySQL. PXB has supported incremental backups for a while, and the operator now brings that capability into the backup workflow.

Every InnoDB data page carries a Log Sequence Number …

One of the most requested features since Readyset first supported MySQL has been GTID-based replication. With the latest release, Readyset now fully supports MySQL Global Transaction Identifiers (GTIDs), and with it, a capability that changes how you think about cache durability: zero-downtime failover.

This post covers what GTID support means for Readyset users, how failover works in practice, and why this matters for anyone running Readyset in production.

The Problem with Binlog File and Position

MySQL's binary log is the backbone of replication and Change Data Capture. Every tool that reads the binlog like replicas, CDC pipelines, Readyset, needs to track where it left off so it can resume after a restart or disconnection.

Historically, that position was tracked as a file name and offset: binlog.000003:154. This works, but it has a fundamental limitation: binlog file names and …

Monitoring MySQL data locks, or the tip of the iceberg This story is about recent (*) performance improvements implemented in MySQL, related to monitoring of data locks. (*) Originally written in Feb 2025. Refresher What is a data lock? When a user session connects to the MySQL database, it executes SQL queries. The query runs; […]

In this eighth post of our series, we decode the three row events — WRITE_ROWS_EVENT, UPDATE_ROWS_EVENT, and DELETE_ROWS_EVENT — that carry the actual row data for INSERT, UPDATE, and DELETE operations in row-based replication.

Introduction

In the previous posts, we decoded the events that set the stage for row-based replication: the GTID_LOG_EVENT identifies the transaction, the QUERY_EVENT opens it with BEGIN, and the TABLE_MAP_EVENT describes the table's schema. Now we finally arrive at the events that carry the actual data — the row events.

All three row events share the same base structure defined by the Rows_event class. The differences come down to which row images each event carries: …

A deep dive into multi-region MySQL deployment patterns on Kubernetes, exploring replication models, failover strategies, and the operational trade-offs required to achieve global scale and resilience.

You read this right, symbolic links (symlinks) are unsafe in MySQL since at least 8.0.39.  As always, it is a little more complicated than that, but if you are using symbolic links and in certain conditions, you risk a crash.  I think it is important to raise awareness on this, hence this post.

My attention was brought to this via the now private Bug #120156: MySQL 8.0.39/8.0.42

My colleague Miguel wrote about ways to audit login attempts in MySQL over 13 years ago, and this is still a relevant subject. I decided to refresh this topic to include some important changes since then.

Very often, it is important to track login attempts to our databases due to security reasons as well as to catch application misconfigurations. I’ll focus here on the most convenient ways to log authentication attempts. While auditing all client connections is usually pointless on busy production systems, when even thousands of new client sessions may be authenticating per second, let’s concentrate especially on the failed ones.

The Error Log

All MySQL and MariaDB variants have an easy way of logging failed authentication attempts in the standard error log via elevated log verbosity. To enable it, in older MySQL versions up …