There are two Operators at Percona to deploy MySQL on Kubernetes:

• one is based on Percona XtraDB Cluster (PXC), production-ready and widely adopted
• another is based on Percona Server for MySQL, now in tech preview and not recommended for production yet

We wrote a blog post in the past explaining the thought process and reasoning behind creating the new Operator for MySQL. The goal for us is to provide production-grade solutions to run MySQL in Kubernetes and support various replication configurations:

• Synchronous replication
  …

In our last blog post about the Automatic Asynchronous Replication Connection Failover feature which was released in MySQL 8.0.22, we showed you its usage and benefits. We now present here additional changes we added in MySQL 8.0.23 to further enhance this feature by making the receiver aware of the source’s group membership changes.…

Tweet Share

As Group Replication (GR) matures and it is deployed in a myriad of different systems, we begin to witness specific network conditions that we must be able to cope with in order to make Group Replication more tolerant and robust to those failures.…

Tweet Share

From MySQL 8.0.21 onwards, START GROUP_REPLICATION includes new options which allow a user to specify credentials to be used for distributed recovery. You can now pass credentials when invoking START GROUP_REPLICATION instead of setting them when configuring the group_replication_recovery channel.

START GROUP_REPLICATION command now has the options:

• USER: User name.

… Tweet Share

Group Replication enables you to create fault-tolerant systems with redundancy by replicating the system state to a set of servers. Even if some of the servers subsequently fail, as long it is not all or a majority, the system is still available.…

Tweet Share

Group Replication distributed recovery is one of the key features and until now it was restricted to be executed over one mysql connection point automatically defined on mysql system variables port and host.

With group_replication_recovery_endpoints we can specify through which interfaces can group replication recovery take place for a given member so that it controls where recovery traffic flows in the network infrastructure.…

Tweet Share

MySQL Group Replication allows you to create an highly-available replication group of servers with minimum effort. It provides automated mechanisms to detect and respond to failures in the members of the group. The response depends on the characteristics of each failure and it is configurable.…

Tweet Share

Group Replication enables you to create fault-tolerant systems with redundancy by replicating the system state to a set of servers. Even if some of the servers subsequently fail, as long it is not all or a majority, the system is still available.…

Tweet Share

In this blog post I would like to give an overview of the most common failover scenarios and operations when using MySQL Group Replication 8.0.19 (aka GR) and Percona XtraDB Cluster 8 (PXC) (which is based on Galera), and explain how each technology handles each situation. I have created a three-node cluster with Group Replication using a single Primary and a three-node PXC, both with default settings. I am also going to use ProxySQL to interface with both clusters.

In both clusters, the name of the nodes are mysql1, mysql2,  and mysql3. In Group Replication the Primary node is where the writes go if we are using single primary configuration. In PXC, I will use the same term as well and will call the node Primary where I am sending the writes. Just to note, in PXC there is no concept of primary node, …

In this two-part blog series, I wanted to cover some failover scenarios with Group Replication. In part one, I will discuss an interesting behavior and performance degradation I discovered while writing these posts. In part two, I will show several failover scenarios and demonstrate how Group Replication handles each situation.

The test environment is very basic, a three-node Group Replication (mysql1,mysql2,myslq3) on MySQL 8.0.19 with default settings. mysql2 is the Primary node.

In this scenario, I was testing a partial network failure when a node gets separated from the primary, but other nodes still can see it.

You would think mysql3 is going to lose quorum and exit the cluster, but no. Inside the cluster, all the nodes are in constant communication with each other, not just …