This is the third post in the series on Write Set in MySQL.  In the first post, we explore how Write Set allows to get better parallel replication in MySQL 8.0.  In the second post, we saw how the MySQL 8.0 improvement is an extension of the work done in MySQL 5.7 to avoid replication delay/lag in Group Replication.  In this post, we will see how Write Set is used in Group Replication to detect

In my previous post, I write that Write Set is not only in MySQL 8.0 but also in MySQL 5.7 though a little hidden.  In this post, I describe Write Set in 5.7 and this will bring us in the inner-working of Group Replication.  I am also using this opportunity to explain and show why members of a group can replicate faster than a standard slave.  We will also see the impacts, on Group Replication,

In my MySQL Parallel Replication session at Percona Live Santa Clara 2017, I talked about a bug in Write Set tracking for parallel replication (Bug#86078).  At the time, I did not fully understand what was going wrong but since then, we (Engineers at Oracle and me) understood what happened and the bug is supposed to be fixed in MySQL 8.0.4.  This journey thought me interesting MySQL behavior and

Multi-channel replication is one of the  great feature shipped with MySQL 5.7, With allowed the capability of slave to have many masters, having a channel for each master by which they replicate. Each channel id has a unique “channel_name”

Multi-Channel Replication

In the above DB Architecture “channel_1, channel_2 and channel_3” represent the channel_name used for replication from different MySQL servers ( Source ). In this blog we are not going see about configuration of multi_source replication, rather we are going to see about rolling back multi-source replication in MySQL. Recently we were working on a client, where we had deployed multi-channel replication replication from two master onto a single slave, sync was happening very fine Then came the situation to break the replication from …

Semi-sync Replication is a plugin available for mysql which allows you to create more durable replication topologies.  For instance you can ensure that in the event of a master crash that at least one of your replicas has all transaction currently written to the master so that when you promote, you know you're not missing any data.

That's a huge simplification.

What's the downside?  Write speed.  If a transaction on your master have to wait until a replica acknowledges it has that transaction, then there is going to be some delay.  Not only that, but your network latency between the two points matters a lot.  If you want greater durability, the cost is performance.

It's important to note that the master doesn't wait until the replica actually runs the transaction on the …

Ok, so now we’re got our InnoDB Cluster a-clustering, MySQL Router a-routing, now we need some disaster to be a-disaster-recovering…

A foreword first.

If you’re looking to use Enterprise Backup to recover a single node and restore that node back into an existing InnoDB Cluster, LeFred takes you through that one nicely here.

Preparing for backup

On our single primary server, the one that allows write, which was ic2/10.0.0.12 in my case:

mysql -uroot -poracle << EOF 
SET sql_log_bin = OFF; 
 create user 'backup'@'%' identified by 'oracle';
 grant all on *.* to 'backup'@'%';
SET sql_log_bin = ON; 
EOF

Let’s create something to backup (if you haven’t already done so of course):

mysqlsh --uri …

Want to setup InnoDB Cluster and be prepared for a Disaster Recovery scenario? Get ready:

Here’s a way to set up InnoDB Cluster using the 3 environments, on Oracle Linux 7.2, 5.7.19 MySQL Commercial Server, MySQL Shell 8.0.3 DMR, MySQL Router. As this is the first blog post for a complete disaster recovery scenario of InnoDB Cluster, we’ll also be installing MySQL Enterprise Backup.

If you’re new to InnoDB Cluster then I’d highly recommend looking at the following to understand how it works and what Group Replication, Shell & Router are.:

• https://dev.mysql.com/doc/refman/5.7/en/mysql-innodb-cluster-production-deployment.html
• …

MySQL 8.0.3 release candidate is out with amazing new replication features, along with changes in couple of replication default options. Thanks to our users for their constant feedback and valuable inputs, MySQL is changing defaults whenever possible to remove configuration overhead for practical deployment of MySQL server.…

MySQL is not only a relational database, but can also be used as a schemaless/NOSQL document store, or a mix of both. This is realized by the JSON datatype, and is useful for any data that is hard to fit in the ”tabular” format of a traditional table.…

In this blog, I’ll look at how to do MySQL point in time recovery (PITR) correctly.

Sometimes we need to restore from a backup, and then replay the transactions that happened after the backup was taken. This is a common procedure in most disaster recovery plans, when for example you accidentally drop a table/database or run an update/delete without the “where” clause and lose data.

The usual way is to get a copy of your binlogs and use mysqlbinlog to replay those transactions. But this approach has many pitfalls that can make the whole PITR process a nightmare. Some examples:

• You need to make sure to run a single mysqlbinlog command with all related binlogs, and pipe them to mysql at once. Otherwise, if binlog.000001 creates a temporary table, and …