老张superzs来更新博客啦,大家新年好啊,好久没有跟大家见面了。说句走心的话,很想你们!最近因为要出版自己的第一本书《MySQL王者晋级之路》一直在忙于宣传。实在抱歉,没能及时更博。今后还是会多奉献精彩文章!
最近绝地求生这个游戏太火了,当我问我的朋友们你们闲时在干嘛,基本上告诉我的答案都是在"吃鸡"啊!想必很多老铁们也玩,那一定应该知道绝地求生中有把枪叫AWM。此枪伤害裸132点,爆头330,即使三级头爆头必死,无防弹衣或者防弹衣有破损,一枪死。是这个游戏中威力最大的狙击×××,足足是98K的两倍。
那么在MySQL领域有没有这么一把威力超大的“枪”呢~答案是必须有啊!但老张先问你们一个问题。
请问你搭建MySQL复制的时候,还在执行备份恢复,在从库进行change master to的操作嘛?如果是那你可就真的落后了。
本章介绍MySQL官方推荐的一款高可用集群方案MySQL Group Replication。简称:MGR(组复制)。它是官方推出的一种基于Paxos协议的状态机复制,彻底解决了基于传统的异步复制和半同步复制中数据一致性问题无法保证的情况。也让MySQL数据库涉及的领域更广,彻底拥有了打开互联网金融行业的大门。2016年12月 MySQL Group Replication推出了第一个GA版本发布在MySQL5.7.17中。但目前直接投入到生产环境中使用,风险还是比较大。建议等其越来越成熟之后,我们再真正投入使用。
随着MySQL8.0版本即将与我们见面,再配合官方逐渐成熟的高可用集群 Group Replication方案,到那时再看看谁还是我们MySQL的对手,全都不在了!MySQL数据库就是作者的信仰,爱你无怨无悔。
先来谈谈什么叫做组复制。组复制是一种可用于实现容错系统的技术。复制组是一个通过消息传递相互交互的server集群。复制组由多个server成员组成,如下图的master1,master2,master3,所有成员独立完成各自的事务。当客户端先发起一个更新事务,该事务先在本地执行,执行完成之后就要发起对事务的提交操作了。在还没有真正提交之前需要将产生的复制写集广播出去,复制到其他成员。如果冲突检测成功,组内决定该事务可以提交,其他成员可以应用,否则就回滚。最终,这意味着所有组内成员以相同的顺序接收同一组事务。因此组内成员以相同的顺序应用相同的修改,保证组内数据强一致性。
组复制可以在两种模式下运行。 在单主模式下,组复制具有自动选主功能,每次只有一个 server成员接受更新,其他成员只提供读服务。在多主模式下运行时,所有的 server 成员都可以同时接受更新,没有主从之分,成员角色是完全对等的。 组复制默认情况下是单主模式,我们可以通过设置参数group_replication_single_primary_mode=off,让其变成多主模式。本章的实战部分就是以多主模式进行MGR复制的搭建。
环境介绍:这里我们准备三个节点,数据库版本使用MySQL5.7.17
数据库IP地址 数据库版本信息 主机名 Server-id
192.168.56.101 MySQL-5.7.17 node2 1013306
192.168.56.102 MySQL-5.7.17 node3 1023306
192.168.56.103 MySQL-5.7.17 proxysql 1033306
实战第1步:
在三个节点上执行安装MySQL5.7操作。(此步省略,详情请见书中第一部分第二章)
实战第2步:
在三个节点上分别设置hostname和ip地址的映射关系
实战第3步:
在三个节点上分别创建复制账号,命令如下
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.56.%' IDENTIFIED BY '123456';
实战第4步:
在三个节点上分别安装GR插件,命令如下
INSTALL PLUGIN group_replication SONAME 'group_replication.so';
组件安装完成之后,展示结果:
root@db 13:23: [(none)]> show plugins;
实战第5步:
在三个节点分别配置各自的集群参数文件,配置完成之后重启数据库
192.168.56.101参数文件配置展示:(剩下两个节点同理)
server_id = 1013306
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
transaction_write_set_extraction = XXHASH64
loose-group_replication_group_name = '1f2cee29-f9a2-11e7-8cbb-08002783b39d'
loose-group_replication_start_on_boot = off
loose-group_replication_local_address = 'node2:33061'
loose-group_replication_group_seeds ='node2:33061,node3:33062,proxysql:33063'
loose-group_replication_bootstrap_group = off
loose-group_replication_single_primary_mode=off
loose-group_replication_enforce_update_everywhere_checks=true
重点参数详解:(一定要记住这些)
MGR一定要开启GTID功能gtid_mode = ON,enforce_gtid_consistency = ON
MGR在当前MySQL版本中,必须要设置binlog_checksum=none
,并且binlog_format=row
MGR需要多源复制功能,所以需要将主从库之间的信息记录到表中。设置master_info_repository = TABLE
和relay_log_info_repository = TABLE
MGR中开启主键信息采集功能:transaction_write_set_extraction= XXHASH64
MGR中把该参数group_replication_single_primary_mode
关闭目的是搭建多主模式。如果搭建单主模型,保持默认参数即可。
MGR中需要设置组的名字,该group_replication_group_name
是通过select uuid()
来生成的。
MGR中本地成员的地址由该参数group_replication_local_address
决定,本例中当前节点是node2。后面的端口是每个节点都需要一个独立的tcp端口号,节点之间通过这个端口号进行通信。
MGR中其他成员的地址由这个参数group_replication_group_seeds
决定
MGR采取多主模式时,需要让该参数group_replication_single_primary_mode=off
(默认是单主模式)。
于此同时需要将该参数group_replication_enforce_update_everywhere_checks=true
。目的是为了做多主模式限制检测。
注:加载到参数文件里面,需要在每个参数的前面加loose。
这里再强调一个参数group_replication_auto_increment_increment
。该参数代表自增属性,默认值为7。我们要保证每个成员的该值相同,并且建议该参数的设置尽量比组内成员的个数大一些,方便后期集群的扩展。
实战第6步:
在192.168.56.101上启动首个节点的MGR集群服务。命令如下:
CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='123456' FOR CHANNEL 'group_replication_recovery'
(MGR需要该异步复制通道,实现新节点加入集群自动从其他节点复制数据的目的,不需要手工指定从哪个节点复制,master_host和master_port信息。都是自动完成)
SET GLOBAL group_replication_bootstrap_group = ON;
(执行初始化操作,只有首个节点需要这一步操作)
START GROUP_REPLICATION;
启动成功之后,查看节点状态信息。命令如下
SELECT * FROM performance_schema.replication_group_members;
原文链接:http://blog.51cto.com/sumongodb/2083286