查看原文
其他

Changes in GreatSQL 8.0.25 (2021-8-26)

GreatSQL社区 老叶茶馆 2024-07-08

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

1.新增特性

1.1 新增节点地理标签

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

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

1.2 采用全新的流控机制

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

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

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

System Variable Namegroup_replication_flow_control_replay_lag_behind
Variable Scopeglobal
Dynamic VariableYES
Permitted Values[0 ~ ULONG_MAX]
Default60
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 Nameforce_parallel_execute
Variable Scopeglobal, session
Dynamic VariableYES
Permitted ValuesON/OFF
DefaultOFF
Description设置并行查询的开关,bool值,on/off。默认off,关闭并行查询特性。


System Variable Nameparallel_cost_threshold
Variable Scopeglobal, session
Dynamic VariableYES
Permitted Values[0, ULONG_MAX]
Default1000
Description设置SQL语句走并行查询的阈值,只有当查询的估计代价高于这个阈值才会执行并行查询,SQL语句的估计代价低于这个阈值,执行原生的查询过程。


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


System Variable Nameparallel_max_threads
Variable Scopeglobal, session
Dynamic VariableYES
Permitted Values[0, ULONG_MAX]
Default64
Description设置系统中总的并行查询线程数。


System Variable Nameparallel_memory_limit
Variable Scopeglobal, session
Dynamic VariableYES
Permitted Values[0, ULONG_MAX]
Default1073741824(1GB)
Description并行执行时leader线程和worker线程使用的总内存大小上限。


System Variable Nameparallel_queue_timeout
Variable Scopeglobal, session
Dynamic VariableYES
Permitted Values[0, ULONG_MAX]
Default0
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项目主页

继续滑动看下一个
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存