MySQL 8.4 has two good options for High Availability clusters: Galera Cluster (and Percona XtraDB Cluster (PXC)) plus MySQL InnoDB Cluster. Both solutions are now mature enough, so what is the deciding factor? Workload characteristics, application compatibility (Galera is virtually synchronous; InnoDB Cluster offers 2 modes – single primary mode, which is one instance being read-write, with the rest being read only, and multi-primary mode, which is closer to what Galera Cluster is) and operational preferences, most likely will decide which one comes out top in 2025, is what we aim to answer at next week’s webinar.

Due to the lack of real-world usage statistics (we can tell you how many Galera Cluster downloads we have, for example, or even customer numbers, but we won’t have anything to compare against), we look at proxy statistics, like …

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 […]

TL;DR: Make sure to run “SET persist_only disabled_storage_engines=’MyISAM’, persist sql_generate_invisible_primary_key=ON;” on all instances and restart each one in your MySQL InnoDB Cluster.

Ok, what does “safe from naughtiness” mean?:
– Anyone creating tables that aren’t InnoDB, as this doesn’t make sense, after all, it is an “InnoDB” cluster.
– Making sure all tables have a Primary Key (invisible or not).
– Making sure that my (invisible) primary keys are visible to the cluster as it will rightfully complain if they aren’t!

This basically means that once you’ve got it all up and running you won’t run into those horrible situations whereby someone, somewhere, creates a MyISAM table that didn’t have a Primary Key and thus leave you with a broken cluster.

Eg.

MySQL rtnode-01:3306 ssl JS > vlc.status()
{
 "clusterName": "VLC",
 "clusterRole": "PRIMARY", …

Maintaining a production dataset at a manageable size can present a considerable challenge during the administration of a MySQL InnoDB Cluster.

Old Days

Back in the day when we only had one main copy of our data (the source), and one read copy (the replica) that we used to look at current and old data from our main system, we used a special trick to remove data without affecting the replica. The trick was to turn off writes to the binary log for our removal commands in the main system. External tools like pt-archiver were also able to use that trick. To stop bypass writing into the binary log, we used the command: SET SQL_LOG_BIN=0.

This mean that on the main production server (replication source), we were purging the data without writing the delete operation into the binary logs:

Current Days

These …

When working with group replication, MySQL router would be the obvious choice for the connection layer. It is tightly coupled with the rest of the technologies since it is part of the InnoDB cluster stack.The problem is that except for simple workloads, MySQL router’s performance is still not on par with other proxies like Haproxy […]

Many of us, old MySQL DBAs used Seconds_Behind_Source from SHOW REPLICA STATUS to find out the status and correct execution of (asynchronous) replication.

Please pay attention of the new terminology. I’m sure we’ve all used the old terminology.

However, MySQL replication has evolved a lot and the replication team has worked to include a lot of useful information about all the replication flavors available with MySQL.

For example, we’ve added parallel replication, group replication, … all that information is missing from the the good old SHOW REPLICA STATUS result.

There much better ways to monitoring and observing the replication process(es) using Performance_Schema.

Currently in Performance_Schema, there are 15 tables relating to replication instrumentation:

+------------------------------------------------------+
| …

To continue our journey to Moodle on Oracle Cloud Infrastructure using Ampere compute instances and MySQL HeatWave Database Service [1] [2], in this article we will see how to scale our architecture using multiple Moodle instances, High Availability for the Database and Read Scale-Out.

This is the architecture we will deploy:

The same principles can be applied to other projects, not just Moodle.

Multiple Compute Instances & MySQL HeatWave High Availability

The first step is to use again the Stack to deploy the initial resources. We must insure that we use a MySQL Shape that has at least 4 OCPUs to …

In the previous post, we saw how to quickly deploy Moodle to Oracle Cloud Infrastructure on Ampere compute instances and using MySQL HeatWave.

In this post, we will explore some other features and the benefits of running on OCI and MySQL HeatWave to extend our architecture dedicated to Moodle in the Cloud.

Read Replicas

Moodle natively offers the possibility of distributing the load between reads and writes. When using MySQL HeatWave Database Service, adding read replicas is also a very easy task. Let’s see how we can benefit from it.

To be able to use MySQL HeatWave Read Replicas, the MySQL shape must have at least 4 OCPUs.

Let’s modify the moodle stack and deploy it again but this time we choose a bigger shape for MySQL:

When everything is ready, …

Learn how to seamlessly add a new node to MySQL Group Replication from a backup. Scale your cluster, save time, and efficiently manage data updates and recoveries.

1. Hot Physical backup approach
2. Clone plugin approach
3. Logical backup approach

We highly recommend checking out our previous blog post on …