CN116401313A - 一种共享存储数据库集群信息同步方法 - Google Patents
一种共享存储数据库集群信息同步方法 Download PDFInfo
- Publication number
- CN116401313A CN116401313A CN202310335286.8A CN202310335286A CN116401313A CN 116401313 A CN116401313 A CN 116401313A CN 202310335286 A CN202310335286 A CN 202310335286A CN 116401313 A CN116401313 A CN 116401313A
- Authority
- CN
- China
- Prior art keywords
- lsn
- data page
- page
- data
- wal
- 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
Links
- 238000000034 method Methods 0.000 title claims abstract description 86
- 238000003860 storage Methods 0.000 title claims abstract description 70
- 238000001514 detection method Methods 0.000 claims abstract description 7
- 230000008569 process Effects 0.000 claims description 38
- 230000015654 memory Effects 0.000 claims description 26
- 230000006870 function Effects 0.000 claims description 17
- 238000004590 computer program Methods 0.000 claims description 8
- 238000011084 recovery Methods 0.000 claims description 6
- 238000005096 rolling process Methods 0.000 claims description 2
- 238000007726 management method Methods 0.000 description 9
- 238000013523 data management Methods 0.000 description 7
- 238000013461 design Methods 0.000 description 5
- 230000004927 fusion Effects 0.000 description 5
- 230000008901 benefit Effects 0.000 description 4
- 238000004364 calculation method Methods 0.000 description 4
- 230000007246 mechanism Effects 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 238000006243 chemical reaction Methods 0.000 description 3
- 230000008878 coupling Effects 0.000 description 3
- 238000010168 coupling process Methods 0.000 description 3
- 238000005859 coupling reaction Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004044 response Effects 0.000 description 3
- 230000001360 synchronised effect Effects 0.000 description 3
- 238000004891 communication Methods 0.000 description 2
- 238000013500 data storage Methods 0.000 description 2
- 230000007423 decrease Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000000977 initiatory effect Effects 0.000 description 2
- 238000000926 separation method Methods 0.000 description 2
- 238000013459 approach Methods 0.000 description 1
- 239000005441 aurora Substances 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000001680 brushing effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000004140 cleaning Methods 0.000 description 1
- 230000008602 contraction Effects 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000008030 elimination Effects 0.000 description 1
- 238000003379 elimination reaction Methods 0.000 description 1
- 230000002708 enhancing effect Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 230000010076 replication Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
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/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/23—Updating
- G06F16/2358—Change logging, detection, and notification
-
- 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/23—Updating
- G06F16/2365—Ensuring data consistency and integrity
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
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)
- Computer Security & Cryptography (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本申请公开了一种共享存储数据库集群信息同步方法,包括预先定义“起始LSN”、“最新LSN”两个变量;在主节点启动后,完成常规的数据完整性检测后,执行如下步骤:获取数据库WAL中最新的LSN;将该最新的LSN存入“起始LSN”和“最新LSN”,并将“起始LSN”和“最新LSN”发送至各从节点;在主节点触发任意涉及数据更新的操作的情况下,执行如下步骤:写WAL,在写完一个日志记录,则获取对应最新的LSN;将最新的LSN存入“最新LSN”,并统计该日志记录中涉及的所有数据页编号wal_page_no;将“最新LSN”和统计到的所有wal_page_no发送给各从节点。本申请的方法能够实现各节点的强独立性,相互影响小,且提高数据同步效率。
Description
技术领域
本申请涉及数据库技术领域,尤其涉及一种共享存储数据库集群信息同步方法。
背景技术
共享存储的数据库集群,在关系数据库市场上已经发展多年。其主要的技术类型有Oracle RAC、Informix SDS和互联网云数据库方案三大类:
1、Oracle RAC
Oracle RAC是最早的共享存储数据库集群,最初在1992年就有了Oracle Cluster版本,到了1998年引入了Cache Fusion(内存融合)技术,发展成今天的样子。Oracle RAC对外提供对等服务,即每个节点对外都可以提供可读、可写服务。Oracle RAC提供了一种多个数据库服务器节点间内存融合的技术,叫作Cache Fusion。每个服务器在处理自身访问时,会查看所需要的内存数据块在哪个服务器中;如果在其它的节点中,它会向该节点请求将数据块发送到本节点,并由本节点控制。同时,Oracle还开发了ASM(automatic storagemanagement)存储管理模块,专门用来提供对多节点共享存储的管理。
Oracle RAC的缺点是耦合度太高,集群中各节点的内存几乎是通过cache fusion(内存融合)机制统一管理的。每个节点在应对数据访问时都需要与其它节点通过多次通讯,确认或传递内存中的数据块。这样的架构很难提供良好的扩展性。业界除了Oracle自己其它厂商都没有采用这样的集群方案。
2、Informix SDS
Informix SDS是Informix在2010年推出的共享存储集群产品。当时,Oracle RAC已经在市场上有10多年了。有声音认为RAC的耦合度太高,集群中有节点故障的话容易影响到其它节点。同时,Cache Fusion(内存融合)的机制在运行时数据传输量与次数过多。为此,Informix提出一种同步的一主多从的集群模式。也就是只有一个数据库节点向外提供读写服务,其它节点仅提供只读服务。但这只是数据库核心角度的功能,因为在这个时期,数据库的路由技术已经比较成熟,对于用户端来说,有多种办法为用户提供透明的服务。有关透明服务的几种常用模式,会在后面简单介绍。在Informix SDS中,Informix在从节点内部嵌入了一个转发模块,能够将接收到的写请求转发给主节点执行。
Informix SDS采用了共享存储,核心内只有主节点对外提供读写服务。主节点遇到数据更新的时候,会首先写WAL(write ahead log,即预先写的日志,以下同)日志;然后主节点会将日志号LSN传送给所有从节点。从节点在接收到主节点发来的LSN(日志序列号,以下同)后,会去共享存储读取WAL日志,并根据日志的内容对本地内存中的数据块做redo。与主节点不同的是,从节点会放弃所有的写盘操作。
在Informix SDS中,从节点的同步机制是通过从主节点接收到的WAL日志位置,从共享存储中读取WAL,在本地做redo(日志重放)来完成的。这里存在两个问题:1)如果仅从主节点得到WAL的LSN,则需要从节点在共享存储上去读取WAL。这时就涉及一个磁盘的I/O。有些时候或者***认为该I/O很耗时。有些类似的方案就要求主节点直接把WAL日志的内容发过来,这样传输的数据量又不可控。同时,各个从节点的WAL重放过程还是比较耗时的。在一些实用性同步级别要求下,主节点是需要等待某些从节点的重放工作的。2)更突出的问题是:从节点的内存大小是有限的,通过WAL信息做redo重放的时候,处理完的数据块是不再回写到共享存储的,因为共享存储中的数据是主节点在维护的。但从节点的内存缓冲区有紧张、耗尽的时候。此时,如果遇到需要把redo过的内存块淘汰的话,就需要从节点维护一个本地的、非共享的磁盘空间,用于临时存放这些从高速缓冲中淘汰下来的数据块。这种本地临时存储的数据块的量会越来越大,不清理的话会影响从节点运行。这时候又需要主节点在每次刷盘操作后,给一定的信息到各个从节点,让从节点根据这些信息释放部分本地的磁盘数据块。这个过程增加了***的复杂度,增加通信量,降低了性能,同时影响了***的稳定性。
3、互联网公司云数据库方案
到了2015年前后,头部的互联网公司在云计算平台上推出数据库的云服务,如:Aurora、PolarDB等。这些数据库强调的是“计算与存储分离”和“云原生”。其中计算与存储分离,指的是数据库将统一利用云计算平台上通用的可扩展存储来管理数据,用于计算的服务器将不绑定特定存储,实现更加自由的数量伸缩。云原生则是将数据库向无服务器(serverless)的模式发展,不再与特定虚机绑定,直接提供数据库的服务。
在这样的发展框架下,这些云数据库方案在架构上是类似于Informix SDS的。毕竟,在云计算众多服务器之间,复杂、频繁地传递内存数据块是不现实的。采用InformixSDS一主多从的结构更为合适,而Informix SDS中各个从节点持续根据WAL做redo(根据日志内容重放操作,以下同)的机制,各节点的计算量较大,且从节点的频繁新增与退出却又是不方便的。
为此,互联网云数据库就更加依赖云上的分布式共享存储,充分利用云平台的分布式存储来支撑数据库集群。在一主多从的数据库集群中,唯一最接近同步的数据就是主节点的预写日志WAL。这是因为主节点的任何更新,最先写入存储的就是WAL。那么,就此引发了“日志即数据”的概念。也就是说各个从节点以访问WAL的结果作为自身的数据标准。为了实现这个目标,这些数据库引入了LSM-tree(Log Structure Merge-Tree)的数据结构来管理数据。LSM以日志的结构管理数据,对于数据的更新效率是很高的,因为只需要追加记录就可以。但LSM对于数据查询的过程就显得复杂,效率会有损失。而且对于传统数据库的多样性访问方法(索引技术)的支持现得单薄。此外,要实现这种数据库方案,对现有的传统数据库改动量过大,数据管理层几乎全部重做。
互联网企业的云数据库方案在架构上可以看成是对Informix SDS的一种进阶。他们秉承了Informix SDS中一写多读的集群工作模式,但着重强调了存储与计算分离,以“日志即数据”的思想,将LSM-tree的概念引入数据库的底层数据管理,避开了传统的数据同步过程。
但LSM的数据管理模式对于数据库的查询效率来说,做出的牺牲比较大。尤其是对数据库采用各种高级、复杂的索引技术有比较大的限制。另外,传统数据库的数据部分以数据块的随机访问为主,如果要做LSM改造的话,工作量非常大,几乎要把底层数据管理重写。
发明内容
本申请实施例提供一种共享存储数据库集群信息同步方法,用以实现各节点的强独立性,相互影响小,且提高数据同步效率。
本申请实施例提供一种共享存储数据库集群信息同步方法,所述共享存储数据库集群为一写多读的主从架构,包括主节点和从节点,所述主节点提供数据读写功能,所述从节点提供只读功能,所述信息同步方法包括:
预先定义变量起始日志序列号(LSN,log serial number)、最新LSN;起始LSN用作从节点在特定情况下做预写式日志(WAL,write ahead log)重放操作时所采用的起始位置,最新LSN为所述主节点最新写入WAL的LSN;
在主节点启动后,完成常规的数据一致性检测后,开始提供服务之前,执行如下步骤:
获取数据库WAL中最新的LSN;
将最新的LSN存入起始LSN和最新LSN,并将起始LSN和最新LSN发送至各从节点;
在主节点触发任意涉及数据更新的操作的情况下,执行如下步骤:
写WAL,在写完一个WAL日志记录后,则获取对应最新的LSN;
将最新的LSN存入最新LSN变量,并统计该WAL日志记录中涉及的所有数据页编号wal_page_no,其中所述wal_page_no为记录日志记录操作过的数据页的编号;
将最新LSN和本次所写日志记录中涉及的所有wal_page_no发送给各从节点。
可选的,在主节点启动后,开始提供服务之前还执行:
根据WAL日志,对数据进行一致性检测,对未提交的事务进行回滚,对已提交、但未落盘的数据进行补写;
在将起始LSN和最新LSN发送至各从节点之后,统计各个从节点跟随的状态,且不必陷入等待状态。
可选的,还包括:
所述主节点启动后,向各从节点发送一次起始LSN;
在运行过程中,根据设定的时间间隔查询本地缓存区中的所有数据页面,找出其中的脏页面,在所有脏页面中找到其LSN的最小值;
若获取的LSN最小值大于在先的起始LSN,则将获取的LSN最小值赋给本地存储的起始LSN,并将该起始LSN发送给各从节点,以使得各从节点基于所述LSN最小值更新其起始LSN。
可选的,在任一从节点本地基于数据页编码page_no维护一个散列表,所述散列表的数据项用于记载数据页的最新LSN;
从节点采用如下方式进行更新:
基于接收到的起始LSN赋值给自身的起始LSN;
基于接收到的最新LSN赋值给自身的最新LSN,以及
记载最早收到的“最新LSN”;
根据接收到的wal_page_no,搜索本地散列表,对散列表中相应数据页的最新LSN进行赋值;
在赋值过程中,禁止其他进程修改所述散列表。
可选的,任一从节点启动后,在提供服务之前,还包括:若接收的起始LSN大于等于最早收到的最新LSN,则直接提供服务。
可选的,还包括任一从节点采用如下方式执行查询:
在需要访问目标数据页之前,获取目标数据页的编码;
若本地缓存不包含所述目标数据页,则基于所获取的目标数据页的编码,从数据页读写服务器Page Server读取所述目标数据页、写入本地缓存,并更新数据页状态,其中Page Server用于提供多节点数据页读写的服务器,每个节点中的程序进程根据数据页编号对数据页做整页的写入或读取;
若本地缓存包含所述目标数据页,则根据目标数据页的编码,在本地的数据表查找;
若本地的数据表的最新LSN相比目标数据页的最新LSN更新,则在内存中恢复目标数据页;
若本地的数据表包含目标数据页的编码、但不包含所需的数据页的情况下,则获取目标数据页的最新LSN,并基于目标数据页的编码分配一个空数据页以使得从节点从“起始LSN”的位置开始,根据WAL的内容,在这个空数据页的基础上,重新构造数据页,直到“最新LSN”的位置;
更新数据页状态。
可选的,在执行查询的过程中,将所述数据表中的数据页的最新LSN,读取到本地变量。
可选的,还包括,所述从节点采用如下方式进行数据页恢复:
读取WAL日志;
利用WAL指针基于WAL日志的LSN配置起止位置;
根据WAL日志记录的内容,对数据页进行日志数据恢复。
本申请实施例还提出一种共享存储集群设备,包括处理器和存储器,所述存储器上存储有计算机程序,所述计算机程序被处理器执行时实现如前述的共享存储数据库集群信息同步方法的步骤。
本申请实施例还提出一种计算机可读存储介质,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现如前述的共享存储数据库集群信息同步方法的步骤。
利用本申请的方案能够实现各节点(主节点和从节点)的强独立性,相互影响小,并且利用本实施例的同步方法能够提高数据同步效率。
上述说明仅是本申请技术方案的概述,为了能够更清楚了解本申请的技术手段,而可依照说明书的内容予以实施,并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂,以下特举本申请的具体实施方式。
附图说明
通过阅读下文优选实施方式的详细描述,各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的,而并不认为是对本申请的限制。而且在整个附图中,用相同的参考符号表示相同的部件。在附图中:
图1为本申请实施例的数据库集群架构示例;
图2为本申请实施例的数据库集群信息同步方法基本流程示例;
图3为本申请实施例的从节点执行查询流程示例。
具体实施方式
下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例,然而应当理解,可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反,提供这些实施例是为了能够更透彻地理解本公开,并且能够将本公开的范围完整的传达给本领域的技术人员。
本申请实施例提供一种共享存储数据库集群信息同步方法,所述共享存储数据库集群为一写多读的主从架构,包括主节点和从节点,所述主节点提供数据读写功能,所述从节点提供只读功能。如图1所示,本申请实施例中的数据库集群,其底层是一个一写多读的主从架构***。只有主节点提供读写功能,而所有的从节点仅提供只读功能。这个基础的***有多种方式对外提供对等的可读写服务。如图1中,有A、B、C三类用户。
A类用户采用扩展的客户端接口模块,该模块会把只读的命令发给从节点,而把写命令发给主节点。这类的接口一般都是对现有的ODBC、JDBC进行增强。
B类用户采用的是一种数据库路由中间件B,这种中间件可以像普通数据库那样提供用户服务,但在内部会自动把写的命令发送给主节点执行,而把只读命令给到从节点执行。如现有的pg_pool或hg_proxy都属于这一类解决方案。
C类用户直接访问集群中的各个节点,但此时,所有的从节点内部附加了写命令转发模块C,它能够将数据库服务器接收到的写命令转发给主节点去执行,然后再把结果返回给客户端。如:Informix SDS,HGDB的Cluster版本采用的这类技术。
而在这个架构中,从主节点到从节点的数据同步是其中重要的技术点。
共享存储的准备
本申请实施例中的数据库集群采用共享存储,严格说,集群中多个数据库节点共同访问共享存储上的同一份数据。
在这个共享存储上,本申请实施例提供以下几种数据存储服务:
Page Server
这是一种能够提供多节点数据页读写的服务器。每个节点中的程序进程根据数据页编号对数据页做整页的写入或读取。每个数据页的大小缺省可以设置为8KB,并可以根据预设参数调整。Page Server用于保证各个节点中的各进程对于数据页的存取完整性。也即任何读到的数据页内容一定是其它进程写完的或没写的,不会出现数据混淆。
Page Server有现成的产品,也可以自行研发。Page Server的访问入口也可以采用多节点设计。Page Server能够提供正常存储的吞吐量即可,为提升性能,可以考虑SSD。
可多点挂载的文件***
相当于一个Linux的文件***可以同时mount到多个节点上。在每个挂载了该文件***的节点上都可以看到这个文件***。其中一个节点写了文件,其它节点可以读取到数据。
多节点挂载的文件***并不要求提供节点之间提供数据读写的完整性。也就是说,一个节点上的进程有可能读到其它节点进程写到一半的内容。这是目前大多数存储厂商提供的普通解决方案。
在本申请实施例中,对于多点挂载的文件***要求:可以是磁盘,顺序读写的速度要快,可靠性高。
数据库对于存储的使用,数据库对于数据的管理分为三类:数据、日志、参数;
数据部分:
数据库的数据是以数据页来组织的,运行过程中是随机访问的模式居多。在多服务器环境中,如果需要共享存储,那么该存储需要提供节点间数据页读写的完整性支持。也即任何对于数据页的读取必须是该数据页写之前或写之后的结果,内容必须是完整的。
由于通常能够提供多节点mount的文件***,对于跨节点之间的读写并不提供保护(在单Linux节点内部,由于文件读写操作属于***调用,所以是能够提供读写完整性的),所以,对于多节点共享存储的数据库解决方案,需要专门提供一种page server,以数据页为读写单位,能够保持多节点之间的读写完整性。
以PostgreSQL数据库为例,PostgreSQL在内部把数据管理的任务交给smgr系列函数来进行处理。smgr函数以数据页为单位访问存储,缺省页面大小为8K。在PostgreSQL数据库中,不仅仅是数据,包括数据字典等,都被当做数据看待,并通过smgr系列函数统一管理与操作。
在本申请实施例中,对smgr系列函数进行改造,让其底层访问上述Page Server的接口,实现数据库数据的共享存储管理。
通过这样的方式,能够避免整个数据库的数据管理与存储部分变成LSM-tree架构,保留了传统数据库成熟、高效的部分,同时也使得集群中的多节点共享存储。此外,由于内存高速缓存的使用,使得对Page Server的I/O性能要求适中。
日志(WAL)部分:
本申请实施例所说的数据库日志,也被称之为WAL(write ahead log),也就是“预先写的日志”,它的写盘是在实际数据更新之前。这样,只要WAL日志中落地的操作,在数据库中就算是可以确认发生的。
在PostgreSQL数据库中,WAL是顺序写的二进制文件。WAL中日志记录的定位通过一个叫LSN(log serial number)变量来确定。而LSN可以看成是写文件时的偏移量,是随着日志的写持续增大的(直到跟换日志存储文件)。
在多节点共享存储的环境中,WAL的部分可以采用未加读写保护的多节点mount(挂载)的文件***承担。
在实际的运行过程中,只有主节点顺序地写WAL,写完后其LSN才会被传送给其它节点。其它节点在读取WAL时,采用的偏移量早已是主节点写过的,因此不会发生读写冲突。只需要保证主节点在写WAL时,不被本地的高速缓存延迟。根据WAL的特性,为了保证数据的安全性(RPO为零),WAL的写缓存原本就可以关掉。
这样,能够以比较低的共享存储要求,满足共享存储数据库集群下日志的管理。
参数文件:
数据库的参数文件是文本文件。在多节点环境中,根据需要可以选择每个节点分别管理自己的参数文件,或者把参数文件放到可共享的文件***中,类似NFS或NAS。在此不做特别要求,可以存放在多点挂载的文件***中,也可以各节点局部独立管理。
如图2所示,所述信息同步方法包括:
主节点增强方案
数据库的主节点对外提供正常的读写服务。主节点的数据管理部分通过smgr函数的改造,访问共享存储提供的Page Server,来管理数据库的数据。日志WAL的部分访问共享存储上的多节点挂载文件***,将WAL存放在这个多节点挂载的文件***上。
在步骤S201中,预先定义两个变量,分别为起始日志序列号(LSN,log serialnumber)(start_lsn)、最新LSN(latest_lsn)。其中,起始LSN用作从节点在特定情况下根据预写式日志(WAL,write ahead log)重放操作时所采用的起始位置;最新LSN为所述主节点最新写入WAL的LSN。
主节点启动操作
数据库服务器作为主节点启动后(主节点与从节点在产品上是同一套,主节点与从节点是数据库启动时的一个模式,可由参数指定),在一些实施例中,在主节点启动后,开始提供服务之前还执行:根据WAL日志,对数据进行一致性检测,对未提交的事务进行回滚,对已提交、但未落盘的数据进行补写,从而达到一致的状态(这是数据库常规的启动过程)。
在主节点启动后,完成常规的数据一致性检测后,开始提供服务之前,执行如下步骤:
在步骤S202中,获取数据库WAL中最新的LSN。
在步骤S203中,将最新的LSN存入变量起始LSN(start_lsn)和最新LSN(latest_lsn),并将起始LSN和最新LSN发送至各从节点,通过这样的方式主节点是否等待从节点回应,取决于对集群耦合级别的要求设定。
主节点写WAL日志操作,数据库主节点在遇到任何一个涉及数据更新的操作时(包括数据对象的创建与改动),都会先写日志,也就是写WAL日志。在写完一个日志记录时,就得到一个最新的LSN。在主节点触发任意涉及数据更新的操作的情况下,执行如下步骤:
在步骤S204中,写WAL,在写完一个WAL日志记录后,则获取对应最新的LSN。数据库主节点在写完一个日志记录后,就得到一个最新的LSN,本申请实施例中在主节点写下一个WAL日志记录之前,需要将最新LSN和所有wal_page_no发送给各从节点。一种优选的方式可以在主节点写完一个WAL日志记录时,立即获取对应最新的LSN并存入变量“最新LSN”,这样的方式可以保证主节点写下一个WAL日志记录之前,最新的LSN不会被其他进程修改,保证数据内容的可靠性。
在步骤S205中,将最新的LSN存入变量“最新LSN”,并统计该WAL中涉及的所有数据页编号wal_page_no,其中所述wal_page_no为记录日志记录操作过的数据页的编号。
在步骤S206中,将最新LSN和所有wal_page_no发送给各从节点。在将起始LSN和最新LSN发送至各从节点之后,统计各个从节点跟随的状态、不陷入等待状态。通过这样的设计主节点能够获取数据库集群的工作状态,无论从节点是否回应,主节点可以继续自身的流程,不必陷入等待状态。
本申请实施例应用于共享存储的集群,主节点与从节点之间的数据同步级别对主节点故障时的主从切换结果影响不大。有影响的是各个从节点对于各自本地查询请求应对的有效程度。因此,主节点在发送latest_lsn和相应的wal_page_no列表给各个从节点后,原则上可以不等待从节点的回应,如果要等待,也只是统计各个从节点跟随的状态,而不必陷入等待状态。
当然,主节点可以保留返回latest_lsn内容给本地客户端的能力。主节点的客户端得到相应的latest_lsn后可以用于在在后在从节点执行查询时,对于数据同步级别的控制。
本申请的关键技术点之一是“主节点发送latest_lsn连同wal_page_no列表给各从节点”,由此主节点能够发送尽可能少的内容,且不必硬性等待从节点回应,对性能影响降到最低。
在一些实施例中,还包括:
所述主节点启动后,向各从节点发送一次起始LSN;
在运行过程中,根据设定的时间间隔查询本地缓存区中的所有数据页面,找出其中的脏页面,在所有脏页面中找到其LSN的最小值。
在步骤S208中,若获取的LSN最小值大于在先的起始LSN,则将获取的LSN最小值赋给本地存储的起始LSN,并将该起始LSN发送给各从节点,以使得各从节点基于所述LSN最小值更新其起始LSN。这样,各从节点所存储的“起始LSN”会随着主节点工作状态的变化逐渐变大,不强制要求从节点得到回应使在后的处理更高效,这样的start_lsn更新提升了效率。
本申请实施例中从节点对外仅提供只读的数据库服务,也就是纯查询。这种限制可以在数据库实例的层面进行。具体实现可以参考PostgreSQL在流复制集群中备节点的只读限制。如果整个数据库集群需要对外提供透明的可读可写访问,则可以采用第一节“***架构介绍”中所述的三种途径(客户端增强接口、数据库路由中间件、服务器端转发模块)对集群***进行增强。
从节点是数据库启动的一种模式,它与主节点在软件上是同一个版本,只是因为启动参数的不同而处于不同的运行模式。
与主节点类似,从节点数据库的数据访问是通过smgr系列函数访问Page Server,而日志部分访问多节点挂载的文件***上的WAL。下面进一步介绍从节点增强方案,从节点配只有从主节点传来的start_lsn、从主节点传来的latest_lsn以及从节点最早收到的latest_lsn后续描述为early_lsn。
在一些实施例中,在任一从节点本地基于数据页编码page_no维护一个数据表,所述数据表的数据项用于记载数据页的最新LSN。一种具体的实现方式为,从节点可以在本地维护一个以数据页编码page_no为散列值的散列表page_hash(数据表),散列表的数据项内容记载的是page_last_lsn。该散列表自身包含散列值冲突的处理。在从节点维护数据页散列表是本申请是的又一关键技术点,通过该散列表可以根据输入的page_no快速找到对应的page_last_lsn。
从节点采用如下方式进行更新:
基于接收到的起始LSN赋值给自身的起始LSN(start_lsn);
基于接收到的最新LSN赋值给自身的最新LSN(latest_lsn),以及
记载最早收到的“最新LSN”,也即将第一次收到的latest_lsn赋给early_lsn,early_lsn=latest_lsn。
根据接收到的wal_page_no,搜索本地,对数据表中相应数据页的最新LSN进行赋值,也即根据一同收到的wal_page_no列表,以其中每个wal_page_no为散列值,搜寻本地数据页散列表page_hash,将latest_lsn赋到page_hash相应的单元中。
在赋值过程中,对page_hash进行保护,禁止其他进程修改所述数据表,在此做并发访问的读写一致性保护。
从节点在启动后,在对外提供服务之前,需要等待主节点传过来的信息。这些信息包括:起始LSN(start_lsn)、最新LSN(latest__lsn)及其wal_page_no列表。在一些实施例中,任一从节点启动后,在提供服务之前,还包括:若接收的起始LSN大于等于最早收到的最新LSN,也即此时从节点自身维护的数据页散列表page_hash包含了足够的数据同步信息,这是从节点能够提供数据完整***的前提条件,此后便可以对外提供查询服务。
集群中,数据库的从节点可以在任意时间启动或重新启动。在通常情况下,先启动所有从节点,再启动主节点是比较顺畅的流程,从节点可以得到主节点启动时第一时间发送过来的信息。
从节点是只读节点,接收并处理客户端的查询请求是从节点的主要工作。如何处理、运行查询,是本申请实施例的重点。首先,从节点接收到客户端发来的查询请求时,需要确认目前数据库的状态是否满足信息同步的要求。如果对于信息同步不做特定的要求,则认为该查询是异步的。若接到的查询请求有附加LSN信息:latest_lsn<查询的附加LSN信息,则等待,判断是否超时,超时退出报错。
在一些实施例中,还包括任一从节点采用如下方式执行查询:
在需要访问目标数据页之前,获取目标数据页的编码,在得到数据页编码的位置,执行如下逻辑,如图3所示:
若本地缓存不包含所述目标数据页,则基于所获取的目标数据页的编码,通过smgr函数,从数据页读写服务器Page Server读取所述目标数据页,如果Page Server上没有相应的数据页,说明该数据块只是在主节点的内存中,还没落盘,则数据页状态=没拿到内存数据页。否则将数据页从Page Server读入内存缓冲、写入本地缓存,并更新数据页状态,数据页状态=拿到内存数据页,其中Page Server用于提供多节点数据页读写的服务器,每个节点中的程序进程根据数据页编号对数据页做整页的写入或读取。
数据页状态=拿到内存数据页的情况下,根据数据页编码,对该页进行封锁。若本地缓存包含所述目标数据页,则根据目标数据页的编码,在本地的数据表查找;
若本地的数据表的最新LSN相比目标数据页的最新LSN更新,则在内存中恢复目标数据页,也即在page_hash中找到page_last_lsn&&(page_hash中的page_last_lsn>数据页中的page_last_lsn),则数据页恢复(数据页编码,数据页中的page_last_lsn,page_hash中的page_last_lsn)。
若本地的数据表包含目标数据页的编码、但不包含所需的数据页的情况下,则获取目标数据页的最新LSN,并基于目标数据页的编码分配一个空数据页。
在散列表page_hash中找该数据页编码,拿到对应的page_last_lsn,若散列表page_hash中没有所需的数据页,报错,并使用该编码分配一个空数据页。
数据页恢复(数据页编码,start_lsn,page_hash中的page_last_lsn)。此时,从节点需要从“起始LSN”的位置开始,根据WAL的内容,在这个空数据页的基础上,重新构造数据页,直到“最新LSN”的位置。
更新数据页状态,解除该数据页封锁。
在一些实施例中,在执行查询的过程中,将所述数据表中的数据页的最新LSN,读取到本地变量,从而不影响散列表本身在这个过程中被其它进程修改。
在一些实施例中,还包括,所述从节点采用如下方式进行数据页恢复:
数据页恢复过程会被反复调用,因此会设计成一个过程,该过程有三个参数:数据页编码(要恢复的数据页编码),开始LSN,结束LSN。
执行过程是:从“开始LSN”的位置开始读取WAL日志,一直到“结束LSN”的位置;对于读取到的每一条日志记录,若日志记录中的数据页编码等于该过程输入参数中的数据页编码,则根据当前WAL日志记录的内容对该数据页进行恢复。循环结束时,将该数据页中的page_last_lsn属性变量赋成“结束LSN”。
数据页恢复的过程会被经常调用,在一些实施例中,可以为WAL日志在从节点本地做一个内存的缓冲管理,根据不同的LSN判断出所需要的WAL记录是否在内存中。
从节点的内存缓冲区在数据页淘汰的时候不必写回存储,直接淘汰。
由于缓冲区中所有的“脏”数据页都是经过WAL重放恢复的,在数据页淘汰策略上,做改进,可以优先淘汰“干净”的数据页。
数据库节点启停与主从转换
数据库节点的启停与主从节点的转换可以通过下述的过程组合而成:
1、主节点停止对外服务
主节点数据库直接停止服务,直接退出。此时,各个从节点不再能得到主节点发送的信息了,但不影响从节点继续对外提供只读服务。
2、从节点的升格成主节点
从节点升格成主节点,其过程相当于从节点重启。
首先,确认集群中主节点停止工作,从节点获得Page Server与WAL的写权限。从物理上讲,这种写权限也许原本就存在,但此时需要在逻辑上得到确认。
接下来,从节点上的数据库实例以主节点模式启动;
此时,只有WAL中的数据被认为是可靠的,Page Server中的数据信息可能是旧的(因为不能保证之前的主节点是正常关闭的)。此时的过程与普通数据库的启动过程是一样的(不依赖之前是否正常关机),需要对数据进行检测、恢复。
在本申请实施例的集群中,采用的是共享存储,各个从节点的地位其实是一样的,用哪个重启、升格都可以。
新的主节点启动后,需要去访问集群管理信息,得到集群中各个从节点的通信地址,给各个从节点发送同步信息。
其它从节点跟随新主节点,在新的主节点产生后,之前的各个从节点需要与新的主节点建立联系,跟随新主节点。此时,从节点执行如下操作:
1)从节点停止对外服务;
2)清空自己的散列表page_hash、latest_lsn、start_lsn;
3)配置新主节点地址信息;
4)从新主节点接收初始LSN、最新LSN、以及被更新数据页编码;当初始LSN大于最初得到的最新SLN,开启对外服务;
这实际上就是一个普通的从节点启动过程。
新的节点以从节点的身份加入集群。
综上,本申请实施例的方案能够适用于多种数据库***的增强与改造,例如可以基于PostgreSQL实现。
本申请实施例的方法主节点仅传递日志编号与更新数据页编码列表。这是目前各种方案中传递数据量几乎最小,但信息又非常有效的模式。专利保护这两个数据项的设计,与此不同的信息设计或比此更繁杂的信息传递不在保护范围。
同时,本申请实施例的方法主节点在此不必依赖从节点的回应,对性能影响降到最低(运行上可以是异步的)。而同时,这个传递的日志编号又可以用于从节点同步级别的控制,并可以提供整个集群从“异步”到“严格同步”的多种级别的数据访问模式,不依赖从节点回应的通信设计。
本申请实施例的方法中从节点维护数据页状态的散列表,并且“按需”刷新数据页。数据页状态散列表体积很小,访问高效,易于维护;专利保护该散列表的设计:以数据页编号为散列值,散列表项的内容只有一个字段:更新数据页最新的LSN。从节点根据使用需要刷新数据页,避免了各类多余的操作,同时也规避了其它解决方案要面对的多种技术问题。
本申请实施例的方法,数据同步效率高;支持节点间多种数据同步级别;各个节点独立性强,相互影响小;能够提供好的查询性能扩展性;方便节点数量伸缩;节点增减、主从转换过程简洁、安全;对于存储的要求低、标准规范,对于现有传统数据库改动量小,适用计算与存储分离的云原生数据库模式,如:serverless数据库。
本申请实施例还提出一种共享存储集群设备,包括处理器和存储器,所述存储器上存储有计算机程序,所述计算机程序被处理器执行时实现如前述的共享存储数据库集群信息同步方法的步骤。
本申请实施例还提出一种计算机可读存储介质,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现如前述的共享存储数据库集群信息同步方法的步骤。
需要说明的是,在本文中,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
上述本申请实施例序号仅仅为了描述,不代表实施例的优劣。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中,包括若干指令用以使得一台终端(可以是手机,计算机,服务器或者网络设备等)执行本申请各个实施例所述的方法。
上面结合附图对本申请的实施例进行了描述,但是本申请并不局限于上述的具体实施方式,上述的具体实施方式仅仅是示意性的,而不是限制性的,本领域的普通技术人员在本申请的启示下,在不脱离本申请宗旨和权利要求所保护的范围情况下,还可做出很多形式,这些均属于本申请的保护之内。
Claims (10)
1.一种共享存储数据库集群信息同步方法,其特征在于,所述共享存储数据库集群为一写多读的主从架构,包括主节点和从节点,所述主节点提供数据读写功能,所述从节点提供只读功能,所述信息同步方法包括:
预先定义变量起始日志序列号(LSN,logserialnumber)、最新LSN;起始LSN用作从节点在特定情况下做预写式日志(WAL,writeaheadlog)重放操作时所采用的起始位置,最新LSN为所述主节点最新写入WAL的LSN;
在主节点启动后,完成常规的数据一致性检测后,开始提供服务之前,执行如下步骤:
获取数据库WAL中最新的LSN;
将最新的LSN存入起始LSN和最新LSN,并将起始LSN和最新LSN发送至各从节点;
在主节点触发任意涉及数据更新的操作的情况下,执行如下步骤:
写WAL,在写完一个WAL日志记录后,则获取对应最新的LSN;
将最新的LSN存入最新LSN变量,并统计该WAL日志记录中涉及的所有数据页编号wal_page_no,其中所述wal_page_no为记录日志记录操作过的数据页的编号;
将最新LSN和本次所写日志记录中涉及的所有wal_page_no发送给各从节点。
2.如权利要求1所述的共享存储数据库集群信息同步方法,其特征在于,在主节点启动后,开始提供服务之前还执行:
根据WAL日志,对数据进行一致性检测,对未提交的事务进行回滚,对已提交、但未落盘的数据进行补写;
在将起始LSN和最新LSN发送至各从节点之后,统计各个从节点跟随的状态,且不必陷入等待状态。
3.如权利要求1所述的共享存储数据库集群信息同步方法,其特征在于,还包括:
所述主节点启动后,向各从节点发送一次起始LSN;
在运行过程中,根据设定的时间间隔查询本地缓存区中的所有数据页面,找出其中的脏页面,在所有脏页面中找到其LSN的最小值;
若获取的LSN最小值大于在先的起始LSN,则将获取的LSN最小值赋给本地存储的起始LSN,并将该起始LSN发送给各从节点,以使得各从节点基于所述LSN最小值更新其起始LSN。
4.如权利要求1所述的共享存储数据库集群信息同步方法,其特征在于,在任一从节点本地基于数据页编码page_no维护一个散列表,所述散列表的数据项用于记载数据页的最新LSN;
从节点采用如下方式进行更新:
基于接收到的起始LSN赋值给自身的起始LSN;
基于接收到的最新LSN赋值给自身的最新LSN,以及
记载最早收到的“最新LSN”;
根据接收到的wal_page_no,搜索本地散列表,对散列表中相应数据页的最新LSN进行赋值;
在赋值过程中,禁止其他进程修改所述散列表。
5.如权利要求4所述的共享存储数据库集群信息同步方法,其特征在于,任一从节点启动后,在提供服务之前,还包括:若接收的起始LSN大于等于最早收到的最新LSN,则直接提供服务。
6.如权利要求4所述的共享存储数据库集群信息同步方法,其特征在于,还包括任一从节点采用如下方式执行查询:
在需要访问目标数据页之前,获取目标数据页的编码;
若本地缓存不包含所述目标数据页,则基于所获取的目标数据页的编码,从数据页读写服务器PageServer读取所述目标数据页、写入本地缓存,并更新数据页状态,其中PageServer用于提供多节点数据页读写的服务器,每个节点中的程序进程根据数据页编号对数据页做整页的写入或读取;
若本地缓存包含所述目标数据页,则根据目标数据页的编码,在本地的数据表查找;
若本地的数据表的最新LSN相比目标数据页的最新LSN更新,则在内存中恢复目标数据页;
若本地的数据表包含目标数据页的编码、但不包含所需的数据页的情况下,则获取目标数据页的最新LSN,并基于目标数据页的编码分配一个空数据页以使得从节点从“起始LSN”的位置开始,根据WAL的内容,在这个空数据页的基础上,重新构造数据页,直到“最新LSN”的位置;
更新数据页状态。
7.如权利要求6所述的共享存储数据库集群信息同步方法,其特征在于,在执行查询的过程中,将所述数据表中的数据页的最新LSN,读取到本地变量。
8.如权利要求6所述的共享存储数据库集群信息同步方法,其特征在于,还包括,所述从节点采用如下方式进行数据页恢复:
读取WAL日志;
利用WAL指针基于WAL日志的LSN配置起止位置;
根据WAL日志记录的内容,对数据页进行日志数据恢复。
9.一种共享存储集群设备,其特征在于,包括处理器和存储器,所述存储器上存储有计算机程序,所述计算机程序被处理器执行时实现如权利要求1至8中任一项所述的共享存储数据库集群信息同步方法的步骤。
10.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现如权利要求1至8中任一项所述的共享存储数据库集群信息同步方法的步骤。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202310335286.8A CN116401313A (zh) | 2023-03-31 | 2023-03-31 | 一种共享存储数据库集群信息同步方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202310335286.8A CN116401313A (zh) | 2023-03-31 | 2023-03-31 | 一种共享存储数据库集群信息同步方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN116401313A true CN116401313A (zh) | 2023-07-07 |
Family
ID=87019361
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202310335286.8A Pending CN116401313A (zh) | 2023-03-31 | 2023-03-31 | 一种共享存储数据库集群信息同步方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN116401313A (zh) |
-
2023
- 2023-03-31 CN CN202310335286.8A patent/CN116401313A/zh active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11755415B2 (en) | Variable data replication for storage implementing data backup | |
US10437721B2 (en) | Efficient garbage collection for a log-structured data store | |
JP4568115B2 (ja) | ハードウェアベースのファイルシステムのための装置および方法 | |
KR101827239B1 (ko) | 분산 데이터 시스템들을 위한 전 시스템에 미치는 체크포인트 회피 | |
KR101833114B1 (ko) | 분산 데이터베이스 시스템들을 위한 고속 장애 복구 | |
CN1746893B (zh) | 事务文件*** | |
US8074035B1 (en) | System and method for using multivolume snapshots for online data backup | |
US11841844B2 (en) | Index update pipeline | |
CN101567805B (zh) | 并行文件***发生故障后的恢复方法 | |
US8112607B2 (en) | Method and system for managing large write-once tables in shadow page databases | |
KR100450400B1 (ko) | 안전 기억 장치가 없는 환경을 위한 이중화 구조의 주 메모리 상주 데이터베이스 관리시스템 및 그 데이터 일치성 제어방법 | |
KR20150132511A (ko) | 로그 레코드 관리 | |
CN108701048A (zh) | 数据加载方法及装置 | |
CN101689129A (zh) | 在群集文件***中的文件***安装 | |
US5504857A (en) | Highly available fault tolerant relocation of storage with atomicity | |
EP1131715A1 (en) | Distributed transactional processing system and method | |
US10909091B1 (en) | On-demand data schema modifications | |
US10803006B1 (en) | Persistent memory key-value store in a distributed memory architecture | |
US6658541B2 (en) | Computer system and a database access method thereof | |
EP4307137A1 (en) | Transaction processing method, distributed database system, cluster, and medium | |
JP4286857B2 (ja) | ノード間共用ファイル制御方法 | |
CN116401313A (zh) | 一种共享存储数据库集群信息同步方法 | |
JP2013161398A (ja) | データベースシステム、データベース管理方法、およびデータベース管理プログラム | |
JP3866448B2 (ja) | ノード間共用ファイル制御方式 | |
WO2020024590A1 (en) | Persistent memory key-value store in a distributed memory architecture |
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 |