You might want to use binlog compression with MySQL/Percona Server for MySQL, but it can come with drawbacks. This article discusses the need for using binlog compression and the potential issues it may cause.

Binlog compression is a technique used to reduce the size of binary log files, which can become quite large over time. This can be especially important in situations where disk space is limited. However, it’s important to be aware that using binlog compression can also cause issues with replication.

Consider the following scenario: you have restored a backup that was taken from a replica node using Percona XtraBackup. Once the restoration is complete, you want to set up replication using the information from the xtrabackup_slave_info …

Although MySQL 8 was released back in 2018, a significant share of MySQL servers out there are still running MySQL 5.x. MySQL 5 had a lengthy run from its release in 2005, and thus many organizations still have databases that were built on 5.x. But Oracle has been phasing out MySQL 5.7 support for various platforms over the past few years and end of life for MySQL 5.7 is slated for October 2023.

If you’re still running a database on MySQL 5.7, it’s time to seriously consider upgrading. You'll get several new features that give you performance improvements and security enhancements, so it is important that you do this soon — especially with the imminent end-of-life of MySQL 5.7, which means there will be no further security updates. Fortunately, this process is usually pretty straightforward, but there are several changes you may have to make. This article will cover many of the things that you should look out for when …

In this blog, I’ll discuss the use case for replication. We want to improve our ability to replicate your data and limit replication to row-based events securely, wherein we do not have control over the source(s).

The replica doesn’t have checking capabilities when processing replicated transactions as of MySQL 8.0.18. It does this to carry out all instructions from its upstream. The replica must impose data access limitations on the replicated stream because changes may get past the security barrier separating the source and replica in some configurations. In that situation, implementing the upstream changes in a more constrained security context is beneficial to organizations needing privilege-controlled aggregate data from multiple separate databases.

In MySQL 8.0.18, a new feature PRIVILEGE_CHECKS_USER is introduced in replication channels. When a PRIVILEGE CHECKS USER account is used, a replication channel is more protected …

Codership is pleased to announce a new Generally Available (GA) release of the multi-master Galera Cluster for MySQL 5.7, consisting of MySQL-wsrep 5.7.40 (release notes, download) and MySQL-wsrep 8.0.31 (release notes, download) with Galera replication library 4.14 (release notes, download) implementing wsrep API version 26. …

ProxySQL is an open-source MySQL proxy server, meaning it serves as an intermediary between a MySQL server and the applications that access its databases. ProxySQL can improve performance by distributing traffic among a pool of multiple database servers.

Consider 2 slaves are routed under Proxysql , In any one of the slave, if the replication is broken, we could still see the traffic routing to the broken replication slave. We can make Proxy to not send traffic to broken replication slave, by setting appropriate value to the variable mysql-monitor_slave_lag_when_null

…

This post was originally published in October 2018 and was updated in March 2023.

pt-query-digest is one of the most commonly used tools for query auditing in MySQL. By default, pt-query-digest reports the top ten queries consuming the most amount of time inside MySQL. A query that takes more time than the set threshold for completion is considered slow, but it’s not always true that tuning such queries makes them faster. Sometimes, when resources on the server are busy, it will impact every other operation on the server, and so will impact queries too. In such cases, you will see the proportion of slow queries going up. That can also include queries that work fine in general.

This article explains a small trick to identify such spots using pt-query-digest and the slow query log. pt-query-digest …

Hello friends, at Percona Managed Services, we usually do different types of things every day, including routine tasks, monitoring, and, very frequently, answering questions that are not always easy to answer.

A few days ago, a client asked us the following question: “Hey Percona, I have a question and a problem simultaneously: I want to delete rows from a table from a specific date back because the data is not necessary. I tried to run the DELETE command, which gave me this error: Cannot delete or update a parent row: a foreign key constraint fails. Could you please help me?”

At first glance, the error message was obviously clear: the table from which rows were to be deleted had a child table, which prevented the execution of the DELETE directly.

“Don’t worry, we’ll take a look at the issue, and …

Introduction/TLDR:

We are considering changing EXPLAIN in Percona Server for MySQL to require less privileges for providing execution plans for INSERT/UPDATE/DELETE statements (and possibly changing the behavior for EXPLAIN SELECT as well), to make it more convenient and safer to use with monitoring and query analysis tools. We would like to get feedback from the Community about the different approaches for achieving this.

The problem:

Running EXPLAIN is a great way to understand how complex SQL statements are executed. So it is natural that monitoring and query analysis tools utilize EXPLAIN for these purposes.

However, there is a problem for cases when INSERT/UPDATE/DELETE statements need to be explained. Running EXPLAIN for these statements, a read-only operation, requires the same privileges as running the original statements …

Given a table named tbl with one million entries, we want to select a random row from this table, fast. Our table definition looks like this:

create table tbl (
    id INTEGER NOT NULL,
    d VARCHAR(200) NOT NULL,
    INDEX(id)
);

Dense id space

We can generate some test data using a recursive CTE:

mysql> set cte_max_recursion_depth = 100000;
mysql> insert into tbl 
    -> with recursive c(n, u) as (
    ->   select 1, uuid() 
    -> union all
    ->   select n+1, uuid() from c where n < 100000
    -> ) select * from c ;

The Recursive CTE will generate 100k pairs of (number, uuid()). The initial row is defined in the upper row of the UNION, each subsequent row builds recursively on top of that, by simply counting …

Given a table named tbl with one million entries, we want to select a random row from this table, fast. Our table definition looks like this:

create table tbl (
 id INTEGER NOT NULL,
 d VARCHAR(200) NOT NULL,
 INDEX(id)
);

Dense id space

We can generate some test data using a recursive CTE:

mysql> set cte_max_recursion_depth = 100000;
mysql> insert into tbl
 -> with recursive c(n, u) as (
 -> select 1, uuid()
 -> union all
 -> select n+1, uuid() from c where n < 100000
 -> ) select * from c ;

The Recursive CTE will generate 100k pairs of (number, uuid()). The initial row is defined in the upper row of the UNION, each subsequent row builds recursively on top of that, by simply counting up.

Since we generate …