Changes in GreatSQL 8.0.25 (2021-8-26)

本文首发于 GreatSQL社区 微信公众号。

1.新增特性

1.1 新增节点地理标签

可以对每个节点设置地理标签，主要用于解决多机房数据同步的问题。新增选项 group_replication_zone_id，用于标记节点地理标签。该选项值支持范围 0 ~ 8，默认值为0。当集群中各节点该选项值设置为不同的时候，就被认定为设置了不同的地理标签。在同城多机房部署方案中，同一个机房的节点可以设置相同的数值，另一个机房里的节点设置另一个不同的数值，这样在事务提交时会要求每组 group_replication_zone_id 中至少有个节点确认事务，然后才能继续处理下一个事务。这就可以确保每个机房的某个节点里，总有最新的事务。

System Variable Name	group_replication_zone_id
Variable Scope	global
Dynamic Variable	YES
Permitted Values	[0 ~ 8]
Default	0
Description	设置MGR各节点不同的地理标签，主要用于解决多机房数据同步的问题。 修改完该选项值之后，要重启MGR服务才能生效。

1.2 采用全新的流控机制

原生的流控算法有较大缺陷，触发流控阈值后，会有短暂的流控停顿动作，之后继续放行事务，这会造成最大1秒的性能抖动，且没有真正起到通用持续流控的作用。

在GreatSQL中，重新设计了流控算法，增加主从延迟时间来计算流控阈值，并且同时考虑了大事务处理和主从节点的同步，流控粒度更细致，不会出现官方社区版本没有必要的1秒小抖动问题。

新增选项 group_replication_flow_control_replay_lag_behind 用于控制MGR主从节点复制延迟阈值，当MGR主从节点因为大事务等原因延迟超过阈值时，就会触发流控机制。

System Variable Name	group_replication_flow_control_replay_lag_behind
Variable Scope	global
Dynamic Variable	YES
Permitted Values	[0 ~ ULONG_MAX]
Default	60
Description	用于控制MGR主从节点复制延迟阈值，当MGR主从节点因为大事务等原因延迟超过阈值时，就会触发流控机制

该选项默认为60秒，可在线动态修改，例如：

mysql> SET GLOBAL group_replication_flow_control_replay_lag_behind = 60;

正常情况下，该参数无需调整。

2.稳定性提升

2.1 支持AFTER模式下多数派写机制

这样在发生网络分区时，依然可以保障集群的高可用性。发生网络分区故障时，只要多数派节点已经回放完毕，集群就可以继续处理新的事务。

2.2 解决磁盘空间爆满时导致MGR集群阻塞的问题

在官方社区版本中，一旦某个节点磁盘空间满了，就会导致整个集群被阻塞， 这种情况下，节点数量越多，可用性越差。

在GreatSQL版本中，一旦发现某节点磁盘空间满了，就会让这个节点主动退出集群，就可以避免整个集群被阻塞的问题。

2.3 解决多主模式下或切主时可能导致丢数据的问题

官方社区版本中，是提前处理事务认证数据的。

而在GreatSQL版本中，调整了事务认证处理流程，改成放到 applier queue 里按照paxos顺序处理，这就解决了在多主模式下或切主时可能导致丢数据的问题。

2.4 解决节点异常退出集群时导致性能抖动的问题

官方社区版本中，paxos通信机制较为粗糙，当节点异常退出时，会造成较长时间（约20~30秒）的性能抖动，最差时TPS可能有好几秒都降为0。

GreatSQL版本中对此进行优化后，只会产生约1~3秒的性能小抖动，最差时TPS可能只损失约20% ~ 30%。

2.5 节点异常状态判断更完善

当发生节点异常崩溃时，GreatSQL版本能更快发现这些异常状态。官方需要5秒才能发现，而GreatSQL只需要大概1秒，这就能有效减少切主和异常节点的等待耗时。

2.6 优化日志输出格式

增加更多DEBUG信息，便于排查MGR运行时遇到的问题。

3.性能提升

3.1 重新设计事务认证队列清理算法

官方社区版本中，对事务认证队列清理时采用了类似全表扫描的算法，清理效率较低，性能抖动较大。

在GreatSQL版本中，对事务认证队列增加了类似索引机制，并控制每次清理的时间，可以有效解决清理效率低、性能抖动大的问题。

3.2 提升一致性读性能

提升一致性读性能，使得从库只读延迟大大降低。

4. 合并华为鲲鹏计算团队贡献的Patch

4.1 InnoDB事务对象映射数据结构优化

在官方社区版本实现中，使用了红黑树结构实现了事务ID到事务对象的快速映射关系。但是该数据结构在高并发应用场景中，大量的锁竞争会造成事务处理的瓶颈。

在GreatSQL中采用全新的无锁哈希结构，显著减少了锁的临界区消耗，提升事务处理的能力。

4.2 InnoDB并行查询优化

根据B+树的特点，可以将B+树划分为若干子树，此时多个线程可以并行扫描同一张InnoDB表的不同部分。对执行计划进行多线程改造，每个子线程执行计划与MySQL原始执行计划一致，但每个子线程只需扫描表的部分数据，子线程扫描完成后再进行结果汇总。通过多线程改造，可以充分利用多核资源，提升查询性能。

优化后，在TPC-H测试中表现优异，最高可提升30倍，平均提升15倍。该特性适用于周期性数据汇总报表之类的SAP、财务统计等业务。

使用限制：

• 暂不支持子查询，可想办法改造成JOIN。
• 暂时只支持ARM架构平台，X86架构平台优化预计一个月后完成。

新增参数选项

System Variable Name	force_parallel_execute
Variable Scope	global, session
Dynamic Variable	YES
Permitted Values	ON/OFF
Default	OFF
Description	设置并行查询的开关，bool值，on/off。默认off，关闭并行查询特性。

System Variable Name	parallel_cost_threshold
Variable Scope	global, session
Dynamic Variable	YES
Permitted Values	[0, ULONG_MAX]
Default	1000
Description	设置SQL语句走并行查询的阈值，只有当查询的估计代价高于这个阈值才会执行并行查询，SQL语句的估计代价低于这个阈值，执行原生的查询过程。

System Variable Name	parallel_default_dop
Variable Scope	global, session
Dynamic Variable	YES
Permitted Values	[0, 1024]
Default	4
Description	设置每个SQL语句的并行查询的最大并发度。 SQL语句的查询并发度会根据表的大小来动态调整，如果表的二叉树太小（表的切片划分数小于并行度），则会根据表的切片划分数来设置该查询的并发度。每一个查询的最大并行度都不会超过parallel_default_dop参数设置的值。

System Variable Name	parallel_max_threads
Variable Scope	global, session
Dynamic Variable	YES
Permitted Values	[0, ULONG_MAX]
Default	64
Description	设置系统中总的并行查询线程数。

System Variable Name	parallel_memory_limit
Variable Scope	global, session
Dynamic Variable	YES
Permitted Values	[0, ULONG_MAX]
Default	1073741824（1GB）
Description	并行执行时leader线程和worker线程使用的总内存大小上限。

System Variable Name	parallel_queue_timeout
Variable Scope	global, session
Dynamic Variable	YES
Permitted Values	[0, ULONG_MAX]
Default	0
Description	设置系统中并行查询的等待的超时时间，如果系统的资源不够，例如运行的并行查询线程已达到parallel_max_threads的值，并行查询语句将会等待，如果超时后还未获取资源，将会执行原生的查询过程。 单位：毫秒

新增状态变量

• PQ_threads_running global级别，当前正在运行的并行执行的总线程数。

• PQ_memory_used global级别，当前并行执行使用的总内存量。

• PQ_threads_refused global级别，由于总线程数限制，导致未能执行并行执行的查询总数。

• PQ_memory_refused global级别，由于总内存限制，导致未能执行并行执行的查询总数。

5.bug修复

• 修复了AFTER模式下的多个bug，提高一致性写AFTER模式的可靠性。例如有新节点加入时，由于消息处理不当、线程同步等问题容易导致一系列异常退出集群的现象。
• 修复了多数派节点不同类型异常退出集群导致的视图更新的问题。当节点崩溃和节点退出同时发生的话，可能会导致MGR视图跟实际情况不符，从而出现一系列不异常问题。
• 修复了MGR部署在单机环境下多节点的TCP self-connect问题。相关bug #98151。
• 修复了recover过程中长时间等待的问题。同时启动多个节点，可能会导致一直卡在recovering状态，持续时间很久（甚至可能超过数小时）。修复了几处不合理的sleep做法，解决该问题。
• 修复了传输大数据可能导致逻辑判断死循环问题。
• 修复若干coredump问题
• a）执行start group_replication 和查询 replication_group_member_stats 并发操作时，可能导致 start group_replication 启动失败，甚至节点coredump。
• b）执行 start group_replication 启动过程可能失败，在销毁内部对象过程中，如果同时查询 replication_group_member_stats 状态，可能导致coredump。

6.使用注意事项

• 当MGR集群处于recovering状态，并且还有业务流量时，【不要】执行stop group_replicationt停止MGR服务，否则可能会导致GTID紊乱甚至丢数据风险。
• 选项 slave_parallel_workers 建议设置为逻辑CPU数的2倍，提高从库回放时的并发效率。
• 设置 group_replication_flow_control_replay_lag_behind 参数后，原生MGR中的流控参数不再起作用，GreatSQL会根据队列长度、大小自动进行流控。
• 在MGR节点正式拉起之前，务必设置 super_read_only=ON（或者确保此时不会有人修改数据）。
• 选项 group_replication_unreachable_majority_timeout 建议不要设置，否则网络分区的时候，给用户返回错误，但其它分区多数派已经提交了事务。
• 出于问题诊断需要，建议设置 log_error_verbosity=3。

Enjoy GreatSQL :)

---

文章推荐：

---

扫码加入GreatSQL/MGR交流QQ群

点击文末“阅读原文”直达GreatSQL项目主页