CN117591552A - 数据处理方法、介质、装置和计算设备 - Google Patents

Abstract

本公开的实施方式提供了一种数据处理方法，涉及云数据库领域。该数据处理方法包括：响应于接收到第一数据的读取请求，确定从节点的第一内存中是否存储第一数据；响应于第一内存中未存储第一数据，根据第一数据的标识信息，在元数据哈希表中确定第一日志记录的起始日志序号；根据起始日志序号，确定第一日志记录在日志文件中的起始位置；根据起始位置，在日志文件中确定第一日志记录；回放第一日志记录，以根据第一数据的长度，在第一日志记录中读取第一数据。本公开通过在第一内存中存储元数据哈希表，可以降低从节点的内存占用，从而实现在共享存储介质中准确读取数据。此外，本公开的实施方式提供了一种介质、装置和计算设备。

Description

数据处理方法、介质、装置和计算设备

技术领域

本公开的实施方式涉及云数据库领域，更具体地，本公开的实施方式涉及数据处理方法、介质、装置和计算设备。

背景技术

本部分旨在为本公开的实施方式提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。

MySQL数据库是目前最为流行的开源数据库之一。随着计算机技术的发展，基于MySQL开发的云原生数据库也越来越多，以PolarDB为例，PolarDB中包括多个MySQL计算节点，这些MySQL计算节点分为主节点和从节点，主节点以读写模式访问网络远端的共享存储介质，从节点以只读模式访问网络远端的共享存储介质。为了使从节点能够提供查询服务，主节点在修改了物理页(Page)的数据时，需要生成对应的日志，从节点通过回放该日志得到新的物理页，实现与主节点保持事务状态和数据同步。

由于从节点的内存有限，若从节点的内存不足，则从节点需要进行物理页淘汰，以释放内存。在物理页淘汰的过程中，可能会淘汰掉通过日志回放得到的新的物理页，若从节点后续需要再次读取该新的物理页，则只能尝试从共享存储介质中读取，而主节点为了提升性能，不会频繁的将新的物理页的数据刷新到共享存储介质中，导致从节点可能在共享存储介质中读取到之前的老页面，也即过去页。

相关技术中，为了解决过去页问题，通常是限制从节点的物理页淘汰，这样虽然不会读取到过去页，但可能会导致从节点的内存膨胀，若从节点的内存被用完，则新的物理页无法存储，导致无法读取新的物理页，从而存在数据读取异常的问题。

发明内容

本公开提供一种数据处理方法、介质、装置和计算设备，以解决由于从节点的内存被用完，新的物理页无法存储导致无法读取新的物理页，从而导致数据读取异常的问题。

在本公开实施方式的第一方面中，提供了一种数据处理方法，应用于云数据库的从节点，云数据库还包括主节点，主节点用于读写数据以及生成读写的日志记录，日志记录所对应的日志文件存储在云数据库的共享存储介质中，从节点通过回放日志记录实现与主节点的数据同步；该数据处理方法包括：响应于接收到第一数据的读取请求，确定从节点的第一内存中是否存储第一数据，第一数据是在主节点中所写的数据，读取请求中携带第一数据的标识信息，第一数据的标识信息用于标识第一数据所在的数据表和第一数据在数据表中的物理页；响应于第一内存中未存储第一数据，根据第一数据的标识信息，在元数据哈希表中确定第一日志记录的起始日志序号，元数据哈希表中存储第一数据的标识信息、起始日志序号和第一数据的长度，第一日志记录与第一数据对应，元数据哈希表存储在第一内存中；根据起始日志序号，确定第一日志记录在日志文件中的起始位置；根据起始位置，在日志文件中确定第一日志记录；回放第一日志记录，以根据第一数据的长度，在第一日志记录中读取第一数据。

在本公开的一个实施例中，从节点还包括日志记录哈希表，日志记录哈希表中存储第一数据的标识信息和第二日志记录，第二日志记录与主节点中预设长度的第二数据对应，日志记录哈希表存储在从节点的第二内存中；在根据第一数据的标识信息，在元数据哈希表中确定第一日志记录的起始日志序号之前，该数据处理方法还包括：响应于第一内存中未存储第一数据，在日志记录哈希表中确定第一数据的标识信息；根据第一数据的标识信息，确定第二日志记录中是否包含第一日志记录；响应于第二日志记录中包含第一日志记录，且第一日志记录的最小日志序号值大于或等于物理页的版本号值，则回放第一日志记录，以读取第一数据。

在本公开的另一个实施例中，根据第一数据的标识信息，在元数据哈希表中确定第一日志记录的起始日志序号，包括：响应于第二日志记录中不包含第一日志记录，或最小日志序号值小于版本号值，根据第一数据的标识信息，在元数据哈希表中确定第一日志记录的起始日志序号。

在本公开的又一个实施例中，根据第一数据的标识信息，确定第二日志记录中是否包含第一日志记录，包括：响应于在日志记录哈希表中查询到第一数据的标识信息，则确定第二日志记录中包含第一日志记录；响应于未在日志记录哈希表中查询到第一数据的标识信息，则确定第二日志记录中不包含第一日志记录。

在本公开的再一个实施例中，元数据哈希表中还存储第一日志记录的终止日志序号，终止日志序号用于表示第一日志记录的回放终止位置。

在本公开的再一个实施例中，还包括：响应于元数据哈希表中的元数据信息的存储时长大于预设时长，异步执行第一操作，第一操作用于指示删除存储时长大于预设时长的元数据信息，元数据信息包括第一数据的标识信息、起始日志序号、第一数据的长度和终止日志序号；或，响应于日志记录哈希表中的第二日志记录的存储时长大于预设时长，异步执行第二操作，第二操作用于指示删除存储时长大于预设时长的第二日志记录。

在本公开的再一个实施例中，在根据第一数据的标识信息，在元数据哈希表中确定第一日志记录的起始日志序号之前，还包括：对日志文件中的第一日志记录进行解析处理，得到元数据信息；将元数据信息存储至元数据哈希表中。

在本公开的再一个实施例中，还包括：确定元数据哈希表是否被引用；响应于元数据哈希表未被引用，对元数据哈希表进行加锁处理。

在本公开的再一个实施例中，还包括：根据元数据哈希表中存储的标识信息，对元数据哈希表进行拆分处理，得到多个元数据哈希子表，多个元数据哈希子表均为加锁状态；相应的，根据第一数据的标识信息，在元数据哈希表中确定第一日志记录的起始日志序号，包括：根据第一数据的标识信息，在多个元数据哈希子表中确定目标元数据哈希子表；对目标元数据哈希子表进行拆锁处理后，在目标元数据哈希子表中确定起始日志序号。

在本公开的再一个实施例中，还包括：响应于第一内存中存储有第一数据，在第一内存中读取第一数据。

在本公开的再一个实施例中，还包括：响应于检测到主节点出现异常，执行主从切换操作。

在本公开实施方式的第二方面中，提供了一种介质，介质中存储有计算机执行指令，计算机执行指令被处理器执行时用于实现如第一方面的数据处理方法。

在本公开实施方式的第三方面中，提供了一种数据处理装置，应用于云数据库的从节点，云数据库还包括主节点，主节点用于读写数据以及生成读写的日志记录，日志记录所对应的日志文件存储在云数据库的共享存储介质中，从节点通过回放日志记录实现与主节点的数据同步；该数据处理装置包括：第一确定模块，用于响应于接收到第一数据的读取请求，确定从节点的第一内存中是否存储第一数据，第一数据是在主节点中所写的数据，读取请求中携带第一数据的标识信息，第一数据的标识信息用于标识第一数据所在的数据表和第一数据在数据表中的物理页；第二确定模块，用于响应于第一内存中未存储第一数据，根据第一数据的标识信息，在元数据哈希表中确定第一日志记录的起始日志序号，元数据哈希表中存储第一数据的标识信息、起始日志序号和第一数据的长度，第一日志记录与第一数据对应，元数据哈希表存储在第一内存中；第三确定模块，用于根据起始日志序号，确定第一日志记录在日志文件中的起始位置；第四确定模块，用于根据起始位置，在日志文件中确定第一日志记录；读取模块，用于回放第一日志记录，以根据第一数据的长度，在第一日志记录中读取第一数据。

在本公开实施方式的第四方面中，提供了一种计算设备，包括：处理器，以及与处理器连接的存储器；存储器存储计算机执行指令；处理器执行存储器存储的计算机执行指令，以实现如第一方面的数据处理方法。

根据本公开实施方式的数据处理方法、介质、装置和计算设备，从节点的第一内存中存储有元数据哈希表，该元数据哈希表中存储有第一数据的标识信息、第一日志记录的起始日志序号和第一数据的长度，通过第一数据的标识信息，可以在元数据哈希表中确定与该第一数据标识信息对应的起始日志序号，并根据起始日志序号，确定第一日志记录在日志文件中的起始位置，这样就可以根据该起始位置，在共享存储介质存储的日志文件中确定第一日志记录，再通过回放第一日志记录，就可以按照第一数据的长度读取到第一数据。由于从节点的第一内存中仅存储有占内存很小的元数据哈希表，而占内存较大的日志文件存储在共享存储介质中，因此，可以降低第一内存的占用，即使出现新的物理页，也可以通过元数据哈希表，在共享存储介质中准确读取新的物理页中的数据，从而保证了用户可以正常且准确地读取到数据，为用户带来了更好的体验。

附图说明

通过参考附图阅读下文的详细描述，本公开示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本公开的若干实施方式，其中：

图1为根据相关技术的云原生数据库PolarDB的架构示意图；

图2为根据相关技术的Redo复制的架构示意图；

图3为根据相关技术的从节点读取正确物理页的示意图；

图4为根据相关技术的从节点读取过去页的示意图；

图5为根据相关技术的限制从节点淘汰页面的示意图；

图6为根据相关技术的insert类型的日志记录的结构示意图；

图7为根据本公开实施例的一种数据处理方法的应用场景示意图；

图8为根据本公开实施例的一种数据处理方法的流程示意图；

图9为根据本公开实施例的一种用户读数据的示意图；

图10为根据本公开实施例的一种数据表的结构示意图；

图11为根据本公开实施例的一种存储介质的结构示意图；

图12为根据本公开实施例的一种数据处理装置的结构示意图；

图13为根据本公开实施例的一种计算设备的结构示意图。

在附图中，相同或对应的标号表示相同或对应的部分。

具体实施方式

下面将参考若干示例性实施方式来描述本公开的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本公开，而并非以任何方式限制本公开的范围。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

本领域技术人员知道，本公开的实施方式可以实现为一种系统、装置、设备、方法或计算机程序产品。因此，本公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。

根据本公开的实施方式，提出了一种数据处理方法、介质、装置和计算设备。

在本文中，需要理解的是，所涉及的术语含义如下：

MySQL：目前最流行的开源关系型数据库，广泛应用于互联网、电商、金融等业务场景，采用传统的Shared-Nothing架构实现，主节点和从节点之间通过Binlog进行数据复制和状态同步。

Shared-Nothing架构：一种传统的数据库系统实现架构，采用计算节点和存储节点耦合的模式，即一个计算节点和一个存储节点组成一个完整的数据库系统，多个计算节点间不共享存储节点。

Binlog：是一个二进制格式的文件，用于记录用户对数据库更新的结构化查询语言(Structured Query Language，简称SQL)信息，例如更改数据库表和更改内容的SQL语句都会记录到binlog里，但是对库、表等内容的查询不会记录。

Binlog复制：传统的MySQL的主节点和从节点之间通过Binlog同步数据信息，由于Binlog包含的是数据库的逻辑修改信息，所以又称为逻辑复制。

Shared-Storage架构：区别于Shared-Nothing架构，Shared-Storage架构的多个计算节点间访问同一个存储节点(共享存储介质)，可高效地进行计算节点扩展和存储节点扩容。

云原生数据库(Cloud-Native Database)：一般指基于共享存储的关系型数据库，大部分是公有云厂商基于MySQL进行二次开发而成，目前已经使用的云原生数据库包括AWSAurora，Aliyun PolarDB，CynosDB等。

InnoDB缓冲池(InnoDB Buffer Pool)：InnoDB是MySQL数据库的存储引擎，可以用于实现事务系统；Buffer Pool是InnoDB的内存缓冲器(Buffer)，作为写缓冲和读缓存。

事务隔离级别：InnoDB的事务有四个隔离级别，分别为：未提交读、提交读(RC)、重复读(RR)与序列化。线上业务一般配置为RC或RR。

RC：一个事务不会读到另一个并行事务已修改但未提交的数据，该隔离级别避免了“脏读取”，但不能避免“幻读”和“不可重复读取”。

RR：可以保证在同一个事物中，多次读取同一数据时返回的结果是相同的，可以避免“脏读取”和“不可重复读取”。

脏读取：指事务读取到其他事务未提交的数据。

幻读：一次事务中前后数据量发生变化，用户产生不可预料的问题。

不可重复读取：指在同一次事务中前后查询不一致的问题。

Redo日志：也可以称为日志记录，是关系型数据库用来实现事务数据持久性的一种方式，为了性能考虑，事务提交时，事务产生的新数据(新数据也称为脏页，事务执行过程中会修改页面内容，当内存物理页(物理页也可以称为数据页)跟磁盘物理页内容不一致的时候，我们称这个内存物理页为脏页)不会刷到存储上，而是先将日志记录持久化，然后再异步回刷脏页。日志记录记录了事务所做的每次修改。

日志序列号(Log Sequence Number，简称LSN)：日志记录一般采用LSN来标识，LSN单调增大。每个脏页也有相应的LSN，表示事务最后一次对该页所做修改时对应的日志记录，因此页的新旧程度也可以通过LSN来判断。当某个LSN之前的日志记录对应的脏页都已经刷到存储上，那么该LSN之前的日志记录所占空间即可被回收，意味着检查点(checkpoint)已经推进到了该LSN。

Mini-transaction：简称mtr，是保证若干个Page(InnoDB的物理页)原子性(指的是数据库系统ACID中的A，表示mtr修改若干个Page过程中，要么全部成功，要么全部失败)变更的单位。一个mtr中包含若干个日志记录，每个日志记录都对应某个Page。

Redo复制：与传统Binlog复制不同，使用日志记录进行主节点和从节点之间的数据复制，即主节点将日志记录发到从节点，从节点通过应用日志(Redo Apply)来更新内存状态的复制方式。由于日志记录包含的是数据库的物理修改信息，所以又称为物理复制。

事务视图(ReadView)：是一个保存事务ID的list列表，可以记录本事务执行时，MySQL还有哪些事务在执行，且还没有提交，也即，记录当前系统中还有哪些活跃的读写事务。

数据定义语言(Data Definition Language，简称DDL)：用来定义数据库对象，例如，数据库、数据表和数据字段。

数据操作语言(Data Manipulation Language，简称DML)：用来对数据库表中的数据进行增删改查操作。

需要说明的是，本公开所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据，并且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准，并提供有相应的操作入口，供用户选择授权或者拒绝。

此外，附图中的任何元素数量均用于示例而非限制，以及任何命名都仅用于区分，而不具有任何限制含义。

下面参考本公开的若干代表性实施方式，详细阐释本公开的原理和精神。

发明概述

本发明人发现，随着计算机技术的发展，基于MySQL开发的云原生数据库也越来越多，以PolarDB为例。图1所示的PolarDB架构图中，包括三个MySQL计算节点和一个共享存储介质(Shared Storage)，这三个MySQL计算节点分别为一个主节点(Primary)和两个从节点(Read Only)，共享存储介质中有n个存储介质，分别为S1，S2，…，Sn。其中，主节点以读写模式访问网络远端的共享存储介质，从节点以只读模式访问网络远端的共享存储介质。计算节点一般为云主机，共享存储介质为支持挂载(mount)到多个计算节点上的分布式文件系统，位于网络远端，与计算节点通过存储网络相连。

在图1所示的PolarDB架构中，由于计算节点和共享存储介质是分离的，因此，可以非常方便的扩展计算节点，以扩展读写能力。例如，若要扩展写能力，则只需提高主节点云主机的中央处理器(Central Processing Unit，简称CPU)和内存规格，无需判断该云主机所在的物理服务器上是否有足够的存储空间；若要扩展读能力，则可以新建更多的从节点，目前的云原生数据库一般支持最大15个从节点。由于各计算节点均访问同一共享存储介质，在扩展读能力时无需对存储数据进行复制，大大节省了存储成本。此外，用户按需使用共享存储介质上的存储空间，少用少付费，多用多付费，可以进一步节省存储成本。

为了使图1所示的PolarDB架构中的从节点能够提供查询服务，需要将主节点的事务状态同步到从节点，并基于此建立事务视图，实现RR事务隔离级别和RC事务隔离级别。此外，还需要将数据库或表的元数据操作(DDL)，以及用户和权限等变更信息同步给从节点。因此，需要基于Redo复制进行主从同步，也即，通过回放日志记录使从节点上的事务状态及各种元数据能与主节点保持一致状态。

Redo复制的架构图可以如图2所示，主节点中可以包括消息接收线程、消息发送线程、日志持久化线程和缓冲池，从节点中可以包括消息发送线程、消息接收线程、日志回放线程和缓冲池，共享存储介质中包括数据(data)存储介质和日志(log)存储介质。在实现Redo复制时，主节点将变更数据写入到自己的缓冲池中，并将变更数据同步到数据存储介质中，在事务提交时通过日志持久化线程将日志记录写入日志存储介质；主节点通过消息发送线程告知从节点有新增的日志记录；从节点通过消息接收线程接收新增日志记录的消息，并通知日志回放线程，日志回放线程读取日志存储介质上的日志记录，并对日志记录进行并行回放，实现将变更数据从数据存储介质存储到自己的缓冲池中，这样从节点就可以在缓冲池中读取变更数据；从节点通过消息发送线程通知主节点日志记录回放已完成的消息，该消息包括事务状态同步、DDL、DML、用户和权限等操作；主节点通过消息接收线程接收日志记录回放已完成的消息，并进行后续操作。

通过如图2所示的Redo复制的架构图，可以保证从节点读到正确版本的页面(Page)内容，从节点读取正确版本页面可以如图3所示。主节点中物理页P1的LSN为100，共享存储介质中存储物理页P1的LSN为100，从节点在共享存储介质中读取物理页P1的LSN为100；当主节点修改了物理页P1得到物理页P2之后，物理页P2的LSN为200，主节点将日志记录LSN＝200存储到共享存储介质中；在物理页P2刷盘前，从节点接收到主节点新增日志记录的消息后，在共享存储介质中读取新增的日志记录LSN＝200，通过回放日志记录之后，得到LSN为200的最新物理页P2。从而保证主节点和从节点的内存状态一致。

图3所示的流程中，若从节点上由于缓冲池的空间不足，会将回放出来的最新物理页P2淘汰掉，若后续需要再次从共享存储介质中读取页面，由于主节点没有将最新物理页P2刷新到共享存储介质中，因此从节点在共享存储介质中读取的是之前的老页面P1，而不是最新物理页P2，也即，出现了过去页面，如图4所示。

在T1时刻，主节点将物理页P1的LSN从100修改为200，得到LSN为200的最新物理页P2，并将LSN＝200的日志存储在共享存储介质中；从节点此时在共享存储介质中读取的是LSN＝100的物理页P1；

在T2时刻，主节点提醒从节点有新的日志产生；

在T3时刻，从节点在共享存储介质中读取并回放LSN＝200的日志，得到LSN＝200的最新物理页P2；

在T4时刻，由于从节点的缓冲池存储空间不足，将最新物理页P2从缓冲池中淘汰；

在T5时刻，从节点再次读取页面时，由于缓冲池中已将最新物理页P2淘汰，因此，从节点需要从共享存储介质中读取页面，但主节点长时间未将最新物理页P2刷新到共享存储介质中，因此，从节点从共享存储介质中读取到的页面不是最新物理页P2，而是过去页面P1。导致从节点读取到了错误的页面数据。

为了解决从节点读取到过去页面的问题，相关技术中提出了两种解决方案。第一种方案是限制从节点的页面淘汰，如图5所示。主节点在T1时刻和T2时刻之间设置有检查点，从节点在T4时刻和T5时刻之间设置有回放位点；回放位点之前，主节点允许页面刷盘，回放位点之后，主节点不允许页面刷盘；检查点之前，从节点允许页面淘汰，检查点之后，从节点不允许页面淘汰。也即，在从节点中，若物理页的LSN大于主节点的检查点，则从节点不能淘汰物理页。这种方案虽然可以解决从节点读取到过去页面的问题，但由于限制了从节点的页面淘汰，可能会导致从节点的缓冲池内存膨胀，极端场景下会导致从节点的缓冲池内存用完，导致阻塞了用户读取新的物理页，存在用户数据读取异常的问题。

第二种方案是将主节点的检查点以后的日志记录都缓存到日志记录哈希表中，这样如果从节点读取到了过去页面，则可以通过Redo Apply，生成最新物理页版本。这种方案虽然可以解决从节点读取到过去页面的问题，但需要缓存检查点以后的日志记录。而日志记录一般包括3个部分：日志类型Type，数据表标识Space ID、物理页标识Page Number等元数据Meta，日志记录对应的数据Body。其中，Body部分的数据是不确定的，不同的Type对应的Body部分的数据不同，且Body部分占据了日志记录的大部分空间，如图6所示。从节点通过日志记录的Meta部分查找需要回放的物理页，通过日志记录的Body部分进行具体的回放操作，以读取数据。

根据图6可以看到，日志记录主要的内容是在Body部分，占据了日志记录哈希表的主要内存，且主节点需要先生成日志记录，从节点才可以回放日志记录，且从节点回放日志记录的时间长、速度慢，因此，主节点的检查点和从节点的回放位点之间存在一定的间隙(gap)，这会导致需要缓存的日志记录数据量非常大，需要申请足够多的内存才能维护日志记录哈希表，极端场景下会导致MySQL内存耗尽(Out Of Memory，简称OOM)，从而导致阻塞了用户读取新的物理页，存在用户数据读取异常的问题。

因此，本公开提出一种数据处理方法，从节点可以对日志记录进行解析，得到需读取数据的标识信息、需读取数据对应日志记录的起始日志序号、需读取数据的长度等元数据信息，并将元数据信息存储在元数据哈希表中，将元数据哈希表存储在从节点的缓冲池中。从节点在接收到需读取数据的读取请求时，确定读取请求中携带的需读取数据的标识信息，然后在自己的缓冲池中读取该日志记录对应的元数据哈希表，确定需读取数据的标识信息对应的起始日志序号，从而就可以根据起始日志序号确定需读取数据对应的日志记录在日志文件中的起始位置，以及根据起始位置，在共享存储介质中定位到日志文件中的日志记录，通过回放该日志记录，就可以按照需读取数据的长度读取到需读取数据。

由于从节点无需限制页面淘汰，并且未在从节点的缓冲池存储日志记录的body部分内容，因此，可以减少从节点缓冲池的内存占用，不会存在从节点的缓冲池内存用完和MySQL内存耗尽的问题，从而，本公开提出的数据处理方法，既可以解决从节点会读取到过去页面的问题，又可以保证用户可以正常且准确地读取到数据，为用户带来了更好的体验。

在介绍了本公开的基本原理之后，下面具体介绍本公开的各种非限制性实施方式。

应用场景总览

首先参考图7，图7示出了根据本公开实施例的一种数据处理方法的应用场景示意图，本公开提供的数据处理方法可以应用于图7所示的数据处理系统，该数据处理系统可以包括主节点、从节点和共享存储介质。其中，主节点中包括主节点内存和日志发送线程，主节点内存中缓存有用户写入的数据和写数据时生成的日志记录。从节点中包括第一内存、第二内存、日志接收线程、回放协调线程、用户读线程和内存回收线程，第一内存中存储有从节点的缓存数据和元数据哈希表，第二内存中存储有日志记录哈希表。共享存储介质中包括数据存储介质和日志存储介质。

在上述应用场景中，用户在主节点进行第一数据的写操作时，主节点生成第一数据对应的第一日志记录，并将第一数据和第一日志记录存储在主节点内存中，然后向数据存储介质发送第一数据，以将第一数据存储在数据存储介质中，并向日志存储介质发送第一日志记录，以将第一日志记录存储在日志存储介质中。主节点在生成第一日志记录之后，通过日志发送线程，向从节点告知新增日志记录的消息。

在上述应用场景中，从节点通过日志接收线程接收新增日志记录的消息，以在日志存储介质中读取第一日志记录。从节点中的回放协调线程会对第一日志记录进行解析，得到第一数据的标识信息、第一日志记录的起始日志序号、第一数据的长度等元数据信息，并将元数据信息存储在元数据哈希表中。此外，回放协调线程还可以从日志存储介质中获取主节点中预设长度的第二数据对应的第二日志记录，并将第二日志记录存储在日志记录哈希表中。

在上述应用场景中，用户在进行读操作时，发起读取第一数据的读取请求，该读取请求中携带第一数据的标识信息。若主节点正常，则根据第一数据的标识信息，直接在主节点内存中读取第一数据即可。

在上述应用场景中，若主节点异常，则需要通过从节点读取第一数据。也即，从节点的用户读线程根据第一数据的标识信息，确定第一内存中存储的缓存数据是否包括有第一数据，也即第一内存中是否存储有第一数据；若第一内存中存储有第一数据，则直接在第一内存中读取第一数据；若第一内存中未存储第一数据，则确定第二内存中的日志记录哈希表中是否可以读取到第一日志记录；若第二日志记录包含第一日志记录，则回放第一日志记录以读取第一数据；若第二日志记录不包含第一日志记录，则在元数据哈希表中确定与第一数据的标识信息对应的起始日志序号，并根据起始日志序号确定第一日志记录在日志文件中的起始位置，然后根据起始位置在日志文件中定位到第一日志记录，这样就可以回放第一日志记录，并根据第一数据的长度，在第一日志记录中读取第一数据。将第一数据返回给用户，即可使用户读取到最新的数据。

在上述应用场景中，为了减少第一内存和第二内存的溢出问题，可以通过从节点的内存回收线程对元数据哈希表和日志记录哈希表进行过期资源清理。也即，将元数据哈希表中存储时长超过预设时长的元数据信息，以及将日志记录哈希表中存储时长超过预设时长的第二日志记录，进行删除。

在上述应用场景中，由于日志记录哈希表中存储的是第二日志记录，且第二日志记录对应的第二数据的长度是预设的，因此，第二内存的大小是可控的；并且，元数据哈希表中存储的是元数据信息，元数据信息所占内存也很小，因此，可以减少第一内存的占用；此外，还会通过从节点的内存回收线程对第一内存和第二内存进行内存回收，因此，进一步减少了第一内存和第二内存的占用，从而不会存在从节点的内存用完和MySQL内存耗尽的问题，这样不仅可以解决从节点读取到过去页面的问题，还可以保证用户可以正常且准确地读取到数据，为用户带来了更好的体验。

示例性方法

下面结合图7的应用场景，参考图8来描述根据本公开示例性实施方式的数据处理方法。需要注意的是，该数据处理方法应用于云数据库的从节点。此外，上述应用场景仅是为了便于理解本公开的精神和原理而示出，本公开的实施方式在此方面不受任何限制。相反，本公开的实施方式可以应用于适用的任何场景。

图8示出了根据本公开实施例的一种数据处理方法的流程示意图，在图8中，该数据处理方法包括以下步骤：

S801：响应于接收到第一数据的读取请求，确定从节点的第一内存中是否存储第一数据，第一数据是在主节点中所写的数据，读取请求中携带第一数据的标识信息。

在该步骤中，云数据库还包括主节点，主节点用于读写数据以及生成读写的日志记录，日志记录所对应的日志文件存储在云数据库的共享存储介质中，从节点通过回放日志记录实现与主节点的数据同步。

具体地，从节点的第一内存可以是从节点的缓冲池(buffer pool)，且第一内存的存储空间有限，因此，第一内存中可以存储第一数据，也可以不存储第一数据，从而在读取第一数据时，需要确定第一内存中是否存储有第一数据。

可选地，第一数据的标识信息用于标识第一数据所在的数据表和第一数据在数据表中的物理页。用户在需要读取第一数据时，可以向从节点发送携带有第一数据的标识信息的读取请求，以便于从节点可以根据第一数据的标识信息，确定用户需要读取的是第一数据。

S802：响应于第一内存中未存储第一数据，根据第一数据的标识信息，在元数据哈希表中确定第一日志记录的起始日志序号。

在该步骤中，元数据哈希表中存储第一数据的标识信息、第一日志记录的起始日志序号和第一数据的长度，第一日志记录与第一数据对应，元数据哈希表存储在第一内存中。

具体地，主节点中在写入第一数据后，会生成第一数据对应的第一日志记录。元数据哈希表中存储的第一数据的标识信息可以为space_id和page_no，其中，space_id用于标识第一数据所在的数据表，page_no用于标识第一数据在数据表中所在的物理页。起始日志序号为第一日志记录的start_lsn信息，第一数据的长度为第一日志记录中body部分的长度。

在一种可选的实施方式中，若第一内存中未存储第一数据，则需要在共享存储介质中读取第一数据，因此，需要根据读取请求中携带的第一数据的标识信息，在元数据哈希表中查询与该第一数据的标识信息对应的起始日志序号，以及与该第一数据的标识信息对应的第一数据的长度。

可选地，在元数据哈希表中，第一数据的标识信息以关键字key存储在元数据哈希表中，起始日志序号和第一数据的长度以值value存储在元数据哈希表中。在接收到读取请求之后，可以在元数据哈希表中确定与读取请求中相同的第一数据的标识信息，然后在元数据哈希表中确定与该第一数据的标识信息对应的起始日志序号和第一数据的长度。

可选地，起始日志序号可以以start_lsn表示，用于表示第一日志记录在日志文件中的起始位置偏移量。

S803：根据起始日志序号，确定第一日志记录在日志文件中的起始位置。

在该步骤中，在确定了第一日志记录的起始日志序号之后，也即确定了第一日志记录在日志文件中的起始位置偏移量，这样就可以确定出第一日志记录在日志文件中对应的起始位置。

S804：根据起始位置，在日志文件中确定第一日志记录。

在该步骤中，在确定了第一日志记录在日志文件中对应的起始位置之后，就可以按照起始位置，在日志文件中定位到第一日志记录。

可选地，由于日志文件是存储在共享存储介质中的，因此，第一日志记录也是存储在共享存储介质中的。

S805：回放第一日志记录，以根据第一数据的长度，在第一日志记录中读取第一数据。

在该步骤中，在共享存储介质中定位到第一日志记录之后，从节点就可以回放第一日志记录。并且，已经确定了第一数据的长度，也即确定了第一日志记录中body部分的长度，而第一日志记录中body部分的字节类型和其他部分的字节类型不同，因此，可以根据字节类型在第一日志记录中确定body部分，再根据body部分的长度，在第一日志记录读取到body部分的内容，也就读取到了第一数据，从而实现从节点与主节点之间的数据同步。

本公开的数据处理方法，从节点的第一内存中存储有元数据哈希表，该元数据哈希表中存储有第一数据的标识信息、第一日志记录的起始日志序号和第一数据的长度，通过第一数据的标识信息，可以在元数据哈希表中确定与该第一数据标识信息对应的起始日志序号，并根据起始日志序号，确定第一日志记录在日志文件中的起始位置，这样就可以根据该起始位置，在共享存储介质存储的日志文件中确定第一日志记录，再通过回放第一日志记录，就可以按照第一数据的长度读取到第一数据。由于从节点的第一内存中仅存储有占内存很小的元数据哈希表，而占内存较大的日志文件存储在共享存储介质中，因此，可以降低第一内存的占用，即使出现新的物理页，也可以通过元数据哈希表，在共享存储介质中准确读取新的物理页中的数据，从而保证了用户可以正常且准确地读取到数据，为用户带来了更好的体验。

在本公开的一个实施例中，从节点还包括日志记录哈希表，日志记录哈希表中存储第一数据的标识信息和第二日志记录，第二日志记录与主节点中预设长度的第二数据对应，日志记录哈希表存储在从节点的第二内存中；根据第一数据的标识信息，在元数据哈希表中确定第一日志记录的起始日志序号之前，该数据处理方法还包括：响应于第一内存中未存储第一数据，在日志记录哈希表中确定第一数据的标识信息；根据第一数据的标识信息，确定第二日志记录中是否包含第一日志记录；响应于第二日志记录中包含第一日志记录，且第一日志记录的最小日志序号值大于或等于物理页的版本号值，则回放第一日志记录，以读取第一数据。

在该实施例中，第二内存是在从节点中单独开辟出的，与第一内存不同的一块内存。在日志记录哈希表中，第一数据的标识信息以key存储在日志记录哈希表中，第二日志记录以value存储在日志记录哈希表中，日志记录哈希表中的标识信息与元数据哈希表中的标识信息相同。

具体地，通过将预设长度的第二数据存储在第二内存中，可以在第一内存中未存储第一数据的情况下，根据第一数据的标识信息，在第二内存中查询是否存储有第一数据。也即，通过第一数据的标识信息，在第二日志记录中定位对应的第一日志记录，若第二日志记录包含第一日志记录，且第一日志记录的最小日志序号值大于或等于物理页的版本号值，则可以直接通过回放第二日志记录，实现在第二内存中读取第一数据。由于从节点在内存中读取数据的速度大于在共享存储介质中读取数据的速度，因此，可以降低从节点读取第一数据时的延迟，提高从节点读取第一数据的效率。

举例而言，第一数据所在物理页为P，物理页P的版本号值为150。在读取第一数据时，会首先在第一内存中查找第一数据，若未在第一内存中找到第一数据，则会查询第二内存中的日志记录哈希表。若通过第一数据的标识信息可以在日志记录哈希表中定位到第一日志记录，则可以确定第一日志记录的最小日志序号lsn。若最小lsn≥150，则说明日志记录哈希表中包含了物理页P的所有日志记录，因此，可以直接在第二内存中获取第一日志记录中的Body部分，这样通过回放第一日志记录即可读取到第一数据，无需再访问元数据哈希表。

可选地，预设长度可以为主节点的检查点开始的预设长度，且该检查点可以配置有可调整的值，也即checkpoint+M，M为可调整的值。若第二内存的存储空间宽裕，且业务对读延迟敏感，则可以将M的值下调，这样就可以存储足够多的body数据；如果第二内存的存储空间不宽裕，或者业务对读延迟不敏感，则可以将M的值上调。因此，可以在保证第二内存够用的情况下，尽量降低从节点读取第一数据的I/O率，降低读延时。

在本公开的另一个实施例中，根据第一数据的标识信息，在元数据哈希表中确定第一日志记录的起始日志序号，包括：响应于第二日志记录中不包含第一日志记录，或最小日志序号值小于版本号值，根据第一数据的标识信息，在元数据哈希表中确定第一日志记录的起始日志序号。

在该实施例中，若在第一内存中未存储第一数据的情况下，第二日志记录不包含第一日志记录，或第一日志记录的最小日志序号值小于物理页的版本号值，则确定既不能在第一内存中读取第一数据，也不能在第二内存中读取数据。因此，需要在共享存储介质中读取第一数据。

具体地，通过第一数据的标识信息，可以确定是否能在元数据哈希表中查询到该第一数据的标识信息，若可以在元数据哈希表中查询到第一数据的标识信息，则可以根据该第一数据的标识信息，确定第一日志记录的起始日志序号，以及根据起始日志序号，确定第一日志记录在日志文件中的起始位置，从而根据起始位置，在日志文件中定位第一日志记录，这样就可以通过回放第一日志记录读取第一数据。

可选地，引入“双hash”机制，也即引入元数据哈希表(元数据hash)和日志记录哈希表(Redo hash)。由于占内存较大的日志文件存储在共享存储介质中，也即第一日志记录的body部分存储在共享存储介质中，而元数据哈希表占用的内存很小，因此，可以降低第一内存的占用，从而不会存在从节点的第一内存用完的问题，也就可以解决“过去页”问题，进而可以保证用户正常且准确地读取到第一数据；通过单独在从节点中开辟出第二内存来存储日志记录哈希表，若可以在日志记录哈希表中读取到第一数据，则可以降低从节点读取第一数据的读延时，为用户带来了更好的体验。基于双hash机制的用户读数据可以如图9所示。

图9示出了根据本公开实施例的一种用户读数据的示意图。在图9中，第一内存中存储从节点的缓存数据和元数据哈希表，第二内存中存储日志记录哈希表。日志记录哈希表中以链表形式存储了多个日志记录(在图9中，以日志记录1、日志记录2、…、日志记录n表示)，元数据哈希表中以链表形式存储了多个元数据信息(在图9中，以元数据信息1、元数据信息2、…、元数据信息n表示)。用户在发起读取请求时，若第一内存中从节点的缓存数据包括第一数据，也即第一内存中存储第一数据，则直接读取第一数据；若第一内存中未存储第一数据，则确定日志记录哈希表中是否存储有第一日志记录，也即确定多个日志记录中是否包括第一日志记录；若多个日志记录中包括第一日志记录，则直接回放第一日志记录，以读取第一数据；若多个日志记录中不包括第一日志记录，则根据第一数据的标识信息，确定是否可以在元数据哈希表中查询到对应的标识信息，若可以在元数据哈希表中查询到对应的标识信息，则根据该标识信息对应的元数据信息，在共享存储介质中确定第一日志记录，从而通过回放第一日志记录，读取第一数据。

在一种可选的实施方式中，若第一数据未存储在第一内存，则从节点可以采用Runtime Apply机制实现将正在进行的回放第一日志记录的操作下推给从节点的用户读线程，这样当用户真正访问到第一数据所在物理页时(从节点响应接收到第一数据的读取请求)，才在第二内存中或在共享存储介质中回放第一日志记录，从而既可以降低无效回放操作导致的网络带宽资源浪费，又可以确保用户读到正确的数据。

在本公开的又一个实施例中，根据第一数据的标识信息，确定第二日志记录中是否包含第一日志记录，包括：响应于在日志记录哈希表中查询到第一数据的标识信息，则确定第二日志记录中包含第一日志记录；响应于未在日志记录哈希表中查询到第一数据的标识信息，则确定第二日志记录中不包含第一日志记录。

在该实施例中，日志记录哈希表中存储的第一数据的标识信息和元数据哈希表中存储的第一数据的标识信息是相同的。若可以在日志记录哈希表中查询到第一数据的标识信息，则认为日志记录哈希表中存储了第一数据对应的第一日志记录，也即，第二日志记录中包含第一日志记录，这样就可以直接回放第一日志记录，实现读取第一数据。由于日志记录哈希表是存储在第二内存中的，在第二内存中读取第一数据的效率比在共享存储介质中读取第一数据的效率高，因此，可以降低从节点读取第一数据的读延时，为用户带来了更好的体验。

在上述实施例中，若不能在日志记录哈希表中查询到第一数据的标识信息，则认为日志记录哈希表中未存储第一数据对应的第一日志记录，也即，第二日志记录中不包含第一日志记录。此时，由于无法在第一内存和第二内存中读取第一数据，因此，需要在共享存储介质中读取第一数据。而共享存储介质中存储的是占内存较大的日志文件，也即第一日志记录的body部分，且元数据哈希表占用的内存很小，因此，可以降低第一内存的占用，从而不会存在从节点的第一内存用完的问题，也就可以解决“过去页”问题，从而可以保证用户正常且准确地读取到第一数据。

在本公开的再一个实施例中，元数据哈希表中还存储第一日志记录的终止日志序号，终止日志序号用于表示第一日志记录的回放终止位置。

在该实施例中，每个物理页有对应的版本号。第一日志记录是在物理页上回放的，在第一日志记录回放完成之后，需要将终止日志序号的值赋给第一数据所在物理页的版本号，以表示第一日志记录已经回放到第一数据所在物理页。后续需要继续读取其他数据时，就可以通过终止日志序号确定上一次的回放终止位置是在哪个物理页，然后继续回放日志记录，而无需从起始日志序号开始再次重复回放第一日志记录。因此，可以减少重复回放日志记录导致的数据读取效率低的问题，也可以减少重复回放日志记录导致的数据读取错误的问题。

在本公开的再一个实施例中，该数据处理方法还包括：响应于元数据哈希表中的元数据信息的存储时长大于预设时长，异步执行第一操作，第一操作用于指示删除存储时长大于预设时长的元数据信息，元数据信息包括第一数据的标识信息、起始日志序号、第一数据的长度和终止日志序号；或，响应于日志记录哈希表中的第二日志记录的存储时长大于预设时长，异步执行第二操作，第二操作用于指示删除存储时长大于预设时长的第二日志记录。

在该实施例中，虽然元数据哈希表占用的内存很小，但第一内存的存储空间也是有限的，若不及时维护第一内存的存储空间，也会由于元数据哈希表存储过多导致第一内存存储空间不足。因此，可以回收第一内存中过期的内存资源，也即将存储时长大于预设时长的元数据信息进行删除，以节省第一内存的存储资源。同理，第二内存的存储空间也是有限的，因此，可以回收第二内存中过期的内存资源，也即需要将存储时长大于预设时长的第二日志记录进行删除，以节省第二内存的存储资源。

可选地，为了提高从节点的设备使用率，可以通过新增后台线程来异步回收过期的内存资源，也即，将回收过期的内存资源的操作和读取第一数据的操作进行异步执行。

在本公开的再一个实施例中，根据第一数据的标识信息，在元数据哈希表中确定第一日志记录的起始日志序号之前，该数据处理方法还包括：对日志文件中的第一日志记录进行解析处理，得到元数据信息；将元数据信息存储至元数据哈希表中。

在该实施例中，元数据信息是预先存储在元数据哈希表中的。主节点在生成第一日志记录之后，会给从节点发送用于提示有新日志生成的消息，从节点接收到该消息之后，会在共享存储介质中读取到第一日志记录，然后对第一日志记录进行解析处理，得到第一数据的标识信息、起始日志序号、第一数据的长度和终止日志序号等元数据信息，其中，第一数据的标识信息包括第一数据所在数据表标识和第一数据所在物理页标识。数据表的结构如图10所示。

图10示出了根据本公开实施例的一种数据表的结构示意图。在图10中，一个数据表中包括多个物理页，每个物理页包括多个缓存区，每个缓存区存放一个日志记录的信息，包括日志记录的状态(state)、该日志记录中记录的数据所在数据表的标识、该日志记录中记录的数据所在物理页的标识，以及该日志记录的数据对应的修改信息列表，修改信息列表中的每个修改信息包括该日志记录的类型、该日志记录的数据对应的数据长度、该日志记录的起始日志序号和终止日志序号，该日志记录的数据未存储在数据表中，通过该日志记录的起始日志序号，就可以在共享存储介质中读取到该日志记录的数据。

在上述实施例中，在得到第一数据的标识信息、起始日志序号、第一数据的长度和终止日志序号等元数据信息之后，就可以将元数据信息存储在元数据哈希表中，这样在后续接收到第一数据的读取请求时，就可以根据元数据哈希表中存储的元数据信息，在共享存储介质中回放第一日志记录，从而读取到第一数据。由于元数据哈希表占用的内存非常小，因此，不会存在从节点的第一内存用完的问题，也就可以解决“过去页”问题，从而可以保证用户正常且准确地读取到第一数据。

可选地，在对日志文件中的第一日志记录进行解析处理，得到元数据信息之后，除了将元数据信息存储到元数据哈希表中之外，还可以将第一数据的标识信息单独进行存储，以便于用户可以获取第一数据的标识信息，这样用户在需要读取第一数据时，可以将第一数据的标识信息携带在读取请求中一起发送给从节点，以便于从节点可以在元数据哈希表中查询第一数据的标识信息。

在本公开的再一个实施例中，该数据处理方法还包括：确定元数据哈希表是否被引用；响应于元数据哈希表未被引用，对元数据哈希表进行加锁处理。

在该实施例中，若元数据哈希表正在被某一个或多个线程访问，则可能会导致数据冲突，例如，某一个或多个线程读取的数据是已经被其他线程修改过的数据，也即，存在并发冲突问题。为了减少元数据哈希表的并发冲突问题，可以采用引用计数无锁化的方式，对元数据哈希表的引用次数进行确定，从而通过引用次数可以判断是否需要对元数据哈希表进行加锁处理。

具体地，若引用次数不为0，则表示当前有线程在访问该元数据哈希表，为了减少并发冲突，不能修改该元数据哈希表，并且，为了保证当前正在访问该元数据哈希表的线程可以正常访问，也不能对该元数据哈希表进行加锁处理。若引用次数为0，则表示当前没有线程在访问该元数据哈希表，此时，可以对元数据哈希表进行加锁处理，这样就不会有线程访问该元数据哈希表，以便于修改该元数据哈希表，从而减少并发冲突。其中，线程访问元数据哈希表也可以称为线程引用元数据哈希表。

在本公开的再一个实施例中，该数据处理方法还包括：根据元数据哈希表中存储的标识信息，对元数据哈希表进行拆分处理，得到多个元数据哈希子表，多个元数据哈希子表均为加锁状态；相应的，根据第一数据的标识信息，在元数据哈希表中确定第一日志记录的起始日志序号，包括：根据第一数据的标识信息，在多个元数据哈希子表中确定目标元数据哈希子表；对目标元数据哈希子表进行拆锁处理后，在目标元数据哈希子表中确定起始日志序号。

在该实施例中，对元数据哈希表进行加锁处理后，可能存在锁冲突问题，也即多个线程同时请求访问加锁后的元数据哈希表时，出现了互相等待元数据哈希表的锁释放的情况。为了减少锁冲突问题，可以进行拆锁处理。也即，按照元数据哈希表中存储的标识信息，对元数据哈希表进行拆分处理，得到多个元数据哈希子表，每个元数据哈希子表有对应的标识信息。然后对得到的多个元数据哈希子表均进行加锁处理，这样就可以得到多个处于加锁状态的元数据哈希子表。

在上述实施例中，在元数据哈希表中确定起始日志序号时，可以先根据第一数据的标识信息，在多个元数据哈希子表中定位到目标元数据哈希子表，这样对目标元数据哈希子表进行拆锁处理后，就可以访问该目标元数据哈希子表，以在目标元数据哈希子表中，确定与第一数据的标识信息对应的起始日志序号。这样就可以根据起始日志序号，确定第一日志记录在日志文件中的起始位置，并根据起始位置，在日志文件中确定第一日志记录，从而可以实现在共享存储介质中回放第一日志记录，以根据第一数据的长度，在第一日志记录中读取第一数据。

在本公开的再一个实施例中，该数据处理方法还包括：响应于第一内存中存储有第一数据，在第一内存中读取第一数据。

在该实施例中，由于在从节点的内存中读取第一数据的效率比在共享存储介质中读取第一数据的效率高，因此，可以先访问从节点的第一内存，若第一内存中存储有第一数据，则可以直接在第一内存中读取第一数据，从而降低第一数据的读延迟。若第一内存中未存储第一数据，则可以访问第二内存，若第二内存中也为存储第一数据，则需要在共享存储介质中读取第一数据。

在本公开的再一个实施例中，该数据处理方法还包括：响应于检测到主节点出现异常，执行主从切换操作。

在该实施例中，为了将云数据库的集群节点角色的管理从人工操作中解脱出来，可以在云数据库中引入Raft算法，通过Raft算法，实现云数据库的集群节点角色的自动化管理。云数据库的集群中，主节点对应Raft协议中的领导者(Leader)角色，从节点对应Raft协议中的跟随者(Follower)角色。当主节点宕机的时候，从节点需要切换为新的主节点。

具体地，新的主节点需要提供读写服务。新的主节点在提供服务的过程中，在有用户需要访问最新page时，新的主节点才去访问元数据哈希表，然后回放第一日志记录。由于此时从节点已经切换为新的主节点，因此，新的主节点在第一日志记录回放完成之后，就可以异步执行将第一日志记录对应的元数据信息进行清理删除的操作，以便于可以缩短主从切换操作的切换时间。

本公开实施例提出的数据处理方法，以开源的MySQL数据库为基础，提出一种基于元数据哈希表的物理复制方案。具体地，将物理复制分为三个阶段：日志记录解析阶段、缓存物理页(Cached Page)回放阶段、元数据哈希表维护阶段。对于日志记录解析阶段，从节点在解析日志记录的过程中，仅仅记录日志记录的元数据信息。对于缓存物理页回放阶段，可以回放从节点内存中的物理页，也即Cached Page，对于不在从节点内存中的物理页，通过Runtime Apply机制，确保用户读到正确的数据。对于元数据哈希表维护阶段，从节点会将日志记录解析阶段记录的元数据信息维护到全局的元数据哈希表中，从而可以节约从节点的内存。这样既不会导致MySQL内存耗尽，从节点也无需限制物理页淘汰，不会导致从节点内存膨胀，因此，可以正常读取新的物理页，从而保证用户读取到正确数据。

此外，本公开实施例提出的数据处理方法，还引入“双hash”机制，也即引入元数据哈希表和日志记录哈希表。由于占内存较大的日志文件存储在共享存储介质中，而元数据哈希表占用的内存很小，因此，可以降低从节点内存的占用，从而不会存在从节点的内存用完的问题，也就可以解决“过去页”问题，从而可以保证用户正常且准确地读取到数据；通过单独在从节点中开辟出另一块内存来存储日志记录哈希表，这样若可以在日志记录哈希表中读取到数据，则可以降低从节点读取数据的读延时，为用户带来了更好的体验。

本公开实施例提出的数据处理方法，可以用于InnoDB。由于对InnoDB内核的侵入较小，涉及到的修改较少，且没有修改Redo物理格式，因此，具有更好的可操作性。

示例性介质

在介绍了本公开示例性实施方式的方法之后，接下来，参考图11对本公开示例性实施方式的存储介质进行说明。

参考图11所示，存储介质1100中存储着根据本公开的实施方式的用于实现上述方法的程序产品，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括计算机执行指令，并可以在终端设备，例如个人电脑上运行。然而，本公开的程序产品不限于此。

该程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质。

可以以一种或多种程序设计语言的任意组合来编写用于执行本公开公开操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备。

示例性装置

在介绍了本公开示例性实施方式的介质之后，接下来，参考图12对本公开示例性实施方式的数据处理装置进行说明，用于实现上述任一方法实施例中的方法，其实现原理和技术效果类似，在此不再赘述。需要说明的是，该数据处理装置应用于云数据库的从节点，云数据库还包括主节点，主节点用于读写数据以及生成读写的日志记录，日志记录所对应的日志文件存储在云数据库的共享存储介质中，从节点通过回放日志记录实现与主节点的数据同步。

图12示出了根据本公开实施例的一种数据处理装置的结构示意图，在图12中，该数据处理装置1200包括：

第一确定模块1201，用于响应于接收到第一数据的读取请求，确定从节点的第一内存中是否存储第一数据，第一数据是在主节点中所写的数据，读取请求中携带第一数据的标识信息，第一数据的标识信息用于标识第一数据所在的数据表和第一数据在数据表中的物理页；

第二确定模块1202，用于响应于第一内存中未存储第一数据，根据第一数据的标识信息，在元数据哈希表中确定第一日志记录的起始日志序号，元数据哈希表中存储第一数据的标识信息、起始日志序号和第一数据的长度，第一日志记录与第一数据对应，元数据哈希表存储在第一内存中；

第三确定模块1203，用于根据起始日志序号，确定第一日志记录在日志文件中的起始位置；

第四确定模块1204，用于根据起始位置，在日志文件中确定第一日志记录；

读取模块1205，用于回放第一日志记录，以根据第一数据的长度，在第一日志记录中读取第一数据。

可选地，从节点还包括日志记录哈希表，日志记录哈希表中存储第一数据的标识信息和第二日志记录，第二日志记录与主节点中预设长度的第二数据对应，日志记录哈希表存储在从节点的第二内存中；该数据处理装置1200还包括：第一处理模块(未示出)，用于在根据第一数据的标识信息，在元数据哈希表中确定第一日志记录的起始日志序号之前，响应于第一内存中未存储第一数据，在日志记录哈希表中确定第一数据的标识信息；根据第一数据的标识信息，确定第二日志记录中是否包含第一日志记录；响应于第二日志记录中包含第一日志记录，且第一日志记录的最小日志序号值大于或等于物理页的版本号值，则回放第一日志记录，以读取第一数据。

可选地，第二确定模块1202用于通过以下方式实现根据第一数据的标识信息，在元数据哈希表中确定第一日志记录的起始日志序号：响应于第二日志记录中不包含第一日志记录，或最小日志序号值小于版本号值，根据第一数据的标识信息，在元数据哈希表中确定第一日志记录的起始日志序号。

可选地，第一处理模块用于通过以下方式实现根据第一数据的标识信息，确定第二日志记录中是否包含第一日志记录：响应于在日志记录哈希表中查询到第一数据的标识信息，则确定第二日志记录中包含第一日志记录；响应于未在日志记录哈希表中查询到第一数据的标识信息，则确定第二日志记录中不包含第一日志记录。

可选地，元数据哈希表中还存储第一日志记录的终止日志序号，终止日志序号用于表示第一日志记录的回放终止位置。

可选地，该数据处理装置1200还包括：第一执行模块(未示出)，用于响应于元数据哈希表中的元数据信息的存储时长大于预设时长，异步执行第一操作，第一操作用于指示删除存储时长大于预设时长的元数据信息，元数据信息包括第一数据的标识信息、起始日志序号和第一数据的长度和终止日志序号；或，响应于日志记录哈希表中的第二日志记录的存储时长大于预设时长，异步执行第二操作，第二操作用于指示删除存储时长大于预设时长的第二日志记录。

可选地，该数据处理装置1200还包括：存储模块(未示出)，用于在根据第一数据的标识信息，在元数据哈希表中确定第一日志记录的起始日志序号之前，对日志文件中的第一日志记录进行解析处理，得到元数据信息；将元数据信息存储至元数据哈希表中。

可选地，该数据处理装置1200还包括：第二处理模块(未示出)，用于确定元数据哈希表是否被引用；响应于元数据哈希表未被引用，对元数据哈希表进行加锁处理。

可选地，该数据处理装置1200还包括：拆分模块(未示出)，用于根据元数据哈希表中存储的标识信息，对元数据哈希表进行拆分处理，得到多个元数据哈希子表，多个元数据哈希子表均为加锁状态；相应的，第二确定模块1202用于通过以下方式实现根据第一数据的标识信息，在元数据哈希表中确定第一日志记录的起始日志序号：根据第一数据的标识信息，在多个元数据哈希子表中确定目标元数据哈希子表；对目标元数据哈希子表进行拆锁处理后，在目标元数据哈希子表中确定起始日志序号。

可选地，该数据处理装置1200还包括：第三处理模块，用于响应于第一内存中存储有第一数据，在第一内存中读取第一数据。

可选地，该数据处理装置1200还包括：第二执行模块，用于响应于检测到主节点出现异常，执行主从切换操作。

示例性计算设备

在介绍了本公开示例性实施方式的方法、介质和装置之后，接下来，参考图13对本公开示例性实施方式的计算设备进行说明。

图13显示的计算设备1300仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图13所示，计算设备1300以通用计算设备的形式表现。计算设备1300的组件可以包括但不限于：至少一个处理单元1301、至少一个存储单元1302，连接不同系统组件(包括处理单元1301和存储单元1302)的总线1303。其中，至少一个存储单元1302中存储有计算机执行指令；至少一个处理单元1301包括处理器，处理器执行该计算机执行指令，以实现上文描述的方法。

总线1303包括数据总线、控制总线和地址总线。

存储单元1302可以包括易失性存储器形式的可读介质，例如随机存取存储器(RAM)1321和/或高速缓存存储器1322，可以进一步包括非易失性存储器形式的可读介质，例如只读存储器(ROM)1323。

存储单元1302还可以包括具有一组(至少一个)程序模块1324的程序/实用工具1325，这样的程序模块1324包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

计算设备1300也可以与一个或多个外部设备1304(例如键盘、指向设备等)通信。这种通信可以通过输入/输出接口1305进行，该输入/输出接口1305也可以称为I/O接口1305。并且，计算设备1300还可以通过网络适配器1306与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图13所示，网络适配器1306通过总线1303与计算设备1300的其它模块通信。应当理解，尽管图中未示出，可以结合计算设备1300使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

应当注意，尽管在上文详细描述中提及了数据处理装置的若干单元/模块或子单元/模块，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多单元/模块的特征和功能可以在一个单元/模块中具体化。反之，上文描述的一个单元/模块的特征和功能可以进一步划分为由多个单元/模块来具体化。

此外，尽管在附图中以特定顺序描述了本公开方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

虽然已经参考若干具体实施方式描述了本公开的精神和原理，但是应该理解，本公开并不限于所公开的具体实施方式，对各方面的划分也不意味着这些方面中的特征不能组合以进行受益，这种划分仅是为了表述的方便。本公开旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。

Claims (10)

1.一种数据处理方法，应用于云数据库的从节点，所述云数据库还包括主节点，所述主节点用于读写数据以及生成读写的日志记录，所述日志记录所对应的日志文件存储在所述云数据库的共享存储介质中，所述从节点通过回放所述日志记录实现与所述主节点的数据同步；

所述数据处理方法包括：

响应于接收到第一数据的读取请求，确定所述从节点的第一内存中是否存储所述第一数据，所述第一数据是在所述主节点中所写的数据，所述读取请求中携带所述第一数据的标识信息，所述第一数据的标识信息用于标识所述第一数据所在的数据表和所述第一数据在所述数据表中的物理页；

响应于所述第一内存中未存储所述第一数据，根据所述第一数据的标识信息，在元数据哈希表中确定第一日志记录的起始日志序号，所述元数据哈希表中存储所述第一数据的标识信息、所述起始日志序号和所述第一数据的长度，所述第一日志记录与所述第一数据对应，所述元数据哈希表存储在所述第一内存中；

根据所述起始日志序号，确定所述第一日志记录在日志文件中的起始位置；

根据所述起始位置，在所述日志文件中确定所述第一日志记录；

回放所述第一日志记录，以根据所述第一数据的长度，在所述第一日志记录中读取所述第一数据。

2.根据权利要求1所述的数据处理方法，所述从节点还包括日志记录哈希表，所述日志记录哈希表中存储所述第一数据的标识信息和第二日志记录，所述第二日志记录与所述主节点中预设长度的第二数据对应，所述日志记录哈希表存储在所述从节点的第二内存中；

所述根据所述第一数据的标识信息，在元数据哈希表中确定第一日志记录的起始日志序号之前，还包括：

响应于所述第一内存中未存储所述第一数据，在所述日志记录哈希表中确定所述第一数据的标识信息；

根据所述第一数据的标识信息，确定所述第二日志记录中是否包含所述第一日志记录；

响应于所述第二日志记录中包含所述第一日志记录，且所述第一日志记录的最小日志序号值大于或等于所述物理页的版本号值，则回放所述第一日志记录，以读取所述第一数据。

3.根据权利要求2所述的数据处理方法，所述根据所述第一数据的标识信息，在元数据哈希表中确定第一日志记录的起始日志序号，包括：

响应于所述第二日志记录中不包含所述第一日志记录，或所述最小日志序号值小于所述版本号值，根据所述第一数据的标识信息，在元数据哈希表中确定第一日志记录的起始日志序号。

4.根据权利要求2或3所述的数据处理方法，所述根据所述第一数据的标识信息，确定所述第二日志记录中是否包含所述第一日志记录，包括：

响应于在所述日志记录哈希表中查询到所述第一数据的标识信息，则确定所述第二日志记录中包含所述第一日志记录；

响应于未在所述日志记录哈希表中查询到所述第一数据的标识信息，则确定所述第二日志记录中不包含所述第一日志记录。

5.根据权利要求2或3所述的数据处理方法，所述元数据哈希表中还存储所述第一日志记录的终止日志序号，所述终止日志序号用于表示所述第一日志记录的回放终止位置。

6.根据权利要求5所述的数据处理方法，还包括：

响应于所述元数据哈希表中的元数据信息的存储时长大于预设时长，异步执行第一操作，所述第一操作用于指示删除存储时长大于预设时长的元数据信息，所述元数据信息包括所述第一数据的标识信息、所述起始日志序号、所述第一数据的长度和所述终止日志序号；

或，响应于所述日志记录哈希表中的第二日志记录的存储时长大于预设时长，异步执行第二操作，所述第二操作用于指示删除存储时长大于预设时长的第二日志记录。

7.根据权利要求6所述的数据处理方法，所述根据所述第一数据的标识信息，在元数据哈希表中确定第一日志记录的起始日志序号之前，还包括：

对所述日志文件中的所述第一日志记录进行解析处理，得到所述元数据信息；

将所述元数据信息存储至所述元数据哈希表中。

8.一种介质，所述介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如权利要求1至7中任一项所述的数据处理方法。

9.一种数据处理装置，应用于云数据库的从节点，所述云数据库还包括主节点，所述主节点用于读写数据以及生成读写的日志记录，所述日志记录所对应的日志文件存储在所述云数据库的共享存储介质中，所述从节点通过回放所述日志记录实现与所述主节点的数据同步；

所述数据处理装置包括：

第一确定模块，用于响应于接收到第一数据的读取请求，确定所述从节点的第一内存中是否存储所述第一数据，所述第一数据是在所述主节点中所写的数据，所述读取请求中携带所述第一数据的标识信息，所述第一数据的标识信息用于标识所述第一数据所在的数据表和所述第一数据在所述数据表中的物理页；

第二确定模块，用于响应于所述第一内存中未存储所述第一数据，根据所述第一数据的标识信息，在元数据哈希表中确定第一日志记录的起始日志序号，所述元数据哈希表中存储所述第一数据的标识信息、所述起始日志序号和所述第一数据的长度，所述第一日志记录与所述第一数据对应，所述元数据哈希表存储在所述第一内存中；

第三确定模块，用于根据所述起始日志序号，确定所述第一日志记录在日志文件中的起始位置；

第四确定模块，用于根据所述起始位置，在所述日志文件中确定所述第一日志记录；

读取模块，用于回放所述第一日志记录，以根据所述第一数据的长度，在所述第一日志记录中读取所述第一数据。

10.一种计算设备，包括：处理器，以及与所述处理器连接的存储器；

所述存储器存储计算机执行指令；

所述处理器执行所述存储器存储的计算机执行指令，以实现如权利要求1至7中任一项所述的数据处理方法。