The multi master plugin for MySQL is here. MySQL Group Replication provides virtually synchronous updates on any node in a group of MySQL servers, with conflict handling and automatic group membership management and failure detection.

For a better understanding on how things work, we go under the hood in this post and will analyse the transaction life cycle on multi master and which components does it interact with. But before that we need to understand first what a group is.

Group Communication Toolkit

The multi master plugin is powered by a group communication toolkit. This is what decides which servers belong to the group, performs failure detection and orders server messages. Being the ordered messaging the magic thing that allows the data to be consistent across all nodes. You can check the details of the group communication toolkit at …

The multi master plugin for MySQL is here “MySQL Group Replication“. It is a virtual synchronous solution for MySQL with conflict detection. It also supports automatic group membership management, failure detection and automatic distributed recovery.

With the introduction of this new feature there was a need to perform some good amount of testing as it involves complex functionalities like :

• Servers execute local transactions and broadcasts the update to the group.
• All servers in the group, even the sender, receive same transaction in the same order and check for conflicts.
• All servers, independently, decide to commit the transaction – no conflicts.
• A new node can join an existing group, so in this case we need distributed recovery to bring it at par with the other servers.

So a great deal of effort has been spent on testing these …

Multi-master update everywhere solution for MySQL is here. MySQL Group Replication ensures virtual synchronous updates on any node in a group of MySQL servers, with conflict handling and failure detection. Distributed recovery is also in the package to ease the process of adding new nodes.

Starting with MySQL 5.7.2 there has been a constant effort from the replication team to provide more fields to monitor the replication performance in the performance schema tables. This post gives a brief  overview of the Performance Schema tables that have been introduced for MySQL Group Replication.

TABLES INTRODUCED

There are two new tables introduced as a part of the MySQL Group Replication monitoring.

• performance_schema.replication_node_status
• performance_schema.replication_connection_nodes

Lets go through each table in detail :

REPLICATION NODE STATUS

MySQL Group Replication is here and with it comes the need to install and configure the underlying group communication toolkit that supports it: Corosync. Corosync is a well known and reliable Group Communication System that is used in such applications as Pacemaker.

In term of support, we develop MySQL Group Replication based on Corosync version 1.4.6, so this tutorial is based on this version. Regardless of this, no known problems are know to exists when using newer versions, but no extensive testing has been done on those.

Along with Corosync we also encourage the use of NSS to better secure your data that is transmitted in the group.

Installing

To install Corosync, you can rely on your packet manager for most distributions or compile it from source.

==> From the package manager

• Debian distributions

$ sudo apt-get install corosync …

The new addition to the MySQL planet, MySQL Group Replication is now on Labs Release for you to try it! It offers you update everywhere capabilities on any group of normal, out of the box, MySQL servers. Concurrent updates on a setup of several MySQL servers is now possible and this with our trademark: the ease of use.

In fact we ship MySQL Group Replication in such a way that for you to form a group and add new nodes, all that is needed is to configure the servers with your unique group id and just press start. In this post we show you the “behind the scenes” of this process, on how the node catches up with the remaining servers through distributed recovery.

The basics about Distributed Recovery

If we were to summarize what distributed recovery is, we could describe it as the process through which a new server gets missing data from a live node, while paying attention to what happens in the group, eventually catching …

Introduction

The multi master plugin for MySQL is here. MySQL Group Replication ensures virtually synchronous updates on any node in a group of MySQL servers, with conflict handling and failure detection. Distributed recovery is also in the package to ease the process of adding new nodes.

For a better understanding on how things work, we go under the hood in this post and you will have a better understanding about the communication layer functionality and implementation.

Group Communication concepts Figure 1 – Plugin Architecture

As the architecture shown in Figure 1, Group Replication is a classic modular and layered piece of software and the bottom two layers comprise the communication module. But, it is not a regular …

The first preview  release of MySQL Group Replication, a MySQL plugin that brings multi-master update everywhere to MySQL, is available on labs. This plugin ties together concepts and technologies from distributed systems, such as group communication, with traditional database replication. The ultimate result is a seamlessly distributed and replicated database over a set of MySQL servers cooperating together to keep the replicated state strongly consistent.

Introduction

Before diving into the details of MySQL Group Replication, lets first introduce some background concepts and an overview of how things work. These will provide some context to help understand what this is all about and what are the differences between traditional MySQL replication and the one implemented in this new plugin.

…