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

一、UDB高可用数据库架构

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

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

二、UDB数据库深度优化

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

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

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

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

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

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

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

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等操作。

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

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

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

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

本文转载自公众号UCloud技术（ID：ucloud_tech）。

原文链接：

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