CN116361073A - 数据安全管理方法、装置、设备及存储介质 - Google Patents
数据安全管理方法、装置、设备及存储介质 Download PDFInfo
- Publication number
- CN116361073A CN116361073A CN202310372964.8A CN202310372964A CN116361073A CN 116361073 A CN116361073 A CN 116361073A CN 202310372964 A CN202310372964 A CN 202310372964A CN 116361073 A CN116361073 A CN 116361073A
- Authority
- CN
- China
- Prior art keywords
- node
- database
- standby
- main
- main node
- 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
- 238000007726 management method Methods 0.000 title abstract description 98
- 238000011084 recovery Methods 0.000 claims abstract description 47
- 238000000034 method Methods 0.000 claims abstract description 37
- 239000002071 nanotube Substances 0.000 claims abstract description 36
- 230000008439 repair process Effects 0.000 claims description 38
- 238000012546 transfer Methods 0.000 claims description 38
- 238000012790 confirmation Methods 0.000 claims description 14
- 238000004590 computer program Methods 0.000 claims description 11
- 230000001360 synchronised effect Effects 0.000 description 22
- 230000006870 function Effects 0.000 description 17
- 238000012544 monitoring process Methods 0.000 description 13
- 239000000306 component Substances 0.000 description 9
- 238000010586 diagram Methods 0.000 description 9
- 238000013508 migration Methods 0.000 description 8
- 230000005012 migration Effects 0.000 description 8
- 230000008569 process Effects 0.000 description 8
- 238000004458 analytical method Methods 0.000 description 7
- 238000001514 detection method Methods 0.000 description 5
- 230000005291 magnetic effect Effects 0.000 description 4
- 230000007246 mechanism Effects 0.000 description 4
- 230000003068 static effect Effects 0.000 description 4
- 230000006854 communication Effects 0.000 description 2
- 239000008358 core component Substances 0.000 description 2
- 235000019800 disodium phosphate Nutrition 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000006467 substitution reaction Methods 0.000 description 2
- 238000003491 array Methods 0.000 description 1
- 210000004556 brain Anatomy 0.000 description 1
- 238000004891 communication Methods 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
- 230000005294 ferromagnetic effect Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000002688 persistence Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 239000000523 sample Substances 0.000 description 1
- 230000001502 supplementing effect Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1448—Management of the data involved in backup or backup restore
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1458—Management of the backup or restore process
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2023—Failover techniques
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本申请公开了一种数据安全管理方法、装置、设备和存储介质。该方法包括：获取数据库的故障转移请求，数据库的故障转移请求包括数据库的主节点、备节点的故障数量，以及数据库的主节点对应的可用性组的架构类型；可用性组的架构类型包括两地两中心和两地三中心，两地两中心包括主节点和第一备节点，两地三中心包括主节点、第一备节点和第二备节点，第一备节点基于数据库的纳管请求生成，第二备份节点为数据库内的备份节点；基于数据库的主节点、备节点的故障数量和可用性组的架构类型对主节点进行故障转移。如此，兼容了数据库的安全性和容灾能力的需求，以此实现用户业务的停机窗口的最小化，为用户交付最佳的数据库容灾能力。
Description
技术领域
本申请涉及数据安全领域，尤其涉及一种数据安全管理方法、装置、设备及存储介质。
背景技术
当前，数据库上云正逐渐成为许多企业业务进一步发展的重要战略选择。云厂商同时也会配套提供数据备份、恢复和容灾等功能，这不仅能够为上云业务补全数据安全的能力，还能大量节省部署相同功能的设施所需的管理成本和技术成本。但是对于已为数据库配套了存量设施与组件的用户，在数据库上云时，数据库配套的存量设施和组件也需要跟随数据库上云一并迁移，在迁移过程中，会面临相关的服务如何跟随数据库上云一并迁移或已配置的硬件资源如何继续使用的一系列复杂问题。
对于隐私数据的安全性有很高要求的用户，其已为数据库配套了存量设施与组件。对于此类用户相比于云服务器提供的资源便利性，其数据的安全性和可预见性更为重要。因此，当其在避免进行数据迁移的同时还想要使用云服务的容灾功能时，业务上云就无法解决问题。
发明内容
有鉴于此，本申请实施例提供了一种安全管理方法、装置、设备及存储介质，能够兼容数据库的安全性和容灾能力的需求。
本申请实施例的技术方案是这样实现的：
第一方面，本申请实施例提供了一种数据安全管理，所述方法包括：
获取数据库的故障转移请求，所述数据库的故障转移请求包括数据库的主节点、备节点的故障数量和所述数据库的主节点对应的可用性组的架构类型；所述可用性组的架构类型包括两地两中心和两地三中心，所述两地两中心包括主节点和第一备节点，所述两地三中心包括主节点、第一备节点和第二备节点，所述第一备节点基于数据库的纳管请求生成，所述第二备份节点为所述数据库内的备份节点；
基于所述数据库的主节点、备节点的故障数量和所述可用性组的架构类型对所述主节点进行故障转移。
上述方案中，所述获取数据库的故障转移请求之前，所述方法包括：
获取数据库的纳管请求，所述数据库的纳管请求包括述数据库的主节点的数据信息；
基于所述主节点的数据信息生成所述主节点对应的第一备节点；
在所述第一备份节点与所述主节点之间创建可用性组，形成所述两地两中心或所述两地三中心的架构类型。
上述方案中，所述基于所述数据库的主节点、备节点的故障数量和所述可用性组的架构类型对所述主节点进行故障转移，包括：
基于所述数据库的主节点、备节点的故障数量和所述可用性组的架构类型确定主节点对应的故障转移方案，所述故障转移方案为第一方案或者第二方案；
基于所述第一方案或者所述第二方案对所述主节点进行故障转移；
其中，所述第一方案用于基于所述主节点修复阈值和所述第一备节点的延迟阈值将所述第一备节点取代主节点，所述第二方案用于基于主节点的心跳信号将所述第二备节点取代所述主节点。
上述方案中，所述基于所述数据库的主节点、备节点的故障数量和所述可用性组的架构类型确定主节点对应的故障转移方案，包括以下至少之一：
若所述可用性组的架构类型为两地两中心，则基于所述第一方案对所述主节点进行故障转移；
若所述可用性组的架构类型为两地三中心且所述数据库的主节点、备节点的故障数量小于所述主节点对应的可用性组的仲裁投票阈值，则基于所述第二方案对所述主节点进行故障转移；
若所述可用性组的架构类型为两地三中心且所述数据库的主节点、备节点的故障数量大于或者等于可用性组的仲裁投票阈值，则基于所述第一方案对所述主节点进行故障转移。
上述方案中，所述基于所述第一方案对所述主节点进行故障转移，包括：
获取主节点的修复参数和所述第一备节点的数据延迟时长；
若所述主节点的修复参数大于或者等于所述主节点的修复阈值，则判断所述第一备节点的数据延迟时长是否小于或者等于所述第一备节点的延迟阈值，若所述第一备节点的数据延迟时长小于或者等于所述第一备节点的延迟阈值，则将所述第一备节点取代所述主节点。
上述方案中，所述主节点的修复参数包括主节点的故障重复确认次数和等待主节点的回复时长，所述若主节点的修复参数大于或者等于所述主节点的修复阈值，包括：
判断若所述故障重复确认次数是否大于或者等于主节点的故障重复确认次数阈值且所述等待主节点的回复时长是否大于或者等于等待主节点回复时间阈值，若所述主节点的故障重复确认次数大于或者等于主节点的故障重复确认次数阈值且所述等待回复时长大于或者等于等待回复时间阈值，则主节点的修复参数大于或者等于主节点的修复阈值。
上述方案中，所述基于第二方案对所述主节点进行故障转移，包括：
获取主节点的心跳信号；
若所述主节点的心跳信号无法获取，则确定所述主节点失活，并将所述第二备节点取代所述主节点。
第二方面，本申请实施例提供了一种数据安全管理装置，所述装置包括：
获取模块，用于获取数据库的故障转移请求，所述数据库的故障转移请求包括数据库的主节点、备节点的故障数量和所述数据库的主节点对应的可用性组的架构类型；所述可用性组的架构类型包括两地两中心和两地三中心，所述两地两中心包括主节点和第一备节点，所述两地三中心包括主节点、第一备节点和第二备节点，所述第一备节点基于数据库的纳管请求生成，所述第二备份节点为所述数据库内的备份节点；
故障转移模块，用于基于所述数据库的主节点、备节点的故障数量和所述可用性组的架构类型对所述主节点进行故障转移。
第三方面，本申请实施例提供了一种数据安全管理设备，包括：处理器和用于存储能够在处理器上运行的计算机程序的存储器，其中，
所述处理器，用于运行计算机程序时，执行第一方面所述方法的步骤。
第四方面，本申请实施例提供了一种计算机存储介质，所述存储介质上存储有计算机程序，所述计算机程序被处理器执行时，实现第一方面所述方法的步骤。
本申请实施例提供的技术方案，获取数据库的故障转移请求，数据库的故障转移请求包括数据库的主节点、备节点的故障数量和数据库的主节点对应的可用性组的架构类型；可用性组的架构类型包括两地两中心和两地三中心，两地两中心包括主节点和第一备节点，两地三中心包括主节点、第一备节点和第二备节点，第一备节点基于数据库的纳管请求生成，第二备节点为数据库内的备份节点；基于数据库的主节点、备节点的故障数量和主节点对应的可用性组的架构类型对主节点进行故障转移。通过数据库的纳管请求实现对数据库的纳管，避免了数据库的存量设施与组件迁移，同时基于数据库的纳管请求生成第一备节点后，精确分析基于第一备节点组成的主节点对应的可用性组的架构类型，再基于数据库的主节点、备节点的故障数量和可用性组的架构类型对主节点进行故障转移实现对数据库的容灾，实现了云服务的容灾功能。如此，在避免了数据库的存量设施迁移的同时，也能够使用云服务的容灾功能，兼容了数据库的安全性和容灾能力的需求，引入了“纳管容灾”的概念，以此实现用户业务的停机窗口的最小化，为用户交付最佳的数据库容灾能力。
附图说明
图1为本申请实施例提供的数据安全管理方法的流程示意图；
图2为本申请一应用示例中纳管容灾的原理框架示意图；
图3为本申请一应用示例中纳管容灾的流程示意图；
图4为本申请一应用示例中云管理平台纳管克隆示意图；
图5为本申请一应用示例中两地两中心的架构示意图；
图6为本申请一应用示例中两地三中心的架构示意图；
图7为本申请一应用示例中同城节点单故障的结构示意图；
图8为本申请一应用示例中同城节点全故障的结构示意图；
图9为本申请实施例提供的数据安全管理装置的结构示意图；
图10为本申请实施例提供的数据安全管理设备的结构示意图。
具体实施方式
下面结合附图及实施例对本申请再作进一步详细的描述。
除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中在本申请的说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本申请。
本申请实施例提供了一种数据安全管理方法，可以应用于数据安全管理设备，这里的数据安全管理设备可以是云管理平台设备，如图1所示，该方法包括以下步骤：
步骤110：获取数据库的故障转移请求，所述数据库的故障转移请求包括数据库的主节点、备节点的故障数量，以及所述数据库的主节点对应的可用性组的架构类型；所述可用性组的架构类型包括两地两中心和两地三中心，所述两地两中心包括主节点和第一备节点，所述两地三中心包括主节点、第一备节点和第二备节点，所述第一备节点基于数据库的纳管请求生成，所述第二备份节点为所述数据库内的备份节点。
这里，获取数据库的故障转移请求的设备可以是云管理平台设备。这里的数据库包括但不限于MySQL、Oracle、SQL Server等数据库。这里的云管理平台设备可以对上述数据库提供智能管理的PAAS(Platform as a Service，平台即服务)服务功能。
这里，数据库的故障转移请求包括了数据库的主节点、备节点的故障数量和数据库的主节点对应的可用性组的架构类型。数据库的节点包括了主节点和备节点。这里的数据库的主节点、备节点的故障数量为数据库中所有节点的故障数量。主节点对应的可用性组用于提高可用性。可用性包括可靠性、故障和恢复，例如，一个系统的可靠性，故障发生时间间隔和故障恢复速度，共同决定了这个系统的可用性。可用性组是一个提供替代数据库镜像的企业级方案的高可用性和灾难恢复功能的方案。SQL Server 2012中引入了AlwaysOn可用性组功能，此功能可最大程度地提高一组用户数据库对企业的可用性。“可用性组”针对一组离散的用户数据库(称为“可用性数据库”，它们共同实现故障转移)支持故障转移环境。一个可用性组支持一组读写主数据库以及多组对应的辅助数据库(例如，一至八组辅助数据库)。这里的主数据库为主节点，副本数据库为备节点，Always On的特点是当集群中存在同步提交的正常状态备节点时，则Always On可以提供在主节点出现故障时，自动切换业务至同步备节点的能力。
这里，主节点对应的可用性组的架构类型根据主节点对应的可用性组中是否包含第二备节点分为两地三中心或者两地三中心。所述两地两中心包括主节点和第一备节点，所述两地三中心包括主节点、第一备节点和第二备节点，这里，第一备节点是基于数据库的纳管请求生成，而第二备份节点为数据库内的备份节点。即在主节点对应的可用性组的架构类型中至少包括了第一备节点。以数据库SQL Server为例，SQL Server包括了主节点a，第一备节点b和第二备节点c，则SQL Server对应的可用性组的架构类型为两地三中心。其中，第一备节点b是基于SQL Server数据库的纳管请求生成的，第二备节点c是为数据库内的备份节点。
步骤120：基于所述数据库的主节点、备节点的故障数量和所述可用性组的架构类型对所述主节点进行故障转移。
这里，在获取到数据库的主节点、备节点的故障数量和主节点对应的可用性组的架构类型后，就可以对主节点进行故障转移。这里的故障转移是指当活动的服务或对应主节点意外终止时，快速启用备节点接替主节点进行工作，从而实现对数据库的容灾要求。
如此，通过数据库的纳管请求实现对数据库的纳管，避免了数据库的存量设施与组件迁移，同时基于数据库的纳管请求生成第一备节点后，精确分析基于第一备节点组成的主节点对应的可用性组的架构类型，再基于数据库的主节点、备节点的故障数量和主节点对应的可用性组的架构类型对主节点进行故障转移实现对数据库的容灾，实现了云服务的容灾功能。如此，在避免了数据库的存量设施迁移的同时，也能够使用云服务的容灾功能，兼容了数据库的安全性和容灾能力的需求，引入了“纳管容灾”的概念，以此来实现用户业务的停机窗口的最小化，为用户交付最佳的数据库容灾能力。
在一些实施例中，所述获取数据库的故障转移请求之前，所述方法包括：
获取数据库的纳管请求，所述数据库的纳管请求包括述数据库的主节点的数据信息；
基于所述主节点的数据信息生成所述主节点对应的第一备节点；
在所述第一备份节点与所述主节点之间创建可用性组，形成所述两地两中心或所述两地三中心的架构类型。
这里，在获取数据库的故障转移请求之前，会对数据库进行纳管的操作，生成第一备节点，并在第一备节点与主节点之间创建可用性组，形成所述两地两中心或所述两地三中心的架构类型。这里的创建分为两种情况，第一、在数据库中的主节点没有包含第二备节点的情况下，第一备节点与主节点之间构成可用性组；第二、在数据库的主节点包含第二备节点的情况下，此时，主节点和第二备节点之间就已经构建了一个可用性组，这里的创建是指第一备节点加入主节点和第二备节点之间构建的可用性组，从而创建出包含主节点、第一备节点和第二备节点的新的可用性组。
这里，可用性组有两种类型的数据同步模式。以SQL Server数据库为例，异步提交模式：在这种模式下，主副本将事务日志块发送到辅助副本，但它不等待事务提交的确认。同步提交模式：在同步提交模式下，主副本等待来自辅助副本的事务提交。收到确认后，SQLServer向客户端确认。
如此，通过对数据进行纳管，可以避免对数据库的迁移。并且基于数据库的纳管请求生成的第一备节点创建数据库的可用性组，也对后续数据库的容灾提供了故障转移的条件。实现在保留数据库资源与当前环境的基础上的同时也补全容灾能力的功能。
在一些实施例中，所述基于所述数据库的主节点、备节点的故障数量和所述可用性组的架构类型对所述主节点进行故障转移，包括：
基于所述数据库的主节点、备节点的故障数量和所述可用性组的架构类型确定主节点对应的故障转移方案，所述故障转移方案为第一方案或者第二方案；
基于所述第一方案或者所述第二方案对所述主节点进行故障转移；
其中，所述第一方案用于基于所述主节点修复阈值和所述第一备节点的延迟阈值将所述第一备节点取代主节点，所述第二方案用于基于主节点的心跳信号将所述第二备节点取代所述主节点。
这里，会根据架构类型的不同确定不同的方案进行故障转移。故障转移的的方案包括第一方案和第二方案。这里，第一方案用于基于主节点修复阈值和第一备节点的延迟阈值将所述第一备节点取代主节点，第二方案用于基于主节点的心跳信号将第二备节点取代所述主节点。这里，第一方案是要将第一备节点取代主节点进行故障转移，在发生故障以后，主节点有可能自行修复。若第一备节点与主节点的同步模式属于异步提交模式，对于异步提交模式来说，数据库中备节点与主节点的数据与会存在理论上的数据延迟。因此，需要基于主节点修复阈值和第一备节点的延迟阈值进行故障转移。第二方案是是基于第二备节点进行故障转移。通常情况下，在数据库中节点通信过程中，会有心跳的hello包，备用节点会一直发送hello包检测主节点是否正常；如果主机在一段时间之内没有应答hello包的话，就认为主节点故障。从而马上选出备节点去接管业务。这样就实现了容灾。因此，需要基于主节点的心跳信号来进行故障转移。
在一些实施例中，所述基于所述数据库的主节点、备节点的故障数量和所述可用性组的架构类型确定主节点对应的故障转移方案，包括以下至少之一：
若所述可用性组的架构类型为两地两中心，则基于所述第一方案对所述主节点进行故障转移；
若所述可用性组的架构类型为两地三中心且所述数据库的主节点、备节点的故障数量小于所述主节点对应的可用性组的仲裁投票阈值，则基于所述第二方案对所述主节点进行故障转移；
若所述可用性组的架构类型为两地三中心且所述数据库的主节点、备节点的故障数量大于或者等于可用性组的仲裁投票阈值，则基于所述第一方案对所述主节点进行故障转移。
这里，根据主节点对应的架构类型的不同会确定不同的故障转移方案。若主节点对应的可用性组的架构类型为两地两中心，则基于第一方案对所述主节点进行故障转移。在两地两中心的架构中，只包括第一备节点和主节点。
若所述主节点对应的可用性组的架构类型为两地三中心且所述数据库的主节点、备节点的故障数量小于所述主节点对应的可用性组的仲裁投票阈值，则基于所述第二方案对所述主节点进行故障转移；若所述主节点对应的可用性组的架构类型为两地三中心且所述数据库的主节点、备节点故障数量大于或者等于可用性组的仲裁投票阈值，则基于所述第一方案对所述主节点进行故障转移。这里的可用性组的仲裁投票阈值是指在在仲裁模式下，仲裁阈值决定集群在正常提供服务时，能够容忍多少个结点发生故障。在集群中的故障结点达到仲裁规定的数量之前，数据库自身能够实现容灾，即能够基于第二备节点进行故障转移。在大于或者等于该仲裁阈值时，需要基于第一备节点进行故障转移即基于第一方案对主节点进行故障转移。
如此，通过主节点可用性组架构类型的不同确定不同的故障转移方案，故障转移方案包括了第一方案和第二方案，适应于多种故障场景，在对用户现有业务架构入侵最小化的基础上，为用户交付最佳的数据库容灾能力。
在一些实施例中，所述基于所述第一方案对所述主节点进行故障转移，包括：
获取主节点的修复参数和所述第一备节点的数据延迟时长；
若所述主节点的修复参数大于或者等于所述主节点的修复阈值，则判断所述第一备节点的数据延迟时长是否小于或者等于所述第一备节点的延迟阈值，若所述第一备节点的数据延迟时长小于或者等于所述第一备节点的延迟阈值，则将所述第一备节点取代所述主节点。
这里，在基于第一方案对主节点进行故障转移时，需要获取主节点的修复参数和第一备节点的数据延迟时长。以主节点的修复参数为a，主节点的修复阈值对应为aThreshold，第一备节点的数据延迟时长为dataDelay，第一备节点的数据延迟阈值为delayThreshold为例，即若：
primaryStatus＝’Disconnected’
a>＝aThreshold
secondaryStatus＝＝’Normal’
dataDelay<＝delayThreshold
则将所述第一备节点取代所述主节点。这里的primaryStatus为主节点，secondaryStatus为第一备节点。primaryStatus＝’Disconnected’和secondaryStatus＝＝’Normal’分别代表确认主节点故障和第一备节点可用。
在一些实施例中，所述主节点的修复参数包括主节点的故障重复确认次数和等待主节点的回复时长，所述若主节点的修复参数大于或者等于所述主节点的修复阈值，包括：
判断所述故障重复确认次数是否大于或者等于主节点的故障重复确认次数阈值且所述等待主节点的回复时长是否大于或者等于等待主节点回复时间阈值，若所述主节点的故障重复确认次数大于或者等于主节点的故障重复确认次数阈值且所述等待回复时长大于或者等于等待回复时间阈值，则主节点的修复参数大于或者等于主节点的修复阈值。
这里，以主节点的故障重复确认次数为retryTimes，主节点的故障重复确认阈值为retryThreshold，主节点的回复时长为waitTime，主节点的回复时长阈值为waitThreshold为例，主节点的修复参数大于或者等于所述主节点的修复阈值包括：
retryTimes>＝retryThreshold
waitTime>＝waitThreshold
在一些实施例中，所述基于第二方案对所述主节点进行故障转移，包括：
获取主节点的心跳信号；
若所述主节点的心跳信号无法获取，则确定所述主节点失活，并将所述第二备节点取代所述主节点。
这里，主节点的心跳信号的获取可以通过心跳包，用心跳包检测主节点是否正常；如果主节点在一段时间之内没有应答心跳包的话，就确定主节点失活。从而马上基于第二备节点去接管业务。
下面结合应用实施例对本申请再作进一步详细的描述。在本应用示例中，以云管理平台和SQL Server数据库为例，提供一种基于数据库纳管与SQL Server Always On可用性组的解决方案。针对用户希望保留数据库资源与当前环境的基础上即不进行数据迁移的同时，使用云管理平台补全容灾能力的需求，最终实现在对用户现有业务架构入侵最小化的基础上，为用户交付最佳的数据库容灾能力。
Always On：SQL Server Availability Group可用性组，是SQL Server 2012及以上版本提供的SQL Server集群高可用特性。其基于Windows Server故障转移集群功能，实现SQL Server集群各节点的高可用性的同时，通过一个具有固定IP地址的虚拟侦听器，对上层应用屏蔽集群的拓扑细节，实现无感知的数据库集群使用。
图2提供了SQL Server纳管容灾的原理框架图，在本申请实施例中，DMP能够实现对数据库SQL Server的状态监测和性能监控，同时还包括备份中心和故障自愈即故障转移的功能。如图2所示，其包含了DMP纳管SQL Server实现容灾的数据流与核心组件，具体包括：
1)用户机房A与SQL Server原节点(SQL Server Node Original)为用户原始资源与数据库所在的环境；这里的SQL Server原节点即为上文中的主节点。
2)云管平台机房B与SQL Server副本节点：DMP云平台环境资源与创建的SQLServer副本节点(SQL Server Node Replica)，其与原节点规格、系统环境一致；这里的SQLServer副本节点即为上文中的第一备节点。这里，SQL Server副本节点与SQL Server原节点之间的同步的模式可以自行设置。一般来说，如果SQL Server副本节点与SQL Server原节点之间是同城的话就为同步提交，如果是跨城则为异步提交。这里的SQL Server副本节点与SQL Server原节点之间就创建了一个Always可用性组。在本应用实施例中，第一备节点与主节点的同步模式为异步提交，即SQL Server副本节点与SQL Server原节点之间的同步模式为异步提交。
3)Agent：运行在数据库节点上的云管理平台功能代理模块，负责拉取本机信息即指标拉取与代理下发云管理平台的操作指令即操作下发。并且云管理平台的Agent管理套件通过部署在用户SQL Server环境中建立纳管状态，实现对源数据库SQL Server的性能监控及基本的状态监测和故障转移。
本应用实施例中的纳管容灾流程包含4个部分：1、建立纳管；2、数据同步；3、状态监测；4、故障转移，详细流程图如图3所示，图3中的源数据库即SQL Server的主节点，副本数据库为SQL Server的备节点，源数据库与副本数据库组建了Always On可用性组。云管理平台也包括了DB Operator与状态与集群拓扑探测。DB Operator功能是数据库的连接，修改和查询等操作，集群拓扑探测用于监测集群的拓扑结构和状态监测。各部分具体的步骤如下：
1、建立纳管部分。本应用实施例通过将云管理平台的Agent管理套件部署在用户SQL Server环境建立纳管状态，实现对源数据库的性能监控及基本的状态管理。同时通过使用云平台资源创建数据库虚拟机，使之与源库组SQL Server建Always On可用性组，结合云管理平台的数据库故障发现与备库主动拉起能力，最终在对用户现有业务架构入侵最小化的基础上，为用户交付最佳的数据库容灾能力。具体内容包括：
获取数据库SQL Server的纳管请求，数据库的纳管请求包括SQL Server原节点(即数据库SQL Server主节点)的数据信息；
基于SQL Server原节点的数据信息生成SQL Server原节点对应的第一备节点即SQL Server副本节点；
在SQL Server副本节点(即SQL Server原节点对应的第一备节点)与SQL Server原节点(即数据库SQL Server主节点)之间创建可用性组，形成所述两地两中心或所述两地三中心的架构类型。
其主要的步骤如下所示：
步骤301：云管理平台拉取数据库SQL Server的环境信息与系统兼容性检查。
将云管理平台的Agent管理套件部署在用户SQL Server环境建立纳管状态后，云管理平台对源数据库SQL Server所在环境进行系统信息检测确认兼容性以确保该数据库SQL Server能够与云管理平台兼容。
步骤302：数据库SQL Server返回系统信息。
这里的系统信即SQL Server原节点(即数据库SQL Server主节点)的数据信息。当云管理平台对源数据库SQL Server所在环境进行系统信息检测确认兼容性后，云管理平台就会拉取源数据库SQL Server的系统信息，相应地，数据库SQL Server返回系统信息。
步骤303：云管理平台建立纳管关系。
当云管理平台与用户原数据库SQL Server建立纳管关系后，云管理平台将能够如管理常规生命周期数据库SQL Server一样管理用户数据库SQL Server，即使其所在的物理主机与云平台相互独立。
2、数据同步部分。
步骤304：依据系统信息克隆创建副本数据库SQL Server。
如图4所示，依据系统信息克隆创建副本数据库SQL Server即基于SQL Server原节点的数据信息生成SQL Server原节点对应的第一备节点即SQL Server副本节点的过程。在本应用实施例中，SQL Server副本节点与SQL Server原节点的同步模式为异步提交。当云管理平台对源数据库所在环境进行系统信息检测确认兼容性后，就可以在拉取源数据库的系统信息即SQL Server原节点(即数据库SQL Server主节点)的数据信息后，云管理平台创建镜像主机即生成SQL Serve节点对应的第一备节点。具体过程是：数据库云管理平台基于云管理平台的分析模块，调用云平台生命周期接口，创建或克隆出与源数据库SQLServer系统环境(主要取决于CPU、内存、系统版本、数据库SQL Server版本等)相似或相同的虚拟机，这一步是为了满足Windows WSFC故障转移集群的组成节点条件。WSFC(windows故障转移群集)是微软高可用技术(HA)的核心组成部分，是Windows Server的一个功能。Always On则是SQL Server的功能，WSFC更加底层，在创建SQL Server Always On高可用组和其他如Exchange等高可用技术之前，都需要部署和配置WSFC。WSFC：Windows ServerFailover Cluster故障转移集群，Windows Server操作系统平台支持的一种高可用集群模式。其通过网络心跳将复数台规格、结构、内容相似的Windows Server节点集群化，并提供投票机制选出集群主、备节点，结合自动故障转移，使其上运行的应用在主机和备选机上高可用地对外提供服务。
步骤305：组建Always On。
当虚拟机资源就绪后，云管理平台就可以将二者作为集群节点，组建成SQLServer Always On可用性组。对于纳管后形成的Always On，根据源数据库SQL Server的集群拓扑、节点个数和节点分布情况可以分为两种架构。分为两地两中心如图5或两地三中心如图6。两地三中心架构(如图6)是标准容灾架构，其依赖于Always On自身提供的数据同步与不同条件下的故障转移能力，配合管理面，实现机房级别故障与区域级别故障的容灾能力。架构中由SQL Server数据库SQL Server主节点(用户机房A节点)、第一备节点(云管异地机房节点)和第二备节点(用户机房B节点)组成。其中，主节点以“同步提交”的模式，将数据同步至同城备节点(机房B节点)即第二备节点上，以“异步提交”的模式同步至跨城备节点(运管异地机房节点)即第一备节点。
3、状态监测部分。在纳管生命周期内，云管理平台的状态与集群拓扑探测模块一直在工作，其定时向Always On拉取集群主节点及对应的备节点的状态信息，用于故障判断。
步骤306：云管理平台主节点状态监测。
这里，云管理平台会对主节点的故障数量以及故障状态进行监测。
步骤307：云管理平台其他节点状态监测。
这里，云管理平台会对其他节点的故障数量以及故障状态进行监测。
步骤308：云管理平台集群拓扑分析。
这里的拓扑分析是指基于当前集群的各节点状态，导出整个集群宏观状态的过程。例如，上述步骤305组建成两地三中心架构后，拓扑分析用于探测该集群中各节点的状态，若主节点故障，第一备节点和第二备节点正常时，则生成“该集群已经故障但可以进行故障转移”的分析结果至云管理平台。示例性地，分析的程序如下所示：
通过上述程序对集群拓扑的分析，并基于上述组建Always On所确立的集群架构，从而为后续容灾管理提供了依据。
4、故障转移部分。
获取数据库SQL Server的故障转移请求，数据库SQL Server的故障转移请求包括数据库SQL Server各节点的故障数量和数据库SQL Server的主节点对应的可用性组的架构类型；主节点对应的可用性组的架构类型包括两地两中心和两地三中心，两地两中心包括主节点和第一备节点，两地三中心包括主节点、第一备节点和第二备节点，第一备节点基于数据库SQL Server的纳管请求生成，第二备节点为数据库SQL Server内的备份节点；
基于数据库SQL Server主节点及对应的备节点的故障数量和主节点对应的可用性组的架构类型对主节点进行故障转移。
步骤309：上报主节点故障信息。
在主节点发生故障以后，集群拓扑监测模块会向云管理平台上报主节点的故障信息，并向云管理平台发送需要进行数据库SQL Server的故障转移请求。此时，故障转移请求包括了SQL Server主节点、备节点的故障数量，以及SQL Server的主节点对应的可用性组的架构类型。主节点对应的可用性组的架构类型包括两地两中心和两地三中心。
步骤310：确定故障转移方案。
云管理平台基于数据库SQL Server主节点及对应的备节点的故障数量和主节点对应的可用性组的架构类型确定主节点对应的故障转移方案，包括以下至少之一，故障转移方案为第一方案或者第二方案；
基于第一方案或者第二方案对主节点进行故障转移；
其中，第一方案用于基于主节点修复阈值和第一备节点的延迟阈值将第一备节点取代主节点，第二方案用于基于主节点的心跳信号将第二备节点取代主节点，主节点的心跳信号的获取可以通过心跳包，用心跳包检测主节点是否正常；如果主节点在一段时间之内没有应答心跳包的话，就确定主节点失活。从而马上基于第二备节点去接管业务。
具体来说，若主节点对应的可用性组的架构类型为两地两中心，则基于第一方案对主节点进行故障转移。
对于两地两中心架构(如图5)，由于缺少可用的同步备节点即第二备节点，实际上Always On的自动故障转移机制不能生效。此时只能依赖云管理平台的管理与监控，实现异地容灾。
若主节点对应的可用性组的架构类型为两地三中心且数据库SQL Server主节点、备节点的故障数量小于主节点对应的可用性组的仲裁投票阈值，则基于第二方案对主节点进行故障转移；
若主节点对应的可用性组的架构类型为两地三中心且数据库SQL Server主节点、备节点的故障数量大于或者等于可用性组的仲裁投票阈值，则基于第一方案对主节点进行故障转移。
通常这里的投票阈值设置为8个，若节点对应的可用性组的架构类型为两地三中心且数据库SQL Server主节点、备节点的故障数量小于8个时，则基于第二方案对主节点进行故障转移。如图7所示，图7为两地三中心的架构，故障类型是同城节点单点故障的情形，当同城机房A出现节点自身故障甚至机房故障时(如图7)，由于同城机房B上节点状态良好即第二备节点状态良好，且一直与原主节点即主节点保持“同步提交”，满足Always On故障转移条件。此时SQL Server Always On通过心跳探测等机制确认节点A即主节点失活后，将自动对同步备节点B即第二备节点实行自动故障转移。B节点即第二备节点接管集群业务成为主节点，集群架构退化为两地两中心模式，继续对外提供业务。显然，两地多中心架构对于同城范围内的单点故障容忍能力，取决于同步备节点的冗余程度。
节点对应的可用性组的架构类型为两地三中心且数据库SQL Server主节点、备节点的故障数量大于或者等于8时，则基于第一方案对主节点进行故障转移。
当遇到极端情况，如城市级别灾难故障发生时，此时同城范围内的冗余节点全部故障(如图8)，假设图8中的同城节点即主节点(用户机房A节点)与第二备节点(用户机房B节点)的数量大于或者等于8，图8也是两地三中心的架构，但是此时，基于仲裁模式的SQLServer Always On，在没有如共享文件系统、共享磁盘等第三者介入的情况下，实际上并不能满足仲裁投票条件(节点故障数量小于8)，不能基于第二备节点实现自动故障转移能力。此时基于第一方案对主节点进行故障转移
步骤311：基于第一方案或者第二方案对主节点进行故障转移。
基于第一方案对主节点进行故障转移，包括：
云管理平台介入工作，并确认上述故障场景发生：重复确认次数达到上限、等待恢复时间达到上限、且无可用同步备节点即第二备节点时：
primaryStatus＝’Disconnected’
retryTimes>＝retryThreshold
waitTime>＝waitThreshold
当满足上述修复阈值，云管理平台将进一步确认可用备节点情况。由于可用备节点即第一备节点基于“异步提交”模式与原主节点通信，数据库中数据会存在理论上的数据延迟。当第一备节点状态正常可用，数据延迟在阈值以下时：
secondaryStatus＝＝’Normal’
dataDelay<＝delayThreshold
灾难恢复流程即被触发，云管理平台将下发主动故障转移命令：确保主节点脱机避免脑裂，并对备节点进行主动故障转移。
第二方案为SQL Server Always On通过心跳探测等机制确认节点A失活后，将自动对同步备节点B实行自动故障转移。
步骤312：新主接管业务
对于第一方案：异地节点接管集群业务成为主节点，此时用户就可以通过新主节点的连接入口、或Always On侦听器等方式，重新接入业务，这取决于用户自身的停机窗口策略。灾难恢复结束后，云管理平台生成灾难恢复报告，向用户发起告警通知，汇报如节点延迟情况、数据丢失情况等关键信息。
对于第二方案：B节点接管集群业务成为主节点，集群架构退化为两地两中心模式，继续对外提供业务。
如此，本应用实施例结合云管理平台纳管数据库和数据备份和容灾的能力，引入“纳管容灾”的概念，基于云管理平台的集群拓扑探测核心模块，精确分析数据库集群的状态，并及时进行容灾处置，以此来实现用户业务的停机窗口的最小化。
为了实现本申请实施例的方法，本申请实施例还提供一种数据安全管理装置，该数据安全管理装置与上述数据安全管理方法对应，上述数据安全管理方法实施例中的各步骤也完全适用于本数据安全管理装置实施例。如图9所示，该数据安全管理装置900包括：获取模块910和数据转移模块920。其中，获取模块910，用于获取数据库的故障转移请求，数据库的故障转移请求包括数据库的主节点、备节点的故障数量和数据库的主节点对应的可用性组的架构类型；可用性组的架构类型包括两地两中心和两地三中心，两地两中心包括主节点和第一备节点，两地三中心包括主节点、第一备节点和第二备节点，第一备节点基于数据库的纳管请求生成，第二备份节点为数据库内的备份节点；
故障转移模块920，用于基于数据库的主节点、备节点的故障数量和可用性组的架构类型对主节点进行故障转移。
在一些实施例中，获取数据库的故障转移请求之前，获取模块910还用于获取数据库的纳管请求，数据库的纳管请求包括述数据库的主节点的数据信息；数据安全管理装置还包括生成模块920，用于基于主节点的数据信息生成主节点对应的第一备节点；数据安全管理装置还包括创建模块930，用于在第一备份节点与主节点之间创建可用性组，形成两地两中心或两地三中心的架构类型。
在一些实施例中，数据安全管理装置还包括确定模块940，用于基于数据库的主节点、备节点的故障数量和可用性组的架构类型确定主节点对应的故障转移方案，故障转移方案为第一方案或者第二方案；故障转移模块920还用于基于第一方案或者第二方案对主节点进行故障转移；其中，第一方案用于基于主节点修复阈值和第一备节点的延迟阈值将第一备节点取代主节点，第二方案用于基于主节点的心跳信号将第二备节点取代主节点。
在一些实施例中，确定模块940还用于以下至少之一：若可用性组的架构类型为两地两中心，则基于第一方案对主节点进行故障转移；
若可用性组的架构类型为两地三中心且数据库的主节点、备节点的故障数量小于主节点对应的可用性组的仲裁投票阈值，则基于第二方案对主节点进行故障转移；
若可用性组的架构类型为两地三中心且数据库的主节点、备节点的故障数量大于或者等于可用性组的仲裁投票阈值，则基于第一方案对主节点进行故障转移。
在一些实施例中，获取模块910还用于获取主节点的修复参数和第一备节点的数据延迟时长；数据安全管理模块还包括判断模块950，用于若主节点的修复参数大于或者等于主节点的修复阈值，则判断第一备节点的数据延迟时长是否小于或者等于第一备节点的延迟阈值，若第一备节点的数据延迟时长小于或者等于第一备节点的延迟阈值，则将第一备节点取代主节点。
在一些实施例中，判断模块950还用于判断若故障重复确认次数是否大于或者等于主节点的故障重复确认次数阈值且等待主节点的回复时长是否大于或者等于等待主节点回复时间阈值，若主节点的故障重复确认次数大于或者等于主节点的故障重复确认次数阈值且等待回复时长大于或者等于等待回复时间阈值，则主节点的修复参数大于或者等于主节点的修复阈值。
在一些实施例中，获取模块910还用于获取主节点的心跳信号；确定模块940还用于若主节点的心跳信号无法获取，则确定主节点失活，并将第二备节点取代主节点。
实际应用时，获取模块910、故障转移模块920、生成模块930、确定模块940及判断模块950，可以由数据安全管理装置中的处理器来实现。当然，处理器需要运行存储器中的计算机程序来实现它的功能。
需要说明的是：上述实施例提供的数据安全管理装置在进行数据安全管理时，仅以上述各程序模块的划分进行举例说明，实际应用中，可以根据需要而将上述处理分配由不同的程序模块完成，即将装置的内部结构划分成不同的程序模块，以完成以上描述的全部或者部分处理。另外，上述实施例提供的数据安全管理装置与数据安全管理方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。
基于上述程序模块的硬件实现，且为了实现本申请实施例的方法，本申请实施例还提供一种数据安全管理设备。图10仅仅示出了该数据安全管理设备的示例性结构而非全部结构，根据需要可以实施图10示出的部分结构或全部结构。
如图10所示，本申请实施例提供的数据安全管理设备1000包括：至少一个处理器1001、存储器1002、用户接口1003和至少一个网络接口1004。数据安全管理设备1000中的各个组件通过总线系统1005耦合在一起。可以理解，总线系统1005用于实现这些组件之间的连接通信。总线系统1005除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图10中将各种总线都标为总线系统1005。
其中，用户接口1003可以包括显示器、键盘、鼠标、轨迹球、点击轮、按键、按钮、触感板或者触摸屏等。
本申请实施例中的存储器1002用于存储各种类型的数据以支持数据安全管理设备的操作。这些数据的示例包括：用于在数据安全管理设备上操作的任何计算机程序。
本申请实施例揭示的数据安全管理方法可以应用于处理器1001中，或者由处理器1001实现。处理器1001可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，数据安全管理方法的各步骤可以通过处理器1001中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器1001可以是通用处理器、数字信号处理器(DSP，Digital SignalProcessor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。处理器1001可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的方法的步骤，可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于存储介质中，该存储介质位于存储器1002，处理器1001读取存储器1002中的信息，结合其硬件完成本申请实施例提供的数据安全管理方法的步骤。
在示例性实施例中，数据安全管理设备可以被一个或多个应用专用集成电路(ASIC，Application Specific Integrated Circuit)、DSP、可编程逻辑器件(PLD，Programmable Logic Device)、复杂可编程逻辑器件(CPLD，Complex Programmable LogicDevice)、现场可编程逻辑门阵列(FPGA，Field Programmable Gate Array)、通用处理器、控制器、微控制器(MCU，Micro Controller Unit)、微处理器(Microprocessor)、或者其他电子元件实现，用于执行前述方法。
可以理解，存储器1002可以是易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(ROM，Read OnlyMemory)、可编程只读存储器(PROM，Programmable Read-Only Memory)、可擦除可编程只读存储器(EPROM，Erasable Programmable Read-Only Memory)、电可擦除可编程只读存储器(EEPROM，Electrically Erasable Programmable Read-Only Memory)、磁性随机存取存储器(FRAM，ferromagnetic random access memory)、快闪存储器(Flash Memory)、磁表面存储器、光盘、或只读光盘(CD-ROM，Compact Disc Read-Only Memory)；磁表面存储器可以是磁盘存储器或磁带存储器。易失性存储器可以是随机存取存储器(RAM，Random AccessMemory)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(SRAM，Static Random Access Memory)、同步静态随机存取存储器(SSRAM，Synchronous Static Random Access Memory)、动态随机存取存储器(DRAM，Dynamic Random Access Memory)、同步动态随机存取存储器(SDRAM，SynchronousDynamic Random Access Memory)、双倍数据速率同步动态随机存取存储器(DDRSDRAM，Double Data Rate Synchronous Dynamic Random Access Memory)、增强型同步动态随机存取存储器(ESDRAM，Enhanced Synchronous Dynamic Random Access Memory)、同步连接动态随机存取存储器(SLDRAM，SyncLink Dynamic Random Access Memory)、直接内存总线随机存取存储器(DRRAM，Direct Rambus Random Access Memory)。本申请实施例描述的存储器旨在包括但不限于这些和任意其它适合类型的存储器。
在示例性实施例中，本申请实施例还提供了一种存储介质，即计算机存储介质，具体可以是计算机可读存储介质，例如包括存储计算机程序的存储器1002，上述计算机程序可由数据安全管理设备的处理器1001执行，以完成本申请实施例方法所述的步骤。计算机可读存储介质可以是ROM、PROM、EPROM、EEPROM、Flash Memory、磁表面存储器、光盘、或CD-ROM等存储器。
需要说明的是：“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。
另外，本申请实施例所记载的技术方案之间，在不冲突的情况下，可以任意组合。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请披露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。
Claims (10)
1.一种数据安全管理方法，其特征在于，所述方法包括：
获取数据库的故障转移请求，所述数据库的故障转移请求包括所述数据库的主节点、备节点的故障数量，以及所述数据库的主节点对应的可用性组的架构类型；所述可用性组的架构类型包括两地两中心和两地三中心，所述两地两中心包括主节点和第一备节点，所述两地三中心包括主节点、第一备节点和第二备节点，所述第一备节点基于数据库的纳管请求生成，所述第二备份节点为所述数据库内的备份节点；
基于所述数据库的主节点、备节点的故障数量和所述可用性组的架构类型对所述主节点进行故障转移。
2.根据权利要求1所述的方法，其特征在于，所述获取数据库的故障转移请求之前，所述方法包括：
获取数据库的纳管请求，所述数据库的纳管请求包括述数据库的主节点的数据信息；
基于所述主节点的数据信息生成所述主节点对应的第一备节点；
在所述第一备份节点与所述主节点之间创建可用性组，形成所述两地两中心或所述两地三中心的架构类型。
3.根据权利要求1所述的方法，其特征在于，所述基于所述数据库的主节点、备节点的故障数量和所述可用性组的架构类型对所述主节点进行故障转移，包括：
基于所述数据库的主节点、备节点的故障数量和所述可用性组的架构类型确定主节点对应的故障转移方案，所述故障转移方案为第一方案或者第二方案；
基于所述第一方案或者所述第二方案对所述主节点进行故障转移；
其中，所述第一方案用于基于所述主节点修复阈值和所述第一备节点的延迟阈值将所述第一备节点取代主节点，所述第二方案用于基于主节点的心跳信号将所述第二备节点取代所述主节点。
4.根据权利要求3所述的方法，其特征在于，所述基于所述数据库的主节点、备节点的故障数量和所述可用性组的架构类型确定主节点对应的故障转移方案，包括以下至少之一：
若所述可用性组的架构类型为两地两中心，则基于所述第一方案对所述主节点进行故障转移；
若所述可用性组的架构类型为两地三中心且所述数据库的主节点、备节点的故障数量小于所述主节点对应的可用性组的仲裁投票阈值，则基于所述第二方案对所述主节点进行故障转移；
若所述可用性组的架构类型为两地三中心且所述数据库的主节点、备节点的故障数量大于或者等于可用性组的仲裁投票阈值，则基于所述第一方案对所述主节点进行故障转移。
5.根据权利要求3所述的方法，其特征在于，所述基于所述第一方案对所述主节点进行故障转移，包括：
获取主节点的修复参数和所述第一备节点的数据延迟时长；
若所述主节点的修复参数大于或者等于所述主节点的修复阈值，则判断所述第一备节点的数据延迟时长是否小于或者等于所述第一备节点的延迟阈值，若所述第一备节点的数据延迟时长小于或者等于所述第一备节点的延迟阈值，则将所述第一备节点取代所述主节点。
6.根据权利要求5所述的方法，其特征在于，所述主节点的修复参数包括主节点的故障重复确认次数和等待主节点的回复时长，所述若主节点的修复参数大于或者等于所述主节点的修复阈值，包括：
判断若所述故障重复确认次数是否大于或者等于主节点的故障重复确认次数阈值且所述等待主节点的回复时长是否大于或者等于等待主节点回复时间阈值，若所述主节点的故障重复确认次数大于或者等于主节点的故障重复确认次数阈值且所述等待回复时长大于或者等于等待回复时间阈值，则主节点的修复参数大于或者等于主节点的修复阈值。
7.根据权利要求3所述的方法，其特征在于，所述基于第二方案对所述主节点进行故障转移，包括：
获取主节点的心跳信号；
若所述主节点的心跳信号无法获取，则确定所述主节点失活，并将所述第二备节点取代所述主节点。
8.一种数据安全管理装置，其特征在于，所述装置包括：
获取模块，用于获取数据库的故障转移请求，所述数据库的故障转移请求包括数据库的主节点、备节点的故障数量，以及所述数据库的主节点对应的可用性组的架构类型；所述可用性组的架构类型包括两地两中心和两地三中心，所述两地两中心包括主节点和第一备节点，所述两地三中心包括主节点、第一备节点和第二备节点，所述第一备节点基于数据库的纳管请求生成，所述第二备份节点为所述数据库内的备份节点；
故障转移模块，用于基于所述数据库的主节点、备节点的故障数量和所述可用性组的架构类型对所述主节点进行故障转移。
9.一种数据安全管理设备，其特征在于，包括：处理器和用于存储能够在处理器上运行的计算机程序的存储器，其中，
所述处理器，用于运行计算机程序时，执行权利要求1至7任一项所述方法的步骤。
10.一种计算机存储介质，所述存储介质上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时，实现权利要求1至7任一项所述方法的步骤。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310372964.8A CN116361073A (zh) | 2023-03-30 | 2023-03-30 | 数据安全管理方法、装置、设备及存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310372964.8A CN116361073A (zh) | 2023-03-30 | 2023-03-30 | 数据安全管理方法、装置、设备及存储介质 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116361073A true CN116361073A (zh) | 2023-06-30 |
Family
ID=86908030
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310372964.8A Pending CN116361073A (zh) | 2023-03-30 | 2023-03-30 | 数据安全管理方法、装置、设备及存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116361073A (zh) |
-
2023
- 2023-03-30 CN CN202310372964.8A patent/CN116361073A/zh active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11360854B2 (en) | Storage cluster configuration change method, storage cluster, and computer system | |
| US9563673B2 (en) | Query method for a distributed database system and query apparatus | |
| US7496646B2 (en) | System and method for management of a storage area network | |
| US9201742B2 (en) | Method and system of self-managing nodes of a distributed database cluster with a consensus algorithm | |
| US6772304B2 (en) | Control method for a data storage system | |
| US6889253B2 (en) | Cluster resource action in clustered computer system incorporation prepare operation | |
| US8055735B2 (en) | Method and system for forming a cluster of networked nodes | |
| CN102656565B (zh) | 已复制数据的故障切换和恢复的方法和系统 | |
| TW523656B (en) | Method and apparatus for building and managing multi-clustered computer systems | |
| US7536586B2 (en) | System and method for the management of failure recovery in multiple-node shared-storage environments | |
| WO2018107772A1 (zh) | 写入请求处理方法、装置及设备 | |
| US9164864B1 (en) | Minimizing false negative and duplicate health monitoring alerts in a dual master shared nothing database appliance | |
| CN110224871A (zh) | 一种Redis集群的高可用方法及装置 | |
| WO2021103499A1 (zh) | 一种基于多活数据中心的流量切换方法及装置 | |
| US20080281959A1 (en) | Managing addition and removal of nodes in a network | |
| CN113515499B (zh) | 一种数据库服务方法及系统 | |
| KR101296778B1 (ko) | ＮｏＳＱＬ 데이터베이스를 위한 결과적 트랜잭션 처리 방법 | |
| US20200112499A1 (en) | Multiple quorum witness | |
| CN109165122B (zh) | 一种提升基于区块链技术实现的应用系统同城多园区部署灾备能力的方法 | |
| WO2003054711A1 (en) | A system and method for management of a storage area network | |
| US20190124145A1 (en) | Method and apparatus for availability management | |
| CN116361073A (zh) | 数据安全管理方法、装置、设备及存储介质 | |
| CN100563233C (zh) | 一种公共对象请求代理结构应用中的容错性方法 | |
| JP2001350777A (ja) | 分散データベースシステム | |
| CN112685234B (zh) | 一种金融级两地三中心高可用MySQL数据库实现方法 |
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 |