Mysql——组复制的配置

一.Mysql组复制

前面我们做了Mysql的主从复制下的异步复制模式，在此基础上，做了GTID的异步复制模式和半同步分布模式，我们知道：

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

在实际使用过程中，可以通过配置参数（rpl_semi_sync_master_timeout 单位是毫秒，默认为10000，即10s）设定若slave 在多长时间没有ack返回，同步模式由半同步自动修改为异步同步模式。（mysql半同步工作原理和oracle dataguard的最大保护模式雷同）

组复制介绍：

组复制分单主模式和多主模式，mysql 的复制技术仅解决了数据同步的问题，如果 master 宕机，意味着数据库管理员需要介入，应用系统可能需要修改数据库连接地址或者重启才能实现。（这里也可以使用数据库中间件产品来避免应用系统数据库连接的问题，例如 mycat 和 atlas 等产品）。组复制在数据库层面上做到了，只要集群中大多数主机可用，则服务可用，也就是说3台服务器的集群，允许其中1台宕机。

组复制的特点：

● 高一致性

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

● 高容错性

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

● 高扩展性

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

● 高灵活性

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

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

什么样的应用场景适合用组复制？

• 1、弹性的数据库复制环境
  组复制可以灵活的增加和减少集群中的数据库实例

• 2、高可用的数据库环境
  组复制允许数据库实例宕机，只要集群中大多数服务器可用，则整个数据库服务可用

• 3、替代传统主从复制结构的数据库环境

二：Mysql的组复制的配置过程

实验环境，我们做的实验是多主模式：

meng1	master
meng2	slave
meng3	slave

其实严格来说这里没有谁是master，谁是slave，大家都是master，谁插入数据的，谁是主master，这个主master会等待所有的节点返回确认信号，master（因为master节点一直在等待）才开始工作。

第一步：在meng1中编辑mysql配置文件

[root@meng1 mnt]# cat /var/lib/mysql/auto.cnf 
[auto]
server-uuid=a4b91867-b023-11e9-928e-525400a8fe0b   
[root@meng1 mnt]# vim /etc/my.cnf

 35 server_id=1     #meng2是2，meng3是3，依次类推
 36 gtid_mod