MGR必需了解的知识及mysql8新的特性

MGR知识点：

0、

MySQL的并行复制多线程复制MTS(Multi-Threaded Slaves)

1、mysql组复制提供了一种server间协调机制的分布式state machine复制，组中的server成员自动地进行协调。

2、SMR

state machine replication(状态机复制)是一种容错服务的一种常规方法，主要通过复制服务器，并协调客户端和服务器镜像间的交互达到目标。这个方法也同事提供了理解和设计复制管理协议的一套基本框架。

Sate machine replication(SMR)状态机复制用于分布式系统的容错处理。通过增加数据副本的数量提高系统的可靠性和可用性。状态机复制是由一系列的进程组成，进程包括无限多个客户端进程C={c1,c2…}和有限个服务器进程S={s1,s2…sn}。任何时候，服务器进程的处于正常状态，即系统不存在拜占庭将军问题。

四个特性：

1、共识(agreemnet):如果某台正确的服务器提交了了一个请求R，则所有正确的服务器最终也会提交R
2、有效(validity):如果某台正确的服务器提出了一个请求R，则所有正确的服务器将最终提交R
3、完整(integrity):任何给定的请求R最多只被每台正确的服务器提交一次，并且仅当R在之前被提出。
4、完全有序(total order):如果两台正确的服务器S1和S2都提交了请求R1和R2,则S1在R2之前提交R1，当且仅当S2在R2之前提交R1

SMR的架构分为：

• 执行层(执行请求)
• 共识层(Paxos，实现共识)
• 消息层(负责接收来自客户端的请求)

SMR实现方式：

1、串行SMR
2、pipelined SMR
3、SDPE是Sequential Delivery-Parallel Execution SMR即串行提交，并行执行SMR

参考地址:https://zhuanlan.zhihu.com/p/30043911

3、通信协议

组通信协议：该协议通过Paxos算法实现组复制中保证数据一致性复制的关键组通信系统引擎，该协议保障了故障检查机制，组成员服务的安全和消息的完全有序传递

4、共识算法、Paxos

https://zhuanlan.zhihu.com/p/31780743

5、加入节点操作流程

流程：

一个节点请求加入group ----> 根据配置的seeds参数与group的seeds其中一个成员建立TCP连接 ----> 该种子节点根据自己的group_replication_ip_whitelist的的白名单是否允许新节点加入(MGR默认不限制新节点的ip) ----> 连接建立成功 ----> 新节点发送加入请求 ----> 该种子节点广播视图变化的消息给所有节点(包括自己) ----> 各个节点收到消息视图修改切换 ----> 每个节点都会广播一个状态交换消息，每个小环消息包含节点的当前状态和信息 ----> 各个节点开始接受其他节点广播消息并更新本地成员列表。---->完成视图切换 ----> 新节点加入group，只是该成员可以接收到group中通过Paxos协议达成共识的消息,并不意味着可以成为ONLINE,原因是新成员还需要进行数据同步，建立正确的数据版本(recovery_module->start_start_recovery) ----> 执行Paxos协议消息，向用户提供访问服务。

状态交换：状态交换与事务数据包采用Paxos协议发送，当收到所有成员的状态消息时，通信模块将完整的新视图封装为数据包group中的每个节点基于MGR的通信模块将其返回给全局事务认证模块的消息队列。

视图数据包：视图数据包通过Paxos放入消息队列，那么各节点依次处理消息队列中的数据包时就能够发现视图数据包，将视图数据包封装为view_change_log_event(vcle)后写入relay log文件中，group_replication_applier通道的并行复制线程读取relay log 中的vcle，并将其写入到Binlog文件中。而binlog文件中的事务就被vcle划分为多个区间，每个区间都代表一个视图。vcle中包含viewid和用于进行全局事务认证模块进行事务认证的冲突检测数据库。基于vcle，我们可以把节点上线前的过程划分2个阶段，分别为：前一个视图数据恢复和本视图缓存事务执行。第一阶段又分为本地恢复和全局恢复。

6、故障恢复实现

MGR正常运行时，节点间通过Paxos歇息传输数据，异地事务经过认证后写入relay log中，由group_replication_applier通道的复制线程复制回放，当有节点加入Group时，需要用到另一个复制通道group_replication_recovery,它是一个传统的Master-Slave异步复制通道。

MGR故障恢复由节点的故障恢复单独的恢复线程执行。

注：5、6 来源：https://zhuanlan.zhihu.com/p/40627399

7、单主模式、双主模式

单主模式：

loose-group_replication_single_primary_mode=true
loose-group_replication_enforce_update_everywhere_checks=false

双主模式：

loose-group_replication_single_primary_mode=false
loose-group_replication_enforce_update_everywhere_checks=true

8、round-Robin 算法

Round-Robin即轮询算法。

轮询调度算法的原理是:每次把来自用户的请求轮流分配给内部中的服务器。如：从s1…sn(n是内部服务器的个数)。

轮询调度算法无需记录当前所有连接的状态，所以它是一种无状态调度。

轮询调度算法假设所有服务器处理能力均衡，不考虑服务器的当前连接数和响应速度，很容易造成服务器间的负载不均衡，因此出现了权重轮询算法。

权重轮询算法：是基于轮询算法改进而来的。根据服务器的不同处理能力，给每个服务器分配不同的权值，使其能够承受相应权值数的服务请求，即权重轮询算法(weighted round-robin)。

8、MGR数据提交流程

MGR模式下，事务完成在引擎层perpare，写Binlog之前会被mysql的预埋钩子HOOK before_commit()拦截，进入到MGR层，将事务封装成消息通过Paxos一致协议(consensus)进行全局排序后发送给MGR各个节点，在各节点上独自进行认证(certifiy)。认证通过后，本地节点写binlog完成提交。其他节点写relay-log，由注册的复制通道group_replication_applier channel完成事务并行回放。

MGR冲突检查机制：基于记录版本的事务认证机制，在内存中维护冲突检查数据库，每个节点独立进行冲突检查，规则相同，结果一样。

https://zhuanlan.zhihu.com/p/67496623
https://zhuanlan.zhihu.com/p/67490476

9、Paxos的事务消息封装了哪些信息？

a、Transaction_context_log_event
	- 事务节点server_uuid
	- 事务执行时的节点gtid_executed信息snapshot_version
	- 执行事务的线程thread_id
	- 事务gtid是否已存在gtid_specified
	- 事务所修改的记录集的主键列表write_set
b、Gtid_log_event
	- 事务节点server_id
	- 事务是否为DML
	- 事务组提交信息last_commited
	- 事务组提交信息sequence_number
	- 事务是否包含非row格式日志may_have_sbr_stmts
c、log_event_group 事务数据
	- query_log_event:"Begin"
	- Row_log_event:write/update/delete
	- .....
	- Xid_log_event

注意：a仅用于认证不写入Binlog(此信息是在内存中的冲突检查数据库中,用于冲突检查)，而b、c、会写入日志。
10、MGR事务全局排序(Paxos全局排序)

事务在MGR中进行认证前，会先进入全局排序，即consensus阶段。这个阶段是把事务认证所需要的信息收集并封装起来通过Paxos协议进行广播。

11、mencius 算法

mencius是paxos算法的变种。

Mencius的目的是减少Paxos主节点负载，提高吞吐量

https://zhuanlan.zhihu.com/p/26013382
https://www.usenix.org/legacy/event/osdi08/tech/full_papers/mao/mao.pdf
http://muratbuffalo.blogspot.com/2010/10/mencius-building-efficient-replicated.html

12、pipeline机制

13、事务认证

事务认证模块建立一个基本的认识：事务认证模块由冲突检测数据库、事务gtid分配器和事务组提交信息分配器等三部分组成

sequence_number即为事务的last_commited

group commit:last_commited和 sequence_number

参考源码地址：
https://github.com/mysql/mysql-server/blob/8.0/plugin/group_replication/src/certifier.cc
https://github.com/mysql/mysql-server/blob/8.0/plugin/group_replication/include/certifier.h

https://zhuanlan.zhihu.com/p/38456119
https://zhuanlan.zhihu.com/p/41175310

https://mysqlhighavailability.com/the-king-is-dead-long-live-the-king-our-homegrown-paxos-based-consensus/

14、MGR实践的注意

冲突检查数据库是运行在内存里的，记录越少，占用内存越少，节点延迟越小，所以合理设置MGR的节点间流控制参数。

- 在集群中有节点重建，其gtid_excuted会落后其他节点，导致其他节点的冲突数据库无法清理而不断增大。
- 尽可能使用小事务，大事务可能导致一个gtid聚集大量的主键信息，虽不导致节点延迟过大，但是数据库中存在大量的主键无法通过每分钟一次的gtid_executed更新来清理，同时也无法通过以事务为计数单位的流控制机制进行事务提交速度限制。
- 在大表alter等DDL操作时可能会引发冲突检查数据库暴涨问题。(以单主模式为例)原因是secondary接地那在单线程回放DDL操作期间，Primary接地那位于DDL之后的DML操作主键会一直在数据库中无法被清理，如果DML过多，可能会压爆内存。

15、数据安全性保障

单主模式
scondary节点：
super_read_only = on

多主模式：
super_read_only = off
当节点挂掉：
super_read_only = on 来保护数据安全

16、保证MGR节点不受异步复制通道影响？(数据安全性保障)
a、需要防止单主模式Secondary节点写入异步复制通道数据。也就是说一个节点不能同时是MGR集群的Secondary接地那和Mater-slave复制的Slave节点。
b、单主模式的primary节点以及多主模式下，节点可以作为异步复制的slave节点。注意：在节点写入异步复制通道数据前，需要检查MGR约束，包括innodb表、需要显示主键、没有cascade外键等。
c、当节点退出MGR，使用super_read_only自动设置为off，但无法阻塞relay-log中的事务回放。
b、若配置mysqld重启后自动启动MGR和异步复制通道，需要确保顺序协调一致。原则是确保MGR先于异步复制通道启动，MGR接地那变为ONLINE转台后再启动异步复制通道

17、监控表
replication_group_member_stats ：提供事务认证过程相关的信息。包括查看冲突数，检查事务数，提交事务数等。可以利用分析延迟
replication_group_members ：集群转态信息

18、组通信线程

调整：
group_replication_poll_spin_loops= 10000;

19、消息碎片

mysql8.0.16及以上 增加参数：group_replication_communication_max_message_size变量指定允许的最大大小，默认10MiB，将每个块广播到组，即将每个块单独转发到Xcom。

20、xcom缓存管理

mysql8.0.16及以上，增加group_replication_message_cache_size参数设置缓存大小限制，默认值为1G。如果达到缓存大小的限制，Xcom将删除已决定和交付的最大条目。之前版本没有相关参数系统默认1G。

如果尝试重新连接无法访问的成员需要恢复消息，但该消息高速缓存中删除，测该成员无法重新连接。因此需要使用group_replication_member_expel_timeout参数增加延迟时间。

附一、常见问题总结

1、
已成功跑起来的MGR
当把所有的节点都重启，再启动第一个节点是需要开启引导，逐个启动其他节点的group_replication。
如果在加入其他节点时，一直处于一下报错

2019-08-08T09:51:02.184851Z 180 [ERROR] [MY-010584] [Repl] Slave I/O for channel 'group_replication_recovery': error connecting to master 'rep@tidb1:3306' - retry-time: 60  retries: 1, Error_code: MY-002061
2019-08-08T09:51:02.283013Z 28 [ERROR] [MY-011582] [Repl] Plugin group_replication reported: 'There was an error when connecting to the donor server. Please check that group_replication_recovery channel credentials and all MEMBER_HOST column values of performance_schema.replication_group_members table are correct and DNS resolvable.'
2019-08-08T09:51:02.283107Z 28 [ERROR] [MY-011583] [Repl] Plugin group_replication reported: 'For details please check performance_schema.replication_connection_status table and error log messages of Slave I/O for channel group_replication_recovery.'

需要执行：mysql -h第一个masterip -uroot -proot123 进入在退出。

2、非innodb存储引擎和没有主键或非null唯一键

插入数据报错：

ERROR 3098 (HY000): The table does not comply with the requirements by an external plugin.

MGR要求：

1.InnoDB存储引擎：数据必须存储在InnoDB事务存储引擎中。
2.主键：组要复制的每个表都必须定义显式主键。

3、官方文档提供的常见问题

https://dev.mysql.com/doc/refman/8.0/en/group-replication-frequently-asked-questions.html

附二、mysql8的新特性

1、redo log 重构日志系统，采用无锁化，并发写入
MTR被并发写入 redo log buffer，
使用link_buf数据结构，并以环形结构对一个连续的MTR分配内存空间区间，新写入的MTR复用旧的MTR的空间位置

redo log有两个独立的线程：log_writer和 log_flusher
log_writer:负责将redo log buffer中的数据写入到os cache中。
log_flusher: 负责不停地执行fsync操作将os cache 中的数据真正写入磁盘中。

类似生产者/消费者持久队列

2、事务认证 、复制并发

冲突检查数据库，进行事务认证

3、writeSet组提交

即事务DML操作更改的记录信息
WriteSet是基于MTS实现的，利用冲突检查数据库来决定并行回放还是回滚。

可以修改certification_info的清理规则，不再基于gtid_executed，而仅需确保一个提交组内尽可能多的事务即可.

paxos协议数据包里包含gtid_executed信息，即事务快照版本。在进行事务认证时，会对比事务携带的gtid_executed和certification_info里面对应的gtid_set。

primary和unique索引会产生writeset，还进一步解释了每个writeset包含了哪几部分：索引名称+db名+db名长度+表名+表名长度+构成索引唯一性的每个列的值+值长度。二级索引不会产生writeset。

https://dev.mysql.com/worklog/task/?id=9556
http://mysql.taobao.org/monthly/2018/06/04/
https://zhuanlan.zhihu.com/p/55323854

4、mysqlbinlog支持协议压缩

mysqlbinlog [--compress|-C] --read-from-remote-server 

5、 XCOM

named eXtended COMmunications, or simply XCOM

6、

binlog-checksum=NONE
group_replication_member_expel_timeout=60

7、索引跳跃扫描

index skip scan （ISS）

ISS 可以在查询过滤组合索引不包括最左列的情况下，走索引扫描，而不必要单独建立额外的索引。

8、字符集默认utf8mb4
MySQL支持了Unicode 9.0
utf8指向的utfmb4

9、实现了DDL的原子性

10、参数持久化

set persist XXXX;
restart;

mysqld-auto.cnf 持久化文件

11、row_number() rank()等

12、可以自动调整内存大小

13、jion的优化

14、数据克隆插件(clone plugin)

15、松散索引扫描主要用于GROUP BY / DISTINCT优化​​
16、快速加字段（不能快速加索引、drop 字段）