MGR MYSQL 的问题 mysql mgr配置

一、MGR的要求

① mysql组复制是mysql5.7.16以后的版本才支持的，小于5.7.17版本的请升级

② InnoDB 存储引擎

数据库非系统表的必须是innoDB存储引擎，可以设置

disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"

② 主键

组要复制的每个表都必须具有定义的主键，或等效的主键，其中等效键是非空唯一键。这些键需要作为表中每一行的唯一标识符，使系统能够通过准确识别每个事务修改了哪些行来确定哪些事务发生冲突。

③ IPv4(mysql8.0好像支持IPv6了)和网络性能要好

④ 隔离级别：官网建议READ COMMITTED级别，不支持SERIALIZABLE隔离级别；
不建议使用级联外键；

二、 MGR单主模式开始搭建

①准备工作

主机
192.168.88.128	master
192.168.88.130	slave
192.168.88131	slave

 三台主机的mysql都已经安装完毕，安装细节略过。

② 主机192.168.88.128配置

vim /etc/my.cnf

server_id=129 #唯一的服务器标识符
gtid_mode=ON #开启二进制
enforce_gtid_consistency=ON ##开启GTID
master_info_repository=TABLE ## mysql.slave_master_info
relay_log_info_repository=TABLE ##  relay日志写入mysql.slave_relay_log_info表中 Group Replication 插件对复制元数据具有一致的可恢复性和事务管理
binlog_checksum=NONE ##二进制日志校验和关闭
log_slave_updates=ON ##备机中的二进制日志也写入
log_bin=binlog ##开启二进制
binlog_format=ROW ##二进制的日志格式

 mysql.slave_master_info表 用于保存从库的IO线程连接主库的连接状态、帐号、IP、端口、密码以及IO线程当前读取主库binlog的file和position等信息（被称为IO线程信息日志）

mysql.slave_relay_log_info表 从库的IO线程会把最近的master的二进制日志写入到relay（中继日志）中，sql线程读取relay日志并重放

plugin_load_add='group_replication.so' ##加载群复制的插件
transaction_write_set_extraction=XXHASH64 ##识与事务关联的写入的哈希的算法设置 XXHASH64为以避免不必要的哈希冲突，从而导致认证失败和用户事务回滚
group_replication_group_name="1c4e283e-b727-11ec-b473-00163e350e12" ##组复制的名称
group_replication_start_on_boot=off ##表示mysql启动时，插件不需要自动启动，我们这里都设置OFF，然后在进入mysql后手动启动
group_replication_local_address= "192.168.88.128:10061" #本机的ip地址
group_replication_group_seeds= "192.168.88.128:10061,192.168.88.130:10061,192.168.88.131:10061" ##组里面的ip
group_replication_bootstrap_group=off ##MGR插件是否引导该组，我们这里都设置OFF，然后在进入mysql后手动启动

③ 配置用户凭证

也就是创建复制的用户,MGR是依赖于group_replication_recovery复制通道进行通讯的。

为了避免创建用户也写入二进制中，所以需要先关闭二进制

##创建用户
SET SQL_LOG_BIN=0;
CREATE USER mgr_user@'%' IDENTIFIED BY '123456';
GRANT REPLICATION SLAVE ON *.* TO mgr_user@'%';
FLUSH PRIVILEGES;
SET SQL_LOG_BIN=1;

CHANGE MASTER TO MASTER_USER='mgr_user', MASTER_PASSWORD='123456' FOR CHANNEL 'group_replication_recovery';

④ 启动组

首次启动组的过程称为引导，使用group_replication_bootstrap_group来引导

mysql> SET GLOBAL group_replication_bootstrap_group=ON;
mysql> START GROUP_REPLICATION;
mysql> SET GLOBAL group_replication_bootstrap_group=OFF;

引导只能由单个服务器完成，即启动组的服务器并且只执行一次。这就是为什么group_replication_bootstrap_group选项的值没有存储在实例的选项文件中的原因。如果它保存在选项文件中，则在重新启动服务器时会自动引导第二个具有相同名称的组。这将导致两个不同的组具有相同的名称

可以检查该组现在是否已创建并且其中有一个成员

select * from performance_schema.replication_group_members;

 ⑤ 把slave主机添加到群组中

A) 192.168.88.130 配置

### MGR配置
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
server_id = 130
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

plugin_load_add='group_replication.so'
transaction_write_set_extraction=XXHASH64
group_replication_group_name="1c4e283e-b727-11ec-b473-00163e350e12"
group_replication_start_on_boot=off
group_replication_local_address= "192.168.88.130:33061"
group_replication_group_seeds= "192.168.88.130:33061,192.168.88.131:33061,192.168.88.128:33061"
group_replication_bootstrap_group=off

只用更新下面两个参数

server_id = 130

group_replication_local_address= "192.168.88.130:33061"

B) 进入mysql执行下面的

SET SQL_LOG_BIN=0;
CREATE USER mgr_user@'%' IDENTIFIED BY '123456';
GRANT REPLICATION SLAVE ON *.* TO mgr_user@'%';
SET SQL_LOG_BIN=1;
CHANGE MASTER TO MASTER_USER='mgr_user', MASTER_PASSWORD='123456' FOR CHANNEL 'group_replication_recovery';

 C) 启动 Group Replication 和 s2 启动加入组的过程。

这里不需要执行SET GLOBAL group_replication_bootstrap_group=ON;来引导组，因为组已经创建，直接假如组即可

START GROUP_REPLICATION;

D) 在master主机查看组成员

select * from performance_schema.replication_group_members;

 F) 查看组成员

select * from performance_schema.replication_group_members;

里面的的状态 member_state 如果都是ONLINE，则表示都是在线的，但是上面出现了recovering则表示我们的这个组员有问题，需要看mysql的日志。

出现了 Slave I/O for channel 'group_replication_recovery': error connecting to master 'test@master-129:3306' - retry-time: 60  retries: 1, Error_code: 1045

 这种错误表示我们的账户没有配置成功，则需要重新执行下面的账户和change master

SET SQL_LOG_BIN=0;
CREATE USER mgr_user@'%' IDENTIFIED BY '123456';
GRANT REPLICATION SLAVE ON *.* TO mgr_user@'%';
SET SQL_LOG_BIN=1;
CHANGE MASTER TO MASTER_USER='mgr_user', MASTER_PASSWORD='123456' FOR CHANNEL 'group_replication_recovery';

 然后在start group_replication操作。

如果上面还是报Slave I/O for channel 'group_replication_recovery'错误，则需要在slave机上面配置hosts;

vim /etc/hosts 

 因为mysql上面的请求是用host去请求的，如果没有配置hosts就解析不了ip,上面的ip是master主机和master主机的hostname

G) 192.168.88.131 配置跟130的一样配置 然后状态都是ONLINE即可

⑥  通过主机master操作数据库，查看从机是否正常复制

⑦ 从机全部自动super_read_only = ON, 只能是只读状态

⑧ 单主模式的高可用

A)当我们的192.168.88.128主机执行

service mysqld stop

这时从机会选举会选择新的主机，会通过 group_replication_member_weight 权重高的则为新的主机。如果没有配置group_replication_member_weight，则服务器将根据它们 server_uuid的字典顺序并通过选择第一个来确定优先级。选出新的主节点后，它会自动设置为读写，其他从节点保持为从节点，因此是只读的。当一个新的主节点被选举出来时，它只有在处理完所有来自旧主节点的事务后才可写。这避免了来自旧主节点的旧事务与在该成员上执行的新事务之间可能出现的并发问题。

B) 后期192.168.88.128主机的处理

CHANGE MASTER TO MASTER_USER='mgr_user', MASTER_PASSWORD='123456' FOR CHANNEL 'group_replication_recovery';
start group_replication; ##重新启动群组

这时，master主机则为130,原master主机128则成为从机。

三、多主模式

多主模式每台主机都配置下面的参数即可 

# 关闭单主模式
group_replication_single_primary_mode = off

# 为各处的多主更新启用或禁用严格的一致性检查。默认是禁用检查。在单主模式下，必须在所有组成员上禁用此选项。在多主模式下，启用此选项时，会检查以下语句以确保它们与多主模式兼容
group_replication_enforce_update_everywhere_checks = on

四、 查看group replication相关的表  

① performance_schema.replication_group_members

该表用于监控在当前视图中的不同server实例的状态，换句话说，是该组的一部分，用于组员服务追踪 

② performance_schema.replication_group_member_stats

channel_name：group replication架构中复制通道的名称“group_replication_applier”
view_id:组成员所在组的视图唯一标识符
member_id:组成员的server uuid,mysql实例启动后生成的唯一标识
count_transactions_in_queue:当前队列中等待冲突检查的事务数量，冲突检测通过后，他们将进行应用
count_transactions_checked:当前已通过检查的事务数量，从启动group replication后计算
count_conflicts_detected:当前未通过检测机制的事务数
count_transactions_rows_validating:当前certification_info里面有多少条记录
transactions_committed_all_members:所有成员已提交的事务集合
last_conflict_free_transaction:最后一次提交事务集合

该表提供与认证过程相关的信息，对于了解申请队列增长情况，出发了多少冲突，检查了多少事务，哪些事务已被所有成员提交等等非常有用 

③ performance_schema.replication_connection_status

channel_name：group replication 组内通道名称
group_name:group replication 的名称
source_uuid:group replication的源uuid
thread_id:连接group replication的进程id
service_state:通道的状态
count_received_heartbeats:组内通道接收到的心跳信号次数
last_heartbeat_timestamp:最近一次接收到心跳信号的时间
received_transaction_set:组内全局事务id的集合
last_error_number:组内最后异常的编号
last_error_message:组内最后异常的信息
last_error_timestamp:组内最后异常的时间

连接到组时，此表中的某些字段显示有关组复制的信息。例如，已从组中接收并在应用队列（中继日志）中排队的事务

④ performance_schema.replication_applier_status

可以使用常规replication_applier_status表观察组复制相关的通道和线程的状态。如果有许多不同的工作线程在应用事务，那么工作表也可以用来监控每个工作线程正在做什么。 

CHANNEL_NAME
此行显示的复制通道。总是有一个默认的复制通道，并且可以添加更多的复制通道
SERVICE_STATE
显示ON复制通道的应用程序线程何时处于活动或空闲状态，OFF 表示应用程序线程未处于活动状态。
REMAINING_DELAY
如果副本在源应用事件后等待 DESIRED_DELAY秒数过去，则此字段包含剩余的延迟秒数。在其他时候，这个字段是 NULL。（ DESIRED_DELAY值存储在 replication_applier_configuration 表中。）
COUNT_TRANSACTIONS_RETRIES
显示由于复制 SQL 线程未能应用事务而进行的重试次数。给定事务的最大重试次数由 slave_transaction_retries 系统变量设置。

五、重新重启组

group replication重启比较麻烦，因为同时重启并不知道那个主机的最后还执行了事务。

所以必须把GTID值最大的mysql主机来引导组，其他的主机在加入组即可。

①  stop group_replication 

如果是单例模式，肯定是先把从机都执行 stop group_replication,然后在主机master执行stop group_replication

② 关机mysql

③ 启动mysql

④ 查看GTID最大值的mysql

SELECT @@GLOBAL.GTID_EXECUTED

⑤ 使用具有最大事务集的成员来引导组

mysql> SET GLOBAL group_replication_bootstrap_group=ON;
mysql> START GROUP_REPLICATION;
mysql> SET GLOBAL group_replication_bootstrap_group=OFF;

 ⑥ 其他主机执行

START GROUP_REPLICATION;

六、性能参数

mysql> set global slave_parallel_type='LOGICAL_CLOCK';

mysql> set global slave_parallel_workers=4;

②在多主的模式下：如果多个节点同时写的话，每个节点都会判断其中的事务是否被执行，推荐每个节点写不同的数据库，例如节点1写A数据库，节点2写B数据库，这样集群的写入性能就会提高 

 ③ 通过设置自增值和步长来解决自增的性能问题

group_replication_auto_increment_increment = 7

推荐一般核心业务表都使用uuid来做主键

七、 MGR的缺点

①仅仅支持Innodb存储引擎，且每张表需要有主键

②一个MGR的集群，最多支持9个节点

③有一个节点的网络不稳定，出现抖动，会影响集群的性能，所以在确定使用MGR架构，必须要保证每个节点之间的网络质量。