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 …

I wrote this post on MyRocks because I believe it is the most interesting new MySQL storage engine to have appeared over the last few years. Although MyRocks is very efficient for writes, I chose a more generic workload that will provide a different MyRocks use case.

The use case is the TPC-C benchmark but executed not on a high-end server but on a lower-spec virtual machine that is I/O limited like for example, with AWS EBS volumes. I decided to use a virtual machine with two CPU cores, four GB of memory, and storage limited to a maximum of 1000 IOPs of 16KB. The storage device has performance characteristics pretty similar to an AWS gp2 EBS volume of about 330 GB in size. I emulated these limits using the KVM iotune settings in my lab.

<iotune>
     <total_iops_sec>1000</total_iops_sec>
     <total_bytes_sec>16384000</total_bytes_sec> …

Operators hide the complexity of the application and Kubernetes. Instead of dealing with Pods, StatefulSets, tons of YAML manifests, and various configuration files, the user talks to Kubernetes API to provision a ready-to-use application. An Operator automatically provisions all the required resources and exposes the application. Though, there is always a risk that the user would want to do something manual that can negatively affect the application and the Operator logic.

In this blog post, we will explain how to limit access scope for the user to avoid manual changes for database clusters deployed with Percona Operators. To do so, we will rely on Kubernetes Role-based Access Control (RBAC).

The goal

We are going to have two roles: …

Table modifications are a common task for database administrators. In this blog, I’ll explain how to alter tables online in a controlled manner that does not disrupt application users or cause application downtime.

One of the tools in Percona Toolkit is pt-online-schema-change, a utility that alters the structure of a table without interfering with the reads or writes. The tool creates an empty copy of the table to alter and modify as desired before copying the rows from the original table into the new one.

When the copying is finished, it removes the original table and replaces it with the new one. Any changes made to data in the original tables during the copy process will be reflected in the new table as the tool creates triggers on …

In this blog, I’m going to discuss how to easily skip the replication errors in GTID (Global Transaction Identifier)-based replication.

In the MySQL world, if replication is broken we all use the famous SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; to skip the replication error. It always works if it’s a traditional binlogs events-based replication and is helpful to quickly resume the replication. But does this same method work for GTID-based replication? Let’s see.

In GTID-based replication, skipping a replication error in a broken replica is not as simple as binlogs-based replication. We have one old blog post — Repair MySQL 5.6 GTID replication by injecting empty transactions —where one of our colleagues showed us one way to skip and fix the replication.

Let’s get into action and …

Percona Server for MySQL 8.0.30-22 introduces a new authentication plugin, named authentication_fido. With this new plugin, it is possible to perform multi-factor authentication using hardware keys, or single-factor passwordless authentication with the same keys. This new plugin is in technical preview.

The plugin works exactly the same as the MySQL Enterprise FIDO authentication plugin, which is documented in detail in the official MySQL documentation and in the Percona Server for MySQL documentation

To try …

Percona Server for MySQL 8.0.30-22 introduces several improvements for the LDAP plugin: SASL support, support for fallback servers, and support for LDAP-based authorization. All improvements are in technical preview.

A description of the existing plugin features and usage instructions are available in the earlier blog post introducing the LDAP simple plugin, and in the Percona Server for MySQL documentation.

SASL connections

We introduced a new plugin similar to the MySQL …

What is a Delay Replica and how does it help?

MySQL Replication is useful, easy to set up, and used for very different purposes. For example:

• split reads and writes
• run data mining or reporting processes on them
• disaster recovery

To learn more, check out How Does MySQL Replication Work?

It’s important to mention that a replication server is not a backup by itself. A mistake on the source, for example, a DROP DATABASE or an UPDATE without a WHERE clause will be replicated nearly instantly to all replica servers. Simply having a replica is not going to be helpful here. How can we avoid that kind of mistake? By having a replica server that intentionally lags behind.

We can never avoid human error in database infrastructure operations. But …