A MySQL replication topology can be very complex (never underestimate a DBA’s creativity). But it’s very frequent to use an asynchronous slave from your primary database to run reporting or logical backup… or any kind of read workload you need. It can also be used as delay slave for data restore purpose.

Once you decided to provide HA to your primary database by migrating to MySQL InnoDB Cluster, you can of course still need and use one or more asynchronous slaves.

You have then an architecture that looks like this :

So as you can notice, your asynchronous slave needs to pick one of the members of the cluster as master. However when this node that act as master crashes (or is stopped for maintenance) what’s happening ?

…

From September 25th to 27th 2017, the MySQL engineers and community team will be speaking at Percona Live Europe in Dublin.

MySQL is also part of the contributing sponsors.

For the conference, we tried to bring new faces to the Community. Usually, it’s always the same famous team leaders speaking at the conferences, this time, it’s not. A lot of key developers will present their own work. We have so much talented people in MySQL we want to present to our community.

Of course, once again we will focus our talks on MySQL 8.0. This is the list of sessions the MySQL Team will deliver:

Monday, Sep 25th

On Monday, I will deliver a tutorial with my friend …

Today is my last day in Asia (China and Taiwan), and between the sessions I had the time to code a small proof-of-concept for people that are asking how they could read their writes on all nodes and ensure the read consistency with their last write ?

The usual (and easier) answer to this particular question is to read on the same host you just wrote. But currently MySQL provides you all the elements to force a consistent read across all the nodes of a group.

Since MySQL 5.7.5, we introduced session_track_gtidsand in 5.7.6 we also introduced  GTIDs context to the OK packet (session tracker) (WL#6128 and WL#6972). So we can use this implementation in …

Recently I wrote a blog post on how to use ProxySQL with 8.0.2 dmr

This blog post was related to the change we implemented in the Group Replication’s monitoring (performance_schema tables) and how sys schema should be changed to modify the view used by ProxySQL according.

However, I used my labs machines that I was using for different purposes too and some changes I made hid a problem that avoid ProxySQL to work with the new defaults in MySQL 8.0.2. Thank you Andy for discovering this.

In fact the new collation default (utf8mb4_0900_ai_ci) is not yet supported by ProxySQL …

In this blog, we’ll look at group replication and how it deals with flow control (FC) and replication lag. 

Overview

In the last few months, we had two main actors in the MySQL ecosystem: ProxySQL and Group-Replication (with the evolution to InnoDB Cluster). 

While I have extensively covered the first, my last serious work on Group Replication dates back to some lab version years past.

Given that Oracle decided to declare it GA, and Percona’s decision to provide some level of Group Replication support, I decided it was time for me to take a look at it again.

We’ve seen a lot of coverage already too many Group Replication topics. There are articles about Group Replication and performance, Group Replication and basic functionalities (or lack of it like automatic node provisioning), Group Replication and ProxySQL, and so on.

But one question kept coming up over and over in my …

Some time ago I wrote this article explaining how to find which node was the Primary Master in a MySQL Group Replication cluster running in Single-Primary Mode.

In the latest release of Group Replication, MySQL 8.0.2 dmr, Jaideep improved the visibility of Group Replication extending the performance_schema tables (see his article).

Thanks to these improvements, it’s now very easy to find which host is acting a Primary-Master. This is the query you can use:

mysql-sql> SELECT MEMBER_HOST as `PRIMARY` 
           FROM performance_schema.replication_group_members 
           WHERE MEMBER_ROLE='PRIMARY';
+---------+
| PRIMARY |
+---------+
| mysql3  |
+---------+
1 row in set (0.00 sec)

Recently, my friend Marco Tusa(MySQL Daddy or the Grinch) wrote his first impression on MySQL Group Replication (part of InnoDB Cluster). And his conclusion was not that positive. But when I analyze his setup, I understand that his assumptions were not so right.

Let's try to explain what were the issues and why his test wasn't correct.

Before commenting Marco's tests, I would like to clarify the flow-control implementation in Group Replication:

We designed the flow-control feature in Group Replication as a safety measure for delaying writer nodes when they consistently exceed the write capacity of the Group, so that a large backlog would not make it hard to switch over from a member to another.

Flow-control is …

Group Replication has been around for some time now and the feedback from community is overwhelming. One of the suggestions (BUG#84795) received is related to deploying a mechanism to prevent a server from being updated after stopping group replication.…

As you may know by now, MySQL 8.0.2 DMR is out ! \o/

Many features have been added (see Geir Høydalsvik‘s announcement) and of course the replication also brought new features and improvements (see this post from Luís Soares).

But some improvements in the monitoring broke the added sys view used by ProxySQL to monitor the state of a member of the group:

mysql> select * from sys.gr_member_routing_candidate_status;
+------------------+-----------+---------------------+----------------------+
| viable_candidate | read_only | transactions_behind | transactions_to_cert | …

MySQL 8 is shaping up quite nicely. And we are having a blast in the MySQL replication team while this is happening. We are continuously improving all-things-replication by introducing new and interesting features. In addition, we have been listening to our community and addressing their feedback.…