CN107066480A - 主备数据库的管理方法、系统及其设备 - Google Patents

主备数据库的管理方法、系统及其设备 Download PDF

Info

Publication number
CN107066480A
CN107066480A CN201611183638.9A CN201611183638A CN107066480A CN 107066480 A CN107066480 A CN 107066480A CN 201611183638 A CN201611183638 A CN 201611183638A CN 107066480 A CN107066480 A CN 107066480A
Authority
CN
China
Prior art keywords
database
lock
primary database
backup
primary
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
Application number
CN201611183638.9A
Other languages
English (en)
Other versions
CN107066480B (zh
Inventor
阳振坤
黄贵
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Oceanbase Technology Co Ltd
Original Assignee
Alibaba Group Holding Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alibaba Group Holding Ltd filed Critical Alibaba Group Holding Ltd
Priority to CN201611183638.9A priority Critical patent/CN107066480B/zh
Publication of CN107066480A publication Critical patent/CN107066480A/zh
Priority to TW106130943A priority patent/TWI677797B/zh
Priority to JP2019533442A priority patent/JP6905161B2/ja
Priority to EP17884001.3A priority patent/EP3561694B1/en
Priority to PCT/CN2017/115392 priority patent/WO2018113543A1/zh
Priority to KR1020197021325A priority patent/KR102142233B1/ko
Priority to SG10202012899PA priority patent/SG10202012899PA/en
Priority to SG10201913120SA priority patent/SG10201913120SA/en
Priority to US16/394,315 priority patent/US10592361B2/en
Priority to PH12019501392A priority patent/PH12019501392A1/en
Application granted granted Critical
Publication of CN107066480B publication Critical patent/CN107066480B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

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/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/2041—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 with more than one idle spare processing component
    • 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/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/142—Reconfiguring to eliminate the error
    • 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
    • G06F11/2025—Failover techniques using centralised failover control functionality
    • 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
    • G06F11/2028—Failover techniques eliminating a faulty processor or activating a spare
    • 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
    • G06F11/2033—Failover techniques switching over of hardware resources
    • 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/2043—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 where the redundant components share a common memory address space
    • 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/23—Updating
    • G06F16/2308—Concurrency control
    • G06F16/2336—Pessimistic concurrency control approaches, e.g. locking or multiple versions without time stamps
    • G06F16/2343—Locking methods, e.g. distributed locking or locking implementation details
    • 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
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/80—Database-specific techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/825—Indexing scheme relating to error detection, to error correction, and to monitoring the problem or solution involving locking

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Quality & Reliability (AREA)
  • Data Mining & Analysis (AREA)
  • Computing Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Hardware Redundancy (AREA)

Abstract

本申请提出一种主备数据库的管理方法、系统及其设备，其中，方法包括：判断主数据库所持有的锁是否到期，其中，主数据库和备份数据库共享锁；如果判断主数据库所持有的锁已到期，则判断是否接收到主数据库的续锁请求；如果未收到所述主数据库的续锁请求，则从备份数据库中选择一个作为新的主数据库，并控制主数据库切换为备份数据库。该方法在主数据库在其持有的锁到期之前，没有发送续锁请求，则判断主数据库持有的锁失效，不能正常为用户提供服务，从而选择一个备份数据成为新的主数据库，提高了主备数据库的切换速率和准确率。

Description

主备数据库的管理方法、系统及其设备
技术领域
本申请涉及信息安全技术领域，尤其涉及一种主备数据库的管理方法、系统及其设备。
背景技术
数据库是金融、商业、交通等领域乃至整个社会的关键基础设施，数据库的持续可用是金融、商业等领域可持续向用户正常进行服务的保障。为了避免单个数据库发生故障，提升数据库的可用性，数据库通常会采用主备配置，当主数据库故障的时候，切换到备份数据库继续进行服务。
相关技术中，主备数据库可采用自动切换的方式进行切换，即对主数据库部署监控系统，一旦发现主数据路异常即发出警报并同时发出命令进行主备数据库的切换。
然而，上述主备数据库的切换方式中，可能会因为误判而导致主数据库在没有出现故障的时候发生切换，或者主数据库发生了故障却没有进行切换，从而导致影响了为用户正常提供服务。
发明内容
本申请的目的旨在至少在一定程度上解决上述的技术问题之一。
为此，本申请的第一个目的在于提出一种主备数据库的管理方法，该方法在主数据库在其持有的锁到期之前，没有发送续锁请求，则判断主数据库持有的锁失效，不能正常为用户提供服务，从而选择一个备份数据成为新的主数据库，提高了主备数据库的切换速率和准确率。
本申请的第二个目的在于提出一种锁仲裁服务器。
本申请的第三个目的在于提出一种主数据库服务器。
本申请的第四个目的在于提出一种备份数据库服务器。
本申请的第五个目的在于提出一种主备数据库的管理系统。
为达上述目的，本申请第一方面实施例的主备数据库的管理方法包括：判断主数据库所持有的锁是否到期，其中，所述主数据库和备份数据库共享所述锁；如果判断所述主数据库所持有的锁已到期，则判断是否接收到所述主数据库的续锁请求；如果未收到所述主数据库的续锁请求，则从所述备份数据库中选择一个作为新的主数据库，并控制所述主数据库切换为备份数据库。
本申请实施例的主备数据库的管理方法，判断主数据库所持有的锁是否到期，如果判断主数据库持有的锁已经到期，则判断是否接收到主数据库的续锁请求，如果没有接收到续锁请求，则从备份数据库中选择一个新的主数据库，并控制主数据库切换为备份数据库。该方法在主数据库在其持有的锁到期之前，没有发送续锁请求，则判断主数据库持有的锁失效，不能正常为用户提供服务，从而选择一个备份数据成为新的主数据库，提高了主备数据库的切换速率和准确率。
另外，本申请实施例的主备数据库的管理方法还具有如下附加的技术特征：
在本申请的一个实施例中，在判断所述主数据库所持有的锁已到期之后，还包括：向所述备份数据库发送锁到期通知；接收所述备份数据根据所述锁到
期通知发送的锁请求，并记录所述锁请求的接收时间。
在本申请的一个实施例中，所述从所述备份数据库中选择一个作为主数据库还用于：选择接收时间最早的备份数据库作为所述主数据库。
在本申请的一个实施例中，所述主数据库的优先级高于所述备份数据库的优先级。
在本申请的一个实施例中，所述锁的更新周期为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的描述，参照上述对锁仲裁服务器，主数据库服务器和备份数据库服务器的描述，在此不再赘述。
综上所述，本申请实施例的主备数据库的管理系统，判断主数据库所持有的锁是否到期，如果判断主数据库持有的锁已经到期，则判断是否接收到主数据库的续锁请求，如果没有接收到续锁请求，则从备份数据库中选择一个新的主数据库，并控制主数据库切换为备份数据库。该系统在主数据库在其持有的锁到期之前，没有发送续锁请求，则判断主数据库持有的锁失效，不能正常为用户提供服务，从而选择一个备份数据成为新的主数据库，提高了主备数据库的切换速率和准确率。
此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本申请的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。
在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (27)

1.一种主备数据库的管理方法，其特征在于，包括以下步骤：
判断主数据库所持有的锁是否到期，其中，所述主数据库和备份数据库共享所述锁；
如果判断所述主数据库所持有的锁已到期，则判断是否接收到所述主数据库的续锁请求；
如果未收到所述主数据库的续锁请求，则从所述备份数据库中选择一个作为新的主数据库，并控制所述主数据库切换为备份数据库。
2.如权利要求1所述的主备数据库的管理方法，其特征在于，在判断所述主数据库所持有的锁已到期之后，还包括：
向所述备份数据库发送锁到期通知；
接收所述备份数据根据所述锁到期通知发送的锁请求，并记录所述锁请求的接收时间。
3.如权利要求2所述的主备数据库的管理方法，其特征在于，所述从所述备份数据库中选择一个作为主数据库具体包括：
选择接收时间最早的备份数据库作为所述主数据库。
4.如权利要求1所述的主备数据库的管理方法，其特征在于，所述主数据库的优先级高于所述备份数据库的优先级。
5.如权利要求1所述的主备数据库的管理方法，其特征在于，所述锁的更新周期为T1，所述主数据库以周期T2发送查询所述锁的状态的锁请求，所述备份数据库以周期T3发送查询所述锁的状态的锁请求，其中，T2小于T1，T3大于或等于T1。
6.如权利要求1所述的主备数据库的管理方法，其特征在于，所述备份数据库包括热备数据库和灾备数据库，其中，所述主数据库和所述热备数据库位于同一数据中心，所述主数据库和所述灾备数据库位于不同的数据中心。
7.如权利要求4或5所述的主备数据库的管理方法，其特征在于，在原主数据库恢复之后，还包括：
接收所述原主数据库发送的锁请求，并在所述锁到期之后控制所述锁由所述原主数据库持有以使所述原主数据库恢复为主数据库，且当前主数据库恢复为备份数据库。
8.如权利要求1所述的主备数据库的管理方法，其特征在于，在从所述备份数据库中选择一个作为新的主数据库之后，还包括：
继续判断当前主数据库所持有的锁是否到期；
如果所述当前主数据库所持有的锁已到期，则判断是否收到原主数据库、所述当前主数据库和其他备份数据库的锁请求；
如果接收到所述原主数据库的锁请求，则将所述原主数据库恢复为主数据库，将所述当前数据库恢复为备份数据库；
如果未接收到所述原主数据库的锁请求，且接收到所述当前主数据库和其他备份数据库的锁请求，则保持所述当前主数据库作为主数据库；
如果未接收到所述原主数据库和所述当前主数据库的锁请求，且接收到其他备份数据库的锁请求，则从所述其他备份数据库中选择一个作为主数据库，并将所述当前主数据恢复为备份数据库。
9.一种锁仲裁服务器，其特征在于，包括：
第一判断模块，用于判断主数据库所持有的锁是否到期，其中，所述主数据库和备份数据库共享所述锁；
第二判断模块，用于在所述主数据库所持有的锁已到期时，判断是否接收到所述主数据库的续锁请求；
第一处理模块，用于在未收到所述主数据库的续锁请求时，从所述备份数据库中选择一个作为新的主数据库，并控制所述主数据库切换为备份数据库。
10.如权利要求9所述的锁仲裁服务器，其特征在于，还包括：
第一发送模块，用于在所述第一判断模块判断所述主数据库所有的锁已到期后，向所述备份数据库发送锁到期通知；
记录模块，用于接收所述备份数据根据所述锁到期通知发送的锁请求，并记录所述锁请求的接收时间。
11.如权利要求10所述的锁仲裁服务器，其特征在于，所述第一处理模块，还用于：
选择接收时间最早的备份数据库作为所述主数据库。
12.如权利要求9所述的锁仲裁服务器，其特征在于，所述主数据库的优先级高于所述备份数据库的优先级。
13.如权利要求9所述的锁仲裁服务器，其特征在于，
所述锁的更新周期为T1，其中，所述主数据库以周期T2发送查询所述锁的状态的锁请求，所述备份数据库以周期T3发送查询所述锁的状态的锁请求，其中，T2小于T1，T3大于或等于T1。
14.如权利要求9所述的锁仲裁服务器，其特征在于，
所述备份数据库包括热备数据库和灾备数据库，其中，所述主数据库和所述热备数据库位于同一数据中心，所述主数据库和所述灾备数据库位于不同的数据中心。
15.如权利要求12或13所述的锁仲裁服务器，其特征在于，还包括：
第一接收模块，用于在原主数据库恢复之后，接收所述原主数据库发送的锁请求；
所述第一处理模块，还用于在所述锁到期之后控制所述锁由所述原主数据库持有以使所述原主数据库恢复为主数据库，且当前主数据库恢复为备份数据库。
16.如权利要求9所述的锁仲裁服务器，其特征在于：
所述第一判断模块，还用于继续判断当前主数据库所持有的锁是否到期；
所述第二判断模块，还用于在所述当前主数据库所持有的锁已到期时，判断是否收到原主数据库、所述当前主数据库和其他备份数据库的锁请求；
第二处理模块，用于在接收到所述原主数据库的锁请求时，将所述原主数据库恢复为主数据库，将所述当前数据库恢复为备份数据库；
第三处理模块，用于在未接收到所述原主数据库的锁请求，且接收到所述当前主数据库和其他备份数据库的锁请求时，保持所述当前主数据库作为主数据库；
第四处理模块，用于在未接收到所述原主数据库和所述当前主数据库的锁请求，且接收到其他备份数据库的锁请求时，从所述其他备份数据库中选择一个作为主数据库，并将所述当前主数据恢复为备份数据库。
17.一种主数据库服务器，其特征在于，包括：
第二发送模块，用于在持有的锁到期时，向锁仲裁服务器发送续锁请求，以便所述锁仲裁服务器未收到所述续锁请求时从备份数据库中选择一个作为新的主数据库；
切换模块，用于控制所述主数据库切换为备份数据库。
18.如权利要求17所述的主数据库服务器，其特征在于，所述主数据库的优先级高于所述备份数据库的优先级。
19.如权利要求17所述的主数据库服务器，其特征在于，所述锁的更新周期为T1，其中，所述主数据库服务器以周期T2发送查询所述锁的状态的锁请求，所述备份数据库以周期T3发送查询所述锁的状态的锁请求，其中，T2小于T1，T3大于或等于T1。
20.如权利要求17所述的主数据库服务器，其特征在于，
所述备份数据库包括热备数据库和灾备数据库，其中，所述主数据库和所述热备数据库位于同一数据中心，所述主数据库和所述灾备数据库位于不同的数据中心。
21.如权利要求18或19所述的主数据库服务器，其特征在于，所述主数据库服务器还包括：
第三发送模块，用于在原主数据库恢复之后，向所述锁仲裁服务器发送锁请求，以便所述锁仲裁服务器接收所述原主数据库发送的锁请求，并在所述锁到期之后控制所述锁由所述原主数据库持有以使所述原主数据库恢复为主数据库，且当前主数据库恢复为备份数据库。
22.一种备份数据库服务器，其特征在于，包括：
第四发送模块，用于向锁仲裁服务器发送锁请求；
第二接收模块，用于接收所述锁仲裁服务器发送的锁确认消息；
第五处理模块，用于根据所述锁确认消息切换为新的主数据库。
23.如权利要求22所述的备份数据库服务器，其特征在于，包括：
第三接收模块，用于接收所述锁仲裁服务器判断所述主数据库所持有的锁已到期之后发送的锁到期通知，其中，所述第四发送模块根据所述锁到期通知发送的锁请求向所述锁仲裁服务器发送锁请求。
24.如权利要求22所述的备份数据库服务器，其特征在于，
所述主数据库的优先级高于所述备份数据库的优先级。
25.如权利要求22所述的备份数据库服务器，其特征在于，
所述备份数据库包括热备数据库和灾备数据库，其中，所述主数据库和所述热备数据库位于同一数据中心，所述主数据库和所述灾备数据库位于不同的数据中心。
26.如权利要求24所述的备份数据库服务器，其特征在于，还包括：
第六处理模块，用于在所述锁仲裁服务器接收所述原主数据库发送的锁请求，并在所述锁到期之后控制所述锁由所述原主数据库持有以使所述原主数据库恢复为主数据库后，控制当前主数据库恢复为备份数据库。
27.一种主备数据库的管理系统，其特征在于，包括：
如权利要求9-16任一项所述的锁仲裁服务器；
如权利要求17-21任一项权利要求所述的主数据库服务器；如权利要求22-26任一项所述的备份数据库服务器。
CN201611183638.9A 2016-12-20 2016-12-20 主备数据库的管理方法、系统及其设备 Active CN107066480B (zh)

Priority Applications (10)

Application Number Priority Date Filing Date Title
CN201611183638.9A CN107066480B (zh) 2016-12-20 2016-12-20 主备数据库的管理方法、系统及其设备
TW106130943A TWI677797B (zh) 2016-12-20 2017-09-11 主備資料庫的管理方法、系統及其設備
JP2019533442A JP6905161B2 (ja) 2016-12-20 2017-12-11 マスタおよびスタンバイデータベースのための管理方法、システム、およびデバイス
EP17884001.3A EP3561694B1 (en) 2016-12-20 2017-12-11 Management method, system, and device for master and standby databases
PCT/CN2017/115392 WO2018113543A1 (zh) 2016-12-20 2017-12-11 主备数据库的管理方法、系统及其设备
KR1020197021325A KR102142233B1 (ko) 2016-12-20 2017-12-11 기본 및 보조 데이터베이스를 관리하기 위한 방법, 시스템 및 장치
SG10202012899PA SG10202012899PA (en) 2016-12-20 2017-12-11 Method, system and apparatus for managing primary and secondary databases
SG10201913120SA SG10201913120SA (en) 2016-12-20 2017-12-11 Method, system and apparatus for managing primary and secondary databases
US16/394,315 US10592361B2 (en) 2016-12-20 2019-04-25 Method, system and apparatus for managing primary and secondary databases
PH12019501392A PH12019501392A1 (en) 2016-12-20 2019-06-18 Method, system and apparatus for managing primary and secondary databases

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201611183638.9A CN107066480B (zh) 2016-12-20 2016-12-20 主备数据库的管理方法、系统及其设备

Publications (2)

Publication Number Publication Date
CN107066480A true CN107066480A (zh) 2017-08-18
CN107066480B CN107066480B (zh) 2020-08-11

Family

ID=59619184

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201611183638.9A Active CN107066480B (zh) 2016-12-20 2016-12-20 主备数据库的管理方法、系统及其设备

Country Status (9)

Country Link
US (1) US10592361B2 (zh)
EP (1) EP3561694B1 (zh)
JP (1) JP6905161B2 (zh)
KR (1) KR102142233B1 (zh)
CN (1) CN107066480B (zh)
PH (1) PH12019501392A1 (zh)
SG (2) SG10201913120SA (zh)
TW (1) TWI677797B (zh)
WO (1) WO2018113543A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018113543A1 (zh) * 2016-12-20 2018-06-28 阿里巴巴集团控股有限公司 主备数据库的管理方法、系统及其设备
CN110442650A (zh) * 2019-08-09 2019-11-12 中国工商银行股份有限公司 数据库切换方法、装置、系统、电子设备及存储介质
CN111159156A (zh) * 2019-12-31 2020-05-15 杭州迪普科技股份有限公司 SQLite数据库的备份方法和装置

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10999392B2 (en) 2019-03-01 2021-05-04 Accenture Global Solutions Limited Message recovery system for computing nodes with replicated databases
CN110765143B (zh) * 2019-10-10 2022-08-02 腾讯科技（深圳）有限公司 数据处理方法、装置、服务器和存储介质
US11379477B2 (en) 2020-03-31 2022-07-05 Sap Se Efficient workload balancing in replicated databases based on result lag computation

Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1851657A (zh) * 2005-07-21 2006-10-25 上海华为技术有限公司 一种双机备份实现方法及系统
CN101038591A (zh) * 2007-04-11 2007-09-19 华为技术有限公司 数据库同步方法及系统
US7496701B2 (en) * 2004-11-18 2009-02-24 International Business Machines Corporation Managing virtual server control of computer support systems with heartbeat message
US20110137879A1 (en) * 2009-12-07 2011-06-09 Saurabh Dubey Distributed lock administration
CN102739451A (zh) * 2012-06-29 2012-10-17 华为技术有限公司 一种主备切换条件更新方法、装置、服务器及系统
CN102945195A (zh) * 2012-11-26 2013-02-27 国电南瑞科技股份有限公司 一种基于SQLite数据库的主备冗余复制方法
US20140244581A1 (en) * 2012-01-17 2014-08-28 Amazon Technologies, Inc. System and method for log conflict detection and resolution in a data store
US20150339200A1 (en) * 2014-05-20 2015-11-26 Cohesity, Inc. Intelligent disaster recovery
US9274902B1 (en) * 2013-08-07 2016-03-01 Amazon Technologies, Inc. Distributed computing fault management
US9348883B2 (en) * 2011-06-01 2016-05-24 Clustrix, Inc. Systems and methods for replication replay in a relational database
CN105933379A (zh) * 2016-04-01 2016-09-07 浪潮电子信息产业股份有限公司 一种业务处理方法、设备及系统

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040003317A1 (en) * 2002-06-27 2004-01-01 Atul Kwatra Method and apparatus for implementing fault detection and correction in a computer system that requires high reliability and system manageability
US7254736B2 (en) * 2002-12-18 2007-08-07 Veritas Operating Corporation Systems and method providing input/output fencing in shared storage environments
US7284151B2 (en) * 2003-07-21 2007-10-16 Oracle International Corporation Conditional data access after database system failure
TWI306241B (en) * 2004-07-12 2009-02-11 Infortrend Technology Inc A controller capable of self-monitoring, a redundant storage system having the same, and its method
US8984328B2 (en) * 2011-03-11 2015-03-17 Microsoft Technology Licensing, Llc Fault tolerance in a parallel database system
CN102831038B (zh) * 2011-06-17 2019-03-01 中兴通讯股份有限公司 Enum-dns的容灾方法及enum-dns
US9116862B1 (en) * 2012-01-17 2015-08-25 Amazon Technologies, Inc. System and method for data replication using a single master failover protocol
CN102891849B (zh) * 2012-09-25 2015-07-22 北京星网锐捷网络技术有限公司 业务数据同步方法、恢复方法及装置和网络设备
US9009444B1 (en) * 2012-09-29 2015-04-14 Emc Corporation System and method for LUN control management
US9667490B1 (en) * 2013-06-05 2017-05-30 Parallels IP Holdings GmbH Method for high availability of services in cloud computing systems
CN103593266B (zh) * 2013-11-12 2016-06-22 浪潮(北京)电子信息产业有限公司 一种基于仲裁盘机制的双机热备方法
TWI529624B (zh) * 2015-03-19 2016-04-11 Univ Nat Central Method and system of fault tolerance for multiple servers
CN104778102A (zh) * 2015-03-27 2015-07-15 深圳市创梦天地科技有限公司 一种主备切换方法及系统
CN106202075B (zh) * 2015-04-29 2021-02-19 中兴通讯股份有限公司 一种数据库主备切换的方法及装置
CN107066480B (zh) * 2016-12-20 2020-08-11 创新先进技术有限公司 主备数据库的管理方法、系统及其设备

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7496701B2 (en) * 2004-11-18 2009-02-24 International Business Machines Corporation Managing virtual server control of computer support systems with heartbeat message
CN1851657A (zh) * 2005-07-21 2006-10-25 上海华为技术有限公司 一种双机备份实现方法及系统
CN101038591A (zh) * 2007-04-11 2007-09-19 华为技术有限公司 数据库同步方法及系统
US20110137879A1 (en) * 2009-12-07 2011-06-09 Saurabh Dubey Distributed lock administration
US9348883B2 (en) * 2011-06-01 2016-05-24 Clustrix, Inc. Systems and methods for replication replay in a relational database
US20140244581A1 (en) * 2012-01-17 2014-08-28 Amazon Technologies, Inc. System and method for log conflict detection and resolution in a data store
CN102739451A (zh) * 2012-06-29 2012-10-17 华为技术有限公司 一种主备切换条件更新方法、装置、服务器及系统
CN102945195A (zh) * 2012-11-26 2013-02-27 国电南瑞科技股份有限公司 一种基于SQLite数据库的主备冗余复制方法
US9274902B1 (en) * 2013-08-07 2016-03-01 Amazon Technologies, Inc. Distributed computing fault management
US20150339200A1 (en) * 2014-05-20 2015-11-26 Cohesity, Inc. Intelligent disaster recovery
CN105933379A (zh) * 2016-04-01 2016-09-07 浪潮电子信息产业股份有限公司 一种业务处理方法、设备及系统

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018113543A1 (zh) * 2016-12-20 2018-06-28 阿里巴巴集团控股有限公司 主备数据库的管理方法、系统及其设备
US10592361B2 (en) 2016-12-20 2020-03-17 Alibaba Group Holding Limited Method, system and apparatus for managing primary and secondary databases
CN110442650A (zh) * 2019-08-09 2019-11-12 中国工商银行股份有限公司 数据库切换方法、装置、系统、电子设备及存储介质
CN111159156A (zh) * 2019-12-31 2020-05-15 杭州迪普科技股份有限公司 SQLite数据库的备份方法和装置
CN111159156B (zh) * 2019-12-31 2023-04-28 杭州迪普科技股份有限公司 SQLite数据库的备份方法和装置

Also Published As

Publication number Publication date
TWI677797B (zh) 2019-11-21
CN107066480B (zh) 2020-08-11
JP6905161B2 (ja) 2021-07-21
SG10202012899PA (en) 2021-01-28
SG10201913120SA (en) 2020-03-30
US10592361B2 (en) 2020-03-17
US20190251008A1 (en) 2019-08-15
WO2018113543A1 (zh) 2018-06-28
EP3561694A1 (en) 2019-10-30
KR102142233B1 (ko) 2020-08-07
EP3561694B1 (en) 2022-06-22
JP2020502686A (ja) 2020-01-23
PH12019501392A1 (en) 2020-02-10
TW201824030A (zh) 2018-07-01
EP3561694A4 (en) 2019-12-18
KR20190095443A (ko) 2019-08-14

Similar Documents

Publication Publication Date Title
CN107066480A (zh) 主备数据库的管理方法、系统及其设备
US7350098B2 (en) Detecting events of interest for managing components on a high availability framework
CN101076736B (zh) 在监督处理控制系统中配置冗余的设备和方法
CN106254100A (zh) 一种数据容灾方法、装置和系统
CN106357787A (zh) 一种存储容灾控制系统
CN106170971A (zh) 一种集群脑裂后仲裁处理方法、仲裁存储装置以及系统
CN109474465A (zh) 一种基于服务器集群的可动态流转的高可用性的实现方法和系统
CN104243527A (zh) 数据同步方法、数据同步装置及分布式系统
CN104718536B (zh) 网络存储系统中的非破坏性控制器更换
CN104813609A (zh) 具有多个服务器节点的物理安全系统
CN110990200B (zh) 一种基于多活数据中心的流量切换方法及装置
CN102467508A (zh) 提供数据库服务的方法及数据库系统
CN110417600B (zh) 分布式系统的节点切换方法、装置及计算机存储介质
CN105141400A (zh) 一种高可用性集群管理方法及相关设备
CN109743344B (zh) 基于轨道交通的综合监控系统的事件存储方法及其设备
CN109726046A (zh) 机房切换方法及切换装置
CN104765889A (zh) 基于数据库高可用框架的切换方法及装置
CN109428740A (zh) 设备故障恢复的方法和装置
CN110442650A (zh) 数据库切换方法、装置、系统、电子设备及存储介质
CN105915426A (zh) 环形网络的故障恢复方法及装置
CN108173971A (zh) 一种基于主备切换的MooseFS高可用方法及系统
CN111988347B (zh) 跳板机系统的数据处理方法和跳板机系统
CN108509296B (zh) 一种处理设备故障的方法和系统
CN106533751A (zh) 一种sdn控制器集群合并方法及装置
CN113890850B (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
TA01 Transfer of patent application right
TA01 Transfer of patent application right

Effective date of registration: 20191211

Address after: P.O. Box 31119, grand exhibition hall, hibiscus street, 802 West Bay Road, Grand Cayman, Cayman Islands

Applicant after: Innovative advanced technology Co., Ltd

Address before: A four-storey 847 mailbox in Grand Cayman Capital Building, British Cayman Islands

Applicant before: Alibaba Group Holding Co., Ltd.

GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20210209

Address after: 801-10, Section B, 8th floor, 556 Xixi Road, Xihu District, Hangzhou City, Zhejiang Province 310000

Patentee after: Ant financial (Hangzhou) Network Technology Co.,Ltd.

Address before: Ky1-1205 P.O. Box 31119, hibiscus street, 802 Sai Wan Road, Grand Cayman Islands, ky1-1205

Patentee before: Innovative advanced technology Co.,Ltd.

TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20210914

Address after: 100020 unit 02, 901, floor 9, unit 1, building 1, No.1, East Third Ring Middle Road, Chaoyang District, Beijing

Patentee after: Beijing Aoxing Beisi Technology Co., Ltd

Address before: 801-10, Section B, 8th floor, 556 Xixi Road, Xihu District, Hangzhou City, Zhejiang Province 310000

Patentee before: Ant financial (Hangzhou) Network Technology Co.,Ltd.