【华为云MySQL技术专栏】TaurusDB备机数据页预热：解决主备切换后，性能下降问题

一、背景介绍

在传统主备高可用的基础上，TaurusDB采用了计算存储分离架构，基于DFV共享存储，解决了主备复制延迟的问题，提升了存储可靠性。当实例主节点因服务器软硬件故障、升级等原因导致不可用时，TaurusDB通过秒级切换和只读升主的方式，实现业务的快速恢复，增强了数据库系统的容灾能力，确保了服务的连续性和稳定性。

然而，新主节点在升主前，由于业务类型和原主节点不同，其缓冲池（Buffer Pool，BP）中的页面与原主节点会存在较大差异。因此，当新主节点首次访问相关数据时，很有可能需要从存储重新加载页面到BP中，这会导致访问时延明显增加。只有在相关页面重新加载完成后，访问时延才能恢复到倒换前的正常水平。

简而言之，主节点切换后，由于BP中的页面缺失，系统会经历一段时间的性能下降，而下降的时长视实例的规格和访问模式等决定。

为了解决这个问题， TaurusDB推出了数据页面预热功能，即将主节点BP里的数据页信息实时同步到备节点，在备节点的BP中持续并行加载相关页面。该备节点升主之后，仍可以直接从BP中获取相关数据页，从而有效地解决了主备倒换后，因BP页面缺失导致的性能下降的问题。

二、原理介绍

TaurusDB使用BufferPool来减少页面访问时的I/O操作，依据页面访问频率在BP中划分young区和old区。当页面初次被访问时，会先被加载到old区，如果持续活跃，就会移动到young区；反之，如果页面不再活跃，将会从young区移回到old区，并最终从BP中淘汰（清除），以此来提高访问热点页面的性能表现。

当向BP中加载页面时，系统通过表空间id（tablespace id，后续简写为space id）和页号（page no）可以锁定唯一页面。

由于TaurusDB采用主备节点共享存储的架构，故主备节点间无需将完整的页面进行同步，仅需要同步space id和page no，备节点即可从共享存储中获取特定页面，大幅减少同步页面的带宽开销。

TaurusDB使用Fil_shard类对表空间的文件访问进行管理。当首次打开表空间时，会调用space_add()将表空间添加到对应的shard中。当需要使用tablespace时，可以调用get_space_by_id() 或 get_space_by_name()来获取space对象。

当页面信息通过space id和page no同步到备节点时，如果表空间之前未打开过，则需要从存储中查询该表空间，并将其添加到Fil_shard中，便于后续根据space信息得到页面并添加到BP中。因此，对于表空间不存在于备节点Fil_shard中的页面，主节点还需要额外发送表空间的元数据信息，用以在备节点从存储中获取该表空间。

三、流程解析

3.1 备机预热整体流程概览

图1 备机预热整体流程

备机预热整体流程，如图1所示，具体如下：

1）启用备机预热时，备机会发起建立一个主备节点间的长链接，专用于页面信息的同步。

2）主机新增一个RingBuffer（环形缓冲区，简称RB），用于持续缓存BP中活动的页面，比如，当某个页面首次加载到BP中，从old区移动到young区或者young区内移动到头部，该页面都会被缓存到RB中。RB采用类似循环链表的方式，当写到尾部后，则回到头部覆盖原有数据继续写入。

3）备机中存在一个用于预热页面的周期任务，当备机中的所有页面处理完成时，就会向主机索取新的一批页面用于预热。收到备机索取页面的请求后，主机会识别RB中该备机未读取过的所有页面信息一并同步。

4）备机收到页面信息后，依据页面元数据获取该页面并将其加载到BP中，直到所有页面处理完成。

5）主节点重复步骤2，备节点重复步骤3、4、5，使得主节点的页面源源不断地加载到备节点的BP中。

3.2 备机处理流程

图2 备机处理流程

备机的整体目标就是根据主机同步过来的页面信息，持续地获取页面并加载到BP中，考虑到读取效率，采用异步读的方式实现页面到BP的加载。下面，从备机同步的不同页面类型介绍图2中的备机处理流程。

第一种，无页面。即该周期主机侧没有页面活动。

第二种，普通页面。

（1）页面的表空间在备机上首次访问时，Fil_shard中不存在该表空间，需要从存储中获取。查询存储还需要提供除space id之外的元数据，这些信息在备机上获取非常麻烦。考虑到表空间已经存在于主机的shard中，那么一个简单的做法是当备机首次访问页面的表空间失败时，将页面信息发回给主机补齐必要的元数据，在下一周期使用。这个发回主机的页面信息称之为重试页面信息。

（2）如果对应的表空间已经存在于Fil_shard中，则根据space id从shard中获取space对象，再结合page no获取到页面加载到BP中。

第三种，重试页面。

先利用表空间元数据信息从存储中获取页面的表空间对象，然后结合page no获取对应页面加载到BP中。

3.3 主机处理流程

图3 主机处理流程

主机处理流程，如图3所示，具体如下：

1）新增一个预热序列号（Preload Sequence Number，PSN），用来记录页面的采集、消费情况，RB中每新增一个页面，PSN增1，于是RB中最大的PSN即标识最新写入的页面。主机侧需要维护每个备机上次读取时的PSN，这样当有备机索取页面时，PSN增量（闭区间[备机PSN+1, RB最大PSN]）对应的全部有效页面即为本批次需要同步的页面。

2）主机处理的页面，包含两种：

第一种，备机发送的重试的页面，需获取这些页面的表空间元数据返回给备机，以便备机快速获取space对象；

第二种，缓存在RB中的热点页面。

3） 主机维护每个备机的页面读取情况，记录对应备节点的PSN：

• RB中的页面缓存采用的是一种best effort的处理方式，即当业务量很大时，RB缓存的页面来不及消费导致RB填满（RB中的所有页面都未被任一个备机消费）时，不再缓存新的热点页面，直到有备机请求消费RB中的页面。

• 任一个备机消费了RB的页面，就允许继续向RB中写入页面。

• 多备机场景下，可能出现某个备机PSN落后的差值大于RB的长度（参考图6中备机2的读取），此时，将RB所有有效的页面按照PSN顺序发给该备机，并将其PSN刷新为所读取页面的最大PSN。需要注意，此时部分页面可能因为被覆盖而不再同步给备机。

4）当一个周期中发送的页面数量超过网络报文最大长度约束时，优先保证重试页面发回备机，否则，将导致备机永远都获取不到有效的space元数据，从而一直在进行页面重试。

3.4 主机RB中，页面的消费过程

对于主机RB中的页面，其消费包含两种典型场景：

其一，业务空闲时，RB中新增热点页面较慢，意味着备机消费请求到达时，RB中需要发送的页面数量（PSN增量）要小于RB页面的总长度，此时每一个写入RB中的热点页面都可以有效发送给备机。

其二，业务繁忙时，RB中新增热点页面较快，如前所述，当RB中的页面已满但仍没有备机消费时，则不再写入，直到有备机来消费时，再将满足PSN范围的所有页面发送。

下面通过图4、图5和图6，详细介绍典型场景的RB写入和发送。其中，xN表示RB中页面的位置（按照x1、x2、x3……增长），tN表示备机向主机RB请求页面的时刻（按照t1、t2、t3……增长），PSN_tN_xN表示tN时刻读取的xN处页面对应的PSN，不同颜色表示不同的备机。

情况1：当业务空闲时，备机读取快于RB写入。

图4 备机读取快于RB写入示意图

如图4所示，业务空闲时，RB中页面的写入和发送过程如下：

t1：RB发送最新页面在x1处的所有页面给备机1，同时，将备机1的PSN刷新为PSN_t1_x1。

t2：RB发送最新页面在x2处的所有页面给备机2，同时，将备机2的PSN刷新为PSN_t2_x2。

t3：收到备机1请求，RB最新写入页面在x3，其PSN为PSN_t3_x3，那么t1→t3，需要发送的页面对应的PSN范围为[PSN_t1_x1+1, PSN_t3_x3]，即要将[x1+1, x3]内的所有页面发给备机1。发送完成后，将备机1的PSN刷新为PSN_t3_x3。

t4：收到备机2请求，RB最新写入页面在x4，其PSN为PSN_t4_x4，那么t2→t4，需要发送的页面对应的PSN范围为[PSN_t2_x2+1, PSN_t4_x4]，即要将[x2+1 ,x4]内的所有页面发给备机2。发送完成后，将备机2的PSN刷新为PSN_t4_x4。

情况2：业务繁忙，备机读取慢于RB写入（考虑只有一个备机）。

图5 单备机时，备机读取慢于RB写入示意图

如图5所示，业务繁忙时，考虑只有一个备机，RB中页面的写入和发送过程如下：

t1：RB发送页面在x1处的所有页面给备机1，同时将备机1的PSN刷新为PSN_t1_x1

t2：RB中先从x1位置持续向尾端写入页面信息，再从头位置写入到x1位置，此时最新页面的PSN增长到PSN_t2_x1，RB已写满，即PSN_t2_x1与PSN_t1_x1的差值等于RB的总长度。但是，因为还没有新的备机页面读请求，BP中后续的热点页面丢弃，不再写入RB。

t3：备机1新的页面读请求到达主机，于是根据PSN的增长顺序，将从x1位置到RB尾和RB头到x1位置的页面信息发送给备机。发送完成后，将备机的PSN刷新为PSN_t2_x1。

情况3：业务繁忙，备机读取慢于RB写入（考虑多个备机）。

图6 多备机时，备机读取慢于RB写入示意图

如图6所示，业务繁忙时，考虑有多个备机，RB中页面的写入和发送过程如下：

t1：RB发送最新页面在x1处的所有页面给备机1，同时将备机1的PSN刷新为PSN_t1_x1。

t2：RB发送最新页面在x2处的所有页面给备机2，同时将备机2的PSN刷新为PSN_t2_x2。如果后续不再有新的备机读取请求，参考单备机时的RB写入，RB最多完成从x2到RB尾、再从RB头到x2的页面信息写入。

t3：收到备机1请求，RB最新页面写入到x4，其PSN为PSN_t3_x4，那么t1→t3，需要发送的页面对应的PSN范围为[PSN_t1_x1+1, PSN_t3_x4]，即要将[x1+1,x4]内的所有页面发给备机1。发送完成后，将备机1的PSN刷新为PSN_t3_x4。

因为收到了备机1的读取请求，所以RB刷新了允许写入的范围，即后续如果不再有新的备机读取请求，RB最多完成从x4到RB尾、再从RB头到x4的页面信息写入。

t4：由于t3时刷新了允许写入的范围，所以当写入到x2时，RB不再等待，而是继续向后写入，直到写入到x3时，收到备机2的读请求。但是从t2到t4，x2→x3这一段被写入了两次，因此，这一段第一次写入的页面信息被覆盖而丢弃。

此时，RB最新页在x3，其PSN为PSN_t4_x3，PSN_t4_x3- PSN_t2_x2差值大于RB总长度，即RB中的所有页面都是备机2未同步过的页面。因为x2→x3段第一次写入的页面信息已被覆盖，所以，x3处的页面信息是最新的，x3+1处是最旧的。于是根据PSN的增长顺序，将从x3到RB尾和RB头到x3所有页面信息发给备机2。发送完成后，将备机2的PSN刷新为PSN_t4_x3。

考虑最坏情况，当某个备机特别慢时，因为RB允许的页面写入范围会不断被其他备机刷新，导致对于该备机，会有比较多的页面没有进行预读预热。

四、倒换流程

假设实例为一主（节点1）两备（节点2、节点3），其中指定了节点2优先倒换，其流程如图7所示。

图7倒换流程

• 节点2和节点3在节点1关机后，会在通信中断后，不断尝试与节点1建立连接。

• 节点2下发升主命令后，会退出连接重试，并关闭和节点1的预热链接。升主后，开始和正常主节点一样创建RB，并向RB中写入页面，等待有备机建立预热链接向备机索取页面后，将页面同步给备机。

• 节点3在下发换主命令后，会退出与之前主节点的连接。然后更新主节点信息，与新主节点建立预热链接后，进入正常的周期性与主节点通信，并在其上加载页面到BP中的预热流程。

五、性能测试

测试条件：使用8U32G实例，sysbench只读模型，64张表，每张表200W数据，sysbench run 5分钟后进行主备倒换。

• 未开启备机预热

可以看到，主备倒换后，运行12s时，QPS达到正常水平。

• 开启备机预热

可以看到1s时，QPS就接近正常水平，2s时就完全达到正常水平。

六、影响和约束

开启备机预热时，备机会持续将主机的热点页面信息加载到BP中。如果备机上还有只读业务，那么，只读的页面也会加载到BP中。当BP写满后，因为备机上预热的页面和只读业务涉及的页面可能不同，于是，预热页面和只读页面会争抢BP，两类业务则会不断将对方的页面从BP中淘汰，使得再次访问相关页面时需要从存储中重新加载，从而影响相关的性能表现。

后续，TaurusDB会支持节点级的热备节点，区别于一般的备机或只读节点，该热备节点上仅存在热备业务，从而避免与只读业务的相互影响。

七、总结

备机预热特性，目标是解决因主备倒换产生的较长时间的性能下降的问题，以尽可能保证客户业务系统的稳定运行。本文从技术背景、原理、测试结果、影响和约束等各方面对特性进行了介绍，希望能够对您有所帮助。

关注“GaussDB数据库”公众号，了解第一手行业资讯。