仿做网站可以整站下载器吧/郑州seo教程

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

1.新增特性

1.1 新增节点地理标签

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

1.2 采用全新的流控机制

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

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

新增选项 group_replication_flow_control_replay_lag_behind 用于控制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架构平台优化预计一个月后完成。

  
  

新增参数选项

新增状态变量

• 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 :)

文章推荐：

• 技术分享 | MGR最佳实践(MGR Best Practice)

• 技术分享 | 万里数据库MGR Bug修复之路

• 技术分享 | 浅谈mysql语法解析调试方法

• 万答#6，MySQL最多只能用到128个逻辑CPU，是真的吗

• GreatSQL重磅特性，InnoDB并行并行查询优化测试

• 技术分析 | 浅谈在MySQL体系下SQL语句是如何在系统中执行的及可能遇到的问题

• 产品 | GreatSQL，打造更好的MGR生态

• 产品 | GreatSQL MGR优化参考

扫码加入GreatSQL/MGR交流QQ群

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