We had a couple of cases where clients reported that the MySQL error log was flooded with the below note:

2023-01-18T13:07:56.946323Z 2 [Note] InnoDB: Stopping purge
2023-01-18T13:07:56.948621Z 2 [Note] InnoDB: Resuming purge
2023-01-18T13:08:27.229703Z 2 [Note] InnoDB: Stopping purge
2023-01-18T13:08:27.231552Z 2 [Note] InnoDB: Resuming purge
2023-01-18T13:08:28.581674Z 2 [Note] InnoDB: Stopping purge

One of my colleagues Sami Ahlroos found that whenever we trigger a truncate on any table, the function is stopping the purge and then resuming it once it has found it stopped.

Below are the steps to reproduce.

1. Log verbosity needs to be set to 3 (the default value)

mysql> show variables like 'log_error_verbosity%';
+---------------------+-------+
| Variable_name       | Value |
+---------------------+-------+
| …

How can we fix a nasty out-of-space issue leveraging the flexibility of Percona Operator for MySQL?

When planning a database deployment, one of the most challenging factors to consider is the amount of space we need to dedicate to data on disk.

This is even more cumbersome when working on bare metal, as it is more difficult to add space when using this kind of solution with respect to the cloud.

When using cloud storage like EBS or similar, it is normally easy(er) to extend volumes, which gives us the luxury to plan the space to allocate for data with a good grade of relaxation. 

Is this also true when using a solution based on Kubernetes like Percona Operator for MySQL? Well, it depends on where you run it. However, if the platform you choose supports the option to extend volumes, K8s per se gives you the …

Recently Oracle released new versions of their software and there are some things of note. MySQL 8.032 is not a major change but you do need to be aware of some changes just in case they have the potential to send you into the court of Murphy’s Law. So let’s look through the release notes to see what is new, changed, and deprecated.

My own comments are in italics and reflect the views of neither Percona nor anyone else. Percona’s release of ‘32 is in the works as we have to add the features Percona provides such as enterprise features (data masking, connection pooling, RocksDB, and much more).

The following items caught my eye as either interesting or ‘I need to add this to my to-do list’.

No more leading dollar signs for table names

> CREATE TABLE $Dollar (i int);
Query OK, 0 rows affected, 1 warning (0.0192 sec)
Warning (code 1681): '$ as the first character of an unquoted identifier' is …

Looking at how people are using COUNT(*) and COUNT(col), it looks like most of them think they are synonyms and just use what they happen to like, while there is a substantial difference in performance and even query results. Also, we find a difference in execution on InnoDB and MyISAM engines.

NOTE: All tests were applied for MySQL version 8.0.30, and in the background, I ran every query three to five times to make sure that all of them were fully cached in the buffer pool (for InnoDB) or by the filesystem (for MyISAM).

Count function for Innodb engine:

Let’s have look at the following series of examples for InnoDB engine:

CREATE TABLE count_innodb (
  id int(10) unsigned NOT NULL AUTO_INCREMENT,
  val_with_nulls int(11) default NULL,
  val_no_null int(10) unsigned NOT NULL,
  PRIMARY KEY idx (id)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

(mysql) > select count(*) from count_innodb; …

Space constraint has been an endless and painstaking process for many of us, especially in systems that have a high number of transactions and data growth exceeding hundreds of GBs in a matter of days. In this blog, I will share a solution to remove this space and remove rows from tables in a few seconds regardless of the size of a table without causing any additional load on the database using table partitions.

The first approach that comes to anyone’s mind for deleting the row is using a DELETE query in SQL. Suppose, one wants to delete rows from a table that are older than one year—the query for such operations would be like this:

DELETE FROM salaries WHERE from_date <DATE_SUB(NOW(),INTERVAL 1 YEAR);

The above query is pretty straightforward but there are a few caveats:

• Server business will grow exponentially and could impact the usual traffic on the server.
• To speed up the above query …

Recently, we performed a database engine major version upgrade in one of our customers’ environments from MySQL 5.7.26 to 8.0.27. After this version upgrade, we experienced issues with backups and replication for one of the nodes.

In this article, I will explain these issues in detail and recommend a way to take backups from a replication environment.

To begin with, we upgraded all the database nodes from 5.7.26 to 8.0.27 and as a recommended way we have a backup set-up from one of the replica nodes. Physical backups are being taken using Percona XtraBackup (PXB) so it does not lock the database during the backup.

With MySQL 5.7, a backup was taken using PXB 2.4. Due to the new data dictionaries, redo log and undo log in MySQL 8.0, we also upgraded PXB to 8.0.27 to avoid …

In Managed Services, we have many customers, and as each has a different kind of config and environment, working on their environment is always fun and interesting. In this blog post, I will showcase an issue we faced when dropping a table and how it was resolved.

There was a ticket to drop a table in a client’s production environment (MySQL 5.7). The table had a # symbol at the beginning of the table’s name. I thought it was easy that we can use quotes or backtick symbols to specify the table to drop. But it did not work as I expected and I came to know why the customer created the ticket to drop the table.

The following example recreates the problem. It shows the table, but you are unable to see the structure and cannot drop it.

mysql> show tables;
+--------------------------+
| Tables_in_percona        |
+--------------------------+
| …

In managed services, we get requests to migrate from traditional to GTID-based replication. However, the customer does not want to first enable the GTID on the source node (production). Before MySQL 8.0.23, replication from the disabled GTID source to an enabled GTID replica was impossible.

In this blog, I will talk about a new MySQL feature introduced in 8.0.23, which allows MySQL to replicate from a GTID-disabled source to GTID-enabled replica. You can enable GTID assignment on a replication channel using the ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS.

You can read the Percona doc if you are unaware of how GTID replication works:

https://www.percona.com/doc/percona-server/5.6/flexibility/online_gtid_deployment.html

…

Recently I came across an interesting investigation about long-running transactions getting killed on an Aurora Reader instance. In this article, I will explain why it is advisable to avoid long-running transactions on Aurora readers when executing frequent DDL operations on the Writer, or at least be aware of how a DDL can impact your Aurora readers.

Aurora uses a shared volume often called a cluster volume that manages the data for all the DB instances which are part of the cluster. Here DB instances could be a single Aurora instance or multiple instances (Writer and Aurora Read Replicas) within a cluster.

Aurora replicas connect to the same storage volume as the primary DB instance and support only read operations. So if you add a new Aurora replica it would not make a new copy of the table data and instead will connect to the shared cluster volume which contains all the data.

This could lead to an issue on replica …

There are eight configuration options related to the character_set in MySQL, as shown below. Without reading the MySQL Character Set documentation carefully, it could be hard to know what these configuration options are used for. In addition, for some of the options, unless there is further testing, it could be hard to know how MySQL uses them.

mysql> show variables like 'character_set%'; 
+--------------------------+-------------------------------------+ 
| Variable_name            | Value                               | 
+--------------------------+-------------------------------------+ 
| character_set_client     | utf8mb4                             | 
| character_set_connection | utf8mb4                             | 
| character_set_database   | utf8mb4 …