CN113760846A - 一种数据处理方法和装置 - Google Patents

一种数据处理方法和装置 Download PDF

Info

Publication number
CN113760846A
CN113760846A CN202110024298.XA CN202110024298A CN113760846A CN 113760846 A CN113760846 A CN 113760846A CN 202110024298 A CN202110024298 A CN 202110024298A CN 113760846 A CN113760846 A CN 113760846A
Authority
CN
China
Prior art keywords
data
physical
log
log file
transaction
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202110024298.XA
Other languages
English (en)
Inventor
袁博文
彭安
刘珊
孟可
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Jingdong Century Trading Co Ltd
Beijing Wodong Tianjun Information Technology Co Ltd
Original Assignee
Beijing Jingdong Century Trading Co Ltd
Beijing Wodong Tianjun Information Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Jingdong Century Trading Co Ltd, Beijing Wodong Tianjun Information Technology Co Ltd filed Critical Beijing Jingdong Century Trading Co Ltd
Priority to CN202110024298.XA priority Critical patent/CN113760846A/zh
Publication of CN113760846A publication Critical patent/CN113760846A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/1805—Append-only file systems, e.g. using logs or journals to store data
    • G06F16/1815—Journaling file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/16—File or folder operations, e.g. details of user interfaces specifically adapted to file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2228—Indexing structures
    • G06F16/2255—Hash tables
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G06F16/24552—Database cache management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/284—Relational databases

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Human Computer Interaction (AREA)
  • Computational Linguistics (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明公开了一种数据处理方法和装置，涉及计算机技术领域。该方法的一具体实施方式包括：获取数据库主节点的重做日志文件；对主节点的重做日志文件进行解析处理，以得到日志数据及其对应的标识信息，将日志数据存储至物理事务，并将物理事务写入本地重做日志文件；根据标识信息从本地重做日志文件中获取物理事务对应的物理数据页，并根据物理数据页执行相应的数据处理。该实施方式显著降低了数据库主从节点的数据同步延时状况和数据同步成本、提升了数据同步的可拓展性和数据库的***性能。

Description

一种数据处理方法和装置
技术领域
本发明涉及计算机技术领域，尤其涉及一种数据处理方法和装置。
背景技术
关系型数据库(如MySQL)的主从模块式下：通过一个主节点对应一个或多个从节点，让主节点负责写，从节点负责读，能够解决单点负载瓶颈，即使出现主节点锁表、宕机等情形，通过读从节点也可以保证业务的正常运作。要实现上述情形，需要保证数据库的主节点与从节点之间实现数据同步。
现有方法中主要通过二进制日志(binary log，简称binlog，主节点服务器在事务提交后，将产生的binlog文件发送给从节点服务器，从节点服务器接收到binlog后，将主节点生成的逻辑日志应用到自己的数据库***中，从而实现主从数据同步的功能)、以及redolog(重做日志技术，记录了对实际数据文件的物理变更(数据文件的什么位置数据做了如何的变更)，只有当redolog存储到从节点的磁盘后，才会将实际的物理数据页修改存储到磁盘，从而实现主从数据同步)。
现有技术中至少存在如下问题：
现有的业务处理方法中存在主从节点的数据同步延时较长、数据同步成本较高、可拓展性差、影响数据库的***性能的技术问题。
发明内容
有鉴于此，本发明实施例提供一种数据处理方法和装置，能够显著降低数据库主从节点的数据同步延时状况、降低数据同步成本、提升数据同步的可拓展性、提升数据库的***性能。
为实现上述目的，根据本发明实施例的第一方面，提供了一种数据处理方法，包括：
获取数据库主节点的重做日志文件；
对主节点的重做日志文件进行解析处理，以得到日志数据及其对应的标识信息，将日志数据存储至物理事务，并将物理事务写入本地重做日志文件；
根据标识信息从本地重做日志文件中获取物理事务对应的物理数据页，并根据物理数据页执行相应的数据处理。
进一步地，获取数据库主节点的重做日志文件，还包括：
确定数据库的主节点与从节点对应的初始一致位点，获取初始一致位点对应的日志序号之后的重做日志文件，并将重做日志文件存储至从节点对应的缓存中。
进一步地，对主节点的重做日志文件进行解析处理，以得到日志数据及其对应的标识信息，将日志数据存储至物理事务，并将物理事务写入本地重做日志文件，还包括：
遍历并获取缓存中的重做日志文件，根据日志类型对重做日志文件进行分类解析处理，提取标识信息和日志数据，将日志数据存储至物理事务，并将物理事务写入本地重做日志文件；其中，标识信息包括表空间编号和数据页编号。
进一步地，将日志数据存储至物理事务，并将物理事务写入本地重做日志文件，还包括：
将日志数据存储至物理事务，确定单日志类型对应的物理事务和多日志类型对应的物理事务；
根据固定日志数据长度为单日志类型对应的物理事务分配日志序号，根据实际日志数据长度为多日志类型对应的物理事务分配日志序号；
根据物理事务对应的日志序号，将日志数据写入本地重做日志文件。
进一步地，根据标识信息从本地重做日志文件中获取物理事务对应的物理数据页，还包括：
根据哈希表中标识信息与物理事务的对应关系，从本地重做日志文件中获取物理事务对应的物理数据页；其中，哈希表是在将日志数据存储至物理事务的步骤之后创建的。
进一步地，在本地重做日志文件产生写入操作的情况下，方法还包括：
拦截写入操作，确定写入操作的操作来源；
根据操作来源对写入状态进行校正。
进一步地，还包括：
采用下列方法中的至少一种对撤销日志对应的从节点事务状态进行校正：禁止从节点事务重生和清理回滚队列。
根据本发明实施例的第二方面，提供了一种数据处理装置，包括：
文件获取模块，用于获取数据库主节点的重做日志文件；
解析模块，用于对主节点的重做日志文件进行解析处理，以得到日志数据及其对应的标识信息，将日志数据存储至物理事务，并将物理事务写入本地重做日志文件；
数据处理模块，用于根据标识信息从本地重做日志文件中获取物理事务对应的物理数据页，并根据物理数据页执行相应的数据处理。
根据本发明实施例的第三方面，提供了一种电子设备，包括：
一个或多个处理器；
存储装置，用于存储一个或多个程序，
当一个或多个程序被一个或多个处理器执行，使得一个或多个处理器实现如上述任一种数据处理方法。
根据本发明实施例的第四方面，提供了一种计算机可读介质，其上存储有计算机程序，该程序被处理器执行时实现如上述任一种数据处理方法。
上述发明中的一个实施例具有如下优点或有益效果：因为采用获取数据库主节点的重做日志文件；对主节点的重做日志文件进行解析处理，以得到日志数据及其对应的标识信息，将日志数据存储至物理事务，并将物理事务写入本地重做日志文件；根据标识信息从本地重做日志文件中获取物理事务对应的物理数据页，并根据物理数据页执行相应的数据处理的技术手段，所以克服了现有的业务处理方法中存在的主从节点的数据同步延时较长、数据同步成本较高、可拓展性差、影响数据库的***性能的技术问题，进而达到显著降低数据库主从节点的数据同步延时状况、降低数据同步成本、提升数据同步的可拓展性、提升数据库的***性能的技术效果。
上述的非惯用的可选方式所具有的进一步效果将在下文中结合具体实施方式加以说明。
附图说明
附图用于更好地理解本发明，不构成对本发明的不当限定。其中：
图1是根据本发明第一实施例提供的数据处理方法的主要流程的示意图；
图2a是根据本发明第二实施例提供的数据处理方法的主要流程的示意图；
图2b是图2a所述方法对应的框架示意图；
图3是根据本发明实施例提供的数据处理装置的主要模块的示意图；
图4是本发明实施例可以应用于其中的示例性***架构图；
图5是适于用来实现本发明实施例的终端设备或服务器的计算机***的结构示意图。
具体实施方式
以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。
图1是根据本发明第一实施例提供的数据处理方法的主要流程的示意图；如图1所示，本发明实施例提供的数据处理方法主要包括：
步骤S101，获取数据库主节点的重做日志文件。
其中，重做日志文件(redolog)，用于记录对实际数据文件的物理变更(数据文件的什么位置数据做了如何的变更)，只有当redolog存储到磁盘后，才会将实际的物理数据页修改存储到磁盘。这样的设计，使得MySQL数据写入非常安全，即使数据库写到一半发生宕机，也可以使用已经存储到磁盘的redolog来进行本地MySQL的Crash Reco vey(崩溃恢复)。
进一步地，根据本发明实施例，上述获取数据库主节点的重做日志文件，还包括：
确定数据库的主节点与从节点对应的初始一致位点，获取初始一致位点对应的日志序号之后的重做日志文件，并将重做日志文件存储至从节点对应的缓存中。
由于不一致数据库或者一致的数据库的不一致位点均无法应用重做日志文件中的数据，因此，保持初始一致位点是实现本申请的基础(根据本发明实施例的一具体实施方式，初始一致位点通过MySQL8.0克隆功能来实现的)。
具体地，根据本发明实施例，通过记录一致位点的LSN(Log Seq uence Number，日志序号，用于表示特定日志文件记录在日志文件中的位置)，以该LSN作为初始LSN，数据库从节点向主节点发起复制请求，以获取到从起始LSN开始后面的一段redolog日志，并记录这段red olog的结束LSN，并将重做日志文件存储至从节点对应的缓存中。通过上述设置，能够以redolog物理复制的形式，进而通过后续操作使得主节点数据库的redolog可以成功在从节点数据库重做应用成数据库数据，解决了现有方法中采用binlog逻辑复制所导致的***性能降低和主从延迟问题。
优选地，根据本发明实施例，通过数据库从节点与主节点约定好的通信协议和通信请求，获取初始一致位点之后的重做日志文件。
步骤S102，对主节点的重做日志文件进行解析处理，以得到日志数据及其对应的标识信息，将日志数据存储至物理事务，并将物理事务写入本地重做日志文件。
具体地，根据本发明实施例，上述对缓存中的重做日志文件的解析过程遵循存储引擎Innodb的设计规则，即以mtr(Mini-transaction，迷你事务，又称物理事务)为操作单元，以迷你日志(MLOG，Mini-l og)为解析单元，对主节点的重做日志文件进行解析处理，将日志数据存储至物理事务，并将物理事务写入本地重做日志文件。
进一步地，根据本发明实施例，上述对主节点的重做日志文件进行解析处理，以得到日志数据及其对应的标识信息，将日志数据存储至物理事务，并将物理事务写入本地重做日志文件，还包括：
遍历并获取缓存中的重做日志文件，根据日志类型对重做日志文件进行分类解析处理，提取标识信息和日志数据，将日志数据存储至物理事务，并将物理事务写入本地重做日志文件；其中，上述标识信息包括表空间编号和数据页编号。
在将重做日志文件存储至从节点对应的缓存中的步骤之后，激活解析线程(logparser)，以利用解析线程实现对重做日志的解析处理。根据本发明实施例的一具体实施方式，持续遍历缓存中的重做日志文件，若无数据(即缓存内没有重做日志文件)则休眠等待；若有，则获取该重做日志文件，根据日志类型对重做日志文件进行分类解析处理，提取表空间编号(space_id)和数据页编号(page_no)(即标识信息)，以及日志数据，将该日志数据存储至物理事务中后，再将该物理事务写入本地重做日志文件，通过上述设置，将主节点的重做日志文件进行解析并构建为本地可用的物理事务，为后续从节点应用该物理事务的数据做好了基础，同时显著降低数据库主从节点的数据同步延时状况、降低数据同步成本。
优选地，根据本发明实施例，上述将日志数据存储至物理事务，并将物理事务写入本地重做日志文件，还包括：
将日志数据存储至物理事务，确定单日志类型对应的物理事务和多日志类型对应的物理事务；
根据固定日志数据长度为单日志类型对应的物理事务分配日志序号，根据实际日志数据长度为多日志类型对应的物理事务分配日志序号；
根据物理事务对应的日志序号，将日志数据写入本地重做日志文件。
根据本发明实施例，重做日志文件在以迷你日志进行为解析单元进行解析之后，会分为单日志类型和多日志类型存储至物理事务中，对于单日志类型的物理事务直接分配日志数据长度对应的日志序号即可；而多日志类型的物理事务在解析过程中根据每个解析单元的长度递增待分配长度，需要等所有的迷你单元解析完成之后，再根据实时日志数据长度分配对应的日志序号。通过上述设置，将日志序号预分配技术与存储引擎的物理事务本身对应的日志***设计相结合，为待应用的物理事务(指应用物理事务中的物理数据页)预分配日志序号，从而保证后续应用物理事务时的连续性和有序性。
步骤S103，根据标识信息从本地重做日志文件中获取物理事务对应的物理数据页，并根据物理数据页执行相应的数据处理。
redo log通常是物理日志，记录的是数据页的物理修改，而不是某一行或某几行修改成什么样，它用来恢复提交后的物理数据页(恢复数据页，且只能恢复到最后一次提交的位置)。
具体地，根据本发明实施例，上述根据标识信息从本地重做日志文件中获取物理事务对应的物理数据页，还包括：
根据哈希表中标识信息与物理事务的对应关系，从本地重做日志文件中获取物理事务对应的物理数据页；其中，哈希表是在将日志数据存储至物理事务的步骤之后创建的。
根据本发明实施例将日志数据写入本地重做日志文件的步骤之后，激活应用线程，以利用应用线程将物理事务应用至缓冲池。具体地，由于解析好的物理事务是按照表空间编号和数据页编号存放于哈希表。因此可以根据表空间编号和数据页编号从缓存中获取物理数据页，如果存在则直接应用，如果不存在则先从磁盘读取该页。通过上述设置，提升数据同步的可拓展性、提升数据库的***性能。
根据本发明实施例，因为哈希表的无序性，而重做日志文件的应用必须是有序的，哈希表的优势是可根据表空间编号和数据页编号进行数据应用，降低物理数据页在缓冲池中的更新频率，降低磁盘的读取次数。同时，重做日志文件对应用的有序性还通过使用线性应用技术进行替代，即以线性存储结构取代哈希表结构存放物理事务。
进一步地，根据本发明实施例，在本地重做日志文件产生写入操作的情况下，上述方法还包括：
拦截写入操作，确定写入操作的操作来源；
根据操作来源对写入状态进行校正。
对于任何一个MySQL实例，均需要存储自己数据库的元数据信息。自MySQL8.0开始，MySQL的元数据完全交由Innodb存储引擎进行存储，因此所有元数据的修改，均会写入redolog。而本地的任何redolog自由写入，均会导致本地物理数据页与主节点redolog记录的物理数据页变更出现不一致，这种不一致轻则导致数据应用失败，重则直接损坏物理文件导致数据库不可用。因此，通过上述设置，采取外部截断与内部校验双重保证的手段，保证了节点数据的一致性，从而保证了从节点的本地重做日志文件的可应用性，提升了数据同步的可拓展性。
优选地，根据本发明实施例，上述方法还包括：
采用下列方法中的至少一种对撤销日志对应的从节点事务状态进行校正：禁止从节点事务重生和清理回滚队列。
撤销表空间(undo space)又叫撤销日志(undolog)，是Innodb保证数据事务性的重要手段。undolog与redolog互相配合，在事务提交、回滚以及崩溃恢复的时候保证数据库事务的一致性。但是undolog在执行的过程中本身也会产生redolog，这个过程如果在需要执行redolog数据应用从节点发生，则必然会出现自由写入的后果。通过上述设置，在上述采取外部截断与内部校验的手段外，还通过采取防止从节点事务重生和清理回滚队列等多重手段对撤销表空间的状态进行校正。根据本发明实施例的一具体实施方式，从节点重启后，会让未完成事务重生，进而执行undolog，禁止其重生，而撤销(undo)操作所执行的内容，皆可由redolog的应用获得，清理回滚队列也采取同样的原理。通过上述设置，保证了从节点的状态与表空间的状态一致，进而保证了日志序号的一致，进而显著提升了数据库的***性能。
根据本发明实施例的技术方案，因为采用获取数据库主节点的重做日志文件；对主节点的重做日志文件进行解析处理，以得到日志数据及其对应的标识信息，将日志数据存储至物理事务，并将物理事务写入本地重做日志文件；根据标识信息从本地重做日志文件中获取物理事务对应的物理数据页，并根据物理数据页执行相应的数据处理的技术手段，所以克服了现有的业务处理方法中存在的主从节点的数据同步延时较长、数据同步成本较高、可拓展性差、影响数据库的***性能的技术问题，进而达到显著降低数据库主从节点的数据同步延时状况、降低数据同步成本、提升数据同步的可拓展性、提升数据库的***性能的技术效果。
图2a是根据本发明第二实施例提供的数据处理方法的主要流程的示意图；如图2a所示，本发明提供的数据处理方法主要包括：
步骤S201，确定数据库的主节点与从节点对应的初始一致位点，获取初始一致位点对应的日志序号之后的重做日志文件，并将重做日志文件存储至从节点对应的缓存中。
由于不一致数据库或者一致的数据库的不一致位点均无法应用重做日志文件中的数据，因此，保持初始一致位点是实现本申请的基础根据本发明实施例的一具体实施方式，初始一致位点通过MySQL8.0克隆功能来实现的。
具体地，根据本发明实施例，通过记录一致位点的LSN(Log Seq uence Number，日志序号，用于表示特定日志文件记录在日志文件中的位置)，以该LSN作为初始LSN，数据库从节点向主节点发起复制请求，以获取到从起始LSN开始后面的一段redolog日志，并记录这段red olog的结束LSN，并将重做日志文件存储至从节点对应的缓存中。通过上述设置，能够以redolog物理复制的形式，进而通过后续操作使得主节点数据库的redolog可以成功在从节点数据库重做应用成数据库数据，解决了现有方法中采用binlog逻辑复制所导致的***性能降低和主从延迟问题。
优选地，根据本发明实施例，通过数据库从节点与主节点约定好的通信协议和通信请求，获取初始一致位点之后的重做日志文件。
步骤S202，遍历并获取缓存中的重做日志文件，根据日志类型对重做日志文件进行分类解析处理，提取标识信息和日志数据，
具体地，根据本发明实施例，上述对缓存中的重做日志文件的解析过程遵循存储引擎Innodb的设计规则，即以mtr(Mini-transaction，迷你事务，又称物理事务)为操作单元，以迷你日志(MLOG，Mini-l og)为解析单元，对主节点的重做日志文件进行解析处理，将日志数据存储至物理事务，并将物理事务写入本地重做日志文件。
在将重做日志文件存储至从节点对应的缓存中的步骤之后，激活解析线程(logparser)，以利用解析线程实现对重做日志的解析处理。根据本发明实施例的一具体实施方式，持续遍历缓存中的重做日志文件，若无数据(即缓存内没有重做日志文件)则休眠等待；若有，则获取该重做日志文件，根据日志类型对重做日志文件进行分类解析处理，提取表空间编号(space_id)和数据页编号(page_no)(即标识信息)，以及日志数据，将该日志数据存储至物理事务中后，再将该物理事务写入本地重做日志文件，通过上述设置，将主节点的重做日志文件进行解析并构建为本地可用的物理事务，为后续从节点应用该物理事务的数据做好了基础，同时显著降低数据库主从节点的数据同步延时状况、降低数据同步成本。
步骤S203，将日志数据存储至物理事务，确定单日志类型对应的物理事务和多日志类型对应的物理事务。
步骤S204，根据固定日志数据长度为单日志类型对应的物理事务分配日志序号，根据实际日志数据长度为多日志类型对应的物理事务分配日志序号。
根据本发明实施例，重做日志文件在以迷你日志进行为解析单元进行解析之后，会分为单日志类型和多日志类型存储至物理事务中，对于单日志类型的物理事务直接分配日志数据长度对应的日志序号即可；而多日志类型的物理事务在解析过程中根据每个解析单元的长度递增待分配长度，需要等所有的迷你单元解析完成之后，再根据实时日志数据长度分配对应的日志序号。
步骤S205，根据物理事务对应的日志序号，将日志数据写入本地重做日志文件。
通过上述设置，将日志序号预分配技术与存储引擎的物理事务本身对应的日志***设计相结合，为待应用的物理事务(指应用物理事务中的物理数据页)预分配日志序号，从而保证后续应用物理事务时的连续性和有序性。
步骤S206，根据哈希表中标识信息与物理事务的对应关系，从本地重做日志文件中获取物理事务对应的物理数据页。
redo log通常是物理日志，记录的是数据页的物理修改，而不是某一行或某几行修改成什么样，它用来恢复提交后的物理数据页(恢复数据页，且只能恢复到最后一次提交的位置)。
根据本发明实施例将日志数据写入本地重做日志文件的步骤之后，激活应用线程，以利用应用线程将物理事务应用至缓冲池。具体地，由于解析好的物理事务是按照表空间编号和数据页编号存放于哈希表。因此可以根据表空间编号和数据页编号从缓存中获取物理数据页，如果存在则直接应用，如果不存在则先从磁盘读取该页。通过上述设置，提升数据同步的可拓展性、提升数据库的***性能。
步骤S207，根据物理数据页执行相应的数据处理。
具体地，如图2b所示，Master节点为数据库主节点，Slave节点为从节点，logparser为解析线程，log applier为应用线程。
根据本发明实施例，因为哈希表的无序性，而重做日志文件的应用必须是有序的，哈希表的优势是可根据表空间编号和数据页编号进行数据应用，降低物理数据页在缓冲池中的更新频率，降低磁盘的读取次数。同时，重做日志文件对应用的有序性还通过使用线性应用技术进行替代，即以线性存储结构取代哈希表结构存放物理事务。
进一步地，根据本发明实施例，在本地重做日志文件产生写入操作的情况下，上述方法还包括：
拦截写入操作，确定写入操作的操作来源；
根据操作来源对写入状态进行校正。
对于任何一个MySQL实例，均需要存储自己数据库的元数据信息。自MySQL8.0开始，MySQL的元数据完全交由Innodb存储引擎进行存储，因此所有元数据的修改，均会写入redolog。而本地的任何redolog自由写入，均会导致本地物理数据页与主节点redolog记录的物理数据页变更出现不一致，这种不一致轻则导致数据应用失败，重则直接损坏物理文件导致数据库不可用。因此，通过上述设置，采取外部截断与内部校验双重保证的手段，保证了节点数据的一致性，从而保证了从节点的本地重做日志文件的可应用性，提升了数据同步的可拓展性。
优选地，根据本发明实施例，上述方法还包括：
采用下列方法中的至少一种对撤销日志对应的从节点事务状态进行校正：禁止从节点事务重生和清理回滚队列。
撤销表空间(undo space)又叫撤销日志(undolog)，是Innodb保证数据事务性的重要手段。undolog与redolog互相配合，在事务提交、回滚以及崩溃恢复的时候保证数据库事务的一致性。但是undolog在执行的过程中本身也会产生redolog，这个过程如果在需要执行redolog数据应用从节点发生，则必然会出现自由写入的后果。通过上述设置，在上述采取外部截断与内部校验的手段外，还通过采取防止从节点事务重生和清理回滚队列等多重手段对撤销表空间的状态进行校正。根据本发明实施例的一具体实施方式，从节点重启后，会让未完成事务重生，进而执行undolog，禁止其重生，而撤销(undo)操作所执行的内容，皆可由redolog的应用获得，清理回滚队列也采取同样的原理。通过上述设置，保证了从节点的状态与表空间的状态一致，进而保证了日志序号的一致，进而显著提升了数据库的***性能。
根据本发明实施例的技术方案，因为采用获取数据库主节点的重做日志文件；对主节点的重做日志文件进行解析处理，以得到日志数据及其对应的标识信息，将日志数据存储至物理事务，并将物理事务写入本地重做日志文件；根据标识信息从本地重做日志文件中获取物理事务对应的物理数据页，并根据物理数据页执行相应的数据处理的技术手段，所以克服了现有的业务处理方法中存在的主从节点的数据同步延时较长、数据同步成本较高、可拓展性差、影响数据库的***性能的技术问题，进而达到显著降低数据库主从节点的数据同步延时状况、降低数据同步成本、提升数据同步的可拓展性、提升数据库的***性能的技术效果。
图3是根据本发明实施例提供的数据处理装置的主要模块的示意图；如图3所示，本发明实施例提供的数据处理装置300主要包括：
文件获取模块301，用于获取数据库主节点的重做日志文件。
其中，重做日志文件(redolog)，用于记录对实际数据文件的物理变更(数据文件的什么位置数据做了如何的变更)，只有当redolog存储到磁盘后，才会将实际的物理数据页修改存储到磁盘。这样的设计，使得MySQL数据写入非常安全，即使数据库写到一半发生宕机，也可以使用已经存储到磁盘的redolog来进行本地MySQL的Crash Reco vey(崩溃恢复)。
进一步地，根据本发明实施例，上述文件获取模块301，还用于：
确定数据库的主节点与从节点对应的初始一致位点，获取初始一致位点对应的日志序号之后的重做日志文件，并将重做日志文件存储至从节点对应的缓存中。
由于不一致数据库或者一致的数据库的不一致位点均无法应用重做日志文件中的数据，因此，保持初始一致位点是实现本申请的基础(根据本发明实施例的一具体实施方式，初始一致位点通过MySQL8.0克隆功能来实现的)。
具体地，根据本发明实施例，通过记录一致位点的LSN(Log Seq uence Number，日志序号，用于表示特定日志文件记录在日志文件中的位置)，以该LSN作为初始LSN，数据库从节点向主节点发起复制请求，以获取到从起始LSN开始后面的一段redolog日志，并记录这段red olog的结束LSN，并将重做日志文件存储至从节点对应的缓存中。通过上述设置，能够以redolog物理复制的形式，进而通过后续操作使得主节点数据库的redolog可以成功在从节点数据库重做应用成数据库数据，解决了现有方法中采用binlog逻辑复制所导致的***性能降低和主从延迟问题。
优选地，根据本发明实施例，通过数据库从节点与主节点约定好的通信协议和通信请求，获取初始一致位点之后的重做日志文件。
解析模块302，用于对主节点的重做日志文件进行解析处理，以得到日志数据及其对应的标识信息，将日志数据存储至物理事务，并将物理事务写入本地重做日志文件。
具体地，根据本发明实施例，上述对缓存中的重做日志文件的解析过程遵循存储引擎Innodb的设计规则，即以mtr(Mini-transaction，迷你事务，又称物理事务)为操作单元，以迷你日志(MLOG，Mini-l og)为解析单元，对主节点的重做日志文件进行解析处理，将日志数据存储至物理事务，并将物理事务写入本地重做日志文件。
进一步地，根据本发明实施例，上述解析模块302，还用于：
遍历并获取缓存中的重做日志文件，根据日志类型对重做日志文件进行分类解析处理，提取标识信息和日志数据，将日志数据存储至物理事务，并将物理事务写入本地重做日志文件；其中，上述标识信息包括表空间编号和数据页编号。
在将重做日志文件存储至从节点对应的缓存中的步骤之后，激活解析线程(logparser)，以利用解析线程实现对重做日志的解析处理。根据本发明实施例的一具体实施方式，持续遍历缓存中的重做日志文件，若无数据(即缓存内没有重做日志文件)则休眠等待；若有，则获取该重做日志文件，根据日志类型对重做日志文件进行分类解析处理，提取表空间编号(space_id)和数据页编号(page_no)(即标识信息)，以及日志数据，将该日志数据存储至物理事务中后，再将该物理事务写入本地重做日志文件，通过上述设置，将主节点的重做日志文件进行解析并构建为本地可用的物理事务，为后续从节点应用该物理事务的数据做好了基础，同时显著降低数据库主从节点的数据同步延时状况、降低数据同步成本。
优选地，根据本发明实施例，上述解析模块302，还用于：
将日志数据存储至物理事务，确定单日志类型对应的物理事务和多日志类型对应的物理事务；
根据固定日志数据长度为单日志类型对应的物理事务分配日志序号，根据实际日志数据长度为多日志类型对应的物理事务分配日志序号；
根据物理事务对应的日志序号，将日志数据写入本地重做日志文件。
根据本发明实施例，重做日志文件在以迷你日志进行为解析单元进行解析之后，会分为单日志类型和多日志类型存储至物理事务中，对于单日志类型的物理事务直接分配日志数据长度对应的日志序号即可；而多日志类型的物理事务在解析过程中根据每个解析单元的长度递增待分配长度，需要等所有的迷你单元解析完成之后，再根据实时日志数据长度分配对应的日志序号。通过上述设置，将日志序号预分配技术与存储引擎的物理事务本身对应的日志***设计相结合，为待应用的物理事务(指应用物理事务中的物理数据页)预分配日志序号，从而保证后续应用物理事务时的连续性和有序性。
数据处理模块303，用于根据标识信息从本地重做日志文件中获取物理事务对应的物理数据页，并根据物理数据页执行相应的数据处理。
具体地，根据本发明实施例，上述数据处理模块303，还用于：
根据哈希表中标识信息与物理事务的对应关系，从本地重做日志文件中获取物理事务对应的物理数据页；其中，哈希表是在将日志数据存储至物理事务的步骤之后创建的。
根据本发明实施例将日志数据写入本地重做日志文件的步骤之后，激活应用线程，以利用应用线程将物理事务应用至缓冲池。具体地，由于解析好的物理事务是按照表空间编号和数据页编号存放于哈希表。因此可以根据表空间编号和数据页编号从缓存中获取物理数据页，如果存在则直接应用，如果不存在则先从磁盘读取该页。通过上述设置，提升数据同步的可拓展性、提升数据库的***性能。
根据本发明实施例，因为哈希表的无序性，而重做日志文件的应用必须是有序的，哈希表的优势是可根据表空间编号和数据页编号进行数据应用，降低物理数据页在缓冲池中的更新频率，降低磁盘的读取次数。同时，重做日志文件对应用的有序性还通过使用线性应用技术进行替代，即以线性存储结构取代哈希表结构存放物理事务。
进一步地，根据本发明实施例，上述数据处理装置300还包括写入状态校正模块，在本地重做日志文件产生写入操作的情况下，写入状态校正模块用于：
拦截写入操作，确定写入操作的操作来源；
根据操作来源对写入状态进行校正。
对于任何一个MySQL实例，均需要存储自己数据库的元数据信息。自MySQL8.0开始，MySQL的元数据完全交由Innodb存储引擎进行存储，因此所有元数据的修改，均会写入redolog。而本地的任何redolog自由写入，均会导致本地物理数据页与主节点redolog记录的物理数据页变更出现不一致，这种不一致轻则导致数据应用失败，重则直接损坏物理文件导致数据库不可用。因此，通过上述设置，采取外部截断与内部校验双重保证的手段，保证了节点数据的一致性，从而保证了从节点的本地重做日志文件的可应用性，提升了数据同步的可拓展性。
优选地，根据本发明实施例，上述数据处理装置300还包括从节点事务状态进行校正模块，用于：
采用下列方法中的至少一种对撤销日志对应的从节点事务状态进行校正：禁止从节点事务重生和清理回滚队列。
撤销表空间(undo space)又叫撤销日志(undolog)，是Innodb保证数据事务性的重要手段。undolog与redolog互相配合，在事务提交、回滚以及崩溃恢复的时候保证数据库事务的一致性。但是undolog在执行的过程中本身也会产生redolog，这个过程如果在需要执行redolog数据应用从节点发生，则必然会出现自由写入的后果。通过上述设置，在上述采取外部截断与内部校验的手段外，还通过采取防止从节点事务重生和清理回滚队列等多重手段对撤销表空间的状态进行校正。根据本发明实施例的一具体实施方式，从节点重启后，会让未完成事务重生，进而执行undolog，禁止其重生，而撤销(undo)操作所执行的内容，皆可由redolog的应用获得，清理回滚队列也采取同样的原理。通过上述设置，保证了从节点的状态与表空间的状态一致，进而保证了日志序号的一致，进而显著提升了数据库的***性能。
根据本发明实施例的技术方案，因为采用获取数据库主节点的重做日志文件；对主节点的重做日志文件进行解析处理，以得到日志数据及其对应的标识信息，将日志数据存储至物理事务，并将物理事务写入本地重做日志文件；根据标识信息从本地重做日志文件中获取物理事务对应的物理数据页，并根据物理数据页执行相应的数据处理的技术手段，所以克服了现有的业务处理方法中存在的主从节点的数据同步延时较长、数据同步成本较高、可拓展性差、影响数据库的***性能的技术问题，进而达到显著降低数据库主从节点的数据同步延时状况、降低数据同步成本、提升数据同步的可拓展性、提升数据库的***性能的技术效果。
图4示出了可以应用本发明实施例的数据处理方法或数据处理装置的示例性***架构400。
如图4所示，***架构400可以包括终端设备401、402、403，网络404和服务器405(此架构仅仅是示例，具体架构中包含的组件可以根据申请具体情况调整)。网络404用以在终端设备401、402、403和服务器405之间提供通信链路的介质。网络404可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。
用户可以使用终端设备401、402、403通过网络404与服务器405交互，以接收或发送消息等。终端设备401、402、403上可以安装有各种通讯客户端应用，例如数据处理类应用、数据同步类应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等(仅为示例)。
终端设备401、402、403可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。
服务器405可以是提供各种服务的服务器，例如对用户利用终端设备401、402、403所(进行数据处理)的服务器(仅为示例)。该服务器可以对接收到的重做日志文件等数据进行分析等处理，并将处理结果(例如日志数据及其对应的标识信息--仅为示例)反馈给终端设备。
需要说明的是，本发明实施例所提供的数据处理方法一般由服务器405执行，相应地，数据处理装置一般设置于服务器405中。
应该理解，图4中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。
下面参考图5，其示出了适于用来实现本发明实施例的终端设备或服务器的计算机***500的结构示意图。图5示出的终端设备或服务器仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。
如图5所示，计算机***500包括中央处理单元(CPU)501，其可以根据存储在只读存储器(ROM)502中的程序或者从存储部分508加载到随机访问存储器(RAM)503中的程序而执行各种适当的动作和处理。在RAM 503中，还存储有***500操作所需的各种程序和数据。CPU 501、ROM 502以及RAM 503通过总线504彼此相连。输入/输出(I/O)接口505也连接至总线504。
以下部件连接至I/O接口505：包括键盘、鼠标等的输入部分506；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分507；包括硬盘等的存储部分508；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分509。通信部分509经由诸如因特网的网络执行通信处理。驱动器510也根据需要连接至I/O接口505。可拆卸介质511，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器510上，以便于从其上读出的计算机程序根据需要被安装入存储部分508。
特别地，根据本发明公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分509从网络上被下载和安装，和/或从可拆卸介质511被安装。在该计算机程序被中央处理单元(CPU)501执行时，执行本发明的***中限定的上述功能。
需要说明的是，本发明所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的***、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本发明中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行***、装置或者器件使用或者与其结合使用。而在本发明中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行***、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。
附图中的流程图和框图，图示了按照本发明各种实施例的***、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的***来实现，或者可以用专用硬件与计算机指令的组合来实现。
描述于本发明实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的模块也可以设置在处理器中，例如，可以描述为：一种处理器包括文件获取模块、解析模块和数据处理模块。其中，这些模块的名称在某种情况下并不构成对该模块本身的限定，例如，文件获取模块还可以被描述为“用于获取数据库主节点的重做日志文件的模块”。
作为另一方面，本发明还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备包括：获取数据库主节点的重做日志文件；对主节点的重做日志文件进行解析处理，以得到日志数据及其对应的标识信息，将日志数据存储至物理事务，并将物理事务写入本地重做日志文件；根据标识信息从本地重做日志文件中获取物理事务对应的物理数据页，并根据物理数据页执行相应的数据处理。
根据本发明实施例的技术方案，因为采用获取数据库主节点的重做日志文件；对主节点的重做日志文件进行解析处理，以得到日志数据及其对应的标识信息，将日志数据存储至物理事务，并将物理事务写入本地重做日志文件；根据标识信息从本地重做日志文件中获取物理事务对应的物理数据页，并根据物理数据页执行相应的数据处理的技术手段，所以克服了现有的业务处理方法中存在的主从节点的数据同步延时较长、数据同步成本较高、可拓展性差、影响数据库的***性能的技术问题，进而达到显著降低数据库主从节点的数据同步延时状况、降低数据同步成本、提升数据同步的可拓展性、提升数据库的***性能的技术效果。
上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。

Claims (10)

1.一种数据处理方法，其特征在于，包括：
获取数据库主节点的重做日志文件；
对所述主节点的重做日志文件进行解析处理，以得到日志数据及其对应的标识信息，将所述日志数据存储至物理事务，并将所述物理事务写入本地重做日志文件；
根据所述标识信息从所述本地重做日志文件中获取所述物理事务对应的物理数据页，并根据所述物理数据页执行相应的数据处理。
2.根据权利要求1所述的数据处理方法，其特征在于，所述获取数据库主节点的重做日志文件，还包括：
确定所述数据库的主节点与从节点对应的初始一致位点，获取所述初始一致位点对应的日志序号之后的重做日志文件，并将所述重做日志文件存储至从节点对应的缓存中。
3.根据权利要求2所述的数据处理方法，其特征在于，所述对所述主节点的重做日志文件进行解析处理，以得到日志数据及其对应的标识信息，将所述日志数据存储至物理事务，并将所述物理事务写入本地重做日志文件，还包括：
遍历并获取所述缓存中的重做日志文件，根据日志类型对所述重做日志文件进行分类解析处理，提取标识信息和日志数据，将所述日志数据存储至物理事务，并将所述物理事务写入本地重做日志文件；其中，所述标识信息包括表空间编号和数据页编号。
4.根据权利要求3所述的数据处理方法，其特征在于，将所述日志数据存储至物理事务，并将所述物理事务写入本地重做日志文件，还包括：
将所述日志数据存储至物理事务，确定单日志类型对应的物理事务和多日志类型对应的物理事务；
根据固定日志数据长度为所述单日志类型对应的物理事务分配日志序号，根据实际日志数据长度为所述多日志类型对应的物理事务分配日志序号；
根据所述物理事务对应的日志序号，将所述日志数据写入本地重做日志文件。
5.根据权利要求1所述的数据处理方法，其特征在于，所述根据所述标识信息从所述本地重做日志文件中获取所述物理事务对应的物理数据页，还包括：
根据哈希表中所述标识信息与所述物理事务的对应关系，从所述本地重做日志文件中获取所述物理事务对应的物理数据页；其中，所述哈希表是在将所述日志数据存储至物理事务的步骤之后创建的。
6.根据权利要求1所述的数据处理方法，其特征在于，在所述本地重做日志文件产生写入操作的情况下，所述方法还包括：
拦截所述写入操作，确定所述写入操作的操作来源；
根据所述操作来源对写入状态进行校正。
7.根据权利要求6所述的数据处理方法，其特征在于，还包括：
采用下列方法中的至少一种对撤销日志对应的从节点事务状态进行校正：禁止从节点事务重生和清理回滚队列。
8.一种数据处理装置，其特征在于，包括：
文件获取模块，用于获取数据库主节点的重做日志文件；
解析模块，用于对所述主节点的重做日志文件进行解析处理，以得到日志数据及其对应的标识信息，将所述日志数据存储至物理事务，并将所述物理事务写入本地重做日志文件；
数据处理模块，用于根据所述标识信息从所述本地重做日志文件中获取所述物理事务对应的物理数据页，并根据所述物理数据页执行相应的数据处理。
9.一种电子设备，其特征在于，包括：
一个或多个处理器；
存储装置，用于存储一个或多个程序，
当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-7中任一所述的方法。
10.一种计算机可读介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现如权利要求1-7中任一所述的方法。
CN202110024298.XA 2021-01-08 2021-01-08 一种数据处理方法和装置 Pending CN113760846A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110024298.XA CN113760846A (zh) 2021-01-08 2021-01-08 一种数据处理方法和装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110024298.XA CN113760846A (zh) 2021-01-08 2021-01-08 一种数据处理方法和装置

Publications (1)

Publication Number Publication Date
CN113760846A true CN113760846A (zh) 2021-12-07

Family

ID=78786279

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110024298.XA Pending CN113760846A (zh) 2021-01-08 2021-01-08 一种数据处理方法和装置

Country Status (1)

Country Link
CN (1) CN113760846A (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114647624A (zh) * 2022-05-11 2022-06-21 成都云祺科技有限公司 块级cdp中数据库一致点的捕获方法、***、存储介质
CN114816247A (zh) * 2022-04-13 2022-07-29 阿里云计算有限公司 一种逻辑数据获取方法及装置
CN115994191A (zh) * 2023-03-24 2023-04-21 北京极数云舟科技有限公司 基于物理复制的ddl执行数据同步方法及装置
CN118093273A (zh) * 2024-04-23 2024-05-28 成都云祺科技有限公司 重做记录中事务处理方法、***及cdp重放与恢复方法

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114816247A (zh) * 2022-04-13 2022-07-29 阿里云计算有限公司 一种逻辑数据获取方法及装置
CN114647624A (zh) * 2022-05-11 2022-06-21 成都云祺科技有限公司 块级cdp中数据库一致点的捕获方法、***、存储介质
CN114647624B (zh) * 2022-05-11 2022-08-02 成都云祺科技有限公司 块级cdp中数据库一致点的捕获方法、***、存储介质
CN115994191A (zh) * 2023-03-24 2023-04-21 北京极数云舟科技有限公司 基于物理复制的ddl执行数据同步方法及装置
CN118093273A (zh) * 2024-04-23 2024-05-28 成都云祺科技有限公司 重做记录中事务处理方法、***及cdp重放与恢复方法
CN118093273B (zh) * 2024-04-23 2024-07-02 成都云祺科技有限公司 重做记录中事务处理方法、***及cdp重放与恢复方法

Similar Documents

Publication Publication Date Title
CN113760846A (zh) 一种数据处理方法和装置
US8548945B2 (en) Database caching utilizing asynchronous log-based replication
US9811577B2 (en) Asynchronous data replication using an external buffer table
US10303666B2 (en) File transfer system using file backup times
US8103621B2 (en) HSM two-way orphan reconciliation for extremely large file systems
US10275481B2 (en) Updating of in-memory synopsis metadata for inserts in database table
US20170161313A1 (en) Detection and Resolution of Conflicts in Data Synchronization
US10628298B1 (en) Resumable garbage collection
US20150193526A1 (en) Schemaless data access management
US11893041B2 (en) Data synchronization between a source database system and target database system
CN111338834B (zh) 数据存储方法和装置
CN115757616A (zh) 一种基于二进制日志的数据一致性校验方法、装置及介质
CN117043763A (zh) 数据库加速器中的易失性数据库高速缓存
CN112925750A (zh) 用于访问数据的方法、电子设备和计算机程序产品
US10877992B2 (en) Updating a database
US9465810B2 (en) Method and system for a fast full style system check using multithreaded read ahead
US20200142784A1 (en) Method, device and computer program product for recovering metadata
CN111694801A (zh) 一种应用于故障恢复的数据去重方法和装置
US10685014B1 (en) Method of sharing read-only data pages among transactions in a database management system
US11663165B2 (en) Method, electronic device, and computer program product for managing file system
US20170091253A1 (en) Interrupted synchronization detection and recovery
CN112559457A (zh) 数据访问方法及装置
US10185759B2 (en) Distinguishing event type
US11500590B2 (en) Method, device and computer program product for data writing
US11385826B2 (en) Method, electronic device and computer program product for restoring orphan block via replication

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination