Ideas, releases, practical guides, and perspectives from the people building with MySQL.
The following report is covering performance evaluation of the currently available OpenSSL releases when they are used by MySQL in CPU-intensive OLTP workloads. However, the main focus is on OpenSSL-3.5.5, which will be used by default in the next MySQL releases.
Read more... (19 min remaining to read)
With MySQL 9.7.0 LTS, MySQL establishes its next long-term support release line, expands key capabilities in Community Edition, and introduces Dynamic Data Masking for Enterprise users. The April releases mark an important milestone for MySQL. With the GA of MySQL 9.7.0 LTS, MySQL moves from the 9.x innovation series to a new Long-Term Support release line. This begins […]
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 …
[Read more]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 …[Read more]
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 …
[Read more]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 …
[Read more]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.