主备数据库的管理方法、系统及其设备与流程

本申请涉及信息安全技术领域，尤其涉及一种主备数据库的管理方法、系统及其设备。

背景技术：

数据库是金融、商业、交通等领域乃至整个社会的关键基础设施，数据库的持续可用是金融、商业等领域可持续向用户正常进行服务的保障。为了避免单个数据库发生故障，提升数据库的可用性，数据库通常会采用主备配置，当主数据库故障的时候，切换到备份数据库继续进行服务。

相关技术中，主备数据库可采用自动切换的方式进行切换，即对主数据库部署监控系统，一旦发现主数据路异常即发出警报并同时发出命令进行主备数据库的切换。

然而，上述主备数据库的切换方式中，可能会因为误判而导致主数据库在没有出现故障的时候发生切换，或者主数据库发生了故障却没有进行切换，从而导致影响了为用户正常提供服务。

技术实现要素：

本申请的目的旨在至少在一定程度上解决上述的技术问题之一。

为此，本申请的第一个目的在于提出一种主备数据库的管理方法，该方法在主数据库在其持有的锁到期之前，没有发送续锁请求，则判断主数据库持有的锁失效，不能正常为用户提供服务，从而选择一个备份数据成为新的主数据库，提高了主备数据库的切换速率和准确率。

本申请的第二个目的在于提出一种锁仲裁服务器。

本申请的第三个目的在于提出一种主数据库服务器。

本申请的第四个目的在于提出一种备份数据库服务器。

本申请的第五个目的在于提出一种主备数据库的管理系统。

为达上述目的，本申请第一方面实施例的主备数据库的管理方法包括：判断主数据库所持有的锁是否到期，其中，所述主数据库和备份数据库共享所述锁；如果判断所述主数据库所持有的锁已到期，则判断是否接收到所述主数据库的续锁请求；如果未收到所述主数据库的续锁请求，则从所述备份数据库中选择一个作为新的主数据库，并控制所述主数据库切换为备份数据库。

本申请实施例的主备数据库的管理方法，判断主数据库所持有的锁是否到期，如果判断主数据库持有的锁已经到期，则判断是否接收到主数据库的续锁请求，如果没有接收到续锁请求，则从备份数据库中选择一个新的主数据库，并控制主数据库切换为备份数据库。该方法在主数据库在其持有的锁到期之前，没有发送续锁请求，则判断主数据库持有的锁失效，不能正常为用户提供服务，从而选择一个备份数据成为新的主数据库，提高了主备数据库的切换速率和准确率。

另外，本申请实施例的主备数据库的管理方法还具有如下附加的技术特征：

在本申请的一个实施例中，在判断所述主数据库所持有的锁已到期之后，还包括：向所述备份数据库发送锁到期通知；接收所述备份数据根据所述锁到

期通知发送的锁请求，并记录所述锁请求的接收时间。

在本申请的一个实施例中，所述从所述备份数据库中选择一个作为主数据库还用于：选择接收时间最早的备份数据库作为所述主数据库。

在本申请的一个实施例中，所述主数据库的优先级高于所述备份数据库的优先级。

在本申请的一个实施例中，所述锁的更新周期为t1，其中，所述主数据库以周期t2发送查询所述锁的状态的锁请求，所述备份数据库以周期t3发送查询所述锁的状态的锁请求，其中，t2小于t1，t3大于或等于t1。

在本申请的一个实施例中，所述备份数据库包括热备数据库和灾备数据库，其中，所述主数据库和所述热备数据库位于同一数据中心，所述主数据库和所述灾备数据库位于不同的数据中心。

在本申请的一个实施例中，在原主数据库恢复之后，还包括：接收所述原主数据库发送的锁请求，并在所述锁到期之后控制所述锁由所述原主数据库持有以使所述原主数据库恢复为主数据库，且当前主数据库恢复为备份数据库。

在本申请的一个实施例中，在从所述备份数据库中选择一个作为新的主数据库之后，还包括：继续判断当前主数据库所持有的锁是否到期；如果所述当前主数据库所持有的锁已到期，则判断是否收到原主数据库、所述当前主数据库和其他备份数据库的锁请求；如果接收到所述原主数据库的锁请求，则将所述原主数据库恢复为主数据库，将所述当前数据库恢复为备份数据库；如果未接收到所述原主数据库的锁请求，且接收到所述当前主数据库和其他备份数据库的锁请求，则保持所述当前主数据库作为主数据库；如果未接收到所述原主数据库和所述当前主数据库的锁请求，且接收到其他备份数据库的锁请求，则从所述其他备份数据库中选择一个作为主数据库，并将所述当前主数据恢复为

备份数据库。

为达上述目的，本申请第二方面实施例的锁仲裁服务器，包括：第一判断模块，用于判断主数据库所持有的锁是否到期，其中，所述主数据库和备份数据库共享所述锁；第二判断模块，用于在所述主数据库所持有的锁已到期时，判断是否接收到所述主数据库的续锁请求；第一处理模块，用于在未收到所述主数据库的续锁请求时，从所述备份数据库中选择一个作为新的主数据库，并控制所述主数据库切换为备份数据库。

根据本申请实施例的锁仲裁服务器，判断主数据库所持有的锁是否到期，如果判断主数据库持有的锁已经到期，则判断是否接收到主数据库的续锁请求，如果没有接收到续锁请求，则从备份数据库中选择一个新的主数据库，并控制主数据库切换为备份数据库。该服务器在主数据库在其持有的锁到期之前，没有发送续锁请求，则判断主数据库持有的锁失效，不能正常为用户提供服务，从而选择一个备份数据成为新的主数据库，提高了主备数据库的切换速率和准确率。

另外，本申请实施例的锁仲裁服务器，具有如下附加的区别技术特征：

在本申请的一个实施例中，所述第一处理模块用于：选择接收时间最早的备份数据库作为所述主数据库。

在本申请的一个实施例中，所述主数据库的优先级高于所述备份数据库的优先级。

在本申请的一个实施例中，所述锁的更新周期为t1，所述主数据库以周期t2发送查询所述锁的状态的锁请求，所述备份数据库以周期t3发送查询所述锁的状态的锁请求，其中，t2小于t1，t3大于或等于t1。

在本申请的一个实施例中，所述备份数据库包括热备数据库和灾备数据库，其中，所述主数据库和所述热备数据库位于同一数据中心，所述主数据库和所述灾备数据库位于不同的数据中心。

在本申请的一个实施例中，还包括：第一接收模块，用于在原主数据库恢复之后，接收所述原主数据库发送的锁请求；所述第一处理模块，还用于在所述锁到期之后控制所述锁由所述原主数据库持有以使所述原主数据库恢复为主数据库，且当前主数据库恢复为备份数据库。

在本申请的一个实施例中，所述第一判断模块，还用于继续判断当前主数据库所持有的锁是否到期；所述第二判断模块，还用于在所述当前主数据库所持有的锁已到期时，判断是否收到原主数据库、所述当前主数据库和其他备份数据库的锁请求；第二处理模块，用于在接收到所述原主数据库的锁请求时，将所述原主数据库恢复为主数据库，将所述当前数据库恢复为备份数据库；第三处理模块，用于在未接收到所述原主数据库的锁请求，且接收到所述当前主数据库和其他备份数据库的锁请求时，保持所述当前主数据库作为主数据库；第四处理模块，用于在未接收到所述原主数据库和所述当前主数据库的锁请求，且接收到其他备份数据库的锁请求时，从所述其他备份数据库中选择一个作为主数据库，并将所述当前主数据恢复为备份数据库。

为达上述目的，本申请第三方面实施例的主数据库服务器，包括：第二发送模块，用于在持有的锁到期时，向锁仲裁服务器发送续锁请求，以便所述锁仲裁服务器未收到所述续锁请求时从备份数据库中选择一个作为新的主数据库；切换模块，用于控制所述主数据库切换为备份数据库。

根据本申请实施例的主数据服务器，在持有的锁到期时，向锁仲裁服务器发送续锁请求，以便锁仲裁服务器未接收到续锁请求时，从备份数据库中选择一个作为新的数据库，同时将主数据库切换为备份数据库。该主数据服务器在不能延展主数据库持有锁的有效期时，将主数据库切换为备份数据库，并选择一个备份数据成为新的主数据库，提高了主备数据库的切换速率和准确率，保证了数据库正常向用户提供服务，提升了用户体验。

另外，本申请实施例的主数据服务器具有如下附加的技术特征:

在本申请的一个实施例中，所述主数据库的优先级高于所述备份数据库的优先级。

在本申请的一个实施例中，所述锁的更新周期为t1，其中，所述主数据库服务器以周期t2发送查询所述锁的状态的锁请求，所述备份数据库以周期t3发送查询所述锁的状态的锁请求，其中，t2小于t1，t3大于或等于t1。

在本申请的一个实施例中，所述备份数据库包括热备数据库和灾备数据库，其中，所述主数据库和所述热备数据库位于同一数据中心，所述主数据库和所述灾备数据库位于不同的数据中心。

在本申请的一个实施例中，所述主数据库服务器还包括：

第三发送模块，用于在原主数据库恢复之后，向所述锁仲裁服务器发送锁请求，以便所述锁仲裁服务器接收所述原主数据库发送的锁请求，并在所述锁到期之后控制所述锁由所述原主数据库持有以使所述原主数据库恢复为主数据库，且当前主数据库恢复为备份数据库。

为达上述目的，本申请第四方面实施例的备份数据库服务器，包括：第四发送模块，用于向锁仲裁服务器发送锁请求；第二接收模块，用于接收所述锁仲裁服务器发送的锁确认消息；第五处理模块，用于根据所述锁确认消息切换为新的主数据库。

根据本谁请实施例的备份数据库服务器，向锁仲裁服务器发送锁请求，接收锁仲裁服务器发送的锁确认消息，根据锁确认消息切换为新的主数据库。该备份数据库服务器在主数据库不能延展主数据库持有锁的有效期时，选择一个备份数据成为新的主数据库，将主数据库切换为备份数据库，提高了主备数据库的切换速率和准确率，保证了数据库正常向用户提供服务，提升了用户体验。

本申请实施例的备份数据库服务器具有如下附加的技术特征：

在本申请的一个实施例中，所述备份数据库服务器包括：第三接收模块，用于接收所述锁仲裁服务器判断所述主数据库所持有的锁已到期之后发送的锁到期通知，其中，所述第四发送模块根据所述锁到期通知发送的锁请求向所述锁仲裁服务器发送锁请求。

在本申请的一个实施例中，所述主数据库的优先级高于所述备份数据库的优先级。

在本申请的一个实施例中，所述备份数据库包括热备数据库和灾备数据库，其中，所述主数据库和所述热备数据库位于同一数据中心，所述主数据库和所述灾备数据库位于不同的数据中心。

在本申请的一个实施例中，所述备份数据库服务器还包括：第六处理模块，用于在所述锁仲裁服务器接收所述原主数据库发送的锁请求，并在所述锁到期之后控制所述锁由所述原主数据库持有以使所述原主数据库恢复为主数据库后，控制当前主数据库恢复为备份数据库。

为达上述目的，本申请第五方面实施例的主备数据库的管理系统，包括本申请第二方面实施例所述的锁仲裁服务器，本申请第三方面实施例所述的主数据库服务器，本申请第四方面实施例所述的备份数据库服务器。

本申请附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

本申请的上述和/或附加的方面和优点从结合下面附图对实施例的描述中将变得明显和容易理解，其中：

图1是根据本申请一个实施例的主备数据库的管理方法的流程图；

图2(a)-图2(c)是根据本申请一个具体实施例的主备数据库部署图；

图3是根据本申请另一个实施例的主备数据库的管理方法的流程图；

图4是根据本申请又一个实施例的主备数据库的管理方法的流程图；

图5是根据本申请一个实施例的锁仲裁服务器的结构示意图；

图6是根据本申请一个具体实施例的锁仲裁服务器的结构示意图；

图7是根据本申请另一个实施例的锁仲裁服务器的结构示意图；

图8是根据本申请又一个实施例的锁仲裁服务器的结构示意图；

图9是根据本申请一个实施例的主数据库服务器的结构示意图；

图10是根据本申请一个具体实施例的主数据库服务器的结构示意图；

图11是根据本申请一个实施例的备份数据库的结构示意图；

图12是根据本申请一个具体实施例的备份数据库服务器的结构示意图；

图13是根据本申请另一个实施例的备份数据库服务器的结构示意图；以及

图14是根据本申请一个实施例的主备数据库的管理系统的结构示意图。

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本申请，而不能理解为对本申请的限制。

下面参考附图描述本申请一个实施例的主备数据库的管理方法、系统及其设备。

图1是根据本申请一个实施例的主备数据库的管理方法的流程图，如图1所示，该主备数据库的管理方法包括：

s110，判断主数据库所持有的锁是否到期，其中，主数据库和备份数据库共享锁。

s120，如果判断主数据库所持有的锁已到期，则判断是否接收到主数据库的续锁请求；

可以理解，为了避免通过监控系统监控并控制主备数据库的切换方式中，对主备数据库的误切换，比如对没有故障的主数据库进行切换或者主数据发生故障却不切换，本申请实施例的主备数据库的管理方法中，引入一个外部的仲裁机制，通过该仲裁机制准确判断主数据库是否发生故障，从而准确控制主备数据库之间的切换。

其中，根据具体应用场景的不同，上述外部的仲裁机制可以有很多种，本申请实施例以该仲裁机制为锁服务进行详细描述。

具体地，主数据和备份数据库共享一把锁，主数据库和备份数据库均会竞争锁的所有权，获取锁的数据库为主数据库，并且由于锁具有互斥特征，所以同一时间只会有一个数据库可为主数据库。

主数据库需要在有效期(通常为几十秒)到期之前不断更新锁以延展其有效期。如果在有效期内，主数据库发生故障或进行升级维护等，则不能完成对锁的更显以延展锁的有效期，从而其他的备份数据库抢到锁，升级为主数据库，而主数据库降级为备份数据库。

具体而言，在实际应用中，为了保护主数据库的不变，避免其在没有发生故障或进行升级维护等操作时被切换为备份数据库，主数据库的优先级高于备份数据库的优先级，以保证在主数据库没有发生故障或进行升级维护等操作的前提下，持有锁的数据库是主数据库。

需要说明的是，上述主备数据库的部署方式有多种，比如可以是一主一备的部署方式，也可是一主多备的部署方式等。

为了便于描述，在本申请的实施例中，以主备数据库的部署方式为两地三中心为例进行描述，即备份数据库包括热备数据库和灾备数据库，其中，主数据库和热备数据库位于同一数据中心，主数据库和灾备数据库位于不同的数据中心。

进一步地，为了判断持有锁的主数据库是否有故障，判断其是否在有效期内延展其对锁持有的有效期。

具体而言，判断主数据库持有的锁是否到期，如果判断主数据库所持有的锁已到期，则判断是否接收到主数据库的续锁请求。

s130，如果未收到主数据库的续锁请求，则从备份数据库中选择一个作为新的主数据库，并控制主数据库切换为备份数据库。

具体而言，如果未收到主数据库的续锁请求，则表明主数据库网络或者电力等故障，不能完成对锁的更新，从而为了正常为用户提供服务，从备份数据库中选择一个作为新的主数据库，并控制主数据库切换为备份数据库。

其中，需要说明的是，根据具体应用场景的不同，可采用不同的方式从备份数据库中选择一个作为主数据库。比如，备份数据库可按一定周期主动查询主数据库的锁到期时，是否发出续锁请求以延展其持有锁的有效性，如果没有，则备份数据库发出锁请求，以便能够迅速获取锁并切换成主数据库。

为了更加清楚的说明本申请实施例的主备数据库的管理方法，下面结合图2(a)-图2(b)以数据库部署方式为两地三新部署方式为例进行说明，即如图2(a)所示，在同城的主机房和热备机房同时部署两个数据库(主数据库和热备数据库)，在异地的灾备机房部署一个独立的数据库(灾备数据库)。

在本示例中，外部仲裁机制服务gos本身可跨地部署，可以包容机房以及布局地区完全失效，或是网络的故障，可始终提供不间断的锁服务。

图2(b)是根据本申请一个实施例的主备数据库切换示意图。

如图2(b)所示，如果主机房整体失效，比如主机房的机房损坏或者是网络故障，则其无法发出续锁请求，从而不能延展其持有锁的有效期，其持有的锁最终会失效，这个过程通常会持续几十秒，在此期间，主数据库无法正常为用户提供服务。

在锁的有效期过后，通常热备机房会获得新锁，从而热备数据库会成为新的主数据库，原来的主数据路自动降级为备份数据库，进而热备数据库作为新的主数据库为用户提供服务，灾备机房从新的主数据库中获取最新的数据，并同步到本地。

综上所述，本申请实施例的主备数据库的管理方法，判断主数据库所持有的锁是否到期，如果判断主数据库持有的锁已经到期，则判断是否接收到主数据库的续锁请求，如果没有接收到续锁请求，则从备份数据库中选择一个新的主数据库，并控制主数据库切换为备份数据库。该方法在主数据库在其持有的锁到期之前，没有发送续锁请求，则判断主数据库持有的锁失效，不能正常为用户提供服务，从而选择一个备份数据成为新的主数据库，提高了主备数据库的切换速率和准确率。

基于上述实施例，主备数据库管理方法中，主备数据库的切换方式可以分为主动切换和被动切换两种方式，具体说明如下：

作为一种示例，为了使得主数据库能够及时对锁进行更新，以及在主数据库发生故障时，其他备份数据库能够迅速获取锁，主数据库可在锁的更新周期内，以相对较短的周期发送查询锁的状态请求，从而在锁将要失效时及时对其更新，维持当前的主数据库的不变性。

同时，备份数据库以相对较长的周期主动发送查询锁的状态的锁请求，从而在主数据库的锁失效时，能够迅速获取锁，进而主动切换成为新的主数据库，不影响为用户提供服务。

举例而言，如果锁的更新周期为t1，主数据库以周期t2发送查询锁的状态的锁请求，备份数据库以周期t3发送查询锁的状态的锁请求，其中，t2小于t1，t3大于或等于t1。

作为另一种示例，如果备份数据库不是始终主动以一定的周期，发送查询锁的状态的锁请求，则在主数据库持有的锁失效时，主动向其他备份数据库发送锁到期通知，以便备份数据库根据锁到期通知发送锁请求，获取锁成为新的主数据库。

具体而言，图3是根据本申请另一个实施例的主备数据库的管理方法的流程图，如图3所示，

s310，判断主数据库所持有的锁是否到期，其中，主数据库和备份数据库共享锁。

s320，如果判断主数据库所持有的锁已到期，向备份数据库发送锁到期通知。

s330，接收备份数据根据锁到期通知发送的锁请求，并记录锁请求的接收时间。

s340，判断是否接收到主数据库的续锁请求。

s350，如果未收到主数据库的续锁请求，选择接收时间最早的备份数据库作为主数据库。

可以理解，主数据库和备份数据库之间的数据是进行准实时同步的，同步的速度取决于数据库的备份速度，通常同城机房的延迟在几毫秒，而异地机房的延时在数百毫秒。

并且如果主数据库的切换时主动发起的，比如是进行版本升级或者是下线维护，可以做到在主数据库放弃主数据库的身份之前，停止写入数据，热备机房获取锁，热备数据库能够同步更新完成所有的数据，因此在一般情况下，热备数据库的数据较完整，因此有限将热备数据库作为下一个主数据库。

具体而言，根据接收到的锁请求的时间，判断出距离主数据库较近的备份数据库。即由于不同的备份数据库可能与当前主数据库的距离不同，比如热备数据库一般距离主数据库较近，而灾备数据库一般距离主数据较远，因此其接收到锁请求的时间不同，热备数据库接收到的请求的时间较早。

进一步地，如果未接收到主数据库的续锁请求，表明当前的数据库出现故障或在进行升级维护等，因此为了尽快正常为用户提供服务，选择接收时间最早的备份数据库作为主数据库。

另外，应当理解的是，当处于同一个数据中心的主数据库和热备数据库出现灾难性的故障的时候，比如发生地震等，本申请实施例的主备数据库的管理方法仍可实现。

如图2(c)所示，当主数据库和热备数据库所在机房都发生故障，则主数据库的锁就会失效，而热备数据库也无法获得锁，因此，灾备数据库将获得锁成为新的主数据库，继续为用户提供服务，整个过程无需人工参与。

综上所述，本申请实施例的主备数据库的管理方法，在主数据库的锁到期失效时，备份数据库迅速获取锁成为新的主数据库，保证在较短的时间内，继续为用户正常的提供服务，提升了用户体验。

在实际应用中，出现故障的原主数据库经过维修、升级等相关操作后，可为用户继续提供服务，因此本申请实施例的主备数据库的管理方法还包括，在原主数据库恢复后，接收原主数据库的锁请求，以将其切换为主数据库。

具体而言，在本示例中，在从备份数据库中选择一个作为新的主数据库之后，始终检测当前主数据库的锁的有效性和原主数据的锁请求，在当前主数据库锁失效时，再次从其他备份数据库中选择一个新的主数据库，或者在接收到原主数据库的锁请求后，由于原主数据库的优先级较高，将原主数据库切换为主数据库，将当前主数据库降级为备份数据库。

图4是根据本申请又一个实施例的主备数据库的管理方法的流程图，如图4所示，该主备数据库的管理方法包括：

s410，继续判断当前主数据库所持有的锁是否到期。

s420，如果当前主数据库所持有的锁已到期，则判断是否收到原主数据库、当前主数据库和其他备份数据库的锁请求。

s430，如果接收到原主数据库的锁请求，则将原主数据库恢复为主数据库，将当前数据库恢复为备份数据库。

具体而言，原主数据库在恢复正常后，发送锁请求，由于原主数据库的优先级较高，在接收到该锁请求后，则将原主数据库恢复为主数据库，将当前主数据库恢复为备份数据库。

s440，如果未接收到原主数据库的锁请求，且接收到当前主数据库和其他备份数据库的锁请求，则保持当前主数据库作为主数据库。

具体而言，在未接收到原主数据库的锁请求，且当前主数据库正常更新锁，则继续保持当前主数据库作为主数据库。

s450，如果未接收到原主数据库和当前主数据库的锁请求，且接收到其他备份数据库的锁请求，则从其他备份数据库中选择一个作为主数据库，并将当前主数据恢复为备份数据库。

具体而言，如果未接收到原主数据库和当前主数据库的锁请求，则表明原主数据库未回复正常，且当前的主数据库也出现故障或需要进行升级操作等，因而为了为用户正常提供服务，需从发送锁请求的其他备份数据库中选择一个作为主数据库，并将当前主数据恢复为备份数据库。

综上所述，本申请实施例的主备数据库的管理方法，在从备份数据库中选择一个作为新的主数据库后，继续判断当前主数据库是否接收到原主数据库的锁请求，以及当前主数据库是否进行锁的更新，当接收到原主数据库的锁请求，则将原主数据库恢复为当前主数据库，将当前主数据库恢复为备份数据库，如果没有接收到原主数据库的锁请求，则判断前主数据库是否有效进行锁的更新，如果没有，则从其他备份数据库中选择一个作为主数据库，并将当前主数据恢复为备份数据库。该方法保证了在原主数据库恢复后，将其恢复为主数据库，能够更好的为用户提供服务，提高了本申请主备数据库的管理方法的实用性。

为了实现上述实施例，本申请还提出了一种锁仲裁服务器。图5是根据本申请一个实施例的锁仲裁服务器的结构示意图。

如图5所示，该锁仲裁服务器包括：

第一判断模块510，用于判断主数据库所持有的锁是否到期，其中，主数据库和备份数据库共享锁。

第二判断模块520，用于在主数据库所持有的锁已到期时，判断是否接收到主数据库的续锁请求。

第一处理模块530，用于在未收到主数据库的续锁请求时，从备份数据库中选择一个作为新的主数据库，并控制主数据库切换为备份数据库。

具体而言，在实际应用中，为了保护主数据库的不变，避免其在没有发生故障或进行升级维护等操作时被切换为备份数据库，主数据库的优先级高于备份数据库的优先级，以保证在主数据库没有发生故障或进行升级维护等操作的前提下，持有锁的数据库是主数据库。

需要说明的是，上述主备数据库的部署方式有多种，比如可以是一主一备的部署方式，也可是一主多备的部署方式等。

为了便于描述，在本申请的实施例中，以主备数据库的部署方式为两地三中心为例进行描述，即备份数据库包括热备数据库和灾备数据库，其中，主数据库和热备数据库位于同一数据中心，主数据库和灾备数据库位于不同的数据中心。

进一步地，为了判断持有锁的主数据库是否有故障，判断其是否在有效期内延展其对锁持有的有效期。

具体而言，第一判断模块510判断主数据库持有的锁是否到期，如果判断主数据库所持有的锁已到期，第二判断模块520则判断是否接收到主数据库的续锁请求。

进而，如果未收到主数据库的续锁请求，则表明主数据库网络或者电力等故障，不能完成对锁的更新，从而为了正常为用户提供服务，第一处理模块530从备份数据库中选择一个作为新的主数据库，并控制主数据库切换为备份数据库。

其中，需要说明的是，根据具体应用场景的不同，第一处理模块530可采用不同的方式从备份数据库中选择一个作为主数据库。比如，备份数据库可按一定周期主动查询主数据库的锁到期时，是否发出续锁请求以延展其持有锁的有效性，如果没有，则备份数据库发出锁请求，以便能够迅速获取锁并切换成主数据库。

综上所述，本申请实施例的锁仲裁服务器，判断主数据库所持有的锁是否到期，如果判断主数据库持有的锁已经到期，则判断是否接收到主数据库的续锁请求，如果没有接收到续锁请求，则从备份数据库中选择一个新的主数据库，并控制主数据库切换为备份数据库。该锁仲裁服务器在主数据库在其持有的锁到期之前，没有发送续锁请求，则判断主数据库持有的锁失效，不能正常为用户提供服务，从而选择一个备份数据成为新的主数据库，提高了主备数据库的切换速率和准确率。

基于上述实施例，主备数据库管理方法中，主备数据库的切换方式可以分为主动切换和被动切换两种方式，具体说明如下：

作为一种示例，为了使得主数据库能够及时对锁进行更新，以及在主数据库发生故障时，其他备份数据库能够迅速获取锁，主数据库可在锁的更新周期内，以相对较短的周期发送查询锁的状态请求，从而在锁将要失效时及时对其更新，维持当前的主数据库的不变性。

同时，备份数据库以相对较长的周期主动发送查询锁的状态的锁请求，从而在主数据库的锁失效时，能够迅速获取锁，进而主动切换成为新的主数据库，不影响为用户提供服务。

举例而言，如果锁的更新周期为t1，主数据库以周期t2发送查询锁的状态的锁请求，备份数据库以周期t3发送查询锁的状态的锁请求，其中，t2小于t1，t3大于或等于t1。

作为另一种示例，如果备份数据库不是始终主动以一定的周期，发送查询锁的状态的锁请求，则在主数据库持有的锁失效时，主动向其他备份数据库发送锁到期通知，以便备份数据库根据锁到期通知发送锁请求，获取锁成为新的主数据库。

具体而言，图6是根据本申请一个具体实施例的锁仲裁服务器的结构示意图，如图6所示，在如图5所示的基础上，该锁仲裁服务器还包括：第一发送模块540和记录模块550。

具体而言，第一发送模块在第一判断模块510判断主数据库所有的锁已到期后，向备份数据库发送锁到期通知，进而记录模块550接收备份数据根据锁到期通知发送的锁请求，并记录锁请求的接收时间。

进而，如果未接收到主数据库的续锁请求，表明当前的数据库出现故障或在进行升级维护等，因此为了尽快正常为用户提供服务，第一处理模块530选择接收时间最早的备份数据库作为主数据库。

综上所述，本申请实施例的锁仲裁服务器，在主数据库的锁到期失效时，备份数据库迅速获取锁成为新的主数据库，保证在较短的时间内，继续为用户正常的提供服务，提升了用户体验。

在实际应用中，出现故障的原主数据库经过维修、升级等相关操作后，可为用户继续提供服务，因此本申请实施例的锁仲裁服务器还用于，在原主数据库恢复后，接收原主数据库的锁请求，以将其切换为主数据库。

图7是根据本申请另一个实施例的锁仲裁服务器的结构示意图。如图7所示，在如图5所示的基础上，该锁仲裁服务器还包括：第一接收模块560。具体而言，在本示例中，第一处理模块530在从备份数据库中选择一个作为新的主数据库之后，第一接收模块560始终接收原主数据的锁请求，在第一接收模块560接收到原主数据库的锁请求后，由于原主数据库的优先级较高，第一处理模块530将原主数据库切换为主数据库，将当前主数据库降级为备份数据库。

作为一种实现方式，图8是根据本申请又一个实施例的锁仲裁服务器的结构示意图。如图8所示，在如图5所示的基础上，该锁仲裁服务器还包括：第二处理模块570，第三处理模块580和第四处理模块590。

具体而言，在从备份数据库中选择一个作为新的主数据库之后，第一判断模块510继续判断当前主数据库所持有的锁是否到期，第二判断模块520在当前主数据库所持有的锁已到期，则判断是否收到原主数据库、当前主数据库和其他备份数据库的锁请求。

如果接收到原主数据库的锁请求，第二处理模块570则将原主数据库恢复为主数据库，将当前数据库恢复为备份数据库。

具体而言，原主数据库在恢复正常后，发送锁请求，由于原主数据库的优先级较高，在接收到该锁请求后，则将原主数据库恢复为主数据库，第二处理模块570将当前主数据库恢复为备份数据库。

如果未接收到原主数据库的锁请求，且接收到当前主数据库和其他备份数据库的锁请求，第三处理模块580则保持当前主数据库作为主数据库。

具体而言，在未接收到原主数据库的锁请求，且当前主数据库正常更新锁，第三处理模块580则继续保持当前主数据库作为主数据库。

如果未接收到原主数据库和当前主数据库的锁请求，且接收到其他备份数据库的锁请求，第四处理模块590则从其他备份数据库中选择一个作为主数据库，并将当前主数据恢复为备份数据库。

具体而言，如果未接收到原主数据库和当前主数据库的锁请求，则表明原主数据库未回复正常，且当前的主数据库也出现故障或需要进行升级操作等，因而为了为用户正常提供服务，第四处理模块590需从发送锁请求的其他备份数据库中选择一个作为主数据库，并将当前主数据恢复为备份数据库。

需要说明的是，本申请锁仲裁服务器中未披露的细节，参考上述结合附图1-4描述的主备数据库的管理方法的实施例，在此不再赘述。

综上所述，本申请实施例的锁仲裁服务器，在从备份数据库中选择一个作为新的主数据库后，继续判断当前主数据库是否接收到原主数据库的锁请求，以及当前主数据库是否进行锁的更新，当接收到原主数据库的锁请求，则将原主数据库恢复为当前主数据库，将当前主数据库恢复为备份数据库，如果没有接收到原主数据库的锁请求，则判断前主数据库是否有效进行锁的更新，如果没有，则从其他备份数据库中选择一个作为主数据库，并将当前主数据恢复为备份数据库。该锁仲裁服务器保证了在原主数据库恢复后，将其恢复为主数据库，能够更好的为用户提供服务，提高了本申请主备数据库的管理方法的实用性。

为了实现上述实施例，本申请还提出了一种主数据库服务器。

图9是根据本申请一个实施例的主数据库服务器的结构示意图，如图9所示，该主数据库服务器包括：

第二发送模块910，用于在持有的锁到期时，向锁仲裁服务器发送续锁请求，以便锁仲裁服务器未收到续锁请求时从备份数据库中选择一个作为新的主数据库。

切换模块920，用于控制主数据库切换为备份数据库。

具体而言，在实际应用中，为了保护主数据库的不变，避免其在没有发生故障或进行升级维护等操作时被切换为备份数据库，主数据库的优先级高于备份数据库的优先级，以保证在主数据库没有发生故障或进行升级维护等操作的前提下，持有锁的数据库是主数据库。

需要说明的是，上述主备数据库的部署方式有多种，比如可以是一主一备的部署方式，也可是一主多备的部署方式等。

为了便于描述，在本申请的实施例中，以主备数据库的部署方式为两地三中心为例进行描述，即备份数据库包括热备数据库和灾备数据库，其中，主数据库和热备数据库位于同一数据中心，主数据库和灾备数据库位于不同的数据中心。

具体而言，第二发送模块910在持有的锁到期时，向锁仲裁服务器发送锁请求，如果锁仲裁服务器未收到锁请求，则表示当前主数据库在进行升级更新或者故障等从而不能正常为用户提供服务器，从而锁仲裁服务器从备份数据库中选择一个作为新的主数据库，以为用户尽快提供正常服务，同时切换模块920控制主数据库切换为备份数据库。

其中，应当理解的是，为了使得主数据库能够及时对锁进行更新，以及在主数据库发生故障时，其他备份数据库能够迅速获取锁，主数据库可在锁的更新周期内，以相对较短的周期发送查询锁的状态请求，从而在锁将要失效时及时对其更新，维持当前的主数据库的不变性。

同时，备份数据库以相对较长的周期主动发送查询锁的状态的锁请求，从而在主数据库的锁失效时，能够迅速获取锁，进而主动切换成为新的主数据库，不影响为用户提供服务。

举例而言，如果锁的更新周期为t1，主数据库以周期t2发送查询锁的状态的锁请求，备份数据库以周期t3发送查询锁的状态的锁请求，其中，t2小于t1，t3大于或等于t1。

综上所述，根据本申请实施例的主数据服务器，在持有的锁到期时，向锁仲裁服务器发送续锁请求，以便锁仲裁服务器未接收到续锁请求时，从备份数据库中选择一个作为新的数据库，同时将主数据库切换为备份数据库。该主数据服务器在不能延展主数据库持有锁的有效期时，将主数据库切换为备份数据库，并选择一个备份数据成为新的主数据库，提高了主备数据库的切换速率和准确率，保证了数据库正常向用户提供服务，提升了用户体验。

在实际应用中，出现故障的原主数据库经过维修、升级等相关操作后，可为用户继续提供服务，因此本申请实施例的主备数据库服务器还用于，在原主数据库恢复后，接收原主数据库的锁请求，以将其切换为主数据库。

图10是根据本申请一个具体实施例的主数据库服务器的结构示意图，如图10所示，在如图9所示的基础上，该主数据服务器还包括：第三发送模块930。

具体而言，原主数据库在恢复正常后，通过第三发送模块930发送锁请求，由于原主数据库的优先级较高，在接收到该锁请求后，锁仲裁服务器接收原主数据库发送的锁请求，并在锁到期之后控制锁由原主数据库持有以使原主数据库恢复为主数据库，且当前主数据库恢复为备份数据库。

其中，需要强调的是，本申请主数据库服务器中未披露的细节，参照上述结合图1-图4对主备数据库的管理方法的描述，在此不再赘述。

综上所述，本申请实施例的主备数据库服务器，保证了在原主数据库恢复后，将其恢复为主数据库，能够更好的为用户提供服务，提升了用户体验。

为了实现上述实施例，本申请还提出了一种备份数据库服务器。图11是根据本申请一个实施例的备份数据库的结构示意图，如图11所示，该备份数据库包括：

第四发送模块1010，用于向锁仲裁服务器发送锁请求。

第二接收模块1020，用于接收锁仲裁服务器发送的锁确认消息。

第五处理模块1030，用于根据锁确认消息切换为新的主数据库。

可以理解，在实际应用中，为了保护主数据库的不变，避免其在没有发生故障或进行升级维护等操作时被切换为备份数据库，主数据库的优先级高于备份数据库的优先级，以保证在主数据库没有发生故障或进行升级维护等操作的前提下，持有锁的数据库是主数据库。然而当主数据库不能有效延展其持有锁的有效期时，锁仲裁服务器需要从备份数据库中选择一个作为主数据库继续为用户提供服务。

具体地，第四发送模块1010向锁仲裁服务器发送锁请求，以便于在主数据库不能有效更新锁时，迅速抢到锁，第二接收模块1020接收锁仲裁服务器发送的锁确认消息，从而第五处理模块1030根据锁的确认消息切换为主数据库。

需要说明的是，上述主备数据库的部署方式有多种，比如可以是一主一备的部署方式，也可是一主多备的部署方式等。

为了便于描述，在本申请的实施例中，以主备数据库的部署方式为两地三中心为例进行描述，即备份数据库包括热备数据库和灾备数据库，其中，主数据库和热备数据库位于同一数据中心，主数据库和灾备数据库位于不同的数据中心。

综上所述，本申请实施例的备份数据库服务器，向锁仲裁服务器发送锁请求，在判断主数据库持有的锁失效，不能正常为用户提供服务时，切换为新的主数据库，提高了主备数据库的切换速率和准确率，保证为用户正常提供服务，提升了用户体验。

基于以上实施例，如果备份数据库服务器不是始终主动以一定的周期，发送查询锁的状态的锁请求，则在主数据库持有的锁失效时，主动向其他备份数据库发送锁到期通知，以便备份数据库服务器根据锁到期通知发送锁请求，获取锁成为新的主数据库。

具体而言，图12是根据本申请一个具体实施例的备份数据库服务器的结构示意图，如图12所示，在如图11所示的基础上，该备份数据库服务器包括：第三接收模块1040。

具体地，第三接收模块1040接收锁仲裁服务器判断主数据库所持有的锁已到期之后发送的锁到期通知，其中，第四发送模块1010根据锁到期通知发送的锁请求向锁仲裁服务器发送锁请求。

进而，如果在锁到期时，所仲裁服务器未接收到主数据库的续锁请求，表明当前的数据库出现故障或在进行升级维护等，因此为了尽快正常为用户提供服务，锁仲裁服务器选择接收时间最早的备份数据库作为主数据库。

综上所述，本申请实施例的备份数据库服务器，在主数据库的锁到期失效时，备份数据库迅速获取锁成为新的主数据库，保证在较短的时间内，继续为用户正常的提供服务，提升了用户体验。

在实际应用中，出现故障的原主数据库经过维修、升级等相关操作后，可为用户继续提供服务，因此本申请实施例的备份数据服务器还用于，在原主数据库恢复后，切换为备份数据库。

图13是根据本申请另一个实施例的备份数据库服务器的结构示意图，如图13所示，在如图11所示的基础上，该备份数据库服务器包括：第六处理模块1050。

具体而言，原主数据库在恢复正常后，发送锁请求，由于原主数据库的优先级较高，锁仲裁服务器在接收到该锁请求后，则将原主数据库恢复为主数据库，第六处理模块1050则将当前主数据库恢复为备份数据库。

应当理解的是，本申请实施例的备份数据库服务器中未披露的细节，参照以上结合图1-图4描述的主备数据库的管理方法的实施例，在此不再赘述。

综上所述，本申请实施例的备份数据库服务器，在原主数据库恢复后，将其恢复为备份数据库，并且仲裁服务器将原主数据库恢复为主数据库，能够更好的为用户提供服务，提升了用户体验。

为了实现上述实施例，本申请还提出了一种主备数据库的管理系统，图14是根据本申请一个实施例的主备数据库的管理系统的结构示意图，如图14所示，该主备数据库的管理系统包括：锁仲裁服务器1000，主数据库服务器2000和备份数据库服务器3000。

需要说明的是，本申请中对锁仲裁服务器1000，主数据库服务器2000和备份数据库服务器3000的描述，参照上述对锁仲裁服务器，主数据库服务器和备份数据库服务器的描述，在此不再赘述。

综上所述，本申请实施例的主备数据库的管理系统，判断主数据库所持有的锁是否到期，如果判断主数据库持有的锁已经到期，则判断是否接收到主数据库的续锁请求，如果没有接收到续锁请求，则从备份数据库中选择一个新的主数据库，并控制主数据库切换为备份数据库。该系统在主数据库在其持有的锁到期之前，没有发送续锁请求，则判断主数据库持有的锁失效，不能正常为用户提供服务，从而选择一个备份数据成为新的主数据库，提高了主备数据库的切换速率和准确率。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本申请的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。