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. …

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. …

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 …

On May 26, The MySQL Community Team at Oracle welcomed MySQL contributors, customers, partners, and community members to the MySQL Contributor Summit at the Oracle Redwood Shores campus, with additional participants joining remotely.  The Contributor Summit brought Oracle engineers and community contributors together to exchange ideas, share ongoing work, and explore opportunities to collaborate on […]

The MySQL team has been working hard to foster innovation, strengthen collaboration with our community, support meaningful contributions, and grow the broader MySQL ecosystem through greater openness and transparency. We believe MySQL is at its best when everyone can see how progress is being made, where work is happening, and how issues move through the […]

MySQL 9.7 LTS is here, establishing the new MySQL 9.7.x Long-Term Support release line. For organizations running MySQL today, this is the right time to evaluate upgrade plans and move toward a current, supported foundation. It is also a good moment for teams standardizing their database strategy to take a fresh look at MySQL. Whether […]

Modern applications often pass JSON back and forth with the database server. With MySQL, we have had great JSON support, but working with relational data as JSON usually meant generating documents manually with built-in JSON functions. When an application sent JSON back to the server, we often had to break that document apart and write […]

One of the best things about MySQL has always been its community. Whether you’re building applications, running production databases, contributing code, creating tools, writing documentation, answering questions, or simply sharing feedback, you’ve helped make MySQL what it is today. In this discussion we shared updates on where we are today and had a discussion on […]

When we introduced MySQL Studio, the goal was to bring the common parts of database development and analysis into one OCI workspace: SQL authoring, schema exploration, results visualization, and Ask Studio. The next step is making that workspace more useful during the everyday flow of MySQL work. For many MySQL developers, DBAs, and application teams, […]