mgr搭建及官方文档详解

使用场景及限制

限制：比如写集合冲突问题，必须要求有主键，只支持innodb，不支持外键、save point等，还有集群的强一致导致对网络的要求较高，如果遇到网络波动，对集群的影响较大。最大9个节点

使用场景：强一致性

 

 

事务

1.当一个事务准备在事务所在的server提交的时候，此server会原子性的广播此事务所修改的值及所在行的标识到所有server；所有server会对提交的事务顺序达成一个共识（consensus）；当不同server并发对某一行数据进行变更时，有可能会产生冲突，certification进程会对冲突进行检测并处理，处理的规则是：提交第一个事务，回滚第二个事务；

2.当在certify阶段后应用日志的阶段，group replication允许破坏certify进程达成的commit顺序，只要不破坏数据的一致性及有效性

 

 

单主与多主模式

单主模式：group_replication_single_primary_mode = on,其他加入到集群的节点super_read_only参数默认会被设置为on，group_replication_enforce_update_everywhere_checks是强一致性检查的开关，单主模式或者想切换为单主模式的时候，必须关掉此参数

选举：1.版本（考虑到兼容性的问题，最低版本被选举为主节点），2. group_replication_member_weight（权重，0-100，默认为50）,3.最小server_uuid

多主模式：不支持外键和SERIALIZABLE 隔离级别 ，这两个约束的检查由此参数控制group_replication_enforce_update_everywhere_checks，多主模式目前还是支持性不强，因为某一节点的ddl还是会阻塞其他节点的增删改；

 

节点之间的关系

1.组关系服务判定哪些节点是online，哪些节点正在加入集群，这些信息会被维护在一个视图中，每一个节点中都会有一个这样的共同维护的视图，增加和删除节点都会触发视图的变更；当一个节点自主离开组时，需要其他大多数节点达成一致意见变更视图，当节点非自主离开组时，比如机器宕机或者网络中断，则会触发failure detection机制，faliue detection机制会触发视图的变更；当一个组内大部分机器都宕机时，视图的变更就不能得到大部分节点的同意，整个组的状态为了避免脑裂就会处在阻塞状态，这时候需要人工干涉；

2. group_replication_member_expel_timeout 防止被怀疑是失败的成员，被提出集群前延长等待的时间

 

failure detection

节点间传递信息没有得到答复，节点则会被怀疑为dead，当一个节点被其他节点怀疑为dead，此时此节点不能执行任何事务

group_replication_member_expel_timeout:设置从创建怀疑(在最初的5秒检测周期之后发生)到驱逐成员之间的时间。可以设置最多1小时的等待时间。

group_replication_autorejoin_tries 使成员在被移出或无法到达的超时之后尝试重新加入群组。该成员每隔5分钟进行指定数量的自动重新联接尝试。

 

fault tolerance

 

 

 

单主模式的搭建

1.参数修改
server-id=1
gtid_mode=ON
enforce_gtid_consistency=ON
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= “192.168.44.130:33061”
loose-group_replication_group_seeds= “192.168.44.130:33061,192.168.44.131:33061,192.168.44.132:33061”
loose-group_replication_bootstrap_group=OFF
report_host=192.168.44.130
report_port=3306
binlog_checksum=NONE
log_slave_updates=ON
master_info_repository=TABLE
relay_log_info_repository=TABLE
 
2.初始化数据库
/soft/mysql/mysql/bin/mysqld –defaults-file=/soft/mysql/mgr/mgr.cnf –initialize-insecure –user=mysql –basedir=/soft/mysql/mysql –datadir=/soft/mysql/mgr/data
 
3.启动数据库
/soft/mysql/mysql/bin/mysqld_safe –defaults-file=/soft/mysql/mgr/my.cnf 2>&1 > /dev/null &
 
4.密码修改
ALTER USER \’root\’@\’localhost\’ IDENTIFIED WITH mysql_native_password BY \’123456\’;
create user \’root\’@\’%\’ identified by \’123456\’;
create user \’repl\’@\’%\’ identified by \’123456\’;
grant all privileges on *.* to \’root\’@\’localhost\’ ;
grant all privileges on *.* to \’root\’@\’%\’ ;
grant all privileges on *.* to \’repl\’@\’%\’ ;
 
5.安装插件
INSTALL PLUGIN group_replication SONAME \’group_replication.so\’;
CHANGE MASTER TO MASTER_USER=\’root\’, MASTER_PASSWORD=\’123456\’ FOR CHANNEL \’group_replication_recovery\’;
 
6./etc/hosts必须设置
 
7.主节点
SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;
 
组复制的监控
1.select * from performance_schema.replication_group_member_stats\G;

 

2.select * from performance_schema.replication_group_members\G;

3. select * from performance_schema.replication_connection_status\G;

 

 

 4. select * from performance_schema.replication_applier_status\G;

 

一致性

 主节点宕机：8.0.14之前，主节点宕机后会立马选举一个新的节点作为主节点，程序端则可以立马对新节点进行读写，即使新的主节点并没有追平数据，这样就可能会读到不一致的数据；8.0.14之后，可以有另一种选择，复制组不提供写服务直到新的节点完全应用旧主节点的日志，由参数group_replication_consistency控制（eventual,before,after,before and after,before_on_primary_failover）

 

distributed  recovery
group添加新节点
1.新节点reset master；
2.初始化数据：
/soft/mysql/mysql/bin/mysqldump -uroot -h192.168.44.130 -p123456 –opt –max_allowed_packet=256M –flush-logs –master-data=2 –single-transaction –net_buffer_length=8M –compress –databases duan >./duan.sql
不用加 –set-gtid-purged=off，保证能生成如图的set gtid_purged语句

3.新库导入数据

4.CHANGE MASTER TO MASTER_USER=\’root\’, MASTER_PASSWORD=\’123456\’ FOR CHANNEL \’group_replication_recovery\’;

5.start group_replication;

 

flow control

组复制要求事务在大部分节点接收并对并发事务的顺序达成一致意见后才可以提交，正常情况下是可以实现的，但假设有一些性能较差的节点，这些节点将会和写节点有较大的差距。

group_replication_flow_control_certifier_threshold

group_replication_flow_control_applier_threshold

 group_replication_flow_control_mode=QUOTA （disabled）

这两个参数默认为25000，当超过这个阈值时，将会触发流控，限制主节点的写入速度。开启流控后，MGR的写入能力由集群中性能最低的节点决定。

 

messages compression and messages fragmentation

STOP GROUP_REPLICATION;

SET GLOBAL group_replication_compression_threshold = 2097152;

START GROUP_REPLICATION;

此参数默认为1000000，可以调整为2m，表示当消息大小超过2m时，则压缩消息 

 

STOP GROUP_REPLICATION;

SET GLOBAL group_replication_communication_max_message_size= 5242880;

START GROUP_REPLICATION;

 

 

 
 
 
 
 

 

 

 

版权声明：本文为duanzexun原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://www.cnblogs.com/duanzexun/p/14464829.html