Just recently, I have been asked to look into what a Disaster Recovery site for InnoDB Cluster would look like.

If you’re reading this, then I assume you’re familiar with what MySQL InnoDB Cluster is, and how it is configured, components, etc.

Reminder: InnoDB Cluster (Group Replication, Shell & Router) in version 8.0 has had serious improvements from 5.7. Please try it out.

So, given that, and given that we want to consider how best to fulfill the need, i.e. create a DR site for our InnoDB Cluster, let’s get started.

Basically I’ll be looking at the following scenario:

InnoDB Cluster Source site with a Group Replication Disaster Recovery Site.

Now, just before we get into the nitty-gritty, here’s the scope.

Life is already hard enough, so we want as much automated as possible, so, yes, InnoDB Cluster gets some of that done, but there are other parts we will still have …

With this post we are reaching the end of our journey to HA for WordPress & MySQL 8.0 on OCI.

If you have not read the two previous articles, this is just the right time.

• MySQL 8.0 InnoDB ReplicaSet with WordPress in OCI
• MySQL 8.0 InnoDB ReplicaSet with WordPress in OCI – part II

We started this trip using the MySQL InnoDB ReplicaSet where only 2 servers are sufficient but doesn’t provide automatic fail-over.

In this article we will upgrade our InnoDB ReplicaSet to …

This article is the second part of our journey to WordPress and MySQL 8.0 High Availability on OCI. The first part can be read here.

We ended part I with one webserver hosting WordPress. This WordPress was connecting locally to MySQL Router using HyperDB add-on. This add-on allows to split the reads & writes on MySQL Servers using replication. And finally we had one MySQL InnoDB ReplicaSet of two …

GTID-based replication makes managing replication topology easy: just CHANGE MASTER to any node and voilà. It doesn’t always work, but for the most part it does. That’s great, but it can hide a serious problem: missing writes. Even when MySQL GTID-based replication says, “OK, sure!”, which is most of the time, you should double check it.

GTID-based replication makes managing replication topology easy: just CHANGE MASTER to any node and voilà. It doesn’t always work, but for the most part it does. That’s great, but it can hide a serious problem: missing writes. Even when MySQL GTID-based replication says, “OK, sure!”, which is most of the time, you should double check it.

GTID-based replication makes managing replication topology easy: just CHANGE MASTER to any node and voilà. It doesn’t always work, but for the most part it does. That’s great, but it can hide a serious problem: missing writes. Even when MySQL GTID-based replication says, “OK, sure!”, which is most of the time, you should double check it.

Today’s article is again related to WordPress and MySQL 8.0. We will see how we can setup MySQL InnoDB ReplicaSet and configure WordPress to split the load using both MySQL Instances: we will split reads and writes between the Primary and the Secondary member of our ReplicaSet.

This will be the first part of our journey to achieve HA for our WordPress site on OCI and using all MySQL Servers we have deployed. We don’t want to have a server idle just waiting to take over in case of an incident.

MySQL InnoDB ReplicaSet

First some words about MySQL InnoDB ReplicaSet.

The ease of use of …

Tweet

On a busy server, the binary logs can end up being one of the largest contributors to amount of disk space used. That means higher I/O, larger backups (you are backing up your binary logs, right?), potentially more network traffic when replicas fetch the logs, and so on. In general, binary logs compress well, so it has been a long time wish for a feature that allowed you to compress the logs while MySQL are still using them. Starting from MySQL 8.0.20 that is now possible. I will take a look at the new feature in this post.

Configuration

The binary log compression feature is controlled by two variables, one for enabling the feature and …

On Monday April 27th, MySQL released a much-anticipated patch release 8.0.20. Along with many bug fixes and improvements, a new property was introduced – binlog-transaction-compression. During our own internal testing we have discovered an incompatibility with our Continuent Tungsten products when this property is enabled.

The newly-released binlog-transaction-compression feature is really interesting because it compresses transaction payloads before being written into the binary logs, which in turn reduces the disk space overhead required for storage. I’m sure many users will be keen to implement this, however at this time the use of binlog-transaction-compression=ON will prevent Replication from functioning correctly.

This …

We have just released MySQL 8.0.20. And it has some interesting replication enhancements. In particular one big and exciting feature: binary log compression. Here is the list of things in this release:

• Binary Log Compression (WL#3549). This work done by Luís Soares implements binary log compression, making use of the popular compression algorithm ZSTD.

… Tweet Share