CN110471909A - 一种数据库管理方法、装置、服务器及存储介质 - Google Patents
一种数据库管理方法、装置、服务器及存储介质 Download PDFInfo
- Publication number
- CN110471909A CN110471909A CN201910792037.5A CN201910792037A CN110471909A CN 110471909 A CN110471909 A CN 110471909A CN 201910792037 A CN201910792037 A CN 201910792037A CN 110471909 A CN110471909 A CN 110471909A
- Authority
- CN
- China
- Prior art keywords
- database
- library
- record
- opening
- master library
- 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.)
- Granted
Links
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/21—Design, administration or maintenance of databases
-
- 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
- G06F16/275—Synchronous replication
Landscapes
- Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种数据库管理方法、装置、服务器及存储介质。该方法包括:获取至少两个数据库所对应系统表中的打开记录;按照预设字段比较各所述系统表中的打开记录,预设字段包括:第一标识符和第一序列值,第一标识符为目标数据库当前进入打开状态对应的标识符,第一序列值为目标数据库的当前日志序列值;根据打开记录的比较结果确定各数据库的属性,所述属性包括主库、备库和脑裂库中的至少一种。上述技术方案利用系统表记录主库的打开记录,备库通过重演Redo日志同步主库系统表的内容,通过比较系统表的打开记录比较各数据库的数据是否一致,进而确定数据库的属性,实现了准确确定主库、备库以及脑裂库,提高数据库运行的稳定性。
Description
技术领域
本发明实施例涉及数据库技术领域,尤其涉及一种数据库管理方法、装置、服务器及存储介质。
背景技术
在大数据时代,利用数据库的主备架构可形成数据守护系统。数据守护系统由一个主库和若干个备库组成,其中,主库提供数据读取和修改服务,备库仅提供只读服务,主库故障时,备库将接管作为主库继续对外提供服务,从而满足用户对数据库服务的高可用性的需求。主库通过重做(Redo)日志记录对数据执行的修改操作,每次数据修改生成Redo日志时会使用一个日志序列值LSN(Log Sequence Number)来标识,一个LSN代表一次数据库修改操作,备库通过重演主库的Redo日志和主库保持数据一致。同一个数据守护系统中只能有一个主库,如果出现了两个主库则认为发生脑裂,数据守护系统异常。
现有的数据库管理方法是根据LSN来判断主库和备库的数据一致情况。但LSN本身不具有明确的逻辑含义,LSN相同并不代表对应的修改内容也是相同的,仅根据LSN无法判断故障数据库与当前主库的数据是否完全一致,无法准确识别数据库的属性,如果对数据库属性的识别出现错误,会导致数据库之间的数据不一致、数据损坏,如果进一步使用脑裂库进行主备切换则会导致整个数据守护系统的数据错乱,故障数据库难以恢复,数据库无法正常稳定的运行。
发明内容
本发明提供了一种数据库管理方法、装置、服务器及存储介质,以实现准确确定数据库的属性,提高数据库运行的稳定性。
第一方面,本发明实施例提供了一种数据库管理方法,包括:
获取至少两个数据库所对应系统表中的打开记录;
按照预设字段比较各所述系统表中的打开记录,所述预设字段包括:第一标识符和第一序列值,所述第一标识符为目标数据库当前进入打开状态对应的标识符,所述第一序列值为目标数据库的当前日志序列值;
根据打开记录的比较结果确定各数据库的属性,所述属性包括主库、备库和脑裂库中的至少一种。
进一步的,还包括:
当主库进入打开状态但还未对数据进行操作时,将所述主库作为目标数据库,并按照预设字段生成所述目标数据库的一条打开记录;
将目标数据库的打开记录写入所述目标数据库对应的系统表中。
进一步的,所述根据打开记录的比较结果确定各数据库的属性,包括:
若各所述系统表所包含各条打开记录的内容相同,则获取各所述数据库的当前日志序列值,并将当前日志序列值较大的数据库确定为主库,其他数据库确定为备库;
若各所述数据库的当前日志序列值均相等,则根据预设规则确定各所述数据库的属性。
进一步的,所述根据打开记录的比较结果确定各数据库的属性,包括:
若存在至少两个系统表中的打开记录的内容为包含关系,则提取第二序列值,所述第二序列值为满足包含关系的系统表中首条内容不同的打开记录中的日志序列值;
若被包含系统表所对应被包含数据库的当前日志序列值小于或等于所述第二序列值,则将所述被包含数据库确定为备库,否则,将所述被包含数据库确定为脑裂库,所述当前日志序列值为所述被包含数据库当前已经产生的最大日志序列值。
进一步的,所述根据打开记录的比较结果确定各数据库的属性,包括:
若各所述系统表中的各条打开记录的内容不相同,且至少两个系统表的打开记录的内容为非包含关系,则检测用户输入的干预指令;
根据所述干预指令确定各数据库的属性。
进一步的,所述根据打开记录的比较结果确定各数据库的属性,包括:
根据打开记录对应的数据库模式、数据库状态以及数据库故障状态的组合类型执行对应的数据库操作以确定各数据库的属性;
所述数据库操作包括以下至少一种:脑裂标记操作、配置状态切换操作、打开状态切换操作、备库模式切换操作、主库模式切换操作以及主库选择操作。
进一步的,所述预设字段还包括以下至少之一:打开记录对应的系统表行号、时间信息、数据库模式、历史主库名称、目标数据库名称、历史主库魔数、目标数据库魔数以及历史主库节点个数;
在所述预设字段包括历史主库节点个数的情况下,所述第一序列值为目标数据库对应历史主库的每个节点重演到的当前日志序列值构成的数组。
第二方面,本发明实施例提供了一种数据库管理装置,包括:
获取模块,用于获取至少两个数据库所对应系统表中的打开记录;
比较模块,用于按照预设字段比较各所述系统表中的打开记录,所述预设字段包括:第一标识符和第一序列值,所述第一标识符为目标数据库当前进入打开状态对应的标识符,所述第一序列值为目标数据库的当前日志序列值;
管理模块,用于根据打开记录的比较结果确定各数据库的属性,所述属性包括主库、备库和脑裂库中的至少一种。
第三方面,本发明实施例提供了一种服务器,包括:
一个或多个处理器;
存储装置,用于存储一个或多个程序;
当所述一个或多个程序被所述一个或多个处理器执行,使得所述一个或多个处理器实现如第一方面所述的数据库管理方法。
第四方面,本发明实施例还提供了一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现如第一方面所述的数据库管理方法。
本发明实施例提供了一种数据库管理方法、装置、服务器及存储介质。该方法包括:获取至少两个数据库所对应系统表中的打开记录;比较各所述系统表中的打开记录;根据打开记录的比较结果确定各数据库的属性,所述属性包括主库、备库和脑裂库中的至少一种。上述技术方案利用系统表记录主库的打开记录,备库通过重演Redo日志同步主库系统表的内容,通过比较系统表的打开记录即可判断各数据库的数据是否一致,基于此确定数据库的属性,实现了准确确定主库、备库以及脑裂库的目的,提高数据库运行的稳定性。
附图说明
图1为本发明实施例一提供的一种数据库管理方法的流程图;
图2为本发明实施例二提供的一种数据库管理方法的流程图;
图3为本发明实施例三提供的一种数据库管理方法的流程图;
图4为本发明实施例四提供的一种数据库管理装置的结构示意图;
图5为本发明实施例五提供的一种服务器的硬件结构示意图。
具体实施方式
下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是,此处所描述的具体实施例仅仅用于解释本发明,而非对本发明的限定。另外还需要说明的是,为了便于描述,附图中仅示出了与本发明相关的部分而非全部结构。
实施例一
图1为本发明实施例一提供的一种数据库管理的流程图,本实施例可适用于在数据守护系统中对主库、备库和脑裂库等进行管理的情况。具体的,该数据库管理方法可以由数据库管理装置执行,该数据库管理装置可以通过软件和/或硬件的方式实现,并集成在服务器中。进一步的,服务器包括但不限定于:工业集成服务器、系统后台服务器以及云端服务器。
参考图1,该方法具体包括如下步骤:
S110、获取至少两个数据库所对应系统表中的打开记录。
具体的,每个数据库维护一张系统表,用于存储主库的打开(Open)记录。本实施例中,由主库专门维护一张系统表来记录主库的每次Open动作,主库在执行Open动作对数据进行操作并产生Redo日志之前,先向其维护的系统表中写入一条Open记录并生成Redo日志,确保该Open记录是该数据库作为主库启动后做的第一个数据修改动作,对应的Redo日志也是主库启动后生成的第一条Redo日志记录。备库通过重演Redo日志的方式来完成对应的系统表的数据同步。在主备库正常运行、数据一致的情况下,各数据库对应的系统表的内容(Open记录)也应是一致的。在对数据库进行管理的过程中,守护进程会定期获取各数据库对应系统表的Open记录,通过比较Open记录来确定或更新各数据库的属性。
需要说明的是,在一些实施方式中,通过为各数据库的守护进程部署对应的文件,用于检测和记录守护系统中可能发生的各种异常情况,部署的文件存储在磁盘上,任何人都能接触到,如果用户误删除或者误拷贝部署的文件,则会直接影响检测结果的准确性。本实施例的方法不依赖于部署文件监控数据库的属性变化,而是直接通过数据库所维护的系统表来记录主库的Open记录,当主库的系统表中的Open记录更新时,通过重演Redo日志,备库的系统表也可以自动更新,从而在未发生脑裂的情况下自动维持各数据库中系统表的Open记录的一致性,其中,系统表是由数据库维护的,因此不需要额外部署文件,也不需要额外处理各文件之间的数据同步。在一个系统表中,Open记录有若干条,主库在每次执行Open动作修改任何数据并产生Redo日志之前,先向系统表中写入一条Open记录并生成Redo日志,备库通过重演Redo日志的方式来同步系统表的数据,主备库定时将系统表中的Open记录发送给各自本地的守护进程,守护进程之间结合本地和远程数据库的Open记录来检测脑裂。这种情况下,普通用户接触不到系统表中的Open记录,可以避免Open记录被误删,保证Open记录的安全和准确性,同时摒弃了借助守护进程进行同步的方式,具有更高的可靠性和同步效率。
示例性的,主库每一次执行Open动作修改数据之前,都生成一条对应的Open记录,每一条Open记录可通过一个全局唯一标识符(Globally Unique Identifier,GUID)来标识。本实施例中设定GUID为小于或等于48字节的字符串,组成方式为“实例名称_序号”,其中,实例名称为执行Open动作的主库实例名(由用户搭建数据守护系统时配置,在守护系统配置完成后,数据库实例名不能再修改,以确保主库实例名的唯一性);序号是从1开始按顺序递增的,例如,主库EP01产生的第一条Open记录的GUID记为“EP01_1”,之后,EP02成为新主库,EP02产生的一条Open记录的GUID记为“EP02_2”。通过GUID唯一地标识主库的每一次Open动作,并存储在主库对应的系统表中,备库通过重演Redo日志同步系统表的Open记录,通过检测主库、备库之间的系统表中记录的Open记录是否一致,能够准确确定主库或备库,或及时识别脑裂库。
S120、按照预设字段比较各所述系统表中的打开记录,所述预设字段包括:第一标识符和第一序列值,所述第一标识符为目标数据库当前进入打开状态对应的标识符,所述第一序列值为目标数据库的当前日志序列值。
具体的,通过比较各数据库系统表中的Open记录,可识别出各数据库系统表的Open记录是否相同,如果不相同,则可进一步识别哪个数据库系统表的Open记录最完善、哪个数据库系统表中缺少Open记录、哪个数据库系统表的Open记录异常等,进而判断各数据库的属性。
具体的,主库每一次进入打开状态但还未进行数据操作时,主库的系统表中都按照预设字段存储一条Open记录,预设字段的格式为:GUID,LSN;其中,GUID用来唯一标识一条Open记录,每产生一条新的Open记录时就会用一个新的GUID来标识,GUID是一个最多48个字节的字符串,组成方式为“实例名称_序号”,实例名称为执行Open动作的主库实例名(由用户搭建数据守护系统时配置,在守护系统配置完成后,数据库实例名不能再修改,以确保主库实例名的唯一性),序号从1开始按顺序递增;LSN是主库执行Open动作时的当前LSN值,由于Open记录是在主库执行所有数据修改操作之前产生的,因此如果主库是从备库新切换过来的,则此时记录的LSN代表的是主库切换之前作为备库时重演到的最大LSN值,主库Open产生的第一条Redo日志一定是向系统表中插入Open记录时生成的,备库则是通过重演主库的Redo日志来同步Open记录(备库仅允许执行只读操作),因此可以通过比较主备库的Open记录来判断主备库的数据同步情况并检测是否出现脑裂。
S130、根据打开记录的比较结果确定各数据库的属性,所述属性包括主库、备库和脑裂库中的至少一种。
示例性的,如果各数据库系统表中的Open记录完全相同,则各数据库系统表的Open记录处于一致状态,将当前数据操作次数最多的数据库作为主库、其他数据库作为备库即可;如果系统表中的Open记录不一致但存在包含关系,则可将Open记录最完善的数据库作为主库,将缺少Open记录的数据库作为备库,或者将Open记录异常(与其他数据库系统表的Open记录既不相同也没有包含关系)的数据库确定为脑裂库。在实际应用中,如果没有数据库发生脑裂,则可以选择正确的数据库作为主库,如果检测到数据库发生脑裂,则不允许发生脑裂的数据库重新加入数据守护系统,避免在脑裂库上继续同步数据导致数据损坏,或者使用脑裂库进行主备切换导致整个数据守护系统的数据被破坏的情况发生。
需要说明的是,本实施例中,Open记录用于记录主库进入Open状态进行数据操作之前的LSN信息,对数据进行操作是指对数据库中的数据进行修改操作,包括数据的插入、删除、更新等,数据修改次数可通过数据库的日志序列值LSN来标识。对于一个数据库,每次对数据进行修改操作时会使用一个新的LSN来标识,每次对数据进行修改时LSN值加1,LSN取值范围是[0,+∞)。
需要说明的是,仅根据LSN值无法准确地判断数据库之间的数据一致情况。例如:在主库故障前,主库与备库之间数据不一致,但主库无法短时间恢复的情况下,强制将备库切换为主库提供数据库服务,则当故障主库恢复数据库服务后,与临时接管的主库之间的数据存在差异,此时故障主库的LSN和临时接管的主库的LSN可能相等,也可能故障主库的LSN较小,此时,仅根据LSN值无法准确地判断故障恢复的主库和临时接管的主库之间的数据是否一致。而本实施例的数据库管理方法是基于比较系统表中的Open记录判断数据库之间的数据是否一致,可以通过LSN值来辅助判断。例如,如果各系统表中的Open记录完全相同,则可将LSN值最大的数据库作为主库,该数据库的数据操作超前于其他数据库。
进一步的,所述方法还包括:当主库进入打开状态但还未对数据进行操作时,将所述主库作为目标数据库,并按照预设字段生成所述目标数据库的一条打开记录。
具体的,当主库进入打开状态但还未进行数据操作时,该主库即为目标数据库,按照预设字段生成该目标数据库对应的一条Open记录,并写入该目标数据库的系统表中,其他数据库作为备库,通过重演Redo日志可同步系统表中的Open记录。
需要说明的是,每次有主库进入打开状态但还未进行数据操作时,由该主库在其维护的系统表中写入一条新的Open记录,用于记录此次属性变化,这条Open记录会同步到其他备库的本地系统表中。因此在主备库正常运行的情况下,各系统表内容是一致的,如果不一致,则Open记录不完善的数据库(未同步跟上主库的Open记录)是备库,或者Open记录的各个字段内容完全不同,则确定出现了脑裂库,此时主备库的数据出现了不一致。
本发明实施例一提供的一种数据库管理方法,通过获取至少两个数据库所对应系统表中的打开记录;比较各所述系统表中的打开记录;根据打开记录的比较结果确定各数据库的属性,所述属性包括主库、备库和脑裂库中的至少一种,利用系统表记录主库的Open记录,备库通过重演Redo日志同步主库系统表的内容,通过比较Open记录判断各数据库的数据是否一致,基于此确定数据库的属性,实现了准确确定主库、备库以及脑裂库的目的,提高数据库运行的稳定性。
实施例二
图2为本发明实施例二提供的一种数据库管理方法的流程图,本实施例是在上述实施例的基础上进行优化,对根据Open记录的比较结果确定各数据库的属性进一步说明。需要说明的是,未在本实施例中详尽描述的技术细节可参见上述任意实施例。
具体的,参考图2,该方法具体包括如下步骤:
S201、获取至少两个数据库所对应系统表中的打开记录。
进一步的,定期获取各数据库系统表中的打开记录,以定期更新数据库属性、及时识别脑裂库。
S202、按照预设字段比较各所述系统表中的打开记录。
S203、各所述系统表所包含各条打开记录的内容是否相同,若是则执行S204;若否则执行S208。
进一步的,比较各所述系统表中的打开记录,包括:针对每个系统表,将所述系统表中的各条打开记录与其他各所述系统表中的各条打开记录的预设字段进行内容比对。
具体的,针对每个系统表,逐条比较本地数据库系统表和远程数据库系统表中的Open记录,若预设字段的内容完全相同(Open记录的条数相同且预设字段的内容也相同),则执行S204,否则执行S208。
S204、获取各所述数据库的当前日志序列值。
示例性的,表1为本地数据库的系统表中的打开记录,表2为远程数据库的系统表中的打开记录。
表1本地数据库的系统表中的打开记录
GUID | LSN |
EP01_1 | 10000 |
EP02_2 | 12000 |
EP03_3 | 20000 |
表2远程数据库的系统表中的打开记录
GUID | LSN |
EP01_1 | 10000 |
EP02_2 | 12000 |
EP03_3 | 20000 |
如表1和表2所示,本地数据库和远程数据库的各预设字段的内容完全相同,即各数据库的Open记录完全一致,可确定没有发生脑裂,这种情况下,从各数据库的内存中读取各数据库的当前日志序列值。需要说明的是,系统表Open记录中的LSN字段是在主库进入打开状态但还未对数据进行操作时,该数据库的当前LSN值,而各数据库的LSN值随着数据操作,仍在以每次加1的形式递增,直到发生下一次主库进入打开状态但还未对数据进行操作时,主库新的当前LSN值再次被写入系统表的LSN字段。
S205、是否各所述数据库的当前日志序列值均相等,若是则执行S207,若否则执行S206。
S206、将当前日志序列值较大的数据库确定为主库,其他数据库确定为备库。
具体的,将当前日志序列值较大的数据库确定为主库,即,将当前数据操作次数最多的数据库作为主库。若本地数据库的当前LSN大于远程数据库的当前LSN,则将本地数据库确定为主库,远程数据库确定为备库,继续运行数据守护系统;若本地数据库的当前LSN小于远程数据库的当前LSN,则将本地数据库确定为备库,远程数据库确定为主库,继续运行数据守护系统。
S207、根据预设规则确定各所述数据库的属性。
具体的,若各所述数据库的当前LSN均相等,则本地数据库和远程数据库的数据操作完全一致,这种情况下可以根据预设规则选择其中任意一个作为主库。示例性的,本实施例设定将数据库名称字符串比较结果中最小的数据库确定为主库。在搭建数据守护系统时,数据库名称已预先在配置文件中配置,对各数据库名称字符串比较大小,将比较结果最小的数据库确定为主库,其他数据库确定为备库,继续运行数据守护系统。例如,根据表1和表2,如果本地数据库和远程数据库的当前LSN均相等,则将数据库名称比较结果最小的“EP01”作为主库。
S208、是否存在至少两个系统表中的打开记录的内容为包含关系,若是则执行S209,若否则执行S213。
具体的,所述包含关系是指,数据库a的系统表中的Open记录多于数据库b的系统表中的Open记录,并且数据库b的系统表中的所有Open记录在数据库a的系统表中都能找到(两个预设字段的内容均相同),但数据库a的系统表在此之后还有其他的Open记录,则数据库a的系统表的Open记录包含数据库b的系统表的Open记录。
示例性的,表3为数据库a的系统表中的打开记录,表4为数据库b的系统表中的打开记录。
表3数据库a的系统表中的打开记录
GUID | LSN |
EP01_1 | 10000 |
EP02_2 | 12000 |
EP03_3 | 20000 |
表4数据库b的系统表中的打开记录
GUID | LSN |
EP01_1 | 10000 |
EP02_2 | 12000 |
如表3和表4所示,数据库a的系统表的打开记录包含数据库b的系统表的打开记录。
S209、提取第二序列值,所述第二序列值为满足包含关系的系统表中首条内容不同的打开记录中的日志序列值。
具体的,若存在至少两个系统表的Open记录的内容为包含关系,则提取第二序列值,进一步判断其他数据库的属性为备库还是脑裂库,其中,第二序列值为满足包含关系的系统表中首条内容不同的Open记录中的LSN。例如,在表3和表4所示的包含关系中,第二序列值为20000。
可选的,如果一个系统表的Open记录最多且包含其他所有系统表的Open记录,则将该Open记录最多的数据库确定为主库,该数据库的Open记录较为完善,其数据操作超前于其他被包含的数据库,其他被包含的数据库可通过重演该数据库的重做日志保持数据一致。
S210、被包含系统表所对应被包含数据库的当前日志序列值是否小于或等于所述第二序列值,若是则执行S211,若否则执行S212。
具体的,被包含系统表所对应被包含数据库的当前LSN为所述被包含数据库当前已经产生的最大日志序列值,从数据库内存中读取。将被包含数据库的当前LSN与第二序列值进行比较。
S211、将所述被包含数据库确定为备库。
具体的,若被包含数据库的当前LSN小于或等于第二序列值,说明被包含数据库的数据操作落后于主库的这次Open动作,则将被包含数据库确定为备库,继续运行数据守护系统,备库通过继续重演和跟进主库的Redo日志以同步主库的数据。
S212、将所述被包含数据库确定为脑裂库。
具体的,若被包含数据库的当前LSN大于第二序列值,说明被包含数据库的数据操作超前于主库的这次Open动作,数据异常,这种情况下发生脑裂,确定被包含数据库为脑裂库,脑裂库的守护进程自动为其设置脑裂标记并将其强制关闭,不再提供数据库服务。
示例性的,仅根据LSN值无法准确地判断数据库之间的数据一致情况。以表3和表4为例,假设还有一个远程数据库EP03,EP02当前的LSN值大于第二序列值20000的场景举例如下:1)在初始阶段,EP02是主库,EP01和EP03是备库,主备库正常运行,数据处于一致状态,三个数据库的系统表的Open记录中都只有两条记录“EP01_1”和“EP02_2”;2)在第二阶段,EP02没有再做过Open动作,Open记录没有变化,仍然还是只有两条记录,但EP02上做了大量的增删改操作,并将Redo日志同步到了EP01和EP03上,假设此时三个数据库的LSN都涨到了20000,然后EP03故障;3)在第三阶段,EP02和EP01仍然正常运行,假设LSN都涨到了20010,然后EP02和EP01全部故障;4)EP03此时恢复正常,用户为了尽快恢复数据库服务,并且可以接受一小部分的数据丢失,因此选择将EP03强制接管为主库,EP03启动到Open状态时,向系统表中写入“EP03_3”这条Open记录,对应的LSN是20000,然后EP03作为有效主库正常对外提供服务,EP03运行一段时间后,假设LSN已经涨到了50000;5)在第五阶段,EP02恢复正常,此时EP02的当前LSN是20010,比“EP03_3”这条Open记录中的LSN值大,也就是在第三阶段中,EP02和EP03的数据已经发生不一致,因此可以将EP02认定为脑裂库,同样的,如果EP01也恢复正常,也会被认定为脑裂库。
S213、检测用户输入的干预指令。
具体的,如果各系统表中的各条Open记录既不相同,也不存在包含关系,则说明数据守护系统中出现了多个主库(Open记录仅主库会主动生成),并且这些主库之间的数据已经不一致,此时,无法依据Open记录和LSN确定有效主库,通过各数据库的守护进程可将数据库强制关闭,以避免数据进一步损坏。这种情况下,检测用户输入的干预指令。干预指令是指在各系统表的Open记录既不相同、也不存在包含关系的情况下,用户输入的属性指定指令,用于指定一个数据库作为主库或者备库。
进一步的,若各系统表中的各条Open记录的内容不相同,且至少两个系统表的Open记录的内容为非包含关系,则检测用户输入的干预指令。
S214、根据所述干预指令确定各数据库的属性。
具体的,根据干预指令将用户指定的数据库确定为主库,同时,将Open记录既不相同也不被主库包含的其他数据库标记为脑裂状态,这类数据库无法作为备库在数据守护系统中运行。需要说明的是,若用户选择的数据库原本为备库,则需先将该数据库的属性切换为主库,再启动该数据库到Open状态以提供数据库服务;若用户选择的数据库原本为主库,则直接将其启动到Open状态提供数据库服务。在用户干预并确定出有效的主库之后,其他数据库的守护进程会根据上述实施例中的方法判断其是否可以作为备库,如果是,则守护进程会自动通知其切换为备库模式并启动到Open状态,如果已经是备库模式则直接将其启动到Open状态。
可选的,在用户干预并确定出有效的主库后,若其他数据库无法作为备库重新加入用户确定出的主库,则通过用户干预重新搭建新的有效备库来使用。
进一步的,当数据守护系统中配置的数据库为两个时,直接比较两个数据库的系统表中的Open记录是否相同、是否为包含关系即可;如果配置的数据库多于两个,则依次将每一个数据库作为本地数据库,其他数据库作为远程数据库,针对一个本地数据库,将其与每个远程数据库的系统表中的Open记录依次进行比较,远程数据库之间不需要再比较,如果各比较结果都是将本地数据库确定为主库,则可最终确定本地数据库为主库;如果各比较结果中的任意一个是将本地数据库确定为备库,则可最终确定本地数据库为备库;如果在与任意一个远程数据库比较后确定本地数据库为脑裂库,则可确定出现脑裂,本地数据库为脑裂库,直到确定所有数据库的属性,继续运行数据守护系统。
需要说明的是,本实施例的数据库管理方法也适用于本地数据库和远程数据库都是备库的情况,针对此情况,也可以按照上述规则检测是否发生脑裂并确定脑裂库,如果没有发生脑裂,则可以选出正确的数据库作为有效主库,守护进程会先将该数据库的属性切换为主库,再启动该数据库到Open状态以提供数据库服务。
本实施例的数据库管理方法,在上述实施例的基础上进行优化,通过比较Open记录和数据库的当前LSN值可选择正确的数据库作为主库或备库;如果检测到发生脑裂,则强制关闭脑裂的数据库,将其确定为脑裂库并禁止其重新加入数据守护系统,从而避免在脑裂库上继续同步数据导致数据损坏,也可以避免使用脑裂库进行主备切换导致整个数据守护系统的数据被破坏。
实施例三
图3为本发明实施例三提供的一种数据库管理方法的流程图。本实施例是在上述实施例的基础上进行优化,通过在打开记录中记录更详细的预设字段进一步提高数据库检测和管理的准确性,并对守护进程将要执行的数据库操作做出进一步说明。需要说明的是,未在本实施例中详尽描述的技术细节可参见上述任意实施例。如图3所示,所述方法包括:
S310、获取至少两个数据库所对应系统表中的打开记录。
S320、按照预设字段比较各所述系统表中的打开记录。
具体的,当主库进入打开状态但还未对数据进行操作时,将所述主库作为目标数据库,并按照预设字段生成目标数据库的一条打开记录。参见上述实施例,预设字段包括第一标识符(GUID)和第一序列值(LSN),在本实施例中,预设字段还可以包括其他的信息。
进一步的,所述预设字段还包括以下至少之一:打开记录对应的系统表行号、时间信息、数据库模式、历史主库名称、目标数据库名称、历史主库魔数、目标数据库魔数以及历史主库节点个数。
需要说明的是,在预设字段包括历史主库节点个数的情况下,第一序列值为目标数据库对应历史主库的每个节点重演到的当前日志序列值构成的数组,其中,数组长度与节点个数相对应,数组下标和节点序号相对应。例如,第一序列值为[10000,8000],表示目标数据库切换为主库之前,对历史主库0号节点重演到的LSN为10000,对历史主库1号节点重演到的LSN为8000。这种情况下,在比较各Open记录是否相同时,除了比较GUID外,还需要依次比较第一序列值中的每个LSN值,所有LSN值都相同才认为第一序列值相同。各数据库系统表的比较结果同样也分为相同、存在包含关系或者既不相同也不存在包含关系这三种。
表5为预设字段的字段名和字段含义的对照表。如表5所示,通过按照预设字段生成目标数据库的每一条打开记录,详细地记录目标数据库的工作状态相关参数,根据这些预设字段的内容可全面、准确地判断各数据库的打开记录是否完全同步,从而准确确定数据库属性。
表5预设字段的字段名和字段含义的对照表
S330、根据打开记录对应的数据库模式、数据库状态以及数据库故障状态的组合类型执行对应的数据库操作以确定各数据库的属性。
具体的,守护进程结合本地数据库和远程数据库的Open记录,定期检测数据守护系统中是否发生脑裂。通过逐条比较本地数据库和远程数据库中的Open记录中的预设字段,如果所有预设字段完全相等则判定两条Open记录相同。如果本地数据库和远程数据库中的各条Open记录都相同,则根据预设规则选择主库;如果远程数据库的Open记录少于本地数据库的Open记录,且远程数据库的Open记录在本地数据库的Open记录中都能找到且比较结果相同,则判定本地数据库包含远程数据库,同理也可判定远程数据库是否包含本地数据库,在存在包含关系的情况下,根据上述实施例的方法可以确定数据库的属性;如果既不满足相同也不满足包含关系,则可根据干预指令确定数据库的属性。
以包含关系为例,表6为本地数据库e的系统表中的打开记录,表7为远程数据库f的系统表中的打开记录,本地数据库e包含远程数据库f。
需要说明的是,表6本地数据库e的Open记录1中的PRI_INST_NAME和CUR_INST_NAME相同、PRI_DB_MAGIC和CUR_DB_MAGIC相同,说明是同一个主库再次执行了Open操作,没有发生过主备库切换,这种情况下N_EP、ALSN_ARR字段存放的是主库自身的节点个数(N_EP)、每个节点的当前LSN数组(ALSN_ARR)信息,而不是切换前作为备库时的重演信息。
需要说明的是,在N_EP大于1的情况下,第一序列值为数组(ALSN_ARR)。
表6本地数据库e的系统表中的打开记录
表7远程数据库f的系统表中的打开记录
字段名 | Open记录1 | Open记录2 |
GUID | EP01_1 | EP02_2 |
ROWID | 1 | 2 |
OPEN_TIME | 2019-6-26 17:45:29 | 2019-6-26 17:51:58 |
SYS_MODE | PRIMARY | PRIMARY |
PRI_INST_NAME | EP01 | EP01 |
CUR_INST_NAME | EP01 | EP02 |
PRI_DB_MAGIC | 214244530 | 214244530 |
CUR_DB_MAGIC | 214244530 | 1753828684 |
N_EP | 1 | 1 |
LSN | 150500 | 157610 |
进一步的,所述数据库操作包括以下至少一种:脑裂标记操作、配置状态切换操作、打开状态切换操作、备库模式切换操作、主库模式切换操作以及主库选择操作。
具体的,在Open记录比较结果的基础上,通过守护进程结合本地数据库和远程数据的数据库模式、数据库状态以及数据库故障状态的组合类型可执行对应的数据库操作,从而确定是否出现脑裂库、是否可以将某个数据库重加入数据守护系统、或者是否将某个备库切换为主库等。
表8为数据库模式、数据库状态以及数据库故障状态的组合类型对照表。如表8所示,数据库模式包括主库(Primary)模式、备库(Standby)模式以及未知(Unknown)模式;数据库状态包括打开(Open)状态、挂起(Suspend)状态、配置(Mount)状态以及未知(Unknown)状态;数据库故障状态包括正常(Ok)状态和故障(Error)状态。其中,未知模式或未知状态表示数据库的模式或状态不确定,例如在启动守护进程、未启动数据库的情况下,守护进程没有收到过数据库的消息,因此无法确定模式或状态,也无法执行数据库操作。
表8数据库模式、数据库状态以及数据库故障状态的组合类型对照表
组合类型 | 数据库模式 | 数据库状态 | 数据库是否故障 |
P/O[O] | Primary | Open | Ok |
P/O[E] | Primary | Open | Error |
P/S[O] | Primary | Suspend | Ok |
P/S[E] | Primary | Suspend | Error |
P/M[O] | Primary | Mount | Ok |
P/M[E] | Primary | Mount | Error |
S/O[O] | Standby | Open | Ok |
S/O[E] | Standby | Open | Error |
S/M | Standby | Mount | Ok/Error |
D/E | Unknown | Unknown | Error |
本实施例中,通过守护进程根据数据库模式、数据库状态以及数据库故障状态的组合类型执行对应的数据库操作。数据库操作包括以下至少一种:脑裂标记操作(SPLIT),即通知本地数据库强制关闭并设置SPLIT标记,判定本地数据库为脑裂库;配置状态切换操作(MOUNT),即通知本地数据库切换为Mount状态;打开状态切换操作(OPEN),即通知本地数据库切换为Open状态;备库模式切换操作(TO_S),即通知本地数据库切换为Standby模式;主库模式切换操作(TO_P),即通知本地数据库切换为Primary模式;主库选择操作(CMP),即按照预设规则进一步比较数据库的设定信息选择主库(这种情况下可能出现脑裂)。其中,MOUNT、TO_P和OPEN可用于将Open记录全面的备库确定为主库,例如,对于Open记录最全面的一个备库,判定其可以作为主库,则通过MOUNT通知该数据库切换为Mount状态,然后通过TO_P通知该数据库切换为Primary模式,最后通过OPEN通知该数据库切换为Open状态,从而切换为主库,即,将该数据库的属性确定为主库。
S340、根据打开记录对应的数据库模式、数据库状态以及数据库故障状态的组合类型执行对应的管理操作。
本实施例通过根据打开记录对应的数据库模式、数据库状态以及数据库故障状态的组合类型执行对应的管理操作,从而在确定数据库属性的基础上对数据库进行管理。所述管理操作包括强制关闭操作(SHTD)和保持操作(KEEP),其中,强制关闭操作为通知本地数据库强制关闭;保持操作即通知本地数据库保持当前状态不变,等待远程数据库的状态变化后再执行后续操作。
以远程数据库包含在本地数据库的情况为例,表9为本地数据库和远程数据库之间组合类型与操作的对照表。
表9本地数据库和远程数据库之间组合类型与操作的对照表
表10本地数据库的组合类型与操作的对照表
本地数据库的组合类型 | 数据库操作 |
P/O[O] | SHTD |
P/O[E] | KEEP |
P/S[O] | SHTD |
P/S[E] | KEEP |
P/M[O] | TO_S |
P/M[E] | KEEP |
S/O[O] | KEEP |
S/O[E] | KEEP |
S/M | OPEN |
D/E | KEEP |
以本地数据库包含在远程数据库的情况为例,表10为本地数据库的组合类型与操作的对照表。这种情况下,本地数据库的当前LSN小于或等于第二序列值,也就是本地数据库确定可以作为备库重加入数据守护系统,这种情况下仅根据本地数据库自身的组合类型即可确定数据库操作或管理操作。
以本地数据库与远程数据库的Open记录相同的情况为例,表11为本地数据库和远程数据库之间组合类型与操作的另一对照表。其中,“X”表示不可能同时存在的组合类型。
表11本地数据库和远程数据库之间组合类型与操作的另一对照表
表12本地数据库和远程数据库的组合类型与操作的另一对照表
以本地数据库与远程数据库的打开记录既不相同也不存在包含关系的情况为例,表12为本地数据库和远程数据库之间组合类型与操作的另一对照表。
进一步的,在本地数据库与远程数据库的Open记录相同的情况下,CMP中进一步比较的设定信息(APPLY信息)包括N_EP、ALSN_ARR,预设规则具体如下:
1)比较本地数据库与所有远程数据库的APPLY信息,远程数据库之间不比较APPLY信息。
2)选择APPLY信息最大的作为主库,其中,APPLY信息最大是指ASEQ_ARR的比较结果最大,此预设规则的前提是本地数据库和远程数据库的Open记录相同,那么所有数据库上记录的最后一次主库Open记录也是相同的,因此N_EP个数(历史主库节点个数)也一定是相同的。
3)APPLY信息相同时,优先选择活动的P/M[O]、S/O或S/M对应的数据库作为主库(P/M[O]的优先级高于S/O的优先级,S/O的优先级高于S/M的优先级),如果存在多个同优先级的库,则选择实例名小的作为主库。
4)如果所有数据库都不符合条件,说明出现脑裂,则保持现状,等待用户的干预指令。
5)如果本地数据库是主库,则根据“远程数据库包含在本地数据库”的情况选择后续操作步骤,如表9所示。
6)如果本地数据库不是主库,则使用“本地数据库包含在远程数据库”规则选择后续操作步骤,如表10所示。
需要说明的是,本实施例不限定S330和S340的执行顺序。
本实施例的数据库管理方法,在上述实施例的基础上进行优化,通过在打开记录中记录更详细的预设字段进一步提高数据库检测和管理的准确性,并通过守护进程根据数据库模式、数据库状态以及数据库故障状态的组合类型执行对应的数据库操作,这种方式可以更加直观全面的覆盖数据守护系统中可能出现的各种场景,并对不同的场景制定了明确的处理规则,进一步保证了数据守护系统的高可用性,同时能够有效地避免在脑裂库上继续同步数据导致数据损坏,也可以避免使用脑裂库进行主备切换导致整个数据守护系统的数据被破坏,实现了准确确定主库、备库以及脑裂库,提高数据库运行的稳定性。
实施例四
图4为本发明实施例三提供的一种数据库管理装置的结构示意图。本实施例提供的数据库管理装置包括:
获取模块410,用于获取至少两个数据库所对应系统表中的打开记录;
比较模块420,用于按照预设字段比较各所述系统表中的打开记录,所述预设字段包括:第一标识符和第一序列值,所述第一标识符为目标数据库当前进入打开状态对应的标识符,所述第一序列值为目标数据库的当前日志序列值;
管理模块430,用于根据打开记录的比较结果确定各数据库的属性,所述属性包括主库、备库和脑裂库中的至少一种。
本发明实施例四提供的一种数据库管理装置,通过获取模块获取至少两个数据库所对应系统表中的打开记录,通过比较模块按照预设字段比较各所述系统表中的打开记录,以比较各数据库的数据是否一致,基于此通过管理模块根据打开记录的比较结果确定各数据库的属性,所述属性包括主库、备库和脑裂库中的至少一种,实现了准确确定主库、备库以及脑裂库的目的,提高数据库运行的稳定性。
在上述实施例的基础上,所述装置还包括:
生成模块,用于当主库进入打开状态但还未对数据进行操作时,将所述主库作为目标数据库,并按照预设字段生成所述目标数据库的一条打开记录;
写入模块,用于将目标数据库的打开记录写入所述目标数据库对应的系统表中。
在上述实施例的基础上,所述比较模块420,具体用于:
针对每个系统表,将所述系统表中的各条打开记录与其他各所述系统表中的各条打开记录的预设字段进行内容比对。
进一步的,所述管理模块430,具体用于:
若各所述系统表所包含各条打开记录的内容相同,则获取各所述数据库的当前日志序列值,并将当前日志序列值较大的数据库确定为主库,其他数据库确定为备库;
若各所述数据库的当前日志序列值均相等,则根据预设规则确定各所述数据库的属性。
进一步的,所述管理模块430,具体用于:
若存在至少两个系统表中的打开记录的内容为包含关系,则提取第二序列值,所述第二序列值为满足包含关系的系统表中首条内容不同的打开记录对应的日志序列值;
若被包含系统表所对应被包含数据库的当前日志序列值小于或等于所述第二序列值,则将所述被包含数据库确定为备库,否则,将所述被包含数据库确定为脑裂库,所述当前日志序列值为所述被包含数据库当前已经产生的最大日志序列值。
进一步的,所述管理模块430,具体用于:
若各所述系统表中的各条打开记录的内容不相同,且至少两个系统表所包含打开记录的内容为非包含关系,则检测用户输入的干预指令;
根据所述干预指令确定各数据库的属性。
进一步的,管理模块430,具体用于:
根据打开记录对应的数据库模式、数据库状态以及数据库故障状态的组合类型执行对应的数据库操作以确定各数据库的属性;
所述数据库操作包括以下至少一种:脑裂标记操作、配置状态切换操作、打开状态切换操作、备库模式切换操作、主库模式切换操作以及主库选择操作。
进一步的,所述预设字段还包括以下至少之一:打开记录对应的系统表行号、时间信息、数据库模式、历史主库名称、目标数据库名称、历史主库的魔数、目标数据库的魔数以及历史主库节点个数;
在所述预设字段包括历史主库节点个数的情况下,所述第一序列值为目标数据库对应历史主库的每个节点重演到的当前日志序列值构成的数组;
可选的,管理模块430,还用于:
根据打开记录对应的数据库模式、数据库状态以及数据库故障状态的组合类型执行对应的管理操作,所述管理操作包括强制关闭操作和保持操作。
进一步的,所述装置还包括:
同步模块,用于通过重演Redo日志同步主库的系统表内容。
具体的,备库基于同步模块通过重演Redo日志的方式同步主库的系统表中的各条Open记录,在正常运行的情况下,各数据库的系统表内容应该完全一致,如果系统表内容不一致,则说明数据守护系统异常,需要使用上述实施例的数据库管理方法进行处理,处理结束后,对于没有发生脑裂的各数据库,通过重演Redo日志会将其系统表再次同步到一致状态。
本发明实施例四提供的数据库管理装置可以用于执行上述任意实施例提供的数据库管理方法,具备相应的功能和有益效果。
实施例五
图5为本发明实施例五提供的一种服务器的硬件结构示意图。如图5所示,本实施例提供的一种服务器,包括:处理器510和存储装置520。该服务器中的处理器可以是一个或多个,图5中以一个处理器510为例,所述服务器中的处理器510和存储装置520可以通过总线或其他方式连接,图5中以通过总线连接为例。
所述一个或多个程序被所述一个或多个处理器510执行,使得所述一个或多个处理器实现上述实施例中任意所述的数据库管理方法。
该服务器中的存储装置520作为一种计算机可读存储介质,可用于存储一个或多个程序,所述程序可以是软件程序、计算机可执行程序以及模块,如本发明实施例中数据库管理方法对应的程序指令/模块(例如,附图4所示的数据库管理装置中的模块,包括:获取模块410、比较模块420以及管理模块430)。处理器510通过运行存储在存储装置520中的软件程序、指令以及模块,从而执行服务器的各种功能应用以及数据处理,即实现上述方法实施例中的数据库管理方法。
存储装置520主要包括存储程序区和存储数据区,其中,存储程序区可存储操作系统、至少一个功能所需的应用程序;存储数据区可存储根据服务器的使用所创建的数据等(如上述实施例中的打开记录、预设字段等)。此外,存储装置520可以包括高速随机存取存储器,还可以包括非易失性存储器,例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中,存储装置520可进一步包括相对于处理器510远程设置的存储器,这些远程存储器可以通过网络连接至服务器。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
并且,当上述服务器中所包括一个或者多个程序被所述一个或者多个处理器510执行时,进行如下操作:获取至少两个数据库所对应系统表中的打开记录;按照预设字段比较各所述系统表中的打开记录;根据打开记录的比较结果确定各数据库的属性,所述属性包括主库、备库和脑裂库中的至少一种。
本实施例提出的设备与上述实施例提出的数据库管理方法属于同一发明构思,未在本实施例中详尽描述的技术细节可参见上述任意实施例,并且本实施例具备与执行数据库管理方法相同的有益效果。
在上述实施例的基础上,本实施例还提供一种计算机可读存储介质,其上存储有计算机程序,该程序被数据库管理装置执行时实现本发明上述任意实施例中的数据库管理方法,该方法包括:获取至少两个数据库所对应系统表中的打开记录;按照预设字段比较各所述系统表中的打开记录;根据打开记录的比较结果确定各数据库的属性,所述属性包括主库、备库和脑裂库中的至少一种。
当然,本发明实施例所提供的一种包含计算机可执行指令的存储介质,其计算机可执行指令不限于如上所述的数据库管理方法操作,还可以执行本发明任意实施例所提供的数据库管理方法中的相关操作,且具备相应的功能和有益效果。
通过以上关于实施方式的描述,所属领域的技术人员可以清楚地了解到,本发明可借助软件及必需的通用硬件来实现,当然也可以通过硬件实现,但很多情况下前者是更佳的实施方式。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在计算机可读存储介质中,如计算机的软盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(RandomAccess Memory,RAM)、闪存(FLASH)、硬盘或光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例所述的数据库管理方法。
注意,上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解,本发明不限于这里所述的特定实施例,对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此,虽然通过以上实施例对本发明进行了较为详细的说明,但是本发明不仅仅限于以上实施例,在不脱离本发明构思的情况下,还可以包括更多其他等效实施例,而本发明的范围由所附的权利要求范围决定。
Claims (10)
1.一种数据库管理方法,其特征在于,包括:
获取至少两个数据库所对应系统表中的打开记录;
按照预设字段比较各所述系统表中的打开记录,所述预设字段包括:第一标识符和第一序列值,所述第一标识符为目标数据库当前进入打开状态对应的标识符,所述第一序列值为目标数据库的当前日志序列值;
根据打开记录的比较结果确定各数据库的属性,所述属性包括主库、备库和脑裂库中的至少一种。
2.根据权利要求1所述的方法,其特征在于,还包括:
当主库进入打开状态但还未对数据进行操作时,将所述主库作为目标数据库,并按照预设字段生成所述目标数据库的一条打开记录;
将目标数据库的打开记录写入所述目标数据库对应的系统表中。
3.根据权利要求1所述的方法,其特征在于,所述根据打开记录的比较结果确定各数据库的属性,包括:
若各所述系统表所包含各条打开记录的内容相同,则获取各所述数据库的当前日志序列值,并将当前日志序列值较大的数据库确定为主库,其他数据库确定为备库;
若各所述数据库的当前日志序列值均相等,则根据预设规则确定各所述数据库的属性。
4.根据权利要求1所述的方法,其特征在于,所述根据打开记录的比较结果确定各数据库的属性,包括:
若存在至少两个系统表中的打开记录的内容为包含关系,则提取第二序列值,所述第二序列值为满足包含关系的系统表中首条内容不同的打开记录中的日志序列值;
若被包含系统表所对应被包含数据库的当前日志序列值小于或等于所述第二序列值,则将所述被包含数据库确定为备库,否则,将所述被包含数据库确定为脑裂库,所述当前日志序列值为所述被包含数据库当前已经产生的最大日志序列值。
5.根据权利要求1所述的方法,其特征在于,所述根据打开记录的比较结果确定各数据库的属性,包括:
若各所述系统表中的各条打开记录的内容不相同,且至少两个系统表的打开记录的内容为非包含关系,则检测用户输入的干预指令;
根据所述干预指令确定各数据库的属性。
6.根据权利要求1所述的方法,其特征在于,所述根据打开记录的比较结果确定各数据库的属性,包括:
根据打开记录对应的数据库模式、数据库状态以及数据库故障状态的组合类型执行对应的数据库操作以确定各数据库的属性;
所述数据库操作包括以下至少一种:脑裂标记操作、配置状态切换操作、打开状态切换操作、备库模式切换操作、主库模式切换操作以及主库选择操作。
7.根据权利要求1-6任一项所述的方法,其特征在于,所述预设字段还包括以下至少之一:打开记录对应的系统表行号、时间信息、数据库模式、历史主库名称、目标数据库名称、历史主库魔数、目标数据库魔数以及历史主库节点个数;
在所述预设字段包括历史主库节点个数的情况下,所述第一序列值为目标数据库对应历史主库的每个节点重演到的当前日志序列值构成的数组。
8.一种数据库管理装置,其特征在于,包括:
获取模块,用于获取至少两个数据库所对应系统表中的打开记录;
比较模块,用于按照预设字段比较各所述系统表中的打开记录,所述预设字段包括:第一标识符和第一序列值,所述第一标识符为目标数据库当前进入打开状态对应的标识符,所述第一序列值为目标数据库的当前日志序列值;
管理模块,用于根据打开记录的比较结果确定各数据库的属性,所述属性包括主库、备库和脑裂库中的至少一种。
9.一种服务器,其特征在于,包括:
一个或多个处理器;
存储装置,用于存储一个或多个程序;
当所述一个或多个程序被所述一个或多个处理器执行,使得所述一个或多个处理器实现如权利要求1-7中任一所述的数据库管理方法。
10.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,该程序被处理器执行时实现如权利要求1-7中任一所述的数据库管理方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910792037.5A CN110471909B (zh) | 2019-08-26 | 2019-08-26 | 一种数据库管理方法、装置、服务器及存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910792037.5A CN110471909B (zh) | 2019-08-26 | 2019-08-26 | 一种数据库管理方法、装置、服务器及存储介质 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN110471909A true CN110471909A (zh) | 2019-11-19 |
CN110471909B CN110471909B (zh) | 2022-03-08 |
Family
ID=68512908
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201910792037.5A Active CN110471909B (zh) | 2019-08-26 | 2019-08-26 | 一种数据库管理方法、装置、服务器及存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN110471909B (zh) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111639087A (zh) * | 2020-05-28 | 2020-09-08 | 北京金山云网络技术有限公司 | 数据库中数据更新方法、装置和电子设备 |
CN112835874A (zh) * | 2021-03-25 | 2021-05-25 | 中国工商银行股份有限公司 | 主备数据库搭建方法、装置及系统 |
CN113032408A (zh) * | 2019-12-24 | 2021-06-25 | 阿里巴巴集团控股有限公司 | 数据处理方法、系统及设备 |
CN113297230A (zh) * | 2020-07-27 | 2021-08-24 | 阿里巴巴集团控股有限公司 | 数据验证方法及装置 |
CN113495811A (zh) * | 2021-06-22 | 2021-10-12 | 交控科技股份有限公司 | 数据库的主备倒切自动恢复方法、装置、设备及存储介质 |
CN114528350A (zh) * | 2022-02-18 | 2022-05-24 | 苏州浪潮智能科技有限公司 | 集群脑裂的处理方法、装置、设备及可读存储介质 |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130262403A1 (en) * | 2012-03-31 | 2013-10-03 | Bmc Software, Inc. | Unique attribute constraints for versioned database objects |
CN105975579A (zh) * | 2016-05-05 | 2016-09-28 | 北京思特奇信息技术股份有限公司 | 一种内存数据库的主备复制方法及内存数据库系统 |
CN106802892A (zh) * | 2015-11-26 | 2017-06-06 | 阿里巴巴集团控股有限公司 | 用于主备数据一致性校验的方法和设备 |
CN108319617A (zh) * | 2017-01-17 | 2018-07-24 | 阿里巴巴集团控股有限公司 | 确定数据库主从差异的方法、装置及切换控制方法、装置 |
CN108932295A (zh) * | 2018-05-31 | 2018-12-04 | 康键信息技术(深圳)有限公司 | 主数据库切换控制方法、装置、计算机设备和存储介质 |
CN109947772A (zh) * | 2018-09-07 | 2019-06-28 | 网联清算有限公司 | 数据库自动切换方法、装置、存储介质及计算机设备 |
CN110109934A (zh) * | 2019-05-08 | 2019-08-09 | 上海达梦数据库有限公司 | 一种数据库管理方法、装置、服务器及存储介质 |
-
2019
- 2019-08-26 CN CN201910792037.5A patent/CN110471909B/zh active Active
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130262403A1 (en) * | 2012-03-31 | 2013-10-03 | Bmc Software, Inc. | Unique attribute constraints for versioned database objects |
CN106802892A (zh) * | 2015-11-26 | 2017-06-06 | 阿里巴巴集团控股有限公司 | 用于主备数据一致性校验的方法和设备 |
CN105975579A (zh) * | 2016-05-05 | 2016-09-28 | 北京思特奇信息技术股份有限公司 | 一种内存数据库的主备复制方法及内存数据库系统 |
CN108319617A (zh) * | 2017-01-17 | 2018-07-24 | 阿里巴巴集团控股有限公司 | 确定数据库主从差异的方法、装置及切换控制方法、装置 |
CN108932295A (zh) * | 2018-05-31 | 2018-12-04 | 康键信息技术(深圳)有限公司 | 主数据库切换控制方法、装置、计算机设备和存储介质 |
CN109947772A (zh) * | 2018-09-07 | 2019-06-28 | 网联清算有限公司 | 数据库自动切换方法、装置、存储介质及计算机设备 |
CN110109934A (zh) * | 2019-05-08 | 2019-08-09 | 上海达梦数据库有限公司 | 一种数据库管理方法、装置、服务器及存储介质 |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113032408A (zh) * | 2019-12-24 | 2021-06-25 | 阿里巴巴集团控股有限公司 | 数据处理方法、系统及设备 |
CN113032408B (zh) * | 2019-12-24 | 2024-05-07 | 阿里巴巴集团控股有限公司 | 数据处理方法、系统及设备 |
CN111639087A (zh) * | 2020-05-28 | 2020-09-08 | 北京金山云网络技术有限公司 | 数据库中数据更新方法、装置和电子设备 |
CN111639087B (zh) * | 2020-05-28 | 2023-09-08 | 北京金山云网络技术有限公司 | 数据库中数据更新方法、装置和电子设备 |
CN113297230A (zh) * | 2020-07-27 | 2021-08-24 | 阿里巴巴集团控股有限公司 | 数据验证方法及装置 |
CN113297230B (zh) * | 2020-07-27 | 2024-03-08 | 阿里巴巴集团控股有限公司 | 数据验证方法及装置 |
CN112835874A (zh) * | 2021-03-25 | 2021-05-25 | 中国工商银行股份有限公司 | 主备数据库搭建方法、装置及系统 |
CN113495811A (zh) * | 2021-06-22 | 2021-10-12 | 交控科技股份有限公司 | 数据库的主备倒切自动恢复方法、装置、设备及存储介质 |
CN114528350A (zh) * | 2022-02-18 | 2022-05-24 | 苏州浪潮智能科技有限公司 | 集群脑裂的处理方法、装置、设备及可读存储介质 |
CN114528350B (zh) * | 2022-02-18 | 2024-01-16 | 苏州浪潮智能科技有限公司 | 集群脑裂的处理方法、装置、设备及可读存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN110471909B (zh) | 2022-03-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN110471909A (zh) | 一种数据库管理方法、装置、服务器及存储介质 | |
US20190102257A1 (en) | Partial database restoration | |
CN102968486B (zh) | 一种基于变化日志的高可靠文件同步方法 | |
CN103761165B (zh) | 日志备份方法及装置 | |
CN105376277B (zh) | 一种数据同步方法及装置 | |
CN107229540A (zh) | 一种基于时间点的数据库恢复方法及系统 | |
CN112214411B (zh) | 一种容灾系统测试方法、装置、设备及存储介质 | |
CN106484565A (zh) | 多数据中心间的数据同步方法及相关设备 | |
KR20070061088A (ko) | 파일 시스템에서 파일 관리 방법 및 이를 위한 메타데이터서버 | |
WO2019057081A1 (zh) | 数据存储方法、数据查询方法、计算机设备及存储介质 | |
CN106453297A (zh) | 检测主从延时方法、装置和系统 | |
CN106502830B (zh) | 一种基于Btrfs文件系统的系统备份还原方法 | |
CN108762982B (zh) | 一种数据库恢复方法、装置及系统 | |
CN112052121A (zh) | 一种硬盘数据的恢复方法及系统 | |
CN110109934A (zh) | 一种数据库管理方法、装置、服务器及存储介质 | |
CN108920301A (zh) | 数据备份方法以及系统、数据恢复方法以及系统 | |
JP2006185108A (ja) | ストレージシステムのデータを管理する管理計算機及びデータ管理方法 | |
CN111404737B (zh) | 一种容灾处理方法以及相关装置 | |
CN114756410B (zh) | 一种双机热备系统的数据恢复方法、装置及介质 | |
CN110928945B (zh) | 一种针对数据库的数据处理方法及装置,数据处理系统 | |
CN106599006B (zh) | 一种数据恢复方法和装置 | |
WO2017080362A1 (zh) | 数据管理方法及装置 | |
CN110716828A (zh) | 一种数据库实时备份方法 | |
CN111858076B (zh) | 一种目标守护进程同步方法和装置 | |
CN112838965B (zh) | 一种强同步角色故障的识别与恢复方法 |
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 | ||
GR01 | Patent grant | ||
GR01 | Patent grant |