GR运维手册 - 第一册 苦海岸边，GR的基础知识
作者简介：
刘伟 云和恩墨开源解决方案事业部首席架构师
多年一线互联网企业DBA经历，对MySQL、NoSQL，PostgreSQL等各类开源数据库均有涉猎，负责开发管理过数千实例规模数据库项目，并带领团队开发了MySQL数据库的监控、备份等自动化组件，对超大规模数据库运维平台的开发及管理有丰富经验。
引言：Group Replication（后文简称GR）是一个MySQL的多主share nothing集群。接下来的这系列分享中，将包含MySQL Group Replication的基础架构以及相关知识，详细的操作步骤在后文说明。
在正文开始之前，我们先来谈谈重要的事情：关于这个题目。
不知道在座各位看到苦海无边是什么反应，反正小编是受到了惊吓，非得要作者给个说法。恩，作者是这样回答的：
如是我闻。世传金丹大道，七返九转，可以至苦海岸边。苦海岸上，出神入化种种次第，传述不明。今得一十三部经书，述阳神化身诸次第修行。
话说说的这是啥？！这不是欺负小编没有读过书嘛。终于在小编再三要求下，作者用人类的语言表达了这个观点：
MySQL的传统高可用比如主从以及双机HA等方案讲述者不在少数，但Group Replication以及Galera等比较新的高可用架构，网上资料麟角凤毛不说，大部分都是在讲安装初始化等基础内容，对监控，高可用等其他内容关注不多，这次趁Group Replication刚刚发布，对常规的种种话题做一些总结。
这次听懂了吗？听懂了。好的那我们开始学习！
MySQL Group Replication架构
从实际的部署情况看，MySQL Group Replication 部署三个或者更多节点，节点之间通过分布式协议沟通。所有节点的地位都是平等的，并不存在一个管理节点。每个节点都会维护一个集群的节点列表，并根据自己与其他节点之间的通讯情况进行动态变更。
Group Replication 程序结构
在MySQL的底层，GR增加了另外的API层来实现所需要的功能。
程序结构上，GRAPI主要分为三部分：
capture 追踪当前正在执行的事务的上下文。
applier 执行远程事务传输到本地的日志到本地数据库。
recovery 负责分布式环境下的节点恢复，以及相关的数据回追，失败处理等。
在这几个主要API层的下面，是统一的复制协议逻辑处理层，这一层主要是统一应用层的各种调用。在更下层，则是通用程度更高的分布式通讯层，处于调用便利，分布式通讯曾对上提供使用的API，API的下面，是Paxos实现的分布式通讯协议组件，这个组件与集群中其他节点一起，形成一个虚拟概念化的分布式集群。
MySQL Group Replication 使用 单个事务，必须只能发生在一个节点（集群内分布式事务没有意义，因为所有节点的数据都是一样的）。
每次一个事务在一个节点提交的时候，就会发送所修改的数据到所有节点，检查期间是否有修改冲突（比如修改了别的节点已经修改并提交成功的事务的数据），如果发现冲突，本事务回滚。如果没有冲突，则可以直接提交成功。 对于非执行事务的远程节点，如果事务判断为执行成功，远程发送过来的数据，会被保存在本地的一个relay log里面（注意，与常规主从同步使用的relay log不是同一组），之后由从库的applier线程采用正常主从同步（目前已经支持LOGICAL_CLOCK并行执行）的方式执行掉对应的relay log。
这里有一个临界点，如果一个事务刚刚被写入relay log，还没有来得及执行掉，这时候有一个事务的执行涉及了相关的数据，那么后来的这个事务在执行阶段可以执行成功，但是必定会在提交阶段失败的。
多节点写事务冲突如下：
假设我们有三节点的集群，其中有节点1，节点2，节点3.
现在在节点1上发起事务1，节点2上发起事务2，都是对同一行的delete，操作顺序如下：
1. 节点1>begin
2. 节点2>begin
3. 节点1>delete
4. 节点2>delete
5. 节点2>commit
6. 节点1>commit # 这一步会失败，整个事务会被回滚。
MySQL Group Replication 目前的限制 1. 所有涉及的数据都必须发生在InnoDB存储引擎的表内。
2. 所有的表必须有明确的主键定义。
3. 网络地址只支持IPv4。
4. 需要低延迟，高带宽的网络。
5. 目前集群限制最多允许9个节点。
6. 必须启用binlog。
7. binlog 格式必须是row格式。
8. 必须打开gtid模式。
9. 复制相关信息必须使用表存储。
10.事务写集合（Transaction write set extraction）必须打开。（这个目前与savepoint冲突，这也是导致mysqldump无法备份GR实例的原因）
11. log slave updates必须打开。
12. binlog的checksum目前不支持。
13. 由于事务写集合的干扰，无法使用savepoint。
14. SERIALIZABLE 隔离级别目前不支持。
15. 对同一个对象，在集群中不同的实例上，并行地执行DDL（哪怕是相互冲突的DDL）是可行的，但会导致数据一致性等方面的错误，目前阶段不支持在多节点同时执行同一对象的DDL。
16. 外键的级联约束操作目前的实现并不完全支持，不推荐使用。
MySQL Group Replication 的一些问题的回复（官方文档） Q：MySQL Group Replication最多允许几个节点？
目前代码里面写死了9个，如果想多加节点进去会拒绝加入。
Q：节点之间相互是怎么通讯的？
节点直接是通过点到点的tcp连接通讯的，这些连接只用于节点之间的消息通讯。
Q：group_replication_bootstrap_group 选项的主要作用是什么?
这个选项主要用于初始化一个新的集群，第二个节点以及后续节点可以通过加入申请加入到这个节点。
Q：集群节点有两个地方需要加入到集群的操作，一个是集群创建的时候，另外一个是关闭并重启集群的时候。我应该在什么地方设置安全验证？
如果需要设置安全相关（用户名密码，SSL）的东西，需要在每个节点上都使用change master语句设置。
Q：Group Replication是否可以用于写负载的横向扩展？
不可以。MySQL Group Replication是share nothing的全量复制方案。集群中的每个节点都包含了数据库所有的数据。如果一个节点写入了N字节的数据，那么所有节点都会写入N字节的数据，所有数据操作都会被复制到所有节点执行。当然，其他节点并不是直接运行源事务的所有操作。事务传输是通过row格式传输的，其实际的应用速度会更好一点。
实际使用中，处于控制带宽以及响应时间的目的，也会使用更优化的row格式传输到目标节点以减少IO的消耗操作。
总的来看，可以使用Group Replication来扩展处理速度，也就是在集群的不同节点处理不同事务，降低单个节点的事务处理压力。
Q：与传统的简单复制模式相比较，同样的负载情况下，Group Replication是否需要更好的带宽以及CPU?
当然会有一些负载上的增加，但实际上很难估计增加了多少，比如节点数量的不同，对带宽的需求也是完全不同的。由于所有节点之间都需要沟通，3节点和9节点的带宽需求差距很大。另外考虑到同步以及消息处理，额外的内存和CPU消耗肯定也是必要的。
Q：是否可以部署Group Replication到广域网上?
不建议这么做。快速的网络是保障GR可用性能的基础，在一般情况下，可以采用压缩等基础，降低带宽方面的消耗，单如果出现丢包，会导致重传以及更高的网络延迟，整个系统的吞吐量以及延迟会到一个无法接受的程度。当然，如果非要部署，当然也是可以的。但这种形式的部署，并不是GR方案的主要设计目的，GR的设计与实现的时候，并不会考虑为这个场景优化。
Q：当节点出现临时问题的时候，节点是否会被自动地踢出集群？
看具体情况。如果是连接问题并且很快恢复了连接，失败检测没有发现到这个问题的话，节点并不会被踢出集群。但如果是一个足够长时间的中断，失败检测发现到的话，这个节点就会被集群踢出。一旦一个节点被踢出集群，需要DBA介入把这个节点重新加回集群。也就是说，这个恢复过程，需要DBA手工或者通过脚本操作来执行。
Q：什么情况下，节点会被踢出集群？
如果节点没有再出现对其他节点的通讯，其他节点会在自己的集群配置中自动踢出这个节点，一般出现于节点奔溃或者网络中断的时候。失败检测发生于一个指定的超时限制触发后，确认情况后，节点会重新生成一个没有失败节点的集群列表。
Q：如果一个节点出现数据延迟的话，会发生什么？
目前的情况下，集群并不处理数据库延迟的问题。DBA需要自己发现，并处理或者修复，乃至从集群中下线掉出现数据延迟的节点。当然，如果延迟过大，触发流量控制的机制，整个集群会变得很慢。流量控制机制是一个可以修改的配置，用户可以按照自己的需求配置。
Q：MySQL Group Replication是否依赖心跳或者超市机制检测失败？
的确有一个失败发现的超时，当一个节点没有任何响应之后，其他节点会自动发现这个问题，并重新构建集群列表。
Q：是否有一个特殊的节点来控制集群的成员变更？
没有这么一个节点，成员的变更都是每个成员自己发起的。每个节点都需要确认失败节点确实已经失败。之后每个成员自己会重新构建 集群列表，不需要人工参与。
关于GR的更多经典文档：
MySQL Group Replication 学习笔记
从主从复制到Group Replication
如何加入"云和恩墨大讲堂"微信群
搜索 盖国强（Eygle）微信号：eyygle，或者扫描下面二维码，备注：云和恩墨大讲堂，即可入群。每周与千人共享免费技术分享，与讲师在线讨论。
关注本微信（OraNews）回复关键字获取
CodeSet,《Oracle性能优化与诊断案例精选》代码;
2016OTC，第六届Oracle技术嘉年华PPT；
2016DTCC, 2016数据库大会PPT；
DBALife,"DBA的一天"精品海报大图；
12cArch,“Oracle 12c体系结构”精品海报；
DBA01，《Oracle DBA手记》第一本下载；
YunHe，“云和恩墨大讲堂”案例文档下载；