Exploring MySQL Group Replication Communication Stack: XCom vs MySQL

May 5, 2024

Mins to Read

All

MySQL Group Replication is a powerful feature that enables multi-master replication in MySQL, allowing for high availability and data consistency in database systems. At the heart of MySQL Group Replication is its communication stack, which manages the coordination and communication between nodes in a replication group. In this blog post, we will explore two critical components of the communication stack: XCom and MySQL. We'll compare the two and discuss their roles in the context of MySQL Group Replication.

MySQL Group Replication Communication Stack

XCom: The Group Communication Service

XCom, also known as Group Communication System (GCS) XCom, is a key component of MySQL Group Replication's communication stack default for MySQL Server 8.0.26 or older. It serves as the underlying framework for group messaging and coordination.

XCom's primary responsibilities include:

Group Membership Management

XCom keeps track of the members in the replication group and ensures that new members are correctly integrated while handling departures gracefully.

Transaction Ordering

XCom is responsible for determining the order in which transactions are applied to ensure data consistency across all nodes in the group.

Message Reliability

XCom guarantees that messages are reliably delivered to all members, even in the presence of network issues or node failures.

Secure connection

TLS/SSL are used for connection and the use of an allowlist for incoming Group Communication System (GCS) connections.

XCom Communication Protocol Flow

MySQL Group Communication Stack

The MySQL Group Communication Stack means that standard methods of user authentication default for MySQL Server 8.0.27 or newer. It's a collection of tools and protocols used for handling communication and coordination within a replication group.

The stack comprises:

Secure connection

Uses MySQL Server's connection security to create InnoDB Clusters more easily than if MySQL Group Replication was implemented.

Network address

Eliminates the necessity of using a separate network port or address for internal MySQL Group Replication communications.

User authentication

Instead of using the allow list to give or revoke access to the group, the MYSQL protocol allows for the use of conventional user authentication techniques.

Network namespaces

Supports MySQL group replication using network namespaces.

Comparing XCom and MySQL Group Communication Stack

Aspect	XCom	MySQL
Supported version	MySQL Server 8.0.26 or older	MySQL Server 8.0.27 or newer
Protocol	It is a specially constructed protocol created to meet the needs of MySQL Group Replication.	MySQL's existing replication
Technology	With its consensus algorithm based on Paxos, XCom offers robust consistency guarantees. It guarantees that the data is seen the same way by every node in the group.	Since MySQL Layer depends on the replication methods already in place in MySQL, it might not provide as strong of a consistency as XCom. It is, nonetheless, more compatible with MySQL deployments that are already in place.
Latency	Utilizes a dedicated communication stack designed specifically for MySQL group replication. This streamlined design focuses on efficient message exchange within the replication group.Latency - 10 to 20 millisecond	The MySQL server communication stack, which addresses communication needs other than MySQL group replication. This expanded capabilities may result in some extra expense compared to XCom's specialised approach. Latency - 10 to 90 millisecond
Security Implementation	Built-in TLS/SSL and allowlist	Standard user authentication and network namespaces support

Switching between Xcom and MySQL communication protocol

The cluster currently utilizes XCom as the communication protocol for both nodes.

 
mysql> select MEMBER_HOST, MEMBER_PORT, MEMBER_STATE, MEMBER_ROLE, MEMBER_VERSION, MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members;

+---------------+-------------+--------------+-------------+----------------+----------------------------+

| MEMBER_HOST   | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |

+---------------+-------------+--------------+-------------+----------------+----------------------------+

| Node1         |        3306 | ONLINE       | PRIMARY     | 8.0.34         | XCom                       |

| Node2         |        3306 | ONLINE       | SECONDARY   | 8.0.34         | XCom                       |

+---------------+-------------+--------------+-------------+----------------+----------------------------+

2 rows in set (0.00 sec)

We must ensure uniformity in the communication stack across all nodes within the group. To achieve this, it's necessary to temporarily halt the MySQL group replication on all nodes.

Validation

Switching the group_replication_communication_stack necessitates a period of downtime. Ensure a safe shutdown of all nodes within the MySQL group replication before making the switch.

Node2:

 
mysql> select MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members;

+-------------+-------------+--------------+-------------+----------------+----------------------------+

| MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |

+-------------+-------------+--------------+-------------+----------------+----------------------------+

| Node2       |        3306 | OFFLINE      |             |                | XCom                       |

+-------------+-------------+--------------+-------------+----------------+----------------------------+

1 row in set (0.00 sec)

Node1:

 
mysql>  select MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members;

+---------------+-------------+--------------+-------------+----------------+----------------------------+

| MEMBER_HOST   | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |

+---------------+-------------+--------------+-------------+----------------+----------------------------+

| Node1         |        3306 | OFFLINE      |             |                | XCom                       |

+---------------+-------------+--------------+-------------+----------------+----------------------------+

1 row in set (0.00 sec)

Implementation

After ensuring that all nodes are offline, modify the group_replication_communication_stack to 'mysql' in the configuration file (cnf). Subsequently, start the node that was most recently shut down to mitigate the risk of data loss.

Node1:

 
mysql> show global variables like 'group_replication_communication_stack';

+---------------------------------------+-------+

| Variable_name                         | Value |

+---------------------------------------+-------+

| group_replication_communication_stack | MYSQL |

+---------------------------------------+-------+

1 row in set (0.01 sec)

As node1 was the last node to be stopped, we are initiating the start-up process with node1 as the initial step in the MySQL group replication sequence

 
mysql> start group_replication;

Query OK, 0 rows affected, 1 warning (1.10 sec)

mysql> select MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members;

+---------------+-------------+--------------+-------------+----------------+----------------------------+

| MEMBER_HOST   | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |

+---------------+-------------+--------------+-------------+----------------+----------------------------+

| Node1         |        3306 | ONLINE       | PRIMARY     | 8.0.34         | MySQL                      |

+---------------+-------------+--------------+-------------+----------------+----------------------------+

1 row in set (0.00 sec)

Node2:

Following that, we can proceed to start node 2 in the MySQL group replication.

 
mysql> start group_replication;

Query OK, 0 rows affected, 1 warning (1.64 sec)

mysql> select MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members;

+---------------+-------------+--------------+-------------+----------------+----------------------------+

| MEMBER_HOST   | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |

+---------------+-------------+--------------+-------------+----------------+----------------------------+

| Node1         |        3306 | ONLINE       | PRIMARY     | 8.0.34         | MySQL                      |

| Node2         |        3306 | ONLINE       | SECONDARY   | 8.0.34         | MySQL                      |

+---------------+-------------+--------------+-------------+----------------+----------------------------+

2 rows in set (0.00 sec)

The outlined steps allow for the seamless switch of group_replication_communication_stack between XCOM and MYSQL, providing flexibility in adapting the communication stack as needed.

Optimize your MySQL Group Replication setup with Mydbops' InnoDB Cluster Consulting Services. Our experts can help you streamline your database management and improve performance. Contact us today to discuss your specific needs.

No items found.