MySQL Group Replication-MGR集群
简介html
MySQL Group Replication（简称MGR）字面意思是mysql组复制的意思,但其实他是一个高可用的集群架构,暂时只支持mysql5.7和mysql8.0版本.node
是MySQL官方于2016年12月推出的一个全新的高可用与高扩展的解决方案,提供了高可用、高扩展、高可靠的MySQL集群服务.mysql
也是mysql官方基于组复制概念并充分参考MariaDB Galera Cluster和Percona XtraDB Cluster结合而来的新的高可用集群架构.linux
MySQL Group Replication是创建在基于Paxos的XCom之上的，正由于有了XCom基础设施，保证数据库状态机在节点间的事务一致性，才能在理论和实践中保证数据库系统在不一样节点间的事务一致性。算法
由通常主从复制概念扩展,多个节点共同组成一个数据库集群，事务的提交必须通过半数以上节点赞成方可提交,在集群中每一个节点上都维护一个数据库状态机，保证节点间事务的一致性。sql
组复制的特色：数据库
● 高一致性bootstrap
基于原生复制及 paxos 协议的组复制技术，并以插件的方式提供，提供一致数据安全保证；ubuntu
● 高容错性vim
只要不是大多数节点坏掉就能够继续工做，有自动检测机制，当不一样节点产生资源争用冲突时，不会出现错误，按照先到者优先原则进行处理，而且内置了自动化脑裂防御机制；
● 高扩展性
节点的新增和移除都是自动的，新节点加入后，会自动从其余节点上同步状态，直到新节点和其余节点保持一致，若是某节点被移除了，其余节点自动更新组信息，自动维护新的组信息；
● 高灵活性
有单主模式和多主模式，单主模式下，会自动选主，全部更新操做都在主上进行；
多主模式下，全部 server 均可以同时处理更新操做。
优势:
高一致性，基于原生复制及paxos协议的组复制技术.
高容错性，有自动检测机制，当出现宕机后,会自动剔除问题节点,其余节点能够正常使用(相似zk集群),当不一样节点产生资源争用冲突时,会按照先到先得处理,而且内置了自动化脑裂防御机制.
高扩展性，可随时在线新增和移除节点,会自动同步全部节点上状态，直到新节点和其余节点保持一致，自动维护新的组信息.
高灵活性，直接插件形式安装(5.7.17后自带.so插件),有单主模式和多主模式，单主模式下，只有主库能够读写,其余从库会加上super_read_only状态,只能读取不可写入,出现故障会自动选主.
缺点:
仍是太新,不太稳定,暂时性能还略差于PXC,对网络稳定性要求很高,至少是同机房作.
应用场景：
一、弹性的数据库复制环境
组复制能够灵活的增长和减小集群中的数据库实例
二、高可用的数据库环境
组复制容许数据库实例宕机，只要集群中大多数服务器可用，则整个数据库服务可用
三、替代传统主从复制结构的数据库环境
组复制的有哪些先决条件：
一、只支持innodb存储引擎
二、每张表都须要有主键
三、只支持ipv4网络环境
四、要求高网络带宽(一般是千兆内网)和低网络延迟
组复制有哪些限制条件？
一、Replication Event Checksums
因为代码设计的缘由，目前组复制还不能支持binlog的checksum,若是要使用组复制，须要配置binlog-checksum=none
二、Gap Locks
组复制校验的进程不支持间隙锁，mysql间隙锁的设计是为了解决幻读问题
三、Table Locks and Named Locks
组复制校验的进程不支持表级锁和named locks
四、SERIALIZABLE Isolation Level
组复制不支持串行事务级别
五、Concurrent DDL versus DML Operations
组复制的多主模式不支持并行的DDL和DML操做
六、Foreign Keys with Cascading Constraints
组复制的多主模式不支持带有级联约束类型的外键
七、Very Large Transactions
组复制不支持巨大的事务
组复制协议：
MGR使用paxos算法来解决一致性的问题，本身的理解：
好比一场法庭审判：
底下的人都是提议者，能够提出本身的意见和建议，可是，最后作出决定的是法官，这个法官能够是一个或者多个。
提出提议的众人争先和法官联系。每个提议者都会提出一个意见，这个意见会生成一个惟一的ID。若是有一个提议者和大多数法官（半数以上）取得的联系，那么这个提议就会被接受
法官就会记录这个提议生成的惟一ID，和上一个ID进行对比，若是如今的这个ID大于旧ID，那么这个意见就会被接收，而后法官们一块儿决定这个意见，以少数服从多数的方式决定。
若是这个ID小于或者等于旧ID，那么法官就会拒绝这个提议，拒绝后，提议者会将这个ID号增长，而后继续向法官提出提议，直到被接受。
在同一时间，只有一个提议能被接受。
MGR冲突检测
MGR多主模式下，一个事务在执行时，并不会作前置的检查，可是在提交阶段，会和其余节点通讯对该事务是否可以提交达成一个决议。在多个节点同对相同记录的修改，在提交时会进行冲突检测，首先提交的事务将得到优先权。例如对同一条记录的修改，t1事务先于t2事务，那么t1事务在冲突检测后得到执行权，顺利提交，而t2事务进行回滚。显然这种多点写入条件下，对于同一条记录的并发修改，因为大量的回滚，致使性能很低，所以MySQL官方建议，这种对于同一条记录的修改，应该放在同一个节点执行，这样能够利用节点本地锁来进行同步等待，减小事务回滚，提升性能。
MGR新节点加入过程
MGR中，新节点申请加入组，会在组中生成一个View_change事件，组内全部online节点将该事件写入到binlog，同时，申请加入组的新节点也会记录这个View_change事件，以后，该节点会进入下面两个阶段。
- 第一阶段，新节点会从组内online的节点中选择一个做为贡献者(donor)，经过标准的异步复制通道，拉取贡献者的binlog，并应用这些binlog。与此同时，新节点也会获取当前组内正在交换的事务信息，并将其缓存到队列中，当binlog应用完成，也就是应用到View_change事件处，异步复制通道关闭，进入第二阶段。
- 第二阶段，新节点处理缓存在队列中的组内事务信息，当队列中的事务信息处理完成，即缓存队列长度为0时，新节点在组内状态变为online。
在第一阶段，遇到任何错误，新节点会自动从组内选择另一个online节点做为贡献者，若是仍然遇到异常，会继续选择其余online节点，直到全部online节点枚举完毕，若是这时仍然报错，会sleep一段时间以后，再次重试，sleep时间和重试次数经过相应参数来控制。
第一阶段，应用binlog的开始点由新节点的gtid_executed决定，结束点由View_change事件决定。MGR新节点加入组的第一阶段，因为使用传统的异步binlog数据同步，若是新加入的节点使用较早的备份，可能出现binlog接不上的状况，新节点一直处于RECOVERING状态，在通过必定时间间隔和必定次数的重试后，恢复失败，新节点从组中退出。另一种状况，binlog可以接上，可是binlog太多，致使应用binlog时间太长，同时第二阶段缓存队列也可能变得很大，整个恢复过程也将花费太长的时间。因些建议新节点加入组时，使用最近、最新的一次完整备份数据做为基础。
安装
1.服务环境设定规划
| ip地址 |
mysql版本 | 数据库端口号 | Server-ID | MGR端口号 | 操做系统 |
| 192.168.202.174 | mysql 5.7.25 | 3306 | 174 | 24901 | CentOS 7.5 |
| 192.168.202.175 | mysql 5.7.25 | 3306 | 175 | 24901 | CentOS 7.5 |
| 192.168.202.176 | mysql 5.7.25 | 3306 | 176 | 24901 | CentOS 7.5 |
多主模式下最好有三台以上的节点,单主模式则视实际状况而定,不过同个Group最多节点数为9.服务器配置尽可能保持一致,由于和PXC同样,也会有"木桶短板效应".
须要特别注意,mysql数据库的服务端口号和MGR的服务端口不是一回事,须要区分开来.
而server-id要区分开来是必须的,单纯作主从复制也要知足这一点了.
2.配置服务器
关闭selinux
vim /etc/selinux/config
SELINUX=disabled
vim /etc/hosts
192.168.202.174 node1
192.168.202.175 node2
192.168.202.176 node3
开放防火墙端口：
firewall-cmd --zone=public --add-port=3306/tcp --permanent
firewall-cmd --zone=public --add-port=24901/tcp --permanent
firewall-cmd --reload
firewall-cmd --zone=public --list-ports
3.安装部署
怎么安装mysql 5.7.25 参考 http://www.javashuo.com/article/p-ywmwsbmw-k.html
直接就说怎么安装MGR了,上面也说了,MGR在mysql5.7.17版本以后就都是自带插件了,只是没有安装上而已,和半同步插件一个套路,因此默认是没有选项.
全部集群内的服务器都必须安装MGR插件才能正常使用该功能.
咱们能够看到,一开始是没有装的
(root@localhost) 11:42:26 [(none)]> show plugins; +----------------------------+----------+--------------------+---------+---------+ | Name | Status | Type | Library | License | +----------------------------+----------+--------------------+---------+---------+ | binlog | ACTIVE | STORAGE ENGINE | NULL | GPL | | mysql_native_password | ACTIVE | AUTHENTICATION | NULL | GPL | | sha256_password | ACTIVE | AUTHENTICATION | NULL | GPL | | InnoDB | ACTIVE | STORAGE ENGINE | NULL | GPL | | INNODB_TRX | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_LOCKS | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_LOCK_WAITS | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_CMP | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_CMP_RESET | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_CMPMEM | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_CMPMEM_RESET | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_CMP_PER_INDEX | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_CMP_PER_INDEX_RESET | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_BUFFER_PAGE | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_BUFFER_PAGE_LRU | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_BUFFER_POOL_STATS | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_TEMP_TABLE_INFO | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_METRICS | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_FT_DEFAULT_STOPWORD | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_FT_DELETED | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_FT_BEING_DELETED | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_FT_CONFIG | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_FT_INDEX_CACHE | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_FT_INDEX_TABLE | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_SYS_TABLES | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_SYS_TABLESTATS | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_SYS_INDEXES | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_SYS_COLUMNS | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_SYS_FIELDS | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_SYS_FOREIGN | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_SYS_FOREIGN_COLS | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_SYS_TABLESPACES | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_SYS_DATAFILES | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | INNODB_SYS_VIRTUAL | ACTIVE | INFORMATION SCHEMA | NULL | GPL | | MyISAM | ACTIVE | STORAGE ENGINE | NULL | GPL | | MRG_MYISAM | ACTIVE | STORAGE ENGINE | NULL | GPL | | MEMORY | ACTIVE | STORAGE ENGINE | NULL | GPL | | CSV | ACTIVE | STORAGE ENGINE | NULL | GPL | | PERFORMANCE_SCHEMA | ACTIVE | STORAGE ENGINE | NULL | GPL | | BLACKHOLE | ACTIVE | STORAGE ENGINE | NULL | GPL | | partition | ACTIVE | STORAGE ENGINE | NULL | GPL | | ARCHIVE | ACTIVE | STORAGE ENGINE | NULL | GPL | | FEDERATED | DISABLED | STORAGE ENGINE | NULL | GPL | | ngram | ACTIVE | FTPARSER | NULL | GPL | +----------------------------+----------+--------------------+---------+---------+
MGR相关参数也是没有加载的,只有一个其余相关的参数
(root@localhost) 11:43:27 [(none)]> show variables like 'group%'; +----------------------+-------+ | Variable_name | Value | +----------------------+-------+ | group_concat_max_len | 1024 | +----------------------+-------+ 1 row in set (0.01 sec)
而后,先看看当前插件的目录
(root@localhost) 11:43:49 [(none)]> show variables like 'plugin_dir'; +---------------+------------------------------+ | Variable_name | Value | +---------------+------------------------------+ | plugin_dir | /usr/local/mysql/lib/plugin/ | +---------------+------------------------------+ 1 row in set (0.00 sec)
再搜索一下咱们须要的MGR插件,是否存在
[root@node1 mysqldata]# ll /usr/local/mysql/lib/plugin/ |grep group_replication -rwxr-xr-x. 1 mysql mysql 16393641 Dec 21 19:11 group_replication.so
最后,重新进入mysql服务,进行安装
(root@localhost) 11:45:25 [(none)]> install PLUGIN group_replication SONAME 'group_replication.so'; Query OK, 0 rows affected (0.10 sec)
这个时候,就有了
(root@localhost) 11:45:26 [(none)]> show plugins; +----------------------------+----------+--------------------+----------------------+---------+ | Name | Status | Type | Library | License | +----------------------------+----------+--------------------+----------------------+---------+ | binlog | ACTIVE | STORAGE ENGINE | NULL | GPL | | mysql_native_password | ACTIVE | AUTHENTICATION | NULL | GPL | | sha256_password | ACTIVE | AUTHENTICATION | NULL | GPL | ........ | ARCHIVE | ACTIVE | STORAGE ENGINE | NULL | GPL | | FEDERATED | DISABLED | STORAGE ENGINE | NULL | GPL | | ngram | ACTIVE | FTPARSER | NULL | GPL | | group_replication | ACTIVE | GROUP REPLICATION | group_replication.so | GPL | +----------------------------+----------+--------------------+----------------------+---------+ 45 rows in set (0.00 sec)
再去看MGR相关的参数,就有不少了
(root@localhost) 11:45:47 [(none)]> show variables like 'group%'; +----------------------------------------------------+----------------------+ | Variable_name | Value | +----------------------------------------------------+----------------------+ | group_concat_max_len | 1024 | | group_replication_allow_local_disjoint_gtids_join | OFF | | group_replication_allow_local_lower_version_join | OFF | | group_replication_auto_increment_increment | 7 | | group_replication_bootstrap_group | OFF | | group_replication_components_stop_timeout | 31536000 | | group_replication_compression_threshold | 1000000 | | group_replication_enforce_update_everywhere_checks | OFF | | group_replication_exit_state_action | READ_ONLY | | group_replication_flow_control_applier_threshold | 25000 | | group_replication_flow_control_certifier_threshold | 25000 | | group_replication_flow_control_mode | QUOTA | | group_replication_force_members | | | group_replication_group_name | | | group_replication_group_seeds | | | group_replication_gtid_assignment_block_size | 1000000 | | group_replication_ip_whitelist | AUTOMATIC | | group_replication_local_address | | | group_replication_member_weight | 50 | | group_replication_poll_spin_loops | 0 | | group_replication_recovery_complete_at | TRANSACTIONS_APPLIED | | group_replication_recovery_reconnect_interval | 60 | | group_replication_recovery_retry_count | 10 | | group_replication_recovery_ssl_ca | | | group_replication_recovery_ssl_capath | | | group_replication_recovery_ssl_cert | | | group_replication_recovery_ssl_cipher | | | group_replication_recovery_ssl_crl | | | group_replication_recovery_ssl_crlpath | | | group_replication_recovery_ssl_key | | | group_replication_recovery_ssl_verify_server_cert | OFF | | group_replication_recovery_use_ssl | OFF | | group_replication_single_primary_mode | ON | | group_replication_ssl_mode | DISABLED | | group_replication_start_on_boot | ON | | group_replication_transaction_size_limit | 0 | | group_replication_unreachable_majority_timeout | 0 | +----------------------------------------------------+----------------------+ 37 rows in set (0.01 sec)
上面有些配置是我预先配置好的,后面会详细解析.
4.配置MGR环境
熟悉mysql的人都知道,mysql支持set global的全局在线配置方式,因此并不局限于配置文件,这里直接解析参数和给出命令.
假设咱们先写到配置文件my.cnf:
首先,MGR是必定要用GTID的,因此,GTID就必需要开,这个还真是要重启才能生效,各位要注意这点
#开启GTID,必须开启 gtid_mode=on #强制GTID的一致性 enforce-gtid-consistency=on
而后,列举一些公共参数的修改
#binlog格式,MGR要求必须是ROW,不过就算不是MGR,也最好用row binlog_format=row #server-id必须是惟一的 server-id = 174 #MGR使用乐观锁,因此官网建议隔离级别是RC,减小锁粒度 transaction_isolation = READ-COMMITTED #由于集群会在故障恢复时互相检查binlog的数据, #因此须要记录下集群内其余服务器发过来已经执行过的binlog,按GTID来区分是否执行过. log-slave-updates=1 #binlog校验规则,5.6以后的高版本是CRC32,低版本都是NONE,可是MGR要求使用NONE binlog_checksum=NONE #基于安全的考虑,MGR集群要求复制模式要改为slave记录记录到表中,否则就报错 master_info_repository=TABLE #同上配套 relay_log_info_repository=TABLE slave-parallel-workers=N #并行的SQL线程数量 slave-parallel-type=LOGICAL_CLOCK #基于组提交的并行复制方式 #slave上apply relay-log时事务顺序提交 slave-preserve-commit-order=1 plugin_dir=/usr/local/mysql/lib/plugin #根据实际状况修改 plugin_load = "rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so;group_replication.so" report_host=192.168.202.174 report_port=3306
最后就是MGR自身的独有配置参数了.
#记录事务的算法,官网建议设置该参数使用 XXHASH64 算法 transaction_write_set_extraction = XXHASH64 #至关于此GROUP的名字,是UUID值,不能和集群内其余GTID值的UUID混用,可用uuidgen来生成一个新的, #主要是用来区分整个内网里边的各个不一样的GROUP,并且也是这个group内的GTID值的UUID loose-group_replication_group_name = 'cc5e2627-2285-451f-86e6-0be21581539f' #IP地址白名单,默认只添加127.0.0.1,不会容许来自外部主机的链接,按需安全设置 loose-group_replication_ip_whitelist = '127.0.0.1/8,192.168.202.0/24' #是否随服务器启动而自动启动组复制,不建议直接启动,怕故障恢复时有扰乱数据准确性的特殊状况 loose-group_replication_start_on_boot = OFF #本地MGR的IP地址和端口，host:port,是MGR的端口,不是数据库的端口 loose-group_replication_local_address = '192.168.202.174:24901' #须要接受本MGR实例控制的服务器IP地址和端口,是MGR的端口,不是数据库的端口 loose-group_replication_group_seeds = '192.168.202.174:24901,192.168.202.174:24901,192.168.202.174:24901' #开启引导模式,添加组成员，用于第一次搭建MGR或重建MGR的时候使用,只须要在集群内的其中一台开启, loose-group_replication_bootstrap_group = OFF #是否启动单主模式，若是启动，则本实例是主库，提供读写，其余实例仅提供读,若是为off就是多主模式了 loose-group_replication_single_primary_mode = off #多主模式下,强制检查每个实例是否容许该操做,若是不是多主,能够关闭 loose-group_replication_enforce_update_everywhere_checks = on
重点来解析几个参数:
group_replication_group_name: 这个必须是独立的UUID值,不能和集群里面其余的数据库的GTID的UUID值同样,在linux系统下能够用uuidgen来生成一个新的UUID
group_replication_ip_whitelist: 关于IP白名单来讲,原本是安全设置,若是全内网涵盖是不太适合的,我这样设置只是为了方便,这个参数能够set global动态修改,仍是比较方便的
group_replication_start_on_boot: 不建议随系统启动的缘由有两个,第一个就是怕故障恢复时的极端状况下影响数据准确性,第二个就是怕一些添加或移除节点的操做被这个参数影响到
group_replication_local_address: 特别注意的是这个端口并非数据库服务端口,是MGR的服务端口,并且要保证这个端口没有被使用,是MGR互相通讯使用的端口.
group_replication_group_seeds: 接受本group控制的IP地址和端口号,这个端口也是MGR的服务端口,能够用set global动态修改,用以添加和移动节点.
group_replication_bootstrap_group: 须要特别注意,引导的服务器只须要一台,因此集群内其余服务器都不须要开启这个参数,默认off就行了,有须要再set global来开启就足够了.
group_replication_single_primary_mode: 取决于想用的是多主模式仍是单主模式,若是是单主模式,就相似于半同步复制,可是比半同步要求更高,由于须要集群内过半数的服务器写入成功后,主库才会返回写入成功,数据一致性也更高,一般金融服务也更推荐这种使用方法.若是是多主模式,看上去性能更高,可是事务冲突的概率也更高,虽然MGR内部有先到先得原则,可是这些仍是不能忽略,对于高并发环境,更加多是致命的,因此通常多主模式也是建议分开来使用,一个地址连接一个库,从逻辑操做上区分开来,避免冲突的可能.
group_replication_enforce_update_everywhere_checks: 若是是单主模式,由于不存在多主同时操做的可能,这个强制检查是能够关闭,由于已经不存在这样的操做,多主是必需要开的,不开的话数据就可能出现错乱了.
若是用set global方式动态开启的话就以下了:
set global transaction_write_set_extraction='XXHASH64'; set global group_replication_start_on_boot=OFF; set global group_replication_bootstrap_group = OFF ; set global group_replication_group_name= 'cc5e2627-2285-451f-86e6-0be21581539f'; set global group_replication_local_address='10.0.2.5:33081'; set global group_replication_group_seeds='10.0.2.5:33081,10.0.2.6:33081,10.0.2.7:33081'; set global group_replication_ip_whitelist = '127.0.0.1/8,192.168.1.0/24,10.0.0.1/8,10.18.89.49/22'; set global group_replication_single_primary_mode=off; set global group_replication_enforce_update_everywhere_checks=on;
须要特别注意的是,同一集群group内的数据库服务器的配置,都必须保持一致,否则是会报错的,或者是形成一些奇葩事情.固然了,server-id和本机的IP地址端口要注意区分.
配置好了,就能够准备启动了,可是启动有顺序要求,须要特别注意.
5.启动MGR集群
就如上面说的,启动MGR是要注意顺序的,由于须要有其中一台数据库作引导,其余数据库才能够顺利加入进来.
若是是单主模式,那么主库就必定要先启动并作引导,否则就不是主了.
当出现异常时,应该要去查看mysql报错文件mysql.err,通常都有相应的error日志提示.
好了,转回正题,如今假设用10.0.2.6这台服务器作引导,先登进本地mysql服务端:
SET SQL_LOG_BIN=0; #启动引导,注意,只有这套开启引导,其余两台都请忽略这一步 mysql> SET GLOBAL group_replication_bootstrap_group=ON; #建立一个用户来作同步的用户,并受权,全部集群内的服务器都须要作 mysql> create user 'sroot'@'%' identified by '123123'; mysql> grant REPLICATION SLAVE on *.* to 'sroot'@'%' with grant option; #清空全部旧的GTID信息,避免冲突 mysql> reset master;set sql_log_bin=1; #建立同步规则认证信息,就是刚才受权的那个用户,和通常的主从规则写法不太同样 mysql> CHANGE MASTER TO MASTER_USER='sroot', MASTER_PASSWORD='123123' FOR CHANNEL 'group_replication_recovery'; #启动MGR mysql> start group_replication; #查看是否启动成功,看到online就是成功了 mysql> SELECT * FROM performance_schema.replication_group_members; +---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | +---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+ | group_replication_applier | a29a1b91-4908-11e8-848b-08002778eea7 | ubuntu | 3308 | ONLINE | PRIMARY | 8.0.11 | +---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+ 1 row in set (0.02 sec) #这个时候,就能够先关闭引导了 mysql> SET GLOBAL group_replication_bootstrap_group=OFF;
而后,就到另外两台服务器192.168.202.175和192.168.202.176了,也是要登进本地mysql服务端:
#不须要启动引导了,下面大体是相似的 #用户受权仍是要作的 SET SQL_LOG_BIN=0; mysql> create user 'sroot'@'%' identified by '123123'; mysql> grant REPLICATION SLAVE on *.* to 'sroot'@'%' with grant option; #清空全部旧的GTID信息,避免冲突 mysql> reset master;SET SQL_LOG_BIN=1; #建立同步规则认证信息,就是刚才受权的那个用户,和通常的主从规则写法不太同样 mysql> CHANGE MASTER TO MASTER_USER='sroot', MASTER_PASSWORD='123123' FOR CHANNEL 'group_replication_recovery'; #启动MGR mysql> start group_replication; #查看是否启动成功,看到online就是成功了
(root@localhost) 13:40:12 [(none)]> SELECT * FROM performance_schema.replication_group_members; +---------------------------+--------------------------------------+-------------+-------------+--------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | +---------------------------+--------------------------------------+-------------+-------------+--------------+ | group_replication_applier | dbab147e-5a88-11e9-b9c3-000c297c0a9d | node1 | 3306 | ONLINE | | group_replication_applier | f8d7e601-5a88-11e9-bc6b-000c29f334ce | node2 | 3306 | ONLINE | +---------------------------+--------------------------------------+-------------+-------------+--------------+
如此类推,在192.168.202.176上就应该是下面这样了
(root@localhost) 13:42:04 [(none)]> SELECT * FROM performance_schema.replication_group_members; +---------------------------+--------------------------------------+-------------+-------------+--------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | +---------------------------+--------------------------------------+-------------+-------------+--------------+ | group_replication_applier | 0c22257b-5a89-11e9-bebd-000c29741024 | node3 | 3306 | ONLINE | | group_replication_applier | dbab147e-5a88-11e9-b9c3-000c297c0a9d | node1 | 3306 | ONLINE | | group_replication_applier | f8d7e601-5a88-11e9-bc6b-000c29f334ce | node2 | 3306 | ONLINE | +---------------------------+--------------------------------------+-------------+-------------+--------------+ 3 rows in set (0.00 sec)
看到MEMBER_STATE所有都是online就是成功链接上了,不过若是出现故障,是会被剔除出集群的而且在本机上会显示error,这个时候就须要去看本机的mysql报错文件mysql.err了.
须要注意的是,如今是多主模式,MEMBER_ROLE里显示的都是PRIMARY,若是是单主模式,就会只显示一个PRIMARY,其余是SECONDARY了.
6.使用
在多主模式下,下面这些链接方式都是能直接读写的
mysql -usroot -p123123 -h192.168.202.174 -P3306 mysql -usroot -p123123 -h192.168.202.175 -P3306 mysql -usroot -p123123 -h192.168.202.176 -P3306
怎么操做我就不说了,和之前的mysql同样create,insert,delete同样,你就看到其余服务器也会有数据了.
若是是单主的话,那么就只有PRIMARY状态的主库能够写数据,SECONDARY状态的只能读不能写,例以下面这样
mysql> select * from ttt; +----+--------+ | id | name | +----+--------+ | 1 | ggg | | 2 | ffff | | 3 | hhhhh | | 4 | tyyyyy | | 5 | aaaaaa | +----+--------+ 5 rows in set (0.00 sec) mysql> delete from ttt where id = 5; ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement
这些操做相关就不详细展开了,搭好了就能够慢慢试.
7.管理维护
为了验证我上面说过的东西,先看看当前的GTID和从库状态
#查一下GTID,就是以前设的那个group的uuid mysql> show master status; +------------------+----------+--------------+------------------+---------------------------------------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+---------------------------------------------------+ | mysql-bin.000003 | 4801 | | | cc5e2627-2285-451f-86e6-0be21581539f:1-23:1000003 | +------------------+----------+--------------+------------------+---------------------------------------------------+ 1 row in set (0.00 sec) #再看从库状态,没有数据,由于根本不是主从结构 mysql> show slave status; Empty set (0.00 sec)
上面看到了一条命令,是查当前节点信息的,下面慢慢列举一些经常使用的命令
#查看group内全部成员的节点信息
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | a29a1b91-4908-11e8-848b-08002778eea7 | ubuntu | 3308 | ONLINE | PRIMARY | 8.0.11 |
| group_replication_applier | af892b6e-49ca-11e8-9c9e-080027b04376 | ubuntu | 3308 | ONLINE | SECONDARY | 8.0.11 |
| group_replication_applier | d058176a-51cf-11e8-8c95-080027e7b723 | ubuntu | 3308 | ONLINE | SECONDARY | 8.0.11 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
3 rows in set (0.00 sec)
#查看GROUP中的同步状况,当前复制状态
mysql> select * from performance_schema.replication_group_member_stats\G
*************************** 1. row ***************************
CHANNEL_NAME: group_replication_applier
VIEW_ID: 15258529121778212:5
MEMBER_ID: a29a1b91-4908-11e8-848b-08002778eea7
COUNT_TRANSACTIONS_IN_QUEUE: 0
COUNT_TRANSACTIONS_CHECKED: 9
COUNT_CONFLICTS_DETECTED: 0
COUNT_TRANSACTIONS_ROWS_VALIDATING: 0
TRANSACTIONS_COMMITTED_ALL_MEMBERS: cc5e2627-2285-451f-86e6-0be21581539f:1-23:1000003
LAST_CONFLICT_FREE_TRANSACTION: cc5e2627-2285-451f-86e6-0be21581539f:23
COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE: 0
COUNT_TRANSACTIONS_REMOTE_APPLIED: 3
COUNT_TRANSACTIONS_LOCAL_PROPOSED: 9
COUNT_TRANSACTIONS_LOCAL_ROLLBACK: 0
*************************** 2. row ***************************
CHANNEL_NAME: group_replication_applier
VIEW_ID: 15258529121778212:5
MEMBER_ID: af892b6e-49ca-11e8-9c9e-080027b04376
COUNT_TRANSACTIONS_IN_QUEUE: 0
COUNT_TRANSACTIONS_CHECKED: 9
COUNT_CONFLICTS_DETECTED: 0
COUNT_TRANSACTIONS_ROWS_VALIDATING: 0
TRANSACTIONS_COMMITTED_ALL_MEMBERS: cc5e2627-2285-451f-86e6-0be21581539f:1-23:1000003
LAST_CONFLICT_FREE_TRANSACTION: cc5e2627-2285-451f-86e6-0be21581539f:23
COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE: 0
COUNT_TRANSACTIONS_REMOTE_APPLIED: 10
COUNT_TRANSACTIONS_LOCAL_PROPOSED: 0
COUNT_TRANSACTIONS_LOCAL_ROLLBACK: 0
*************************** 3. row ***************************
CHANNEL_NAME: group_replication_applier
VIEW_ID: 15258529121778212:5
MEMBER_ID: d058176a-51cf-11e8-8c95-080027e7b723
COUNT_TRANSACTIONS_IN_QUEUE: 0
COUNT_TRANSACTIONS_CHECKED: 9
COUNT_CONFLICTS_DETECTED: 0
COUNT_TRANSACTIONS_ROWS_VALIDATING: 0
TRANSACTIONS_COMMITTED_ALL_MEMBERS: cc5e2627-2285-451f-86e6-0be21581539f:1-23:1000003
LAST_CONFLICT_FREE_TRANSACTION: cc5e2627-2285-451f-86e6-0be21581539f:23
COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE: 0
COUNT_TRANSACTIONS_REMOTE_APPLIED: 9
COUNT_TRANSACTIONS_LOCAL_PROPOSED: 0
COUNT_TRANSACTIONS_LOCAL_ROLLBACK: 0
3 rows in set (0.00 sec)
#当前server中各个通道的使用状况，
mysql> select * from performance_schema.replication_connection_status\G
*************************** 1. row ***************************
CHANNEL_NAME: group_replication_applier
GROUP_NAME: cc5e2627-2285-451f-86e6-0be21581539f
SOURCE_UUID: cc5e2627-2285-451f-86e6-0be21581539f
THREAD_ID: NULL
SERVICE_STATE: ON
COUNT_RECEIVED_HEARTBEATS: 0
LAST_HEARTBEAT_TIMESTAMP: 0000-00-00 00:00:00.000000
RECEIVED_TRANSACTION_SET: cc5e2627-2285-451f-86e6-0be21581539f:1-23:1000003
LAST_ERROR_NUMBER: 0
LAST_ERROR_MESSAGE:
LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00.000000
LAST_QUEUED_TRANSACTION: cc5e2627-2285-451f-86e6-0be21581539f:23
LAST_QUEUED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 2018-05-09 16:38:08.035692
LAST_QUEUED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
LAST_QUEUED_TRANSACTION_START_QUEUE_TIMESTAMP: 2018-05-09 16:38:08.031639
LAST_QUEUED_TRANSACTION_END_QUEUE_TIMESTAMP: 2018-05-09 16:38:08.031753
QUEUEING_TRANSACTION:
QUEUEING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
QUEUEING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
QUEUEING_TRANSACTION_START_QUEUE_TIMESTAMP: 0000-00-00 00:00:00.000000
*************************** 2. row ***************************
CHANNEL_NAME: group_replication_recovery
GROUP_NAME:
SOURCE_UUID:
THREAD_ID: NULL
SERVICE_STATE: OFF
COUNT_RECEIVED_HEARTBEATS: 0
LAST_HEARTBEAT_TIMESTAMP: 0000-00-00 00:00:00.000000
RECEIVED_TRANSACTION_SET:
LAST_ERROR_NUMBER: 0
LAST_ERROR_MESSAGE:
LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00.000000
LAST_QUEUED_TRANSACTION:
LAST_QUEUED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
LAST_QUEUED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
LAST_QUEUED_TRANSACTION_START_QUEUE_TIMESTAMP: 0000-00-00 00:00:00.000000
LAST_QUEUED_TRANSACTION_END_QUEUE_TIMESTAMP: 0000-00-00 00:00:00.000000
QUEUEING_TRANSACTION:
QUEUEING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
QUEUEING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
QUEUEING_TRANSACTION_START_QUEUE_TIMESTAMP: 0000-00-00 00:00:00.000000
2 rows in set (0.00 sec)
#当前server中各个通道是否启用,on是启用
mysql> select * from performance_schema.replication_applier_status;
+----------------------------+---------------+-----------------+----------------------------+
| CHANNEL_NAME | SERVICE_STATE | REMAINING_DELAY | COUNT_TRANSACTIONS_RETRIES |
+----------------------------+---------------+-----------------+----------------------------+
| group_replication_applier | ON | NULL | 0 |
| group_replication_recovery | OFF | NULL | 0 |
+----------------------------+---------------+-----------------+----------------------------+
2 rows in set (0.00 sec)
#单主模式下，查看那个是主库,只显示uuid值
mysql> select * from performance_schema.global_status where VARIABLE_NAME='group_replication_primary_member';
+----------------------------------+--------------------------------------+
| VARIABLE_NAME | VARIABLE_VALUE |
+----------------------------------+--------------------------------------+
| group_replication_primary_member | a29a1b91-4908-11e8-848b-08002778eea7 |
+----------------------------------+--------------------------------------+
1 row in set (0.00 sec)
例以下面这个例子
mysql> show global variables like 'server_uuid'; +---------------+--------------------------------------+ | Variable_name | Value | +---------------+--------------------------------------+ | server_uuid | af892b6e-49ca-11e8-9c9e-080027b04376 | +---------------+--------------------------------------+ 1 row in set (0.00 sec) mysql> show global variables like 'super%'; +-----------------+-------+ | Variable_name | Value | +-----------------+-------+ | super_read_only | ON | +-----------------+-------+ 1 row in set (0.00 sec)
好明显,这台不是主库,super_read_only都开启了.
8.切换到多主模式
MGR切换模式须要从新启动组复制，因些须要在全部节点上先关闭组复制，设置 group_replication_single_primary_mode=OFF 等参数，再启动组复制。
# 中止组复制(全部节点执行)： mysql> stop group_replication; mysql> set global group_replication_single_primary_mode=OFF; mysql> set global group_replication_enforce_update_everywhere_checks=ON; # 随便选择某个节点执行 mysql> SET GLOBAL group_replication_bootstrap_group=ON; mysql> START GROUP_REPLICATION; mysql> SET GLOBAL group_replication_bootstrap_group=OFF; # 其余节点执行 mysql> START GROUP_REPLICATION; # 查看组信息，全部节点的 MEMBER_ROLE 都为 PRIMARY mysql> SELECT * FROM performance_schema.replication_group_members; +---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | +---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+ | group_replication_applier | 5254cf46-8415-11e8-af09-fa163eab3dcf | 192.168.56.102 | 3306 | ONLINE | PRIMARY | 8.0.11 | | group_replication_applier | 601a4025-8415-11e8-b2b6-fa163e767b9a | 192.168.56.103 | 3306 | ONLINE | PRIMARY | 8.0.11 | | group_replication_applier | 8cb3f19b-8414-11e8-9d34-fa163eda7360 | 192.168.56.101 | 3306 | ONLINE | PRIMARY | 8.0.11 | +---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+ 3 rows in set (0.00 sec)
能够看到全部节点状态都是online，角色都是PRIMARY，MGR多主模式搭建成功。
切回单主模式
# 全部节点执行 mysql> stop group_replication; mysql> set global group_replication_enforce_update_everywhere_checks=OFF; mysql> set global group_replication_single_primary_mode=ON; # 主节点（192.168.56.101）执行 SET GLOBAL group_replication_bootstrap_group=ON; START GROUP_REPLICATION; SET GLOBAL group_replication_bootstrap_group=OFF; # 从节点（192.168.56.10二、192.168.56.103）执行 START GROUP_REPLICATION; # 查看MGR组信息 mysql> SELECT * FROM performance_schema.replication_group_members; +---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | +---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+ | group_replication_applier | 5254cf46-8415-11e8-af09-fa163eab3dcf | 192.168.56.102 | 3306 | ONLINE | SECONDARY | 8.0.11 | | group_replication_applier | 601a4025-8415-11e8-b2b6-fa163e767b9a | 192.168.56.103 | 3306 | ONLINE | SECONDARY | 8.0.11 | | group_replication_applier | 8cb3f19b-8414-11e8-9d34-fa163eda7360 | 192.168.56.101 | 3306 | ONLINE | PRIMARY | 8.0.11 | +---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+ 3 rows in set (0.00 sec)
9.异常处理：
一、注意:前面的用户密码修改和建立用户操做必须设置binlog不记录，执行后再打开，不然会引发START GROUP_REPLICATION执行报错:
报错信息以下:
ERROR 3092 (HY000): The server is not configured properly to be an active member of the group. Please see more details on error log.1
mysql后台报错信息:
2017-04-17T12:06:55.113724+08:00 0 [ERROR] Plugin group_replication reported: 'This member has more executed transactions than those present in the group. Local transactions: 423ccc44-2318-11
e7-96e9-fa163e6e90d0:1-4 > Group transactions: 7e29f043-2317-11e7-9594-fa163e98778e:1-5,
test-testtest-test-testtesttest:1-6'
2017-04-17T12:06:55.113825+08:00 0 [ERROR] Plugin group_replication reported: 'The member contains transactions not present in the group. The member will now exit the group.'
2017-04-17T12:06:55.113835+08:00 0 [Note] Plugin group_replication reported: 'To force this member into the group you can use the group_replication_allow_local_disjoint_gtids_join option'
2017-04-17T12:06:55.113947+08:00 3 [Note] Plugin group_replication reported: 'Going to wait for view modification'
2017-04-17T12:06:55.114493+08:00 0 [Note] Plugin group_replication reported: 'getstart group_id 4317e324'
2017-04-17T12:07:00.054225+08:00 0 [Note] Plugin group_replication reported: 'state 4330 action xa_terminate'
2017-04-17T12:07:00.056324+08:00 0 [Note] Plugin group_replication reported: 'new state x_start'
2017-04-17T12:07:00.056349+08:00 0 [Note] Plugin group_replication reported: 'state 4257 action xa_exit'
2017-04-17T12:07:00.057272+08:00 0 [Note] Plugin group_replication reported: 'Exiting xcom thread'
2017-04-17T12:07:00.057288+08:00 0 [Note] Plugin group_replication reported: 'new state x_start'
2017-04-17T12:07:05.069548+08:00 3 [Note] Plugin group_replication reported: 'auto_increment_increment is reset to 1'
2017-04-17T12:07:05.069644+08:00 3 [Note] Plugin group_replication reported: 'auto_increment_offset is reset to 1'
2017-04-17T12:07:05.070107+08:00 9 [Note] Error reading relay log event for channel 'group_replication_applier': slave SQL thread was killed
解决方案：
根据提示打开group_replication_allow_local_disjoint_gtids_join选项，mysql命令行执行:
mysql> set global group_replication_allow_local_disjoint_gtids_join=ON;
再次启动组复制
mysql> START GROUP_REPLICATION;
二、连不上master，报错信息以下：
2017-04-17T16:18:14.756191+08:00 25 [Warning] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information.
2017-04-17T16:18:14.814193+08:00 25 [ERROR] Slave I/O for channel 'group_replication_recovery': error connecting to master'repl_user@host-192-168-99-156:3306' - retry-time: 60 retries: 1, Error_code: 2005
2017-04-17T16:18:14.814219+08:00 25 [Note] Slave I/O thread for channel 'group_replication_recovery' killed while connecting to master
2017-04-17T16:18:14.814227+08:00 25 [Note] Slave I/O thread exiting for channel 'group_replication_recovery', read up to log 'FIRST', position 4
2017-04-17T16:18:14.814342+08:00 19 [ERROR] Plugin group_replication reported: 'There was an error when connecting to the donor server. Check group replication recovery's connection credentials.'
解决方案：
添加映射
vim /etc/hosts
192.168.99.156 db1 host-192-168-99-156
192.168.99.157 db2 host-192-168-99-157
192.168.99.158 db3 host-192-168-99-158
重启下组复制
mysql> stop group_replication;
Query OK, 0 rows affected (8.76 sec)
mysql> start group_replication;
Query OK, 0 rows affected (2.51 sec)
3.
ERROR 3092 (HY000): The server is not configured properly to be an active member of the group. Please see more details on error log.
查看日志：
2018-06-12T09:50:17.911574Z 2 [ERROR] Plugin group_replication reported: ‘binlog_checksum should be NONE for Group Replication’
解决办法：（三个节点都执行，不要忘记在配置文件中也要更新）
mysql> show variables like '%binlog_checksum%';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| binlog_checksum | CRC32 |
+-----------------+-------+
1 row in set (0.00 sec)
mysql> set @@global.binlog_checksum='none';
Query OK, 0 rows affected (0.09 sec)
mysql> show variables like '%binlog_checksum%';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| binlog_checksum | NONE |
+-----------------+-------+
1 row in set (0.00 sec)
mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected (12.40 sec)
参考来源：
https://dev.mysql.com/doc/refman/5.7/en/group-replication.html
https://blog.csdn.net/mchdba/article/details/54381854
http://www.voidcn.com/article/p-aiixfpfr-brr.html
https://www.cnblogs.com/luoahong/articles/8043035.html
https://blog.csdn.net/i_am_wangjian/article/details/80508663
- 1. MySQL Group Replication-现有普通复制集群提高为Group Replication
- 2. mysql集群
- 3. mysql 集群
- 4. MySQL cluster集群/NDB集群学习
- 5. mysql集群-ndb
- 6. mysql集群01:认识mysql集群
- 7. MySQL集群---①浅谈MySQL集群原理
- 8. Mysql集群
- 9. MySQL Cluster 集群
- 10. mySQL集群
- 更多相关文章...
- • Swarm 集群管理 - Docker教程
- • MySQL GROUP BY：分组查询 - MySQL教程
- • 漫谈MySQL的锁机制
- • ☆技术问答集锦（13）Java Instrument原理
-
每一个你不满意的现在，都有一个你没有努力的曾经。