如何理解MySQL高可用数据库内核深度优化的四重定制

发布时间:2021-11-29 10:58:46 作者:柒染
来源:亿速云 阅读:142

如何理解MySQL高可用数据库内核深度优化的四重定制,相信很多没有经验的人对此束手无策,为此本文总结了问题出现的原因和解决方法,通过这篇文章希望你能解决这个问题。

如何理解MySQL高可用数据库内核深度优化的四重定制

近期我们的数据库团队对原生复制的多个方面进行了深度优化,提升了UDB高可用数据库的功能和性能。今天借社群这个平台,跟大家分享一二。

一、UDB高可用数据库架构

虚拟IP在HAProxy发生宕机时通过IP漂移的方式对HAProxy进行切换,用户不需要再次修改IP。

如何理解MySQL高可用数据库内核深度优化的四重定制

在上述架构中,从节点UDB的数据是否完整、是否与主库保证数据一致性是整个高可用架构的关键,所以用于数据传输的半同步复制起着至关重要的作用。针对原生的半同步复制,我们作了内核层面的深度优化。

二、UDB数据库深度优化

UDB是以开源数据库MySQL Community Server 5.7.16为基线版本,围绕高可用架构做内核深度优化。

如何理解MySQL高可用数据库内核深度优化的四重定制

复制流程,如上图所示,主要经过如下几个步骤:

我们在原生复制的基础上做了内核的深度优化,针对上述流程中的部分步骤,在功能和性能上做了改进,使得 UDB更加稳定。

1、Binlog日志复制优化

存在的问题

原生半同步复制存在退化问题,在网络抖动导致超时或者从库追赶主库日志进度时,复制会由半同步复制退化为异步复制。

相比于可靠的半同步复制,异步复制过程中,从库是没有办法感知接收到relay  log与主库的binlog是否一致。如果发生宕机,也就没有办法确认从库数据是否与主库一致,是否可以发生数据库切换,这种不确定的情况是我们不希望看到的。

优化方案

建立双通道复制,在原有半同步复制的基础上增加一条UDB复制通道:

如何理解MySQL高可用数据库内核深度优化的四重定制

如上图所示,当从库发生宕机或者网络发生故障后,主从复制停止。当从库复制恢复正常后,原生复制通道通过异步复制的方式进行数据追补,UDB复制通道只接收***的binlog记录位置,这样可以***限度地减少主从之间异步复制的时间。即在网络可连通的情况下,无论何时发生宕机,从库均知道与主库是否处于数据一致的状态(或者落后了多少)。

2、Relay log文件记录的优化

存在的问题

在MySQL中,binlog是以event为基本单位进行记录,以MySQL 5.7  ROW格式(开启GTID)的binlog为例,一个DML(insert)会以5个event的格式记录到binlog中(其他操作均以一个或者多个event组成,不再一一罗列),分别为:

全部event组成一个完整的事务,完整的事务才会被SQL线程正确复现到从库上。当前IO线程接收binlog时,是以event为单位进行接收,即接收到一个event,记录到relay  log中后再继续接收下一个。这种做法是低效的,也没有充分利用到MySQL本身的文件缓存。

优化方案

优化IO线程记录relay log的方式,将以event为单位记录,修改为以事务为单位进行记录。合并IO线程小的IO操作,提高IO性能。

如何理解MySQL高可用数据库内核深度优化的四重定制

将单个的event写操作合并为多个event统一写操作,将小的IO操作合并成较大的IO操作,提高IO性能。

3、Master.info文件记录的优化

存在的问题

Master.info文件在搭建复制时,记录主库IP、PORT等连接主库的相关信息,在复制过程中,记录IO线程从主库接收到的binlog的文件名和位置,文件和位置会在每次记录relay  log成功后更新。

在基于GTID搭建复制后,master.info中记录的binlog文件和位置不再作为复制的依据,所以master.info中记录的binlog的文件和位置不再是有效的数据,也就没有必要每次进行更新。

优化方案

在IO线程记录relay  log成功后,更新master.info文件之前,添加判断。如果开启了GTID并且使用GTID作为复制的依据(auto_position=1),那么不再更新master.info中binlog的文件和位置。

其它的master.info操作仍然保留,如change master、shutdown等操作。

4、Relay log锁的优化

存在的问题

在IO线程和SQL线程复制进度相似的情况下,在操作relay  log时,会使用同一块文件缓存,在读写文件缓存时,需要加锁来保证操作的正确性。而IO线程和SQL线程需要频繁地读写这块公共内存,就需要对同一把锁频繁的竞争,从而导致性能下降。

优化方案

将IO线程和SQL线程对relay  log的操作拆分开来,不再使用同一块文件缓存。虽然这样做会导致SQL线程增加一次读IO操作。但是消除了对锁的竞争,大大地提高了IO线程和SQL线程整体的性能。

如何理解MySQL高可用数据库内核深度优化的四重定制

三、总结

优化后的复制流程图如下:

如何理解MySQL高可用数据库内核深度优化的四重定制

数据库原生复制流程中包括记录binlog、记录relay  log、记录master.info、relay-log.info等,针对上述流程中的部分步骤以及其它未列出的优化,在功能和性能上进行改进,UDB高可用数据库在功能和性能上均得到了明显的提升。

看完上述内容,你们掌握如何理解MySQL高可用数据库内核深度优化的四重定制的方法了吗?如果还想学到更多技能或想了解更多相关内容,欢迎关注亿速云行业资讯频道,感谢各位的阅读!

推荐阅读:
  1. Apache深度优化
  2. Nginx深度优化

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

数据库 mysql

上一篇:MySQL InnoDB内存压力判断以及存在的疑问是怎样的

下一篇:C/C++ Qt TreeWidget单层树形组件怎么应用

相关阅读

您好,登录后才能下订单哦!

密码登录
登录注册
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》