版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/lmocm/article/details/79571088
本课件包含：
1， MySQL官方文档 group replicateion 介绍
2，single & multi group replication 部署配置
3，my.cnf 配置参数
1， MGR 官方文档及注意点：
Deploying Group Replication in Single-Primary Mode
部署 MySQL组复制 单主模式
Create the data directories in a directory named data and initialize each one
每个数据库创建对应的目录，最好目录保持一样
####
mkdir data
mysql-5.7/bin/mysqld --initialize-insecure --basedir=$PWD/mysql-5.7 --datadir=$PWD/data/s1
mysql-5.7/bin/mysqld --initialize-insecure --basedir=$PWD/mysql-5.7 --datadir=$PWD/data/s2
mysql-5.7/bin/mysqld --initialize-insecure --basedir=$PWD/mysql-5.7 --datadir=$PWD/data/s3
这里是安装MySQL服务，通过--initialize-insecure 参数来初始化，其特点是跳过系统定义的初始密码。
Group Replication Server Settings
To install and use the Group Replication plugin you must configure the MySQL Server instance correctly.
It is recommended to store the configuration in your my.cnf file
要配置组复制配置，需要正确安装组复制插件及配置合适的参数。
同时推荐参数放入my.cnf 配置文件里。
####
[mysqld]
# server configuration
datadir=<full_path_to_data>/data/s1
basedir=<full_path_to_bin>/mysql-5.7/
port=24801
socket=<full_path_to_sock_dir>/s1.sock
这是mysql 基本的配置参数需求。
Replication Framework
复制参数框架参数：
server_id=1
(server_id值所有节点必须唯一）
gtid_mode=ON
enforce_gtid_consistency=ON
master_info_repository=TABLE
relay_log_info_repository=TABLE
binlog_checksum=NONE
log_slave_updates=ON
log_bin=binlog
binlog_format=ROW
以上为组复制主要涉及的参数：
These settings configure the server to use the unique identifier number 1, to enable global transaction
identifiers and to store replication metadata in system tables instead of files. Additionally, it instructs the
server to turn on binary logging, use row-based format and disable binary log event checksums.
这里服务参数通过唯一id 来应用全局性事务
复制的元数据放在表中，而没有以文件方式存放.
服务需要打开二进制日志，并且需要使用基于row模式，同时需要禁用二进制日志校验（binlog_checksum=NONE）。
Group Replication Settings
At this point the my.cnf file ensures that the server is configured and is instructed to instantiate the
replication infrastructure under a given configuration. The following section configures the Group
Replication settings for the server.
组复制框架的参数设置：
#####
transaction_write_set_extraction=XXHASH64
loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
loose-group_replication_start_on_boot=off
loose-group_replication_local_address= "127.0.0.1:24901"
loose-group_replication_group_seeds= "127.0.0.1:24901,127.0.0.1:24902,127.0.0.1:24903"
loose-group_replication_bootstrap_group= off
############ 注意，IP相同，只要端口不一样，都可以添加到同一集群下####
-----------------------------------------------
NOte:
The loose-* prefix used for the group_replication variables above instructs the
server to continue to start if the Group Replication plugin has not been loaded at the time the server is started.
前缀以loose-* 开头的参数，是用于组复制的变量参数。
最好在组复制启动前，安装好组复制的插件。
Line 1 instructs the server that for each transaction it has to collect the write set and encode it as a hash using the XXHASH64 hashing algorithm
第1行指示服务器，对于每个事务，它必须收集编写集，并使用XXHASH64散列算法将其编码为散列（所有节点配置一样）
Line 2 tells the plugin that the group that it is joining, or creating, is named "aaaaaaaa-aaaa-aaaa-aaaaaaaaaaaaaaaa".
第二行指示 组复制集群的名称,这是唯一的。所有节点需要配置一样。(按这种模式，可以不一样。但是确保唯一）
Line 3 instructs the plugin to not start operations automatically when the server starts.
第3行指示插件在服务器启动时不会自动启动操作。
Line 4 tells the plugin to use the IP address 127.0.0.1, or localhost, and port 24901 for incoming connections from other members in the group
第四行当前节点的对应IP和端口。（这里的端口是组复制MGR集群的内部端口，不是MySQL对外提供服务的外部端口)
important:
The server listens on this port for member-to-member connections. This port must
not be used for user applications at all, it must be reserved for communication
between different members of the group while running Group Replication
重要提醒：
（这里的端口是组复制MGR集群的内部端口，不是MySQL对外提供服务的外部端口)
The local address configured by group_replication_local_address must be accessible to all
group members.
参数group_replication_local_address 本地地址配置得地址必须所有组内成员都能访问。
For example, if each server instance is on a different machine use the IP and port of the
machine, such as 10.0.0.1:33061. The recommended port for group_replication_local_address
is 33061, but in this tutorial we use three server instances running on one machine, thus ports 24901 to
24903 are used.
Line 5 tells the plugin that the following members on those hosts and ports should be contacted in case it
needs to join the group. These are seed members, which are used when this member wants to connect
to the group. Upon joining the server contacts one of them first (seed) and then it asks the group to
reconfigure to allow the joiner to be accepted in the group. Note that this option does not need to list all
members in the group, but rather a list of servers that should be contacted in case this server wishes to
join the group
第五行，因为在同意服务器下，得3个不同实例作为 MGR 集群，那么通过不同得端口来区分(同时也确定了，不同节点可以使用不同得端口，但是如果是多服务器下，推荐使用同一端口，便于管理)
#####
Create a MySQL user with the REPLICATION-SLAVE privilege.
mysql> SET SQL_LOG_BIN=0;
mysql> CREATE USER rpl_user@'%';
mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%' IDENTIFIED BY 'rpl_pass';
mysql> FLUSH PRIVILEGES;
mysql> SET SQL_LOG_BIN=1;
mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='rpl_pass' FOR CHANNEL 'group_replication_recovery';
### 注意：
这里change 时，会自动识别my.cnf 中得配置（端口，IP等）。
######
Launching Group Replication
Once server s1 has been configured and started , install the Group Replication plugin. Connect to the
server and issue the following command:
启动组复制
推荐启动组复制前，先安装插件，SQL语句如下：
MYSQL> INSTALL PLUGIN group_replication SONAME 'group_replication.so';
mysql> show plugins;
######
MYSQL>SET GLOBAL group_replication_bootstrap_group=ON;
MYSQL>START GROUP_REPLICATION;
MYSQL>SET GLOBAL group_replication_bootstrap_group=OFF;
启动组复制命令：
##注意
mgr 部署第一次启动时，第一个节点需要使用。 之后新增得节点直接使用start group_replication 即可。
Once the START GROUP_REPLICATION statement returns, the group has been started. You can check
that the group is now created and that there is one member in it:
mysql> SELECT * FROM performance_schema.replication_group_members;
组复制启动后，查询组复制组内成员，通过表 performance_schema.replication_group_members.
--提示，一般组复制所有得表在performance_schema 用户下，以replication_group-* 为前缀。
####
The information in this table confirms that there is a member in the group with the unique identifier
ce9be252-2b71-11e6-b8f4-00212844f856, that it is ONLINE and is at myhost listening for client
connections on port 24801.
### 新增组成员：
#####
18.2.1.5 Adding Instances to the Group
Adding a Second Instance
In order to add a second instance, server s2, first create the configuration file for it. The configuration is
similar to the one used for server s1, except for things such as the location of the data directory, the ports
that s2 is going to be listening on or its server_id. These different lines are highlighted in the listing
below.
[mysqld]
# server configuration
datadir=<full_path_to_data>/data/s2
basedir=<full_path_to_bin>/mysql-5.7/
port=24802
socket=<full_path_to_sock_dir>/s2.sock
#
# Replication configuration parameters
#
server_id=2
gtid_mode=ON
enforce_gtid_consistency=ON
master_info_repository=TABLE
relay_log_info_repository=TABLE
binlog_checksum=NONE
log_slave_updates=ON
log_bin=binlog
binlog_format=ROW
#
# Group Replication configuration
#
transaction_write_set_extraction=XXHASH64
loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
loose-group_replication_start_on_boot=off
loose-group_replication_local_address= "127.0.0.1:24902"
loose-group_replication_group_seeds= "127.0.0.1:24901,127.0.0.1:24902,127.0.0.1:24903"
loose-group_replication_bootstrap_group= off
#####
MYSQL> SET SQL_LOG_BIN=0;
MYSQL> CREATE USER rpl_user@'%';
MYSQL> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%' IDENTIFIED BY 'rpl_pass';
MYSQL> SET SQL_LOG_BIN=1;
MYSQL>
CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='rpl_pass' FOR CHANNEL 'group_replication_recovery';
Install the Group Replication plugin and start the process of joining the server to the group. The following
example installs the plugin in the same way as used while deploying server s1.
mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';
Add server s2 to the group.
mysql> START GROUP_REPLICATION;
这里需要注意，新增得组内节点，在新增后，直接start, 而不需要设置参数group_replication_bootstrap_group 先ON 再start, 再off.
important :
Unlike the previous steps that were the same as those executed on s1, here there is a difference in that
you do not issue SET GLOBAL group_replication_bootstrap_group=ON; before starting Group
Replication, because the group has already been created and bootstrapped by server s1. At this point
server s2 only needs to be added to the already existing group.
mysql> SELECT * FROM performance_schema.replication_group_members;
Adding Additional Instances:
Adding additional instances to the group is essentially the same sequence of steps as adding the second
server, except that the configuration has to be changed as it had to be for server s2. To summarise the
required commands:
1. Create the configuration file
[mysqld]
# server configuration
datadir=<full_path_to_data>/data/s3
basedir=<full_path_to_bin>/mysql-5.7/
port=24803
socket=<full_path_to_sock_dir>/s3.sock
#
# Replication configuration parameters
#
server_id=3
gtid_mode=ON
enforce_gtid_consistency=ON
master_info_repository=TABLE
relay_log_info_repository=TABLE
binlog_checksum=NONE
log_slave_updates=ON
log_bin=binlog
binlog_format=ROW
#
# Group Replication configuration
#
transaction_write_set_extraction=XXHASH64
loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
loose-group_replication_start_on_boot=off
loose-group_replication_local_address= "127.0.0.1:24903"
loose-group_replication_group_seeds= "127.0.0.1:24901,127.0.0.1:24902,127.0.0.1:24903"
loose-group_replication_bootstrap_group= off
2. Start the server
mysql-5.7/bin/mysqld --defaults-file=data/s3/s3.cnf
3. Configure the recovery credentials for the group_replication_recovery channel.
SET SQL_LOG_BIN=0;
CREATE USER rpl_user@'%';
GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%' IDENTIFIED BY 'rpl_pass';
FLUSH PRIVILEGES;
SET SQL_LOG_BIN=1;
CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='rpl_pass' \\
FOR CHANNEL 'group_replication_recovery';
4. Install the Group Replication plugin and start it.
INSTALL PLUGIN group_replication SONAME 'group_replication.so';
START GROUP_REPLICATION;
mysql> SELECT * FROM performance_schema.replication_group_members;
18.3 Monitoring Group Replication:
• performance_schema.replication_group_member_stats
• performance_schema.replication_group_members
These existing P_S replication tables also show information regarding Group Replication
• performance_schema.replication_connection_status
• performance_schema.replication_applier_status
The replication channels created by the Group Replication plugin are named:
• group_replication_recovery - This channel is used for the replication changes that are related to
the distributed recovery phase.
• group_replication_applier - This channel is used for the incoming changes from the group. This
is the channel used to apply transactions coming directly from the group
18.4.1 Deploying in Multi-Primary or Single-Primary Mode
Group Replication operates in the following different modes:
• single-primary mode
• multi-primary mode
Group Replication does not handle client-side fail-over,
that must be handled by the application itself, a connector or a middleware framework such as a proxy or
router.
###
These checks can be deactivated by setting the option
group_replication_enforce_update_everywhere_checks to FALSE. When deploying in singleprimary mode, this option must be set to FALSE.
18.4.1.1 Single-Primary Mode
In this mode the group has a single-primary server that is set to read-write mode. All the other members
in the group are set to read-only mode (i.e., super-read-only ). This happens automatically. The primary
is typically the first server to boostrap the group, all other servers that join automatically learn about the primary server and are set to read only.
In the event the primary member is removed from the group, then an election is performed and a new
primary is chosen from the remaining servers in the group. This election is performed by looking at the new
view, ordering the server UUIDs in lexicographical order and by picking the first one. Once a new primary
is elected, it is automatically set to read-only and the other secondaries remain as secondaries, and as
such, read-only.
It is a good practice to wait for the new primary to apply its replication related relay-log before re-routing the
client applications to it.
##########################
18.4.1.2 Multi-Primary Mode
In multi-primary mode, there is no notion of a single primary. There is no need to engage an election
procedure since there is no server playing any special role.
All servers are set to read-write mode when joining the group.
18.4.1.3 Finding the Primary
The following example shows how to find out which server is currently the primary when deployed in
single-primary mode.
mysql> SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME= 'group_replication_pri
Number of Attempts
The number of attempts a joiner makes when trying to connect to a donor from the pool of donors is 10.
This is configured through the group_replication_recovery_retry_count plugin variable .
SET GLOBAL group_replication_recovery_retry_count= 10;
Sleep Routines
The group_replication_recovery_reconnect_interval plugin variable defines how much time
the recovery process should sleep between donor connection attempts. This variable has its default set to
60 seconds and you can change this value dynamically. The following command sets the recovery donor
connection retry interval to 120 seconds.
SET GLOBAL group_replication_recovery_reconnect_interval= 120;
The Group Replication plugin has a configuration option to determine from which hosts
an incoming Group Communication connection can be accepted. This option is called
group_replication_ip_whitelist. If you set this option on a server s1, then when server s2 is
establishing a connection to s1 for the purpose of engaging group communication, then s1 first checks the
whitelist before accepting the connection from s2. If s2 is in the whitelist, then s1 accepts the connection,
otherwise s1 rejects the connection attempt by s2
If you do not configure any whitelist, the server automatically sets the whitelist to the private networks that
the server has an interface on. This means that a server, even if it has interfaces on public IPs, does not by
default allow connections from external hosts.
Whenever the IP whitelist is set to AUTOMATIC, an entry in the error log can be emitted in such case,
similar to:
2016-07-07T06:40:49.320686Z 4 [Note] Plugin group_replication reported: 'Added automatically \\
IP ranges 10.120.40.237/18,10.178.59.44/22,127.0.0.1/8 to the whitelist'
You can improve the security of the group further by manually setting the list of IP addresses permitted for
group communication connections to come from. The list can be specified in CIDR notation or as simple IP
addresses. A comma must separate each entry. For example:
mysql> STOP GROUP_REPLICATION;
mysql> SET GLOBAL group_replication_ip_whitelist="10.120.40.237/18,10.178.59.44/22,127.0.0.1/8";
mysql> START GROUP_REPLICATION;
##############
Configuring SSL for Recovery
Recovery is performed through a regular asynchronous replication connection. Once the donor is selected,
the joiner establishes an asynchronous replication connection. This is all automatic.
However, a user that requires an SSL connection must have been created before the joiner connects to the
donor. Typically, this is set up at the time one is provisioning a server to join the group.
donor> SET SQL_LOG_BIN=0;
donor> CREATE USER 'rec_ssl_user'@'%' REQUIRE SSL;
donor> GRANT replication slave ON *.* TO 'rec_ssl_user'@'%';
donor> SET SQL_LOG_BIN=1;
Assuming that all servers already in the group have a replication user set up to use SSL, you configure the
joiner to use those credentials when connecting to the donor. That is done according to the values of the
SSL options provided for the Group Replication plugin.
new_member> SET GLOBAL group_replication_recovery_use_ssl=1;
new_member> SET GLOBAL group_replication_recovery_ssl_ca= '.../cacert.pem';
new_member> SET GLOBAL group_replication_recovery_ssl_cert= '.../client-cert.pem';
new_member> SET GLOBAL group_replication_recovery_ssl_key= '.../client-key.pem';
And by configuring the recovery channel to use the credentials of the user that requires an SSL
connection.
new_member> CHANGE MASTER TO MASTER_USER="rec_ssl_user" FOR CHANNEL "group_replication_recovery";
new_member> START GROUP_REPLICATION;
Table 18.6 SSL Options
Server Configuration Plugin Configuration Description
ssl_key Path of key file. To be used as client and server certificate.
ssl_cert Path of certificate file. To be used as client and server
certificate.
ssl_ca Path of file with SSL CAs that are trusted.
ssl_capath Path of directory containing certificates for SSL CAs that
are trusted.
ssl_crl Path of file containing the certificate revocation lists.
ssl_crlpath Path of directory containing revoked certificate lists files.
ssl_cipher Permitted ciphers to use while encrypting data over the
connection.
tls_version Secure communication will use this version and its
protocols
• group_replication_ssl_mode - specifies the security state of the connection between Group
Replication members
Table 18.7 group_replication_ssl_mode configuration values
Value Description
DISABLED Establish an unencrypted connection (default).
REQUIRED Establish a secure connection if the server supports secure connections.
VERIFY_CA Like REQUIRED, but additionally verify the server TLS certificate against the configured Certificate Authority (CA)
certificates.
VERIFY_IDENTITY Like VERIFY_CA, but additionally verify that the server certificate matches the host to which the connection is
attempted.
[mysqld]
ssl_ca = "cacert.pem"
ssl_capath = "/.../ca_directory"
ssl_cert = "server-cert.pem"
ssl_cipher = "DHE-RSA-AEs256-SHA"
ssl_crl = "crl-server-revoked.crl"
ssl_crlpath = "/.../crl_directory"
ssl_key = "server-key.pem"
group_replication_ssl_mode= REQUIRED
########################
18.7 Requirements and Limitations
要求和限制
Infrastructure
基础设施
• InnoDB Storage Engine. Data must be stored in the InnoDB transactional storage engine.
innodb 存储引擎
• Primary Keys. Every table that is to be replicated by the group must have an explicit primary key
defined. Primary keys play an extremely important role in determining which transactions conflict by
identifying exactly which rows each transaction has modified.
每张表必须有主键，主键再全局事务中在冲突作用中，起着关键左右。
• IPv4 Network. The group communication engine used by MySQL Group Replication only supports
IPv4. Therefore, Group Replication requires an IPv4 network infrastructure.
只支持 IPv4
• Network Performance. Group Replication is designed to be deployed in a cluster environment
where server instances are very close to each other, and is impacted by both network latency as well as
network bandwidth
必须确保网络性能,这对网络实时性要求比较高，所以对于异地延时很大得网络环境，最好要放弃使用此MGR。
####
Server Instance Configuration
MySQL参数基本配置要求：
• Binary Log Active. Set --log-bin[=log_file_name].
• Slave Updates Logged. Set --log-slave-updates.
• Binary Log Row Format. Set --binlog-format=row
• Global Transaction Identifiers On. Set --gtid-mode=ON
• Replication Information Repositories. Set --master-info-repository=TABLE
and --relay-log-info-repository=TABLE. The replication applier needs to have the
master information and relay log metadata written to the mysql.slave_master_info and
mysql.slave_relay_log_info system tables. This ensures the Group Replication plugin
has consistent recoverability and transactional management of the replication metadata.
• Transaction Write Set Extraction. Set --transaction-write-set-extraction=XXHASH64 so
that while collecting rows to log them to the binary log, the server collects the write set as well. The write
set is based on the primary keys of each row and is a simplified and compact view of a tag that uniquely
identifies the row that was changed. This tag is then used for detecting conflicts.
####
18.7.2 Limitations
MGR 约束条件：
• Replication Event Checksums. Due to a design limitation of replication event checksums, Group
Replication cannot currently make use of them. Therefore set --binlog-checksum=NONE.
• Gap Locks. The certification process does not take into account gap locks, as information about gap
locks is not available outside of InnoDB. See Gap Locks for more information.
Note
Unless you rely on REPEATABLE READ semantics in your applications, we
recommend using the READ COMMITTED isolation level with Group Replication.
InnoDB does not use gap locks in READ COMMITTED, which aligns the local
conflict detection within InnoDB with the distributed conflict detection performed
by Group Replication
• Table Locks and Named Locks. The certification process does not take into account table
locks
• Savepoints Not Supported. Transaction savepoints are not supported.
不支持检查点。
#####注意：
1， mgr 得端口必须和 MySQL对外提供服务得端口不一样。
2，第一次部署，需要设置参数
group_replication_bootstrap_group on 后 启动 mgr ,然后此参数 为off.
(
important :
Unlike the previous steps that were the same as those executed on s1, here there is a difference in that
you do not issue SET GLOBAL group_replication_bootstrap_group=ON; before starting Group
Replication, because the group has already been created and bootstrapped by server s1. At this point
server s2 only needs to be added to the already existing group.
)
3, 因mgr 限制问题，涉及得一些语法将不被支持，包括mysqldump 一般得写法。
4，无非必要，推荐使用single 模式，而非multi 模式。