Group Replication 组复制 1、特性： a、高一致性，以插件方式提供一致数据安全保证 b、高容错性，大多数服务正常就可继续工作，自动不同节点检测资源征用冲突，按顺序优先处理。内置自动防脑裂机制。 c、高扩展性，自动添加移除节点，并更新组信息。 d、高灵活性，单主模式和多住模式。单主模式自动选主，所有更新操作在主进行。多主模式，所有server同时更新。 2、事务并发冲突处理： 两个不同的事务在两个节点上操作同一行数据，就会有冲突。GR会采用乐观策略，依赖事务提交的时间先后顺序，先发起提交的节点能够正确提交，后面的提交会失败。 3、节点故障自动检测： 组内节点心跳检测来识别出组内成员是否挂掉。当一个节点失败，将由其他节点决定是否将这个失效的节点从group里面剔除。当然这是建立在满足大多数节点存活并且可以进行决议的前提上。 4、容错能力 GR基于分布式一致性算法实现，一个组允许部分节点挂掉。只要大多数节点仍然存活并且之间通讯没有问题，那么这个组对外仍能正常提供服务。 如3个节点可以最多挂掉一个。建议由奇数个节点组成。当由偶数时，出现一半节点挂掉，两边都没有大多数，因此整个集群实际上处于不可用。 若不满足大多数，所有事务写操作都会阻塞，直到集群满足大多数节点存活为止。 5、两种模式 a、单主模式：single-primary 组内只有一个节点负责写入，读可以从任意一个节点读取。默认是单主 b、多主模式：multi-primary 写操作交下发到组内所有节点，组内所有节点同时可读可写。 通过在my.cnf中进行定义 group_replication_single_primary_mode 6、single-primary:只有一台可写，其他只能读 read_only=0 可读可写 read_only=1 只读 部署步骤： 先将primary启动，设置可读可写，然后再将其他节点一一加进group。其他节点会自动同步primary节点上的变化，将自己设置为只读。 故障自动修复： 当primary节点挂掉，其他节点会进行选举，提升为primary节点。选举规则是根据server_uuid升序来选择，排在最前面的提升为primary节点。 查看当前是否为primary节点？ select @@read_only; 0 为可读可写，为primary 7、组复制要求和限制 引擎为innodb 每个表必须提供主键 只支持ipv4 一个group最多只能有9个节点 不支持replication event checksums，需在my.cnf中配置 不支持savepoints （保存点） multi-primary的限制（以上的也包括） : 不支持serializable事务隔离级别，（串行） 不能完全支持外键约束 不支持在不同节点上对同一个数据库对象并发执行DDL语句（在不同节点上并发进行RW事务，后发起的事务会失败） 8、组复制配置 server_id=1 唯一标识符 log-bin=log_file_name 开启binlog模式 binlog-format=row 行模式 gtid-mode=ON 全局事务ID master-info-repository=TABLE 　　 这两个参数会将master.info和relay.info保存在表中 relay-log-info-repository=TABLE transaction-write-set-extraction=XXXHASH64 log-slave-updates=true 当从库log_slave_updates参数没有开启时，从库的binlog不会记录来源于主库的操作记录。只有开启log_slave_updates，从库binlog才会记录主库同步的操作日志。 binlog-checksum=NONE 其中 type 包含：1）CRC32，使用 ISO-3309 CRC-32 校验和；2）NONE，即关闭校验和。默认是 CRC32 以下部分是server组复制的配置 transaction_write_set_extraction=XXHASH64 loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa" loose-group_replication_start_on_boot=off loose-group_replication_local_address= "127.0.0.1:24901" loose-group_replication_group_seeds= "127.0.0.1:24901,127.0.0.1:24902,127.0.0.1:24903" loose-group_replication_bootstrap_group= off 第1行指示server必须为每个事务收集写集合，并使用XXHASH64哈希算法将其编码为散列。 第2行告知插件，正在加入或创建的组要命名为“aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa”。 第3行指示插件在server启动时不自动启动组复制。 第4行告诉插件使用IP地址127.0.0.1或本地主机，端口24901用于接受来自组中其他成员的传入连接 第5行告诉插件，当下面这些server需要加入组时，应该连接到这些主机和端口上访问他们。这些就是种 子成员，当此成员想要连接到组时使用 第6行指示插件是否自动引导组，此选项在任何时候只能在一个server实例上使用，通常是首次引导组时 组复制是一种可用于实现容错系统的技术。复制组是一个通过消息传递相互交互的服务器组。通信层提供了很多保证， 例如原子消息和总消息序号的传递。通过这些强大的特性，我们可以构建更高级的数据库复制解决方案。 MySQL组复 制构建在这些属性和抽象之上，并实现多主复制协议的更新。实质上，复制组由多个数据库实例组成，并且组中的每 个实例都可以独立地执行事务。但是所有读写（RW ）事务只有在被组批准后才会提交。只读（RO）事务不需 要在组内协调，因此立即提交。换句话说，对于任何RW事务，组需要决定是否提交，因此提交操作不是来 自始发服务器的单向决定。准确地说，当事务准备好在始发服务器上提交时，该始发服务器原子地广播写 入值（已改变的行）和对应的写入集（已更新的行的唯一标识符）。然后为该事务建立一个全局总序号。 最终，这意味着所有服务器以相同的顺序接收同一组事务。因此，所有服务器以相同的顺序应用相同的一 组更改，因此它们在组内保持一致。 但是，在不同服务器上并发执行的事务之间可能存在冲突。通过检查两个不同的并发事务的写集合来检测这样的冲突， 这个检查过程称为认证（ certification ）。如果在不同的服务器上执行的两个并发事务更新同一行，则会出现冲突。解 析过程会这么做，首先发起的事务在所有服务器上提交，而后发起的事务将在源服务器上回滚，并由组中的其他服务 器删除。这实际上是一个分布式环境下“优先提交者赢”的规则。