【华为云MySQL技术专栏】TaurusDB主备复制原理剖析

1、背景介绍

在数据库架构中，主机、备机以及只读节点（Read Replica）是实现高可用性、负载均衡和数据备份的核心组件。

MySQL的主备使用Share-nothing的架构，通过Binlog实现主备复制。TaurusDB与MySQL的主备架构不同，使用了Share-storage的架构，主备之间也不使用Binlog来实现同步。

本文主要介绍TaurusDB主从复制的实现原理与主要流程。

2、TaurusDB主备架构

与开源MySQL的主备架构不同，TaurusDB是一种Share-storage的架构，主备之间也不使用binlog来实现同步。对于TaurusDB，备机和只读节点是相同的概念。

另一个与开源MySQL不同的地方是，主机写入共享存储系统的，只有Redo日志，数据页面的生成、修改由共享存储系统来进行。主机写Redo日志到共享存储系统，只读节点从共享存储系统读取主机写的Redo日志，来实现主备同步。对于数据页面，主机和只读节点都是从共享存储系统来读取。

这样的架构，新增只读节点不受数据量大小影响，实现了快速新增只读节点；只读节点与主节点的时延也很低，之间直接传输的数据也很少，带宽占用低；只读节点可以快速在线升主来恢复主节点故障。

3、主备复制的主要流程

既然TaurusDB是基于共享存储架构的，只读节点能不能只从共享存储读取数据，不与主机有任何交互呢？答案是不行的。一方面是只读节点必须获取一些位置、大小等元信息，来正确的从共享存储中读取数据；另一方面是只读节点读取数据页面放入自己的缓冲池后，需要持续的通过Redo日志来进行同步，才能知道缓冲池中的哪些数据已经有修改，需要获取新的，哪些没有修改，可以继续使用。还有一些其他需要同步的信息，我们下面来介绍TaurusDB的主备同步主要做了哪些工作。

TaurusDB的只读节点通过处理Redo日志来实现主备同步。主备同步是为了主机新增或修改的数据，只读节点能够尽可能快的查询到。由于TaurusDB的主备使用的是Share-storage的架构，Redo日志并不需要从主机来获取，而是从共享存储读取。主备之间传递的仅是一些必需的元数据信息。

这些主备之间直接同步的元数据信息主要包括以下方面。

主机发送给只读节点：

1.Redo日志在共享存储系统中的位置、大小等元信息，用于读取Redo日志

2.表空间数据页面和共享存储系统分片的映射关系，用于读取数据页面

3.初始的事务快照信息，用于事务的可见性判断，会通过解析redo日志来不断更新

只读节点发送给主机自己不再使用的Redo日志的位点信息（Recycle LSN），自己最“老”的事务快照信息给主机，主机使用这些数据来确定回收数据的范围，避免将只读节点仍可能使用的历史数据进行回收。

只读节点会启动一个与主机通信的线程handle_slave_sync，用于从主机接收和向主机发送所需的元数据信息。其主要逻辑如下。

extern "C" void *handle_slave_sync(void *arg) {
  // ...
  // 连接主机
  safe_connect();
  // ...
  // 获取初始的元数据信息
  get_init_info_from_master();
  // ...
  // 持续同步，发送同步信息，接收并处理主机的同步信息
  while (!abort_slave) {
    // 组装自己的recycle lsn和最“老”事务快照等同步信息并发送
    assemble_global_sync_msg();
    my_net_write();
    apply_sync_msg_from_master();
  }
  // ...
}

通过主备通信线程，只读节点获取了所需的信息，可以进行对于Redo日志的读取和处理。

为了加快处理Redo日志，只读节点会启动多组后台线程进行流水线式的并行处理，线程数量可配置。包括reader、dispatcher、parser、advancer、impeller这几类线程，他们之间通过event来通知唤醒，配合完成处理。当主备通信线程通过同步信息，发现有新的Redo日志时，会通知reader线程从共享存储开始读取Redo日志，然后开始一系列的处理。

如图2所示，多种线程配合完成对于Redo日志的处理，实现主备同步。

Log dispatcher线程：等待log reader线程的通知，分发日志到各个log parser线程。

Log parser线程：等待log dispatcher线程的通知，解析Redo日志，主要是两方面，一是将针对具体数据页面的Redo日志按页面的ID分组整理到一起；二是将其他类型的Redo日志解析处理，待后续处理使用，如汇总已提交的事务的ID等。

Log impeller线程：主要用于处理修改数据页面的Redo日志，将log parser处理后的日志，针对每个不同的页面ID，合并组织到一起；失效缓冲池（Buffer Pool）中的数据页面，并缓存Redo日志到相应的称为Log Directory的目录结构中，用于后续生成新版本的数据页面。

Advancer线程处理其他主备同步动作，主要包括：元数据锁（Metadata Lock，MDL）的处理，避免表的元数据的修改与数据查询产生冲突；事务快照的更新，获取新的活跃事务和已提交的事务，用于事务可见性判断。

Redo日志有多种类型，除了直接针对数据页面内容的修改之外，还包含一些其他信息，需要只读节点进行解析、处理，用于和主机保持同步。对于从共享存储系统读入的每一块Redo日志，都会经过图3中的处理过程。

直接针对数据页面内容的修改的Redo日志，会汇总在按页面ID为key的hash表中。一方面用于Buffer pool中相同ID页面的失效，使得只读节点知晓对于该页面ID，后续需要使用时，要获取新版本的数据页面。另一方面缓存在全局的Log Directory中，使得只读节点在需要新版本的数据页面时，可以自行基于已在Buffer pool中的旧版本页面，回放缓存的对应的Redo日志，来得到新版本的数据页面，减少从共享存储中读取页面的开销，提升性能。

只读节点还需要从各种类型的Redo日志中，解析、处理如下信息。

1.已提交事务的ID列表

通过Redo日志中的已提交的事务ID信息，可以更新活跃事务列表，用于可见性判断。例如对于可重复读隔离级别，已提交的事务，其修改是可见的，而ID值处于这些已提交事务之间的，Redo日志中没有记录其已提交，属于活跃事务，其修改不可见。

2.事务Purge No

用于获取最大的事务ID，以及只读节点事务快照的low limit no的确定。

3.更新和删除的表空间的信息

用于更新space cache，如已删除或大小发生扩展。

4.元数据锁(MDL)相关请求

Redo日志中记录了DDL语句对于MDL锁的申请和释放等，只读节点模拟同样的申请和释放流程，避免元数据的修改和查询之间产生冲突。例如正在使用的索引，发生了删除。

5.需要失效的内存对象，如Query Cache等

6.需要失效的Undo表空间信息

用于处理主机执行的undo truncate等操作。

7.需要更新的统计信息

通过以上处理，只读节点完成了对于主机的同步，可以对外提供针对当前最新数据的查询服务。值得注意的是，TaurusDB并不是强一致性的，从原理上来讲，只读节点和主机之间是一定存在时延的。在上述介绍的Redo处理流程，当前这一轮完成前，只读节点只能提供截止到上一次同步完成的Redo日志的位点（Log sequence number, LSN）的数据查询。

4、总结

与开源MySQL的主备架构不同，TaurusDB使用的共享存储架构，主备之间通过Redo日志实现同步，仅需传递少量的元数据信息。备机从共享存储读取Redo日志，通过失效旧的数据页面、回放元数据锁、更新事务快照、缓存日志等处理，实现了主备快速同步。这种架构的优势在于，新增只读节点不受数据量大小影响，支持快速新增只读节点，且只读节点与主节点之间的时延低、传输的数据带宽占用低；只读节点可以通过快速在线升主来恢复主节点故障。