Introduction to MySQL Group Replication (MGR): Features, Evolution, Deployment and Testing

MySQL Group Replication (MGR) is a high‑availability and high‑scalability solution introduced by Oracle MySQL in December 2016 with MySQL 5.7.17. It provides strong consistency, fault tolerance, scalability, and flexibility through native replication and the Paxos protocol.

Key features:

High consistency : plugin‑based group replication guarantees data safety.

High fault tolerance : the cluster continues operating as long as a majority of nodes are alive; automatic split‑brain protection is built‑in.

High scalability : nodes can be added or removed automatically, with state synchronization.

High flexibility : supports single‑primary (automatic leader election) and multi‑primary modes.

The architecture consists of an APIs layer, component layer, protocol module, and API+Paxos engine.

Technical evolution

2.1 Master‑Slave replication – asynchronous replication where the primary writes and slaves apply relay logs.

2.2 Semi‑synchronous replication – the primary waits for at least one slave to acknowledge receipt before committing.

2.3 Group replication – a share‑nothing distributed cluster with at least three servers, each holding a full copy of the data.

MGR technical characteristics

3.1 Fault detection – distributed service that identifies unresponsive members and removes them from the group.

3.2 Fault tolerance – based on the Paxos algorithm; to tolerate f failures, the cluster needs n = 2*f + 1 servers (e.g., three servers tolerate one failure).

3.3 Member management – uses a Group View with a view ID to track membership changes; view changes can be queried via performance_schema.replication_group_member_stats .

Installation experience

Test nodes:

10.10.1.214 10.10.1.217 10.10.6.91

All nodes run MySQL 8.0.24. After extracting the tarball, the following commands initialize the server:

su - mysql
wget http://mirrors.ustc.edu.cn/mysql-ftp/Downloads/MySQL-8.0/mysql-8.0.24-linux-glibc2.12-x86_64.tar
tar -xf mysql-8.0.24-linux-glibc2.12-x86_64.tar
cd mysql-8.0.24-linux-glibc2.12-x86_64
mkdir conf data
./bin/mysqld --initialize --datadir=/home/mysql/mysql-8.0.24-linux-glibc2.12-x86_64/data --basedir=/home/mysql/mysql-8.0.24-linux-glibc2.12-x86_64
./bin/mysqld_safe --defaults-file=conf/my.cnf &

Configuration file (my.cnf) example:

[mysqld]
bind-address=0.0.0.0
datadir=/home/mysql/mysql-8.0.24-linux-glibc2.12-x86_64/data
basedir=/home/mysql/mysql-8.0.24-linux-glibc2.12-x86_64
port=3306
socket=/home/mysql/mysql-8.0.24-linux-glibc2.12-x86_64/data/mysqld.sock
user=mysql
server_id=1
gtid_mode=ON
enforce_gtid_consistency=ON
master_info_repository=TABLE
relay_log_info_repository=TABLE
log_slave_updates=ON
log_bin=binlog
binlog_format=ROW
innodb_buffer_pool_size=1g
transaction_write_set_extraction=XXHASH64
plugin_load_add='group_replication.so'
group_replication_group_name="8d3cebd8-b132-11eb-8529-0242ac130003"
group_replication_start_on_boot=off
group_replication_local_address="10.10.1.214:33061"
group_replication_group_seeds="10.10.1.214:33061,10.10.1.217:33061,10.10.6.91:33061"
group_replication_bootstrap_group=off
loose-group_replication_ip_whitelist='10.10.1.214,10.10.1.217,10.10.6.91'

Single‑primary deployment

Bootstrap the primary node:

# Create replication user and install plugin
SET SQL_LOG_BIN=0;
CREATE USER rpl_user@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
GRANT BACKUP_ADMIN ON *.* TO rpl_user@'%';
FLUSH PRIVILEGES;
SET SQL_LOG_BIN=1;
CHANGE REPLICATION SOURCE TO SOURCE_USER='rpl_user', SOURCE_PASSWORD='password' FOR CHANNEL 'group_replication_recovery';
INSTALL PLUGIN group_replication SONAME 'group_replication.so';
SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;
SELECT * FROM performance_schema.replication_group_members;

Join a secondary node (repeat on each secondary):

# Same user creation steps as above
SET SQL_LOG_BIN=0;
CREATE USER rpl_user@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
GRANT BACKUP_ADMIN ON *.* TO rpl_user@'%';
FLUSH PRIVILEGES;
SET SQL_LOG_BIN=1;
CHANGE REPLICATION SOURCE TO SOURCE_USER='rpl_user', SOURCE_PASSWORD='password' FOR CHANNEL 'group_replication_recovery';
START GROUP_REPLICATION;
SELECT * FROM performance_schema.replication_group_members;

Multi‑primary deployment

Set the mode to multi‑primary before adding nodes:

SET GLOBAL group_replication_single_primary_mode=OFF;

Bootstrap the first node (same steps as single‑primary, but keep group_replication_single_primary_mode=OFF ), then start other nodes with the same configuration.

Testing

# Show databases on any node
SHOW DATABASES;
CREATE DATABASE test;
SHOW DATABASES;

Application scenarios include financial systems requiring zero data loss, replacement of traditional master‑slave HA, and elastic scaling in private‑cloud environments.

Conclusion

Although MGR has been available since 2016 and is used by companies such as NetEase and DiDi, adoption is still limited due to relatively weak demand, immature ecosystem, and unresolved bugs. Over time, as the ecosystem matures, MGR is expected to become a mainstream high‑availability solution for MySQL.