mysql的组复制

先说说数据库复制的各种形式

异步复制模式下,Master上执行事务产生 binlog,slave 通过连接 master 抓取 binlog 的内容接收到本地的 relaylog 上,然后 apply 对应的事务,产生 slave 服务器上自身的 binlog(由--log-slave-update 参数决定)。流程图如下:

Screenshot from 2018-06-11 16-13-45.png

其次是半同步复制,流程图如下

Screenshot from 2018-06-11 16-15-21.png

异步复制模式下,如果 slave 全部宕机,则在 master 上的事务无法同步到 slave 上,存在一定的数据安全风险。


半 同步复制解决了数据安全风险的问题,在半同步环境下要求至少有一台 slave 接收到 master 的binlog并成功写入到本地的 relaylog, master 上的事务才可以成功提交,这样对主库的事务提交速度会产生一定影响,半同步在数据安全和数据库性能两者之间做了一个中和。


在实际使用过程中,可以通过配置参数(rpl_semi_sync_master_timeout 单位是毫秒,默认为10000,即10s)设定若 slave 在多长时间没有ack返回,同步模式由半同步自动修改为异步同步模式。


组复制分单主模式和多主模式,mysql 的复制技术仅解决了数据同步的问题,如果 master 宕机,意味着数据库管理员需要介入,应用系统可能需要修改数据库连接地址或者重启才能实现。

Screenshot from 2018-06-11 16-17-24.png


组复制的特点:

● 高一致性

基于原生复制及 paxos 协议的组复制技术,并以插件的方式提供,提供一致数据安全保证;


● 高容错性

只要不是大多数节点坏掉就可以继续工作,有自动检测机制,当不同节点产生资源争用冲突时,不会出现错误,按照先到者优先原则进行处理,并且内置了自动化脑裂防护机制;


● 高扩展性

节点的新增和移除都是自动的,新节点加入后,会自动从其他节点上同步状态,直到新节点和其他节点保持一致,如果某节点被移除了,其他节点自动更新组信息,自动维护新的组信息;


● 高灵活性

有单主模式和多主模式,单主模式下,会自动选主,所有更新操作都在主上进行;

多主模式下,所有 server 都可以同时处理更新操作。


目前组复制最多支持一个组中有 9 个 server

做组复制时,注意做好解析/etc/hosts,关闭密码插件,在 /etc/my.conf 中写入,

validate_password=OFF
或是在vim /etc/init.d/mysqld 进行注释

Screenshot from 2018-06-13 21-05-14.png


实验:

server1    192.168.122.11

server2    192.168.122.12

server3    192.168.122.13


一、配置文件

/etc/my.cnf  

server2,3的配置文件区别仅在于 server-id 与 local_address

Screenshot from 2018-06-13 22-45-05.png

复制框架

设置将 server 配置为使用唯一标识号 1,以启用全局事务标识符,并将复制元数据存储在系统表(而不是文件)中。 此外,它设置 server 打开二进制日志记录,使用基于行的格式并禁用二进制日志事件校验和。


组复制设置

Screenshot from 2018-06-13 22-45-10.png

第 1 行指示 server 必须为每个事务收集写集合,并使用 XXHASH64 哈希算法将其编码为散列。

第 2 行告知插件,正在加入或创建的组要命名为“aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa”。

第 3 行指示插件在 server 启动时不自动启动组复制。

第 4 行告诉插件使用 本地主机或IP 地址 127.0.0.1 ,端口 24091 用于接受来自组中其他成员的传入连接。

第 5 行告诉插件,当下面这些 server 需要加入组时,应该连接到这些主机和端口上访问他们,这些就是种子成员。

第 6 行指示插件是否自动引导组。此选项在任何时候只能在一个 server 实例上使用,通常是首次引导组时(或在整个组被崩溃然后恢复的情况下)。 如果您多次引导组,例如,当多个 server 实例设置了此选项,则它们可能会人为地造成脑裂的情况,其中存在两个具有相同名称的不同组。 在第一个server 实例加入组后禁用此选项。


二、数据库配置


1.用户凭据

分布式恢复过程依赖于 group_replication_recovery 复制通道,该复制通道用于在组成员之间传输事务。 因此,需要设置具有正确权限的复制用户,以便组复制可以直接建立成员到成员的恢复复制通道。

mysql> SET SQL_LOG_BIN=0;    关闭二进制日志

mysql> grant replication slave on *.* to rpl_user@'%' identified by 'LH=liuhuan123';    创建 rpl_user 用户并且授权使之可以进行复制功能

mysql> flush privileges; 

mysql> SET SQL_LOG_BIN=1;    开启二进制日志

mysql> change master to master_user='rpl_user',master_password='LH=liuhuan123' for channel 'group_replication_recovery';    下次需要从其他成员恢复其状态时,使用 group_replication_recovery 复制通道的给定凭据.。


2.启动组复制


mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';    安装插件

mysql> SET GLOBAL group_replication_bootstrap_group=ON;    server1引导组,启动组复制程序,只用在组复制成员中执行一次即可。不可将此参数写在配置文件中,因为在下一次启动组复制时,会有两个不同的组有相同的名称。

mysql> START GROUP_REPLICATION;    启动 server1的组复制

mysql> SET GLOBAL group_replication_bootstrap_group=OFF;    将引导组复制的程序关闭,其余成员直接加入该组即可。


mysql> SELECT * FROM performance_schema.replication_group_members;  查看

Screenshot from 2018-06-13 23-07-02.png



三、向组中添加实例


server2端

mysql> SET SQL_LOG_BIN=0;
mysql> grant replication slave on *.* to rpl_user@'%' identified by 'LH=liuhuan123';
mysql> SET SQL_LOG_BIN=1;
mysql> CHANGE MASTER TO MASTER_USER='rpl_user',MASTER_PASSWORD='LH=liuhuan123' for CHANNEL 'group_replication_recovery';

mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';    安装插件

mysql> start group_replication;    将 server2 添加到组

Screenshot from 2018-06-13 23-14-26.png

查日志得:

Screenshot from 2018-06-13 23-15-49.png


上网查找(网站 bing.com)

Screenshot from 2018-06-13 23-17-11.png


Screenshot from 2018-06-13 23-18-40.png

server3同理,查看mysql> SELECT * FROM performance_schema.replication_group_members;


Screenshot from 2018-06-13 23-20-27.png


四、高可用验证


1、验证数据写入

server1端,写入数据

Screenshot from 2018-06-13 23-24-11.png

server2,3端查看

Screenshot from 2018-06-13 23-25-21.png


2、模拟宕机一个节点验证


关闭server2

Screenshot from 2018-06-13 23-28-39.png

Screenshot from 2018-06-13 23-28-53.png

在server1写入数据

Screenshot from 2018-06-13 23-29-44.png

启动server2

Screenshot from 2018-06-13 23-30-42.png

再次查看组成员,发现server2已重新加入组

Screenshot from 2018-06-13 23-31-30.png


查看数据,发现数据已同步

Screenshot from 2018-06-13 23-32-20.png