mysql数据库深度优化工具_MySQL高可用数据库内核深度优化的四重定制

最新推荐文章于 2022-05-16 15:39:45 发布

春秋读书读春秋

最新推荐文章于 2022-05-16 15:39:45 发布

阅读量89

点赞数

文章标签： mysql数据库深度优化工具

本文链接：https://blog.csdn.net/weixin_34593927/article/details/113908832

版权

【51CTO晃荡】8.26 带你与清华大年夜学、搜狗、京东大年夜咖们一路商量基于算法的IT运维实践

c3fd2b081ac4e1f67ae88950e44fee62.jpg-wh_651x-s_3691887151.jpg

一、UDB高可用数据库架构UDB以虚拟IP、HAProxy、单节点UDB数据库搭建双节点高可用架构：

双节点的UDB数据库包管数据库数据的全量冗余，同时包管数据库的可用性;

HAProxy在同一时光只连接一个UDB节点，避免多点写入带来的数据冲突问题;

双节点HAProxy包管Proxy的可用性;

虚拟IP在HAProxy产生宕机时经由过程IP漂移的方法对HAProxy进行切换，用户不须要再次修改IP。

在上述架构中，大年夜节点UDB的数据是否完全、是否与主库包管数据一致性是全部高可用架构的关键，所以用于数据传输的半同步复制起着至关重要的感化。针对原生的半同步复制，我们作了内核层面的深度优化。

二、UDB数据库深度优化

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

复制流程，如上图所示，重要经由如下几个步调：MySQL Server履行SQL成功后，记录binlog;

Dump线程攫取binlog后，发送到大年夜机IO线程;

IO线程将接收到的binlog记录到relay log中，同时记录接收进度到master.info中;

SQL攫取relay log中的日记内容进行复现，同时记录复制日记的进度到relay-log.info中。

我们在原生复制的基本上做了内核的深度优化，针对上述流程中的部分步调，在功能和机能上做了改进，使得 UDB加倍稳定。

1、Binlog日记复制优化

存在的问题

原生半同步复制存在退化问题，在收集颤抖导致超时或者大年夜库追赶主库日记进度时，复制会由半同步复制退化为异步复制。

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

比拟于靠得住的半同步复制，异步复制过程中，大年夜库是没有办法感知接收到relay log与主库的binlog是否一致。如不雅产生宕机，也就没有办法确认大年夜库数据是否与主库一致，是否可以产生数据库切换，这种不肯定的情况是我们不欲望看到的。

优化筹划

如上图所示，昔时夜库产生宕机或者收集产生故障后，主大年夜复制停止。昔时夜库复制恢复正常后，原生复制通道经由过程异步复制的方法进行数据追补，UDB复制通道只接收最新的binlog记录地位，如许可以最大年夜限度地削减主大年夜之间异步复制的时光。即在收集可连通的情况下，无论何时产生宕机，大年夜库均知道与主库是否处于数据一致的状况(或者落后了若干)。

2、Relay log文件记录的优化

三、总结

存在的问题

在MySQL中，binlog是以event为根本单位进行记录，以MySQL 5.7 ROW格局(开启GTID)的binlog为例，一个DML(insert)会以5个event的格局记录到binlog中(其他操作均以一个或者多个event构成，不再一一列举)，分别为：GTID_EVENT：记录当前事务的GTID

QUERY_EVENT：事务开端

TABLE_MAP_EVENT：操尴尬刁难应的表

WRITE_ROW_EVENT：插入记录

XID_EVENT：提交事务

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

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

优化筹划

优化IO线程记录relay log的方法，将以event为单位记录，修改为以事务为单位进行记录。归并IO线程小的IO操作，进步IO机能。