MySQL 5.7 高可用数据库内核深度优化三步走

阅读数:146 2019 年 11 月 13 日 18:58

MySQL 5.7高可用数据库内核深度优化三步走

UDB 是 UCloud 提供的云数据库,支持实例级别的高可用。UCloud 数据库团队在数据库原生复制的多个方面进行了深度优化,提升了 UDB 高可用数据库的功能和性能。

一、UDB 高可用数据库架构

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

  • 双节点的 UDB 数据库保证数据库数据的全量冗余,同时保证数据库的可用性;
  • HAProxy 在同一时间只连接一个 UDB 节点,避免多点写入带来的数据冲突问题;
  • 双节点 HAProxy 保证 Proxy 的可用性;
  • 虚拟 IP 在 HAProxy 发生宕机时通过 IP 漂移的方式对 HAProxy 进行切换,用户不需要再次修改 IP。

MySQL 5.7高可用数据库内核深度优化三步走

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

二、UDB 数据库深度优化

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

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

  • MySQL Server 执行 SQL 成功后,记录 binlog;
  • Dump 线程读取 binlog 后,发送到从机 IO 线程;
  • IO 线程将接收到的 binlog 记录到 relaylog 中,同时记录接收进度到 master.info 中;
  • SQL 读取 relaylog 中的日志内容进行复现,同时记录复制日志的进度到 relay-log.info 中。

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

1、Relay log 文件记录的优化

  • 存在的问题

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

  • GTID_EVENT:记录当前事务的 GTID
  • QUERY_EVENT:事务开始
  • TABLE_MAP_EVENT:操作对应的表
  • WRITE_ROW_EVENT:插入记录
  • XID_EVENT:提交事务

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

  • 优化方案

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

MySQL 5.7高可用数据库内核深度优化三步走

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

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

  • 存在的问题

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

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

  • 优化方案

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

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

3、Relay log 锁的优化

  • 存在的问题

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

  • 优化方案

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

MySQL 5.7高可用数据库内核深度优化三步走

三、总结

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

MySQL 5.7高可用数据库内核深度优化三步走

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

本文转载自公众号 UCloud 技术(ID:ucloud_tech)。

原文链接:

https://mp.weixin.qq.com/s/fGk8kcIOVgXkTw1p4MknyQ

评论

发布