MySQL Group Replication 学习（原理篇）

MYSQL Group Replication 是MYSQL5.7.17后推出的新特性，是集高可用、易扩展、高容错等于一体的复制架构，本文主要是对其原理做相关学习梳理。
一、常见复制技术架构对比
1、传统异步复制：
主库执行事务，完成binlog写入并将相关事务信息发送到从库的relay-log，此时不管从库是否接收到主库的事务信息（写入relay-log），主库都完成commit提交，从而完成undo和redo的写入。

2、半同步复制：
主库执行事务，完成binlog写入并将相关事务信息发送到所有从库的relay-log，此时需要至少一个从库接收到主库的事务信息（写入relay-log），主库接收到从库返回的ACK确认后完成commit提交，从而完成undo和redo的写入。

3、组复制：
主库执行事务，先在组内进行写集合检测事务是否冲突（certify），如果没有冲突则完成binlog和relay-log的写入，并完成commit和apply相应操作，如果有冲突（一般多主模式会出现事务冲突），则按照先提交事务的服务器进行事务提交，后提交的进行回滚，完成事务的正常执行。
下文是官方文档所述：
当事务准备好在始发服务器上提交时，该始发服务器原子地广播写入值（已改变的行）和对应的写入集（已更新的行的唯一标识符）。然后为该事务建立一个全局总序号。最终，这意味着所有服务器以相同的顺序接收同一组事务。因此，所有服务器以相同的顺序应用相同的一组更改，因此它们在组内保持一致。 但是，在不同服务器上并发执行的事务之间可能存在冲突。通过检查两个不同的并发事务的写集合来检测这样的冲突，这个检查过程称为认证（ certification ）。如果在不同的服务器上执行的两个并发事务更新同一行，则会出现冲突。解析过程会这么做，首先发起的事务在所有服务器上提交，而后发起的事务将在源服务器上回滚，并由组中的其他服务器删除。这实际上是一个分布式环境下“优先提交者赢”的规则。

二、组复制优缺点
优点：
   高一致性，基于原生复制及paxos协议的组复制技术，以插件方式提供一致数据安全保证；
   高容错性，大多数服务正常就可继续工作，自动不同节点检测资源征用冲突，按顺序优先处理，内置自动防脑裂机制；
   高扩展性，自动添加移除节点，并更新组信息；
   高灵活性，单主模式和多主模式。单主模式自动选主，所有更新操作在主进行；多主模式，所有server同时更新。
缺点：
   1.存储引擎必须为innodb
   2.每个表必须提供主键
   3.只支持ipv4，网络需求较高
   4.一个group最多只能有9台服务器
   5.不支持Replication event checksums，
   6.不支持Savepoints，不能通过mysqldump --singile-transaction备份
   7.multi-primary mode部署方式不支持SERIALIZABLE事务隔离级别
   8.multi-primary mode部署方式不能完全支持级联外键约束
   9.multi-primary mode部署方式不支持在不同节点上对同一个数据库对象并发执行DDL(在不同节点上对同一行并发进行RW事务，后发起的事务会失败)
   10.GTID限制同样适用于组复制
三、组复制应用场景
1、高可用架构场景，multi-primary
2、自动化部署，完成自动化故障切换
3、动态增加、删除节点（弹性扩展的场景）
三、组复制相关机制和服务
1、失败检测机制
  组复制提供了一种故障检测机制，其能够找到和报告哪些服务器是没有响应的，并假定其是死的。更深入地说，故障检测器是提供关于哪些服务器可能已死的信息的分布式服务。后续如果组同意怀疑可能是真的，则由组来决定该服务器确实已经失败。这意味着组中的其余成员进行协调决定排除给定成员。服务器无响应时触发怀疑机制。当服务器A在给定时间段内没有从服务器B接收消息时，发生超时就会引起怀疑。如果服务器与组的其余部分隔离，则它怀疑所有其他服务器都失败。由于无法与组达成协议（因为它无法获得大多数成员认可），因此其怀疑没有后果。当服务器以此方式与组隔离时，它无法执行任何本地事务。
2、组成员服务
  MySQL组复制依赖于组成员服务group membership service。这是内置的插件。它定义哪些服务器是在线的并参与在复制组中。在线服务器列表通常称为视图view。因此，组中的每个服务器具有一致的视图，其是在给定时刻积极参与到组中的成员。
  复制组的成员们不仅需要同意事务是否提交，而且也需要决定当前视图。因此，如果服务器同意新的服务器成为组的一部分，则该组本身被重新配置以将该服务器集成在其中，从而触发视图改变。相反的情况也发生，如果服务器自愿地离开组，则该组动态地重新布置其配置，并且触发视图改变。
  请注意，当成员自愿离开时，它首先启动动态组重新配置。这触发一个过程，所有成员必须同意新的视图（也就是新视图中没有该离开成员）。然而，如果成员不由自主地离开（例如它已意外停止或网络连接断开），则故障检测机制实现这一事实，并且提出该组的重新配置（新视图没有该离开成员）。如上所述，这需要来自组中大多数成员的同意。如果组不能够达成一致（例如，以不存在大多数服务器在线的方式进行分区），则系统不能动态地改变配置，从而阻止脑裂情况引起的多写。最终，这意味着管理员需要介入并解决这个问题。
3、容错机制
MySQL组复制构建在Paxos分布式算法的实现上，以提供服务器之间的分布式协调。因此，它需要大多数服务器处于活动状态以达到选举条件，从而做出决定。这对系统可以容忍的故障数量有直接影响，一个组复制中成员数量设置（n）为n = 2×f + 1。
在实践中，这意味着为了容忍一个故障，组必须有三个服务器。因此，如果一个服务器故障，仍然有两个服务器形成大多数（三分之二）并且允许系统自动地继续运行。但是，如果第二个服务器也异常失败，则该组（剩下一个服务器）阻塞，因为没有多数可以做出决定。
（实际测试中发现，即时2个实例也可进行读写，待进一步验证）

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/27067062/viewspace-2142118/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/27067062/viewspace-2142118/