The latest from the MySQL community

Who has never encountered a customer who, for all sorts of reasons (valid or not), was unable to update an application and therefore could no longer connect to the latest versions of MySQL? Or worse still, data that is shared between two applications, one of which absolutely must use the latest version of MySQL and […]

Percona Toolkit 3.7.1 has been released on Dec 17, 2025. The most important updates in this version are:

• Finalized SSL/TLS support for MySQL
• Added support for Debian 13 and Amazon Linux 2023
• Fixed MariaDB support broken in version 3.7.0
• Added options to skip certain collections in pt-k8s-debug-collector and pt-stalk
• Documentation improvements
• Other performance improvements

In this blog, I will outline the most significant changes. A full list of improvements and bug fixes can be found in the release notes.

SSL/TLS support for MySQL

Percona Toolkit historically did not have consistent SSL support. This was reported at …

A lightweight, secure, and extensible MCP (Model Context Protocol) server for MySQL designed to bridge the gap between relational databases and large language models (LLMs).

I’m releasing a new open-source project: mysql-mcp-server, a lightweight server that connects MySQL to AI tools via the Model Context Protocol (MCP). It’s designed to make MySQL safely accessible to language models, structured, read-only, and fully auditable.

This project started out of a practical need: as LLMs become part of everyday development workflows, there’s growing interest in using them to explore database schemas, write queries, or inspect real data. But exposing production databases directly to AI tools is a risk, especially without guardrails.

…

MySQL replication has been around forever, and yet… people still manage to set it up in ways that break at the worst possible moment. Even in 2025, you can get burned by tiny schema differences, missing primary keys, or one forgotten config flag. I’ve seen replicas drift so far out of sync they might as well live in a different universe.

This guide covers the practical best practices—the stuff real DBAs use every day to keep replication stable, predictable, and boring. (Boring is a compliment in database land.)

Always Use GTIDs. Yes, Always.

GTID-based replication is one of those features that people resist turning on, and then once they do, they never want to go back.

Why GTIDs?

• Failover become sane
• Reparenting replicas stops being a headache
• Missing transactions are easy to detect

Your my.cnf should absolutely include:

Copy Copied!

In our earlier post, we unpacked the mechanics of MySQL HeatWave maintenance, the behind-the-scenes process that keeps your MySQL environments secure, stable, and optimized without changing your database version. We also touched on how Auto Minor Version Upgrades occur when a version reaches the end of its lifecycle. With this update, MySQL HeatWave introduces Configurable Maintenance Windows and Auto-Upgrade Controls, giving you […]

You’ve made it this far in your MySQL adventure: your digital library boasts neat shelves (tables), well-behaved columns, and students—err, readers—lined up in orderly rows. You can create tables, insert new authors, update overdue fines, and remove that one book nobody wants to talk about. But what happens when you need to make several changes […]

In my first post on the MySQL 8.4 Audit Log Filter component, I covered how to install the component and configure a basic filter that captures all events. The Audit Log Filter framework offers a highly granular and configurable auditing mechanism, enabling administrators to log specific events based on criteria such as user, host, or event type. This selective approach enhances observability, supports compliance initiatives, and minimizes unnecessary logging overhead.

In this follow-up, we’ll take a deeper technical look at defining and optimizing audit log filters to capture only the most relevant database activities—delivering actionable audit data while significantly reducing noise and log volume.

Example 1

Audit all events:

Copy Copied!

SELECT audit_log_filter_set_filter('log_all_events', …

Learn how to responsibly update or delete your MySQL data—including the concept of soft deletes—using engaging library metaphors and practical SQL examples. This post guides beginners through UPDATE and DELETE statements, safety tips, and real-world scenarios.

The audit log filter component in MySQL 8.4 provides administrators with a powerful mechanism for auditing database activity at a fine-grained level. While it offers significant flexibility—such as selectively logging events based on users, hosts, or event types—it can also be challenging to understand and configure correctly.

In this article, we will examine how the audit log filter component works, walk through its core concepts, and share practical tips for configuring and managing audit filters effectively. Our goal is to help you leverage this feature to improve observability, meet compliance requirements, and reduce unnecessary logging overhead.

Enabling Audit Log Filter

We will be using Percona Server 8.4.4 or higher in the examples below. First, we need to enable the audit log filter component. To install the audit log filter component, we need to run the following command:

Copy Copied!

MySQL Analysis: With an AI-Powered CLI Tool

As DBAs with MySQL we often live on a Linux terminal window. We also enjoy free options when available. This post shows an approach that allows us to stay on our terminal window and still use an AI-powered tool. You can update to use other direct AI providers but I set this example up to use aimlapi.com as it brings multiple AI models to your terminal for free with limited use or very low cost for more testing.

Note: I'm not a paid spokesperson for AIMLAPI or anything - this is just an easy example to highlight the idea.

The Problem

You're looking at a legacy database with hundreds of tables, each with complex relationships and questionable design decisions made years ago. The usual process involves:

• Manual schema inspection
• Cross-referencing documentation (if it exists)
• Running multiple EXPLAIN queries
…