企业级mysql数据库集群----mysql的全同步复制(组复制)

背景

异步复制
异步复制，主库将事务 Binlog 事件写入到 Binlog 文件中，此时主库只会通知一下 Dump 线程发送这些新的 Binlog，然后主库就会继续处理提交操作，而此时不会保证这些 Binlog 传到任何一个从库节点上。
全同步复制
全同步复制，当主库提交事务之后，所有的从库节点必须收到、APPLY并且提交这些事务，然后主库线程才能继续做后续操作。但缺点是，主库完成一个事务的时间会被拉长，性能降低。
半同步复制
半同步复制，是介于全同步复制与全异步复制之间的一种，主库只需要等待至少一个从库节点收到并且 Flush Binlog 到 Relay Log 文件即可，主库不需要等待所有从库给主库反馈。同时，这里只是一个收到的反馈，而不是已经完全完成并且提交的反馈，如此，节省了很多时间。

配置组复制

实验需要三台虚拟机server1 server2 server3
这三台虚拟机没有主从之分，只有一个主节点，三台虚拟机上面的配置都是一样的，展示组节点上虚拟机的配置。在组节点的虚拟机上，可以查看三台虚拟机是否配置成功！
在主从复制中，备服务器并没有上线，而在组复制重，之前的备服务器也上线，也就是说，三台虚拟机都是即可写也可读
先在组节点上(server1)配置
步骤一：由于目前的实验环境是之前半同步复制的环境，所以讲主、从服务器上的mysql关闭
systemctl stop mysqld


步骤二：拷贝主库的UUID
复制uuid /var/lib/mysql/auto.cnf

步骤三：删除/var/lib/mysql/*，为了重新配置一个新的mysql环境，同时，也让刚才的UUID跟现在的不冲突

步骤四：修改配置文件
在官网 https://dev.mysql.com/doc/refman/5.7/en/group-replication-configuring-instances.html上拷贝

vim /etc/my.cnf
server_id=1
gtid_mode=ON
enforce_gtid_consistency=ON
master_info_repository=TABLE
relay_log_info_repository=TABLE
binlog_checksum=NONE #关闭binlog校验
log_slave_updates=ON
log_bin=binlog
binlog_format=ROW #组复制依赖基于行的复制格式
transaction_write_set_extraction=XXHASH64
loose-group_replication_group_name=“c36cc649-3f17-11e9-960e-525400cf2a01” #这块的这个UUID就是刚才拷贝的UUID
loose-group_replication_start_on_boot=off
loose-group_replication_local_address= “172.25.136.1:33061” #这块的ip地址是本机的ip
loose-group_replication_group_seeds= “172.25.136.1:33061,172.25.136.2:33061,172.25.136.3:33061” #这几个ip是我们设置的一个组里的ip，也就是三个服务器的ip地址
loose-group_replication_bootstrap_group=off ##插件是否自动引导，这个选项一般都要off掉，只需要由发起组复制的节点开启，并只启动一次，如果是on，下次再启动时，会生成一个同名的组，可能会发生脑裂
loose-group_replication_ip_whitelist=“127.0.0.1,172.25.10.0/24”
loose-group_replication_enforce_update_everywhere_checks=ON
loose-group_replication_single_primary_mode=OFF #后两行是开启多主模式的参数

步骤五：启动mysqld
systemctl start mysqld （这个时候在启动mysqld的时候，会出错，服务一直起不来，第一，检查自己的配置文件，第二，将服务先关闭，再重起服务）

步骤六：初始化数据库—修改初始密码

步骤七：配置数据库
在官网上查看，根据官网上的提示进行相对应的修改。

SET SQL_LOG_BIN=0; #关闭二进制日志，防止传到其他server上
CREATE USER rpl_user@’%’ IDENTIFIED BY ‘Westos+123’;
GRANT REPLICATION SLAVE ON . TO rpl_user@’%’;
FLUSH PRIVILEGES;
SET SQL_LOG_BIN=1; ##开启日志
CHANGE MASTER TO MASTER_USER=‘rpl_user’, MASTER_PASSWORD=‘Westos+123’ FOR CHANNEL ‘group_replication_recovery’;
INSTALL PLUGIN group_replication SONAME ‘group_replication.so’;
SHOW PLUGINS; ##查看插件，这一步在组节点上进行就可以
SET GLOBAL group_replication_bootstrap_group=ON; ##组复制发起节点开启这个参数，
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;

SELECT * FROM performance_schema.replication_group_members; ##查看server1是否online，只有online了才能说明这个服务器配置成功，这一步也只是在组节点上进行
注意：我们先不要添加数据，以防出错，最后测试的时候再添加数据



在server2上配置

在server2上的操作顺序为server1上的步骤一、步骤三、步骤四、步骤五、步骤六、步骤七
唯一不同的就是步骤四中，server_id和本机ip不一样，步骤七的数据库的配置没有SHOW PLUGINS;、SET GLOBAL group_replication_bootstrap_group=OFF;之外，全都一样



server2和server3上配置一模一样
总之，MySQL 组复制提供了高可用性，高弹性，可靠的 MySQL 服务
但是组复制的效率很低
当master节点写数据的时候，会等待所有的slave节点完成数据的复制，然后才继续往下进行
组复制的每一个节点都可能是slave