MySQL 组复制实现了基于复制协议的多主更新(单主模式)。
复制组由多个 server成员构成，并且组中的每个 server 成员可以独立地执行事务。但所有读写（RW）事务只有在冲突检测成功后才会提交。只读（RO）事务不需要在冲突检测，可以立即提交。
对于任何 RW 事务，提交操作并不是由始发 server 单向决定的，而是由组来决定是否提交。准确地说，在始发 server 上，当事务准备好提交时，该 server 会广播写入值（已改变的行）和对应的写入集（已更新的行的唯一标识符）。然后会为该事务建立一个全局的顺序。最终，这意味着所有 server 成员以相同的顺序接收同一组事务。因此，所有 server 成员以相同的顺序应用相同的更改，以确保组内一致。
组复制使您能够根据在一组 server 中复制系统的状态来创建具有冗余的容错系统。因此，只要它不是全部或多数 server 发生故障，即使有一些 server 故障，系统仍然可用，最多只是性能和可伸缩性降低，但它仍然可用。server 故障是孤立并且独立的。它们由组成员服务来监控，组成员服务依赖于分布式故障检测系统，其能够在任何 server 自愿地或由于意外停止而离开组时发出信号。
他们是由一个分布式恢复程序来确保当有 server 加入组时，它们会自动更新组信息到最新。并且多主更新确保了即使在单个服务器故障的情况下也不会阻止更新，不必进行 server故障转移。因此，MySQL 组复制保证数据库服务持续可用。
值得注意的一点是，尽管数据库服务可用，但当有一个 server 崩溃时，连接到它的客户端必须定向或故障转移到不同的 server。 这不是组复制要解决的问题；可以用mysql-router 或者其他中间件,比如mycat、altas等。
架构图如下
限制
表需要有主键
采用GTID+binlog的方式进行复制
复制事件校验 binlog_checksum=none
Gap Locks不可用
多主模式下限制
隔离级别
官网建议使用READ COMMITTED级别，除非应用程序依赖于REPLEATABLE READ，RC模式下没有GAP LOCK，比较好支持Innodb本身的冲突检测机制何组复制的内部分布式检测机制一起协同工作。不支持SERIALIZABLE隔离级别
外键
不建议使用级联外键，如果使用必须配置group_replication_enforce_update_everywhere_checks=ON
DDL操作
多主不支持同一对象不同实例的并发的DDL+DML混合操作 ，MySQL5.7上的DDL不是原子操作无法回滚，因此group replication没有对DDL做冲突检测，可能导致数据不一致；应用或中间件要能够把所有的DDL语句转到同一台MySQL上去执行。
本次测试环境
192.168.20.201 redis01
192.168.20.202 redis02
192.168.20.203 redis03
编辑my.cnf
原文地址：https://www.cnblogs.com/omsql/p/9277047.html