In this blog post, we will explore how network partitions impact group replication and the way it detects and responds to failures. In case you haven’t checked out my previous blog post about group replication recovery strategies, please have a look at them for some insight. Topology: [crayon-675be1dcb0beb530772817/] Scenario 1: One of the GR nodes […]
Group replication is a fault-tolerant/highly available replication topology that ensures if the primary node goes down, one of the other candidates or secondary members takes over so write and read operations can continue without any interruptions. However, there are some scenarios where, due to outages, network partitions, or database crashes, the group membership could be broken, or we end […]
Flow control is not a new term, and we have already heard it a lot of times in Percona XtraDB Cluster/Galera-based environments. In very simple terms, it means the cluster node can’t keep up with the cluster write pace. The write rate is too high, or the nodes are oversaturated. Flow control helps avoid excessive […]
This blog post will cover the basic setup of the InnoDB ClusterSet environment, which provides disaster tolerance for InnoDB Cluster deployments by associating a primary InnoDB Cluster with one or more replicas in alternate locations/different data centers. InnoDB ClusterSet automatically manages replication from the primary cluster to the replica clusters via a specific ClusterSet Async replication channel. If the primary cluster becomes inaccessible due to a loss of network connectivity or a data center issue, you can make a replica cluster active in its place.
Now, let’s see in detail how exactly we can configure the topology.
We have used the sandbox environment available via MySQLShell utility for this setup.
Environment
Cluster1: 127.0.0.1:3308 127.0.0.1:3309 127.0.0.1:3310 Cluster2: 127.0.0.1:3311 127.0.0.1:3312 127.0.0.1:3313 Router: …[Read more]
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