WO2012071920A1 - 分布式内存数据库的实现方法、系统、令牌控制器及内存数据库 - Google Patents

分布式内存数据库的实现方法、系统、令牌控制器及内存数据库 Download PDF

Info

Publication number
WO2012071920A1
WO2012071920A1 PCT/CN2011/079418 CN2011079418W WO2012071920A1 WO 2012071920 A1 WO2012071920 A1 WO 2012071920A1 CN 2011079418 W CN2011079418 W CN 2011079418W WO 2012071920 A1 WO2012071920 A1 WO 2012071920A1
Authority
WO
WIPO (PCT)
Prior art keywords
memory database
mmdb
information
site
cluster
Prior art date
Application number
PCT/CN2011/079418
Other languages
English (en)
French (fr)
Inventor
查峰
何沁
Original Assignee
华为技术有限公司
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 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP11845808.2A priority Critical patent/EP2648114B1/en
Publication of WO2012071920A1 publication Critical patent/WO2012071920A1/zh
Priority to US13/866,467 priority patent/US20130238676A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25Integrating or interfacing systems involving database management systems

Definitions

  • the present invention relates to communication technologies, and in particular, to a method, a system, a token controller and an in-memory database for implementing a distributed in-memory database. Background technique
  • MMDB Main Memory Database
  • MMDB Main Memory Database
  • two token controllers are deployed on two devices, one master token controller works, and the other standby token controller idles on two devices. Both are equipped with dual-machine control software, and the two token controllers are displayed as a floating IP.
  • the two token controllers are displayed as a floating IP.
  • the standby token controller can take over the work of the primary token controller through the switching function of the dual-machine control software, and still present to the MMDB as a floating IP. So for MMDB, there is still a command in the cluster. — The card controller does not feel the switchover of the active and standby token controllers.
  • the embodiment of the invention provides a method, a system, a token controller and an MMDB for implementing a distributed MMDB, which can improve the reliability of the distributed MMDB.
  • a method for implementing a distributed MMDB comprising:
  • MMDB list includes intra-cluster information organized according to at least one of the node MMDB information
  • Transaction within the cluster is processed according to intra-cluster information in the MMDB list.
  • a method for implementing a distributed MMDB comprising:
  • an MMDB list Obtaining, according to the node MMDB information, an MMDB list, where the MMDB list includes intra-cluster information organized according to at least one of the node MMDB information;
  • a message containing the list of MMDBs is sent to the at least one MMDB such that the at least one MMDB processes transactions within the cluster based on intra-cluster information in the MMDB list.
  • An in-memory database including: - a sending module, configured to send a message including node MMDB information to at least two token controllers; a receiving module, configured to respectively receive a message including a list of MMDBs from the at least two token controllers, where The MMDB list includes intra-cluster information organized according to at least one of the node MMDB information;
  • a processing module configured to process a transaction in the cluster according to the information in the cluster in the MMDB list.
  • a token controller comprising:
  • a receiving module configured to receive, by the at least one MMDB, a message that includes node memory data information
  • An obtaining module configured to obtain an MMDB list according to the node MMDB information, where the
  • the MMDB list includes intra-cluster information organized according to at least one of the node MMDB information; a sending module, configured to send a message including the MMDB list to the at least one MMDB, so that the at least one MMDB is configured according to the MMDB
  • the intra-cluster information processes the transactions within the cluster.
  • a distributed MMDB system comprising: at least two token controllers and at least one MMDB; the MMDB, configured to send a message including node MMDB information to the at least two token controllers, and receive the respective a message including an MMDB list of at least two token controllers, where the MMDB list includes intra-cluster information organized according to at least one of the node MMDB information, storing the internal test data list, and according to the MMDB The intra-cluster information in the list processes the transactions within the cluster;
  • the token controller is configured to receive a message including the node memory data information of the MMDB, and obtain an MMDB list according to the node MMDB information, and then include the MMDB list. – A message is sent to the at least one MMDB.
  • a site system includes at least: a first site and a second site,
  • a token controller in the first site configured to receive, by the token controller of the second site, a message including the primary in-memory database information of the second site, and according to the primary in-memory database information of the second site Obtaining, in the intra-cluster information of the first site, the in-memory database list of the first site, and sending the in-memory database list of the first site to the in-memory database of the first site;
  • An in-memory database in the first site configured to send a message including node memory database information to a token controller of the first site, and obtain memory of the first site from a token controller of the first site a database list, and processing a transaction between the first site according to the in-memory database list, or a transaction between the first site and the second site;
  • the in-memory database list includes: as a slave in-memory database The primary in-memory database information of the second site joined to the first site, and the intra-cluster information of the first site organized according to the node in-memory database information.
  • the MMDB is not required to be controlled by the dual-machine software, and the active/standby dual-machine solution is not required.
  • Each MMDB can obtain the MMDB list through interaction with the token controller, and process the intra-cluster according to the MMDB list.
  • the transaction avoids the delay problem caused by processing transactions such as the active/standby switchover, reduces the execution complexity, eliminates the need for idle spare devices, reduces the purchase cost, and improves the reliability of the distributed MMDB.
  • FIG. 1 is a schematic flowchart of a method for implementing a distributed MMDB according to an embodiment of the present invention
  • FIG. 2 is a schematic diagram of a scenario when an MMDB logs in or keeps a heartbeat or exits an MMDB cluster according to an embodiment of the present invention
  • FIG. 3 is a schematic flowchart of a method for implementing a distributed MMDB when an MMDB is logged in according to an embodiment of the present invention
  • FIG. 4 is a schematic flowchart of a method for implementing a distributed MMDB when an MMDB maintains a heartbeat according to an embodiment of the present invention
  • FIG. 5 is a schematic diagram of a scenario when a token controller is faulty according to an embodiment of the present invention.
  • FIG. 6 is a schematic flowchart of a method for implementing a distributed MMDB when a token controller fails according to an embodiment of the present invention
  • FIG. 7 is a schematic flowchart of a method for implementing a distributed MMDB when a token controller re-enters a cluster according to an embodiment of the present invention
  • FIG. 8 is a schematic flowchart of a method for implementing a distributed MMDB when receiving a write operation according to an embodiment of the present invention
  • FIG. 9 is a schematic flowchart of a method for implementing a distributed MMDB in a MMDB failure according to an embodiment of the present invention.
  • FIG. 10 is a schematic flowchart of a method for implementing a distributed MMDB in an MMDB failure recovery according to an embodiment of the present invention
  • FIG. 11 is a schematic structural diagram of an MMDB according to an embodiment of the present disclosure
  • - Figure 12 is a schematic structural diagram of an MMDB according to another embodiment of the present invention
  • FIG. 13 is a schematic structural diagram of a token controller according to an embodiment of the present disclosure.
  • FIG. 14 is a schematic flowchart of a method for implementing a distributed MMDB according to an embodiment of the present invention
  • FIG. 15 is a schematic flowchart of a method for implementing a distributed MMDB between sites when receiving a write request according to an embodiment of the present invention
  • 16 is a schematic diagram of interaction between token controllers between different sites in a method according to an embodiment of the present invention.
  • FIG. 17 is a schematic diagram of data synchronization between sites when receiving a write request according to an embodiment of the present invention
  • FIG. 18 is a schematic flowchart of a method for implementing distributed MMDB between sites when a primary MMDB is changed according to an embodiment of the present invention
  • FIG. 19 is a schematic diagram of a site system according to an embodiment of the present invention.
  • this embodiment provides a method for implementing a distributed MMDB, where the method mainly involves an MMDB and a token controller for managing the MMDB, including:
  • Step 101 The MMDB sends a message containing the node MMDB information to at least two tokens to control crying.
  • the node MMDB information includes at least: a name of the local MMDB, an IP address, a port, a database priority level, and the like.
  • MMDB1 in a cluster 1 sends its own node MMDB information to the token controller 1 and the token controller 2 of the management cluster 1, wherein the MMDB information of the node includes: MMDB name, IP address, port of the MMDB1 , and the priority level of MMDB1.
  • the general MMDB has the highest performance requirements on the device.
  • the MMDB is configured with a database priority level.
  • the priority is used to indicate the order in which the primary MMDB works in the cluster. Therefore, the database priority level of the above MMDB1 is used to indicate the priority level of MMDB1 working in the cluster 1 as the primary MMDB.
  • a general cluster can contain multiple MMDBs. Therefore, if there is MMDB2 in the cluster 1, MMDB3.... is similar to the above MMDB1, and is not mentioned here.
  • Step 102 The MMDB respectively receives, by the at least two token controllers, a message that includes an in-memory database list, where the in-memory database list includes intra-cluster information that is organized according to at least one node in-memory database information;
  • the information in the cluster includes at least: node MMDB information of each MMDB constituting the cluster, master-slave mode information of each MMDB constituting the cluster, and a token controller that sends the MMDB column. Controller priority level.
  • the token controller 1 sorts out the MMDB list according to the node MMDB information of the MMDB1 and the node MMDB information of other MMDBs, and the MMDB list includes Such as: node MMDB information of each MMDB in cluster 1, master-slave mode letter of each MMDB —, and the controller priority level of token controller 1.
  • the token controller 2 is also the same.
  • token controller 1 sends a message containing the list of MMDBs to each MMDB in cluster 1, such as MMDB1.
  • Token Controller 2 also sends a message containing the MMDB list to each MMDB in Cluster 1, such as MMDB1. In order for MMDB1 to process transactions within the cluster based on the information in the cluster in the MMDB list.
  • Step 103 The MMDB processes the transactions in the cluster according to the information in the cluster in the in-memory database list.
  • the intra-cluster transaction includes: entering or exiting the cluster by the MMDB, the MMDB in the cluster is faulty, the faulty MMDB recovers from a fault, and the token controller of the cluster is managed.
  • the faulty token controller recovers the fault, and there is a write operation request request to write the data information to the MMDB or the like.
  • each token controller of the management cluster is set with a controller priority level, and the controller priority level is used to indicate a priority order in the cluster as the primary token controller works. Therefore, the token controller 1 is also provided with a controller priority level, which is used to indicate the priority of the token controller 1 in the cluster 1 as the master token controller, and the master token controller is equivalent to the master command.
  • the card controller, the non-working slave token controller is equivalent to the token controller. Similarly, the same is true for token controller 2.
  • the method further includes: when the received message including the MMDB list is from at least two When the primary token controller in the token controller is based on the MMDB column — — Intra-cluster information processing within the table
  • the intra-cluster transactions include:
  • the intra-cluster information in the MMDB list of the autonomous token controller is subject to the in-cluster transactions. That is, the MMDB list sent by the primary token controller shall prevail, and other MMDB lists sent from the token controller are used for backup storage, so that when the primary token controller fails, it is used as an emergency.
  • MMDB 1 receives a message that the token controller 1 includes an MMDB list, and the MMDB list includes intra-cluster information sorted according to the MMDB information of the MMDB1 and other MMDBs in the cluster 1, for example, each of the clusters 1
  • the MMDB receives the token control 2 message containing the MMDB list, and the list contains the information in the cluster according to the MMDB information of the MMDB1 and other MMDBs in the cluster 1, such as: each of the clusters 1
  • the device where the non-working token controller provided in this embodiment is located is not idle, that is, even if it is a non-working token controller, it will not work, waiting for the primary token controller.
  • the non-working token controller is also a working device (ie, a hot machine), so there is no problem of requiring multiple devices to be purchased, and no dual-machine software control is required.
  • the MMDB list obtained by the interaction with the token controller is processed, and the technical means such as device failure or write operation request is processed according to the list, which can be solved in the prior art.
  • This embodiment provides a method for implementing a distributed MMDB, where the method includes a distributed MMDB cluster, the cluster includes at least two MMDBs, and at least two tokens that manage MMDBs in the cluster.
  • the controller, and the MMDB can be combined with the token controller on the same device or on different devices, wherein the communication protocol between each MMDB and the token controller is extended, including:
  • the setting has a name (the name is unique within the cluster), the setting has a unique controller priority level in the cluster, and the address information of each MMDB in the cluster is set; each MMDB setting has a name (the name is in the cluster) Uniquely, the setting has a database priority level unique to the cluster, and the address information of each token controller that manages the cluster is set.
  • the MMDB is MMDB1 as an example. As shown in Figure 3, it includes:
  • the MMDB1 sends a registration message to each token controller to establish a connection with each token controller.
  • the registration message includes the MMDB information of the MMDB1, which may include: MMDB1 name, IP address of MMDB 1, MMDB Port, MMDB 1 database priority level, etc.
  • Step 202 After receiving the registration message, the token controller broadcasts the MMDB list containing the intra-cluster information of the cluster in the cluster, so as to respond to the MMDB1, and simultaneously adds the MMDB1 to the cluster to notify the other in the cluster. MMDB.
  • the list of MMDB includes: Name of each MMDB, IP address and port, master-slave mode information, and the order The controller priority of the card controller.
  • the master-slave mode information may include which token controller is the master token controller and which tokens are slave token controllers and the like in the network.
  • the heartbeat step 301 needs to be saved with the token controller.
  • the MMDB1 periodically sends a heartbeat message to all the token controllers, and the heartbeat message includes the node MMDB information of the MMDB 1.
  • All of the above token controllers include a token controller 1, a token controller 2, and a token controller 3.
  • the MMDB information can refer to the following table.
  • MMDB IP address IP address in the MMDB1 cluster
  • MMDB port MMDB1 cluster IP port number
  • MMDB priority The priority of the MMDB controller, which can be increased from 1 to 1. The smaller the number, the higher the priority.
  • Step 302 After receiving the heartbeat message of the MMDB1, each token controller broadcasts a response message including the MMDB list to all MMDBs in the cluster.
  • Each MMDB saves the list after receiving the MMDB list, and updates the intra-cluster information in the MMDB list according to the heartbeat message received periodically.
  • the MMDB list can refer to the following table II. - -
  • MMDB name Distributed MMDB system unique name
  • MMDB IP address Distributed MMDB system IP address
  • MMDB port Distributed MMDB system IP port number
  • MMDB priority MMDB database priority, an integer that can be incremented by 1. The smaller the number, the higher the priority.
  • Attribute The master-slave mode information of the MMDB, as specified by the token controller.
  • Priority level of the token controller The controller priority level of the token controller that broadcasts the MMDB list.
  • MMDB1 as an example to describe the process of periodically sending heartbeat messages to interact with the token controller.
  • the process is a step performed by each MMDB.
  • the specific execution mode is similar to MMDB1. Said.
  • Each MMDB can pass the above registration and the heartbeat process described above with the token controller, which can be associated with the token.
  • the controller interacts with each other to understand the status of each MMDB in the cluster and the status of each token controller. Obtain: All token controller information, including the controller priority of each token controller; all MMDBs in the cluster, Each MMDB name, IP address and port number and its master-slave mode information.
  • the MMDB only takes the MMDB list of the primary token controller with the highest controller priority.
  • the cluster MMDB list data broadcast by other token controllers is only used for backup.
  • MMDB Select a token controller with the second highest priority as the primary token controller and validate the MMDB list sent by it.
  • MMDB1 When MMDB1 exits the cluster, the following describes the MMDB as MMDB1.
  • the MMDB1 logs out before each token controller is logged off, so MMDB1 sends a logout to each token controller.
  • the message is to revoke the connection with each token controller, and the logout message contains the node MMDB information of the MMDB.
  • the specific implementation process is similar to the time of logout. Referring to the scenario of the token controller failure shown in FIG.
  • the MMDB can consider that the token controller is faulty.
  • the MMDB mainly includes the following two situations:
  • the faulty token controller has the highest priority, that is, the primary token controller fails, but the other token controllers are working properly, that is, the token controller is not faulty, and the new token controller is required at this time.
  • the work of the token controller as the primary token controller taking over the fault;
  • the controller of the failed token controller has the highest priority, that is, from the token controller. – ⁇ , at this time, because only the highest priority token controller is the working primary token control controller, other priority token controllers are only used for hot backup, so MMDB can do no special processing.
  • the implementation method of the distributed MMDB provided in this embodiment is used when the transaction in the cluster is:
  • the MMDB is according to the above.
  • the information in the intra-cluster information processing cluster in the MMDB list mainly includes the following steps: Step 601: The MMDB determines a controller priority level of the faulty token controller according to the intra-cluster information in the current latest MMDB list.
  • Step 602 if the controller priority level of the faulty token controller is the highest controller priority another 'J, then step 603 is performed; otherwise, step 604 is performed;
  • Step 603 The MMDB selects, as the primary token controller, a token controller with the highest priority of the current controller from among other token controllers other than the faulty token controller according to the information in the cluster.
  • Step 604 the process ends.
  • the MMDB 1 finds that the token controller 1 is faulty, and determines the token controller 1 according to the intra-cluster information in the MMDB list sent by the token controller 1 before. Controller priority level, assuming that the controller has a priority level of A.
  • the token controller 1 representing the failure is the working primary token controller, so the primary token controller needs to be re-determined, so the MMDB1 is removed according to the intra-cluster information in the MMDB list.
  • the token controller 2 with the second highest priority of the controller is selected from the token controller other than the token controller 1, and the token controller 2 is used as the new master token controller, and thereafter
  • the transaction is processed based on the MMDB list sent by the token controller 2; if the above A is not the highest controller priority level, the token controller 1 representing the failure is from the token controller, and will not be brought to the cluster. The big impact, so the process can be ended without special treatment.
  • H does not have controller priority level A as the highest controller priority level for explanation.
  • the MMDB may determine whether it is the primary token controller according to the priority level of the faulty token controller, and if the determination is yes, according to the MMDB list
  • the information in the cluster can select the token controller with the second highest priority of the controller as the new primary token controller, thereby ensuring that the primary token controller can quickly take over the original primary token from the token controller.
  • the controller works, and since the replacement token controller is also a heat engine, there is no delay, and the purchase cost caused by the cold machine backup is avoided, and the technical problem of the complicated and troublesome two-machine software is obtained. Reduce the cost of purchase, the convenience of the single, and the high reliability.
  • the above describes the implementation method of the distributed MMDB when the intra-cluster transaction is a token controller failure. Then, correspondingly, the following provides a distributed MMDB when the token controller in the cluster is faulty to recover the fault. Implementation.
  • a faulty token controller If the failed token controller fails to restart, the failed token controller will rejoin the cluster through the registration process, so the MMDB can re-receive the MMDB list sent by the faulty token controller.
  • the MMDB can re-receive the MMDB list sent by the faulty token controller.
  • a faulty token controller If a faulty token controller is re-registered into the cluster, it mainly includes the following two situations:
  • the fault recovery token controller has a higher priority than the current primary token controller, so the failed token controller should be the new primary token controller after joining the cluster.
  • the controller of the fault recovery controller has a lower priority than the controller of the current primary token controller, and the fault recovery token controller will act as a slave token after joining the cluster. – The controller is used. At this time, because only the token controller with the highest priority is the working controller, the token controllers of other priorities are only used for hot backup, so the MMDB can do nothing special.
  • the MMDB processes the transactions in the cluster according to the information in the cluster in the MMDB list, including:
  • Step 701 After receiving the message including the MMDB list from the fault recovery token controller, the MMDB determines the controller priority level of the fault recovery token controller according to the intra-cluster information in the MMDB list.
  • the MMDB1 receives the registration message (which may also be a heartbeat message) including the MMDB list sent by the fault recovery token controller 1, and determines the fault recovery according to the intra-cluster information in the MMDB list.
  • the token controller 1 has a controller priority of another ij, and the controller has a priority of A.
  • Step 702 If the controller priority level of the fault recovery token controller is higher than the current priority of the current master token controller, step 703 is performed; otherwise, step 705 is performed.
  • the current priority level of the controller of the primary token controller 2 is a, determining whether a is lower than the controller priority of A, and if a is lower than the level of A, the token representing the fault recovery
  • the controller 1 should be used as a new master token controller, and step 703 is performed; otherwise, the token controller 1 representing the fault recovery is a slave token controller, and the MMDB can perform no special processing, and step 705 is performed.
  • Step 703 The MMDB determines, according to the MMDB list from the current primary token controller, whether the MMDB list of the fault recovery token controller is available. If it is determined that the MMDB library column of the fault recovery token controller is available, step 704 is performed. Otherwise, when the next time the MMDB list of the failed recovery token controller is received, step 703 is continued. Specifically, for example: MMDB1 checks whether the fault recovery token controller 1 is consistent according to the MMDB list of the primary token controller 2, that is, whether the data on the MMDB list of the token controller 2 is related to the token controller 1 The data on the MMDB list is consistent. If the data is inconsistent, it indicates that the token controller 1 has not established a normal heartbeat with all the MMDBs in the cluster.
  • MMDB selects the fault recovery token controller as the new primary token controller. Specifically, for example: MMDB1 switches to the fault recovery token controller 1, the fault recovery token controller 1 as the new working primary token controller, and the MMDB list sent by the token controller 1 For in-cluster transaction processing, token controller 2 is used as a slave token controller.
  • Step 705 the process ends.
  • the method provided in this embodiment can ensure that the token controller with high priority of the controller continues to be used as the primary token controller after the fault is recovered, because the token controller with higher priority has better configuration, or performance may be superior. It is more suitable to work as the primary token controller. Therefore, after the fault is recovered, the token controller with superior performance can be used as the technical scheme of the primary token controller, which helps to ensure the processing capability of the token controller. Improve reliability.
  • a method for implementing a distributed MMDB when there is a write operation request is provided. In a cluster of distributed MMDBs, the master MMDB has obtained a list of MMDBs in the cluster from messages from the token controller.
  • processing the transactions in the cluster according to the information in the cluster in the MMDB list includes: - Step 801, the main MMDB updates the data information in the local MMDB according to the write operation request; specifically, the main MMDB updates the data information in the local MMDB according to the operations of inserting, deleting, updating, etc. in the write operation request, and Each write operation request adds an operation sequence number in the order received.
  • Step 802 the main MMDB updates the write operation request to the slave MMDB according to the information in the cluster in the MMDB list, so as to update the data information in the local MMDB according to the write operation request from the MMDB.
  • the main MMDB sends the write operation to each slave MMDB according to the priority of each MMDB database from the first to the last priority, thereby ensuring that the database priority is higher from the MMDB.
  • the MMDB receiving the write operation request updates the data information in the local MMDB according to the operations of insert, delete, update, etc. in the write operation request, and also requests for each received write operation. Add the operation sequence number in the order received. For example: receiving the fifth write operation request from MMDB1, so adding sequence number 5 to the updated MMDB1 data information, receiving the fifth write operation request from MMDB2, adding sequence number 5 to the updated MMDB2 Data information.
  • the reliability of MMDB is guaranteed as follows: If one fails from MMDB, it has no major impact on the cluster to which MMDB belongs. It only affects the efficiency of concurrent query of cluster MMDB, and increases the efficiency from one MMDB. However, if the primary MMDB fails, then the entire cluster does not have a database in which the MMDB can perform write operations, so such a failure must be resolved.
  • the cluster transaction is: If one of the MMDBs in at least one MMDB fails, as shown in FIG. 9, the implementation method of the distributed MMDB includes:
  • Step 901 The token controller determines the faulty MMDB according to the information in the cluster in the MMDB list. -- the database priority level;
  • Token controller 1 (which can be the working primary token controller or the slave token controller) determines the database priority of the faulty MMDB1 based on the information in the cluster in the MMDB list.
  • the MMDB1 database has a priority of B.
  • Step 902 if the database priority level of the faulty MMDB is the highest controller priority level, step 903 is performed; otherwise, step 904 is performed;
  • Step 903 The token controller selects the MMDB with the highest priority of the current database as the new primary MMDB from other MMDBs other than the faulty MMDB according to the information in the cluster, and updates the master-slave mode information in the MMDB list according to the selection process.
  • Step 904 The token controller sends the MMDB list to each MMDB in the cluster.
  • the token controller 1 determines that B is the highest database priority level, it means that MMDB1 is the master MMDB, so the new MMDB needs to take over the work of the MMDB1, so according to the information in the cluster, other than the MMDB 1 MMDB selects the MMDB2 with the highest priority of the current database, that is, MMDB2 with the second highest priority of the database as the new primary MMDB takes over the work of MMDB1, and updates the MMDB list according to the process of selecting MMDB2, including updating MMDB2.
  • Master-slave mode information that is, change MMDB2 from "from” to "main”, identify MMDB1 failure, and so on.
  • the MMDB2 that becomes the new primary MMDB will take over the work of MMDB1, such as performing a write operation, etc.; if the token controller 1 determines that B is not the highest database priority level, it represents MMDB1 is a slave MMDB, so it is possible to identify the MMDB1 fault only in the sent MMDB list without special handling.
  • the token controller may select an MMDB in each slave MMDB as – The new primary MMDB, and each MMDB in the cluster is notified by broadcasting the MMDB list. After receiving the write operation request from the MMDB, it will be forwarded to the new master MMDB; after the new master MMDB updates the data information according to the write operation request, the write operation request is synchronized to each slave MMDB. But there is a limit here: we should take the initiative to choose which MMDB is the new master MMDB. Generally, several MMDBs are deployed in a cluster, but the capabilities of the devices that carry these MMDBs are different. Some devices have better CPU and memory performance and higher cost.
  • MMDB reliability is configured for the MMDB installed by each device according to the high to low performance of the MMDB device or other factors.
  • the token controller can dynamically select the MMDB with the highest database priority, designate it as the primary MMDB, and broadcast the notification to each MMDB in the cluster to reduce the delay caused by manual switching and improve distributed. MMDB reliability.
  • the above describes the implementation method of the distributed MMDB when there is a MMDB fault. Then, the following describes the implementation method of the distributed MMDB provided by the present embodiment when the faulty MMDB is restored, that is, the MMDB is the fault recovery MMDB. 10, including:
  • Step 1001 The fault recovery MMDB sends a message containing the node MMDB information to the token controller. After receiving the message from the fault recovery MMDB containing the node memory data information, the token controller restores the node MMDB according to the fault recovery MMDB.
  • the information determines the database priority level of the MMDB for failure recovery, and organizes the node information of the MMDB into the MMDB list and sends it to each MMDB.
  • MMDB1 for failover joins the cluster first registering with token controller 1 (the token controller 1 can be either the primary token controller or the token controller).
  • the registration message includes the node MMDB information of MMDB1.
  • token controller 1 After receiving the registration message, token controller 1 determines the database priority level of MMDB1. Because the primary MMDB2 already works in the current cluster, even if the database priority of MMDB1 is higher than the database priority of MMDB2, token controller 1 MMDB 1 will not be selected as the new primary MMDB immediately, because MMDB 1 needs to complete the data information update first. When the data information in MMDB 1 is consistent with the current primary MMDB2 data information, it can be selected as the new primary MMDB. The token controller 1 only needs to organize the node MMDB information of MMDB1 into the MMDB list, and sends the list to each MMDB.
  • Step 1002 If the database priority level of the fault recovery MMDB is higher than the database priority level of the current primary MMDB, the fault recovery MMDB sends a data update request to the primary MMDB according to the information in the cluster in the MMDB list, where the data update request includes fault recovery.
  • the operation sequence number of the last recorded data information in the MMDB so that the current main MMDB returns the data information of the serial operation sequence number; otherwise, the fault recovery MMDB can end the process without performing special steps without performing the following steps.
  • MMDB1 of the MMDB list sent by the token controller 1 is received, and it is learned from the information in the cluster that the main MMDB in the current cluster is MMDB2.
  • the MMDB2 sends a data update request to the MMDB2, which includes the operation sequence number of the last recorded data information in the MMDB1.
  • MMDB1 can directly end this process.
  • Step 1003 after receiving the data update request, the current master MMDB returns the data information of the connection operation sequence number to the fault recovery MMDB;
  • MMDB2 sends the data information of operation sequence number 11 to the current latest operation sequence number 30 to MMDB1.
  • the fault recovery MMDB updates the local MMDB of the fault recovery MMDB according to the data information of the returned connection operation sequence number, and sends an update completion response to the main MMDB so that the main MMDB performs the process of exiting the main MMDB mode.
  • the MMDB1 of the fault recovery updates the local MMDB of MMDB1, completes the data synchronization process, and sends an update completion response message to MMDB2.
  • Step 1005 After receiving the update completion response message, the current primary MMDB performs a process of exiting the primary MMDB mode, including: the current primary MMDB initiates a request to exit the primary MMDB mode to the token controller, and disables the local write function. Once there is a new write operation request, the above-mentioned fault recovery is also the MMDB with the highest database priority.
  • the current master MMDB2 After receiving the update completion response message, the current master MMDB2 initiates a request to the token controller 1 to exit the master MMDB mode, and at the same time disables the local write function of the MMDB2, and if there is a new write operation request, the fault recovery is performed. MMDB1.
  • Step 1006 After the current primary MMDB exits the primary MMDB mode, the token controller selects the fault recovery MMDB as the new primary MMDB, and updates the fault recovery MMDB to the new primary MMDB's master-slave mode information to the MMDB list. And broadcast the MMDB list to each MMDB, and each MMDB can know through the MMDB list that the current primary MMDB has been switched to – The new MMDB.
  • Token controller 1 selects MMDB1 of the failed recovery as the new primary MMDB after the current primary MMDB2 exits the primary MMDB mode. This information is sorted into the MMDB list, and the MMDB list is broadcast to each MMDB, and each MMDB knows that the current primary MMDB has been switched to MMDB1, and thereafter, the write operation request is executed by the highest priority database level MMDB1. Other MMDBs in the cluster receive write operation requests and will forward them to MMDB1 for execution.
  • the MMDB with the highest priority of the database recovers, and registers with the token controller when restarting, it cannot be immediately selected as the primary MMDB, and the data information copying process must be completed first.
  • the current primary MMDB synchronizes data to the highest MMDB of the database and the data is consistent
  • the current primary MMDB requests the token controller to abandon the chairman.
  • the token controller re-determines the MMDB with the highest priority of the newly registered database as the primary MMDB and broadcasts the MMDB list to all MMDBs in the cluster. Therefore, the MMDB with superior performance can still be used as the main MMDB again after the failure recovery.
  • the MMDB includes: a sending module 11, a receiving module 12, and a processing module 13.
  • the sending module 11 is configured to send a message including the node MMDB information to the at least two token controllers
  • the receiving module 12 is configured to respectively receive the message including the MMDB list from the at least two token controllers, where the MMDB list is
  • the in-cluster information is organized according to the at least one node MMDB information
  • the processing module 13 is configured to process the transactions in the cluster according to the intra-cluster information in the MMDB list.
  • the processing module 13 may include: a fault determining unit 131, and a first selecting unit 132.
  • the fault determining unit 131 is configured to determine, according to the information in the cluster in the MMDB list, a controller priority level of the faulty token controller when the token controller is faulty;
  • the first selecting unit 132 is configured to: when the fault determining unit 131 determines that the controller priority level of the faulty token controller is the highest controller priority level, according to the in-cluster information, control from a token other than the faulty token controller The token controller with the highest priority of the current controller is selected as the primary token controller.
  • the processing module may further include: a recovery determining unit 134, an available determining unit 135, and a second selecting unit 136.
  • the recovery determining unit 134 is configured to determine, when the faulty recovered token controller re-enters the cluster, the fault recovery token according to the intra-cluster information in the MMDB list received by the receiving module from the fault recovery token controller Controller's controller priority level;
  • the determining unit 135 is configured to: when the recovery determining unit 134 determines that the controller priority level of the fault recovery token controller is higher than the current master token controller's controller priority level, according to the MMDB from the current primary token controller The list determines the availability of the MMDB list of the failed token controller;
  • the second selection unit 136 when the MMDB column of the token controller for determining that the fault recovery is available at the time available determining unit 135 has availability, selects the fault recovery token controller as the new primary token controller.
  • the processing module may further include: a writing unit 133 and a synchronization recovery unit 137.
  • the writing unit 133 is configured to receive a write operation request when in the main MMDB state, and further - - Update the data information in the local MMDB according to the write operation request, and then update the write operation request to the slave MMDB according to the information in the cluster in the MMDB list, so as to update the data information in the local MMDB according to the write operation request from the MMDB. .
  • the synchronization recovery unit 137 is configured to send a data update request to the primary MMDB according to the information in the cluster in the MMDB list when the database priority level is higher than the database priority level of the current primary MMDB, and the data update request includes a higher record in the MMDB.
  • the operation sequence number of the data information so that the main MMDB returns the data information of the serial operation sequence number, and then updates the data information of the local MMDB according to the data information of the returned connection operation sequence number, and sends an update completion response to the main MMDB, so that the main MMDB executes the exit master. Processing of the MMDB mode.
  • the MMDB provided in this embodiment can be deployed on the same device as the token controller, or can be deployed on different devices.
  • the networking is very flexible. It does not need to be deployed by Active-Standby dual-machine. It does not need to perform two-machine switching action. It is easier to be faulty. The switching process is automatically completed, which avoids the delay caused by manual switching and improves the reliability of distributed MMDB.
  • the embodiment provides a token controller.
  • the token controller includes: a receiving module 21, an obtaining module 22, and a sending module 23.
  • the receiving module 21 is configured to receive a message that includes the node memory data information from the at least one MMDB
  • the obtaining module 22 is configured to obtain the MMDB list according to the node MMDB information, where the MMDB list includes the intra-cluster information according to the at least one node MMDB information.
  • the sending module 23 is configured to send the message including the MMDB list to the at least one MMDB, so that the at least one MMDB processes the transactions in the cluster according to the intra-cluster information in the MMDB list.
  • the token controller further includes: a fault determining unit 24, and a first selecting unit 25.
  • the fault determining unit 24 is configured to determine, according to information in the cluster in the MMDB list, a database priority level of the faulty MMDB when one of the at least one MMDB fails;
  • the first selecting unit 25 is configured to: when the fault determining unit 24 determines that the database priority level of the faulty MMDB is the highest controller priority level, select the MMDB with the highest current database priority level from other MMDBs other than the faulty MMDB according to the information in the cluster. As the new main MMDB.
  • the token controller may further include: a recovery determining unit 26, a second selecting unit
  • the recovery determining unit 26 is configured to determine, after receiving the message including the node memory data information from the fault recovery MMDB, the database priority level of the fault recovery MMDB according to the node MMDB information of the fault recovery MMDB;
  • the second selecting unit 27 is configured to: when the recovery determining unit 26 determines that the database priority level of the fault recovery MMDB is higher than the current primary MMDB database priority level, after the current primary MMDB exits the primary MMDB mode, select the fault recovery MMDB as The new master MMDB.
  • the token controller provided in this embodiment is suitable for being deployed on a working device, that is, a hot machine. Therefore, it is possible to avoid deploying complex dual-machine software to the cold machine, thereby causing the cold start to be started when the active/standby switchover occurs, and the delay generating technology is generated.
  • the problem is that the technical effect of reducing the delay, improving the reliability, and reducing the purchase cost when the token controller needs to be switched is obtained.
  • This embodiment provides a distributed MMDB system, as shown in FIG. 2, including: MMDB cluster — and a token controller cluster, where the MMDB cluster includes at least two token controllers, and the token controller cluster includes: at least one MMDB;
  • Each MMDB is configured to send a message including node MMDB information to at least two token controllers, and respectively receive messages from the at least two token controllers including the MMDB list, wherein the MMDB list includes at least The intra-cluster information of the node MMDB information is stored, the internal test data list is stored, and the transactions in the cluster are processed according to the intra-cluster information in the MMDB list; each token controller is configured to receive the MMDB message containing the node memory data information. And obtaining the MMDB list according to the node MMDB information, and then sending the message containing the MMDB list to at least one MMDB.
  • the distributed MMDB system does not require dual-machine software to control the MMDB, and does not require an active/standby dual-system solution.
  • Each MMDB can obtain an MMDB list through interaction with the token controller, and process the intra-cluster according to the MMDB list.
  • the transaction avoids the delay problem caused by processing the transaction such as the active/standby switchover, reduces the execution complexity, eliminates the need for idle spare devices, reduces the purchase cost, and improves the reliability of the distributed MMDB.
  • the embodiment further provides a method for implementing a distributed MMDB, where the method includes at least two sites, a first site and a second site, at least one MMDB cluster deployed in each site, and a token for managing the MMDB cluster. Controller cluster.
  • Each MMDB cluster is composed of multiple MMDBs.
  • Each token controller cluster is composed of multiple token controllers, and the IP address and port of the token controller of the remote site are configured on each token controller. .
  • an MMDB can only belong to one MMDB cluster, and the write operation request can only operate on the main MMDB in its own MMDB cluster, so in order to ensure that it belongs to the cluster outside it.
  • the MMDB does not perform replication. Therefore, in this embodiment, the following work needs to be done:
  • a site as a domain, and the domain name is globally unique.
  • the domain name of site 1 that is, the global site name is mmdb_Sitel
  • the domain name of site 2 that is, the global site name is mmdb_Site2;
  • Each MMDB cluster in the site is configured with a cluster name, which is a string and is unique within the site.
  • the MMDB global cluster name of the cluster is a combination of the cluster name and the global site name of the site to which it belongs.
  • the format is: Cluster name @global site name.
  • each token controller in the site has a token name, the name is a string, and is unique within the site, such as mm db_ringl, the global name of the token controller is the token controller in the site.
  • token name is a string
  • the global name of the token controller is the token controller in the site.
  • Each MMDB in the site has a memory name, which is a string and is unique within the site, such as mmdbl.
  • the global name of the MMDB is a combination of the name of the site and the domain name of the site.
  • the format is: MMDB name@ Site domain name, for example: "mmdbl @ mmdb_Sitel"
  • each site is configured with a global site name
  • Each MMDB cluster in the site is configured with a cluster name, and the cluster name and the global site name are combined into a global cluster name of the MMDB cluster;
  • Each token controller in the site is configured with a token name, and the token name is combined with the global site name into the global tokenizer name of the token controller;
  • Each MMDB in the site is configured with a memory name, and the memory name is combined with the global site name.
  • the global memory name of the MMDB is the global memory name of the MMDB.
  • the device is a local site or an offsite site, and different sites can be distinguished based on the global site name following @. .
  • Step 1401 The MMDB of the first station sends a message including the node MMDB information to the token controller of the first station;
  • each MMDB of the first site sends a message containing its node MMDB information to the token control cluster of the first site, i.e., each token controller.
  • the message containing its node MMDB information may be a heartbeat message that needs to be sent periodically, or may be a registration message sent when joining the MMDB cluster.
  • the foregoing node MMDB information includes the following: a cluster name, a name of the local MMDB, an IP address, a port, and a database priority level.
  • the MMDB1 of the first site sends a heartbeat message including the node MMDB information of the MMDB 1 to the token controller 1 of the first site, where the node MMDB information includes: the name of the cluster to which the MMDB 1 belongs, and the name of the local MMDB of the MMDB 1. , IP address, port, database priority.
  • the MMDB2 of the first site sends a heartbeat message including the node MMDB information of the MMDB2 to the token controller 1 of the first site, where the node MMDB information includes: the name of the cluster to which the MMDB2 belongs, the name of the local MMDB of the MMDB2, the IP address, and the port , database priority level. – The same is true for the MMDB3 at the first site.
  • Step 1402 The token controller of the first site receives a message including the primary MMDB information of the second site from the token controller of the second site;
  • each token controller of the first site interacts with each token controller of the second site to manage the primary MMDB information of the respective MMDB cluster by using a heartbeat message, and further, Interact with each other's token controller information. That is, through the heartbeat message, each token controller of the first site can acquire the token controller information of the second site token controller that sends the heartbeat message and the information of the master MMDB in the MMDB cluster it manages. .
  • the token controller information includes: a global site name of the site to which the token controller belongs, a global name of the token controller, a controller priority level of the token controller, an IP address of the token controller, and port.
  • the primary MMDB information includes: a global cluster name of the cluster to which the primary MMDB belongs, a global memory name of the primary MMDB, and an IP address and port of the primary MMDB.
  • the token controller 1 of the site 1 interacts with the token controller 1 of the site 2 through a heartbeat message, through which the token controller 1 acquires the primary MMDB information of the site 1, and the token controller 2 Card controller information.
  • the primary MMDB information of the site 1 includes: a global cluster name of the cluster to which the primary MMDB belongs, a global memory name of the primary MMDB, and an IP address and port of the primary MMDB;
  • the token controller information of the token controller 2 includes: 2 global site name, global name of token controller 2, controller priority level of token controller 2, IP address and port of token controller 2.
  • the token controller 2 can also obtain the master MMDB information of the token controller 1 of the site 2 and the token controller information of the token controller 1 through the interaction.
  • the token controller of the first site acquires the MMDB list of the first site according to the primary MMDB information of the second site and the intra-cluster information of the first site, where the information in the cluster of the first site is based on The node MMDB information of at least one MMDB of a site is collated; wherein the information in the cluster may include at least: node MMDB information of each MMDB constituting the MMDB cluster, master-slave mode information of each MMDB constituting the MMDB cluster, and The controller priority level of the token controller that sent the MMDB column.
  • the token controller 1 of the site 1 acquires the MMDB list of the site 1 based on the main MMDB information of the token controller 2 from the site 2 described above and the intra-cluster information of the site 1.
  • the intra-cluster information in the MMDB list of the site 1 is organized according to the node MMDB information of multiple MMDBs from the site 1;
  • the specific meaning of obtaining the MMDB list according to the primary MMDB information of the token controller 2 of the site 2 means: if the primary MMDB information of the token controller 2 of the site 2 is determined if the primary of the site 2 If the MMDB is not in the MMDB cluster of the MMDB site 1, the primary MMDB of the site 2 is added to the MMDB cluster of the site 1 from the MMDB in the MMDB cluster of the site 1.
  • Step 1404 the token controller of the first site sends the MMDB list of the first site to at least one MMDB in the first site, so that the MMDB processes the inter-site or intra-site transactions according to the MMDB list.
  • the transaction between the first site and the second site refers to: a transaction between the first site and the second site, or a transaction in the first site, which may include: the write operation request of the first site is synchronized to the second site, The write operation request of the second site is synchronized to the first site, and the write operation request of the primary MMDB of the first site or the second site is synchronously processed, and the first site receives the write operation from the application. -- Ask for processing, etc.
  • the token controller 1 of the site 1 sends the MMDB list of the above site 1 to the MMDB 1, MMDB2, MMDB3, etc. of the site 1, so that the MMDB 1, MMDB2, MMDB3 processes the site 1 and the site 2 according to the MMD list.
  • Step 1405 the MMDB of the first site acquires the first site from the token controller of the first site.
  • the MMDB list includes the main MMDB information as the second site joining the first site from the MMDB, and the intra-cluster information of the first site collated according to the at least one node MMDB information; and processing the site according to the MMDB list Inter- or intra-site transactions.
  • the MMDB of the first site acquires the MMDB list of the first site, and processes the transaction between the first site and the second site according to the MMDB list, or the transaction in the first site.
  • MMDB1 of site 1 obtains the MMDB list of site 1 from token controller 1 of site 1 (the token controller 1 can be any token controller), where
  • the MMDB list includes: intra-cluster information organized by the site 1 according to the node MMDB information of each MMDB in the MMDB cluster, and main MMDB information of the main MMDB of the site 2 joined from the MMDB in the MMDB cluster as the site 1.
  • the information in the cluster includes: MMDB information of each MMDB node, master-slave mode information of each MMDB, and a controller priority level of the token controller that sends the MMDB column;
  • the primary MMDB information of the primary MMDB of the site 2 includes: The global cluster name of the cluster to which the primary MMDB belongs, the global memory name of the primary MMDB, and the IP address and port of the primary MMDB.
  • steps 1401 to 1405 are described by taking Site 1 and Site 2 as an example, and actually may include more sites, such as Site 3, Site 4, etc., and other sites work in the same manner.
  • Site 2 in this embodiment is similar, as in step 1405, site 1 receives — —
  • the MMDB list may further include: a primary MMDB information of the site 3 that joins the MMDB cluster from the MMDB as the site 1.
  • the process before processing the inter-site or intra-site transaction according to the MMDB list in the above steps 1401 to 1405 is described by taking one cycle as an example.
  • the token controller of the site 1 and the token control of the site 2 are used.
  • the device periodically interacts with heartbeat messages.
  • the MMDB of Site 1 and the token controller of Site 1 may also periodically interact through heartbeat messages.
  • the master MMDB information is obtained through the interaction between the inter-site token controllers, and the master MMDB information of the other party is collated into the MMDB list of the site, and the inter-site or intra-site is processed according to the MMDB list.
  • the data synchronization and other transactions solve the technical problems in the prior art that the complex data synchronization must be managed by running the synchronization software, thereby reducing the complexity of data synchronization between the sites, and improving the disaster tolerance capability of the site.
  • the reliability between sites is suitable for large distributed MMDB scenarios with multiple sites.
  • the transactions between sites or sites are:
  • the primary MMDB in the site receives a write operation request
  • the transactions between sites or within the site according to the MDDB list include:
  • Step 1501 When the primary MMDB receives the write operation request from the application, the primary MMDB in the first site updates the data information of the primary MMDB according to the write operation request.
  • step 1501 can be implemented as follows:
  • the master MMDB in the first site When receiving the write operation request from the application, the master MMDB in the first site adds an operation sequence number to the received write operation request, and then updates the data information of the master MMDB according to the write operation request.
  • the first station updates the data information of each slave MMDB according to the write operation request, where each slave MMDB includes: the slave MMDB in the first site acquired according to the information in the cluster, and the first obtained according to the master MMDB information The primary MMDB in the second site;
  • the step 1502 includes: the first station updates the data information of each slave MMDB according to the write operation request, where the write request carries the global site name of the site to which the write operation belongs and the operation sequence number of the write operation request, so that each The operation sequence number of the write operation request is recorded from the MMDB according to the global site name.
  • Step 1503 After updating the data information according to the write operation request, the primary MMDB of the second site updates the data information of the second site from the MMDB according to the write operation request.
  • the step 1503 includes: the primary MMDB of the second site stores the write operation request to the location of the data information of the first site in the primary MMDB of the second site according to the global site name of the first site, where In this location, the operation sequence number corresponding to the data information requested by the write operation request is the operation sequence number carried in the write operation request.
  • first site and the second site may be included, and the third site is executed in a similar manner to the second site.
  • the main MMDB of the station 1 receives the 100th write operation request from the application, adds the operation sequence number 100 to the write operation request, and updates the data information of the main MMDB according to the write operation request. , including insert, delete, update, etc. write operations;
  • Site 1 can synchronize the write operation request to the slave MMDB1, MMDB2, and MMDB3 according to the IP address and port of the MMDB in the MMDB list of the site 1, and the global site of the site 1 is carried in the write operation request.
  • MMDB4 joins the primary MMDB of Site 3 of Site 1 as an MMDB.
  • the data information from the MMDB 1 is updated from the MMDB 1 according to the write operation request for storing the location of the site 1 from the MMDB 1, and the operation sequence number of the portion is recorded as 100; from the MMDB 2, the request is requested from the MMDB 2 according to the write operation.
  • the data information location for storing the site 1 updates the data information from the MMDB2, and records the operation sequence number of the part as 100; similarly, the data information for storing the site 1 in the slave MMDB3 is requested from the MMDB3 according to the write operation request.
  • the location updates the data information from MMDB3, and records the operation sequence number of the part as 100; from MMDB4, according to the write operation request, the data information from the MMDB4 is updated in the location for storing the data information of the site 1 from the MMDB4, and Record the operation number of this part as 100;
  • the write operation request is also synchronized to each slave MMDB of the site 2, and the write operation request carries the global site name of the site 1, and the operation sequence number 100, And the write operation of inserting, deleting, updating, etc.; after each slave MMDB of the site 2 receives the write operation request of the master MMDB of the site 2, that is, the MMDB3, each slave MMDB of the site 2 respectively performs the write operation request according to the The data information for storing the location information of the site 1 is updated, and the operation sequence number of the part is recorded as 100; similarly, since the MMDB4 is also the main MMDB of the site 3, the write operation request is also synchronized.
  • each slave MMDB of the site 3 After each MMDB of the site 3, each slave MMDB of the site 3 receives the write operation request of the master MMDB of the site 3, that is, the MMDB 4, each slave MMDB of the site 3 is separately used for storage according to the write operation request.
  • the location of the data information of the station 1 updates the corresponding data information, and records the operation sequence number of the part as 100.
  • the primary MMDB in the first site only synchronizes the write operation request to the primary MMDB of the second site, and the primary MMDB of the second site is responsible for the write operation request.
  • - - Synchronize to each slave MMDB of the second site, instead of synchronizing to the master and slave MMDBs of the second site respectively, thereby reducing data traffic between sites and reducing the complexity of data synchronization between sites, thereby ensuring capacity Disaster, it can improve the reliability of data synchronization between sites. As shown in FIG.
  • the primary MMDB of the second site is changed, in the method provided in this embodiment, the MMDB of the first site is according to the MMDB list.
  • Handling transactions between sites or within sites includes:
  • Step 1801 The token controller of the second site learns that the primary MMDB is faulty according to the heartbeat message, or the MMDB with a higher priority than the database of the primary MMDB joins the MMDB cluster of the second site.
  • Token Controller 1 of Site 2 (which can be either the primary token controller or the token controller) cannot receive the heartbeat message of MMDB1 working as the primary MMDB in the current MMDB cluster. Or, Site 2 receives a registration message that MMDB2 with a higher priority than MMDB1 joins the MMDB cluster.
  • Step 1802 The token controller of the second site selects the changed primary MMDB, that is, the new primary MMDB, according to the database priority level of each MMDB from the MMDB cluster, and indicates the selected result in the MMDB list. Broadcast the MMDB list to notify the second site of each MMDB in the MMDB cluster.
  • the token controller 1 of the site 2 selects MMDB2 as a new master MMDB according to the database priority level of each MMDB in the MMDB list, and indicates the selected result in the MMDB list, and sends it to each of the sites 2MMDD clusters.
  • MMDB the MMDB can know that MMDB2 is the new master MMDB.
  • Step 1803 the new primary MMDB in the second site sends the last recorded operation sequence number and the primary MMDB information of the MMDB to the token controller of the second site.
  • the token controller of the second site will record the operation sequence number of the new master MMDB and the master MMDB information of the new master MMDB.
  • the last recorded operation sequence number 100 of MMDB2 and the primary MMDB information of MMDB2 are sent to the Token Controller 1 of Site 2.
  • the token controller 1 of the site 2 notifies the token controller 11 of the site 1 of the last recorded operation signal 100 and the master MMDB information of the MMDB 2 (the token controller 11 may be the master token controller of the site 1 or Is the slave controller of Site 1).
  • the primary MMDB information includes: a global cluster name of the MMDB cluster to which the MMDB2 belongs, a global memory name of the MMDB2, and an IP address and port of the MMDB2.
  • Step 1804 the token controller of the first site acquires the last recorded operation sequence number of the MMDB in the second site and the main MMDB information of the new primary MMDB from the token controller of the second site, and carries the operation sequence number and the new The message of the primary MMDB information of the primary MMDB is sent to the primary MMDB of the first site.
  • Site 1's token controller 11 receives site 2 as a new master MMDB
  • MMDB2 last recorded the operation sequence number 100 and the main MMDB information of MMDB2, and sent these to MMDB3, which is currently working as the primary MMDB.
  • Step 1805 The primary MMDB of the first site acquires the primary MMDB information of the changed primary MMDB in the second site and the last recorded operation sequence number of the primary MMDB of the second site, and obtains a corresponding write operation according to the primary MMDB information and the operation sequence number. Data information.
  • MMDB3 currently working as the primary MMDB in Site 1 receives the new primary MMDB from Site 2 sent by token controller 11 from Site 1, ie the last recorded operation sequence number of MMDB2. — —
  • the request is obtained from the site 2, and the data information of the write operation corresponding to the operation sequence number 100 is obtained at the location where the site 2 data information is stored in the MMDB3.
  • Step 1806 the primary MMDB of the first site updates the data information of the write operation to the new primary MMDB of the second site.
  • the MMDB3 of the site 1 sends the data information of the write operation corresponding to the operation sequence number 100 to the MMDB2 of the site 2, and the MMDB2 of the site 2 updates the MMDB of the MMDB2 based on the data information.
  • the framework of the distributed MMDB may be composed of multiple sites, and each site may deploy at least one distributed MMDB cluster, and the MMDB cluster master MMDB receives the write operation request of the application, and generates for each operation.
  • An incremental unique 64-bit data number which is the sequence number of the operation requested by the write operation.
  • this operation sequence number must be included as a parameter in the message requesting the update.
  • each master MMDB will receive the data information synchronized by the other sites from the MMDB as one of the other site MMDB clusters, the master MMDB must record the operation number and the global site name of other sites, thereby completing the present The data update process of the site, and the operation number, the write operation request, and the site name to which the write operation request belongs are synchronized to the slave MMDB in the site.
  • each MMDB also records the operation number of the MMDBJ cluster (differentiated by the global site name) in other sites.
  • the token controller of the site 1 reselects a new primary MMDB according to the local MMDB database priority. After receiving the MMDB list of the token controller, the new primary MMDB will Returning the last recorded operation sequence number and other information to the token controller, - - The token controller notifies the token controller of the other site to the token controller of the other site, and the token controller of the other site passes it to the master MMDB in its MMDB cluster.
  • the master MMDB can continue to synchronize the data information to the new primary MMDB of the site 1 from the sequence number breakpoint, and the new master MMDB synchronizes the data information to the replicated slave MMDBs within the cluster.
  • the site 1 can obtain the lost data information through the data synchronization process with other sites, and continue its functions, thereby achieving the complexity in reducing the data synchronization process, and the disaster tolerance capability and reliability. High technical effect.
  • the embodiment provides an optional MMDB. As shown in FIG. 11, the sending module 11 can also send a message including the node MMDB information to the token controller of the first site.
  • the receiving module 12 can also be used to The token controller of the first site acquires the MMDB list of the first site, the MMDB list includes the main MMDB information as the second site joining the first site from the MMDB, and the cluster of the first site organized according to the at least one node MMDB information
  • the internal information; the processing module 13 can also be used to process transactions between sites or within the site according to the MMDB list.
  • the embodiment provides an optional MMDB, as shown in FIG. 11, wherein the processing module 13 is further configured to receive a write operation request when the MMDB device is in the main MMDB state, and update each slave according to the write operation request.
  • Data information of the MMDB wherein each slave MMDB includes: a slave MMDB in the first site acquired according to the information in the cluster, and a master MMDB in the second site acquired according to the master MMDB information; and can also be used as a write operation
  • the data information from the MMDB in the first site is updated according to the write operation request of the second site.
  • This embodiment provides an optional MMDB, as shown in FIG. 11, where the processing module 13 can also - - for adding an operation sequence number to the received write operation request when receiving the write operation request; and also for carrying the global site name and the write operation of the site to which the write operation belongs in the write operation request The requested operation sequence number, so that each MMDB records the operation sequence number of the operation request according to the global site name.
  • the embodiment provides an optional MMDB, as shown in FIG. 11, wherein the processing module 13 is further configured to obtain the primary MMDB information of the changed primary MMDB in the second site when the primary MMDB of the second site is changed.
  • the operation sequence number of the last MMDB of the second site is recorded, and the data information of the corresponding write operation is obtained according to the main MMDB information and the operation sequence number, and the data information of the write operation is updated to the main MMDB after the second site change.
  • the MMDB device provided in this embodiment can perform the process of data synchronization between sites without the control of the synchronization software, improves the disaster tolerance, ensures the reliability, and is applicable to a large cross-site distributed MMDB scenario, which can be reduced. Solution costs, improve product strength.
  • the embodiment provides an optional token controller, as shown in FIG. 13, wherein the receiving module 21 is further configured to receive, by using a token controller of the second site, a message including the primary MMDB information of the second site; The module 22 is further configured to obtain, according to the primary MMDB information of the second site and the intra-cluster information of the first site, the MMDB list of the first site, where the intra-cluster information of the first site is based on at least one MMDB from the first site.
  • the node MMDB information is collated; the sending module 23 is further configured to send the MMDB list of the first site to the at least one MMDB of the first site, so that the MMDB processes the inter-site or intra-site transactions according to the MMDB list.
  • the embodiment provides an optional token controller.
  • the fault determining unit 24 is further configured to acquire a second token controller from the second site when the primary MMDB of the second site is changed.
  • station — The last recorded operation sequence number and main MMDB information of the changed primary MMDB in the point, and the message carrying the operation sequence number and the primary MMDB information of the primary MMDB is sent to the primary MMDB of the first site.
  • the token controller provided in this embodiment can replace the synchronization software to control the process of data synchronization between sites, reduce the complexity of implementing control data synchronization between sites, strengthen disaster tolerance, and improve reliability.
  • the embodiment provides a site system, where the system includes at least: a first site 61 and a second site 62.
  • a token controller in the first site 61 for receiving a message including the primary MMDB information of the second site 62 from the token controller of the second site 62, and according to the primary MMDB information of the second site 62 and the first site
  • the intra-cluster information of 61 acquires the MMDB list of the first site 61, and then sends the MMDB list of the first site 61 to the MMDB of the first site 61;
  • the MMDB in the first site 61 is configured to send a message including the node MMDB information to the token controller of the first site 61, and obtain the MMDB list of the first site 61 from the token controller of the first site 61, and according to The MMDB list processes transactions between the first sites 61, or transactions between the first site 61 and the second site 62.
  • the MMDB list includes: primary MMDB information as the second site 62 joined to the first site 61 from the MMDB, and intra-cluster information of the first site 61 organized according to the node MMDB information.
  • the MMDB and token controller in the second site can also be executed like the MMDB and token controller in the first site to complete transactions between the first site and the second site or between the second site.
  • the synchronization application controls the data synchronization between different sites in order to ensure the points.
  • the MMDB is disaster-tolerant, but the process is complicated, the scalability is poor, and therefore the fault is easy, and the reliability is poor.
  • the solution provided by the embodiment of the present invention adopts a token controller between two different sites.
  • the main MMDB information of the other party is obtained interactively, and according to the MMDB information processing including the information and the technical means of processing the information between the sites or the intra-station in the cluster, the complexity and scalability of the synchronous application software can be avoided.
  • Technical problems so you can obtain the technical possibilities of providing possibilities and enhancing disaster tolerance.
  • the present invention can be implemented by means of software plus a necessary general hardware platform, and of course, can also be through hardware, but in many cases, the former is a better implementation. the way.
  • the technical solution of the present invention which is essential or contributes to the prior art, may be embodied in the form of a software product stored in a readable storage medium, such as a floppy disk of a computer. , a hard disk or an optical disk, etc., including a number of instructions for a device (which may be a laptop, etc.) to perform the methods of various embodiments of the present invention.

Description

一 一 分布式内存数据库的实现方法、 系统、 令牌控制器及内存数据库 本申请要求于 2010 年 12 月 2 日提交中国专利局、 申请号为 201010570252. X, 发明名称为 "分布式内存数据库的实现方法、 系统、 令牌控 制器及内存数据库"的中国专利申请的优先权, 其全部内容通过引用结合在本 申请中。 技术领域
本发明涉及通信技术,尤其涉及一种分布式内存数据库的实现方法、系统、 令牌控制器及内存数据库。 背景技术
MMDB ( Main Memory Database, 内存数据库)是一种数据库技术, 主要 用于实现将数据放在内存中,进而可直接操作内存中保存该数据的数据库的目 的。访问保存在内存中数据与访问保存在磁盘上的数据相比, 由于数据处理时 无需进行磁盘访问, 所以读写速度可以提高很多, 故而在很多技术领域, 使用 MMDB的技术。 现有技术中主要采用如下方案部署分布式 MMDB:
根据 Active-Standby主备双机方案,即部署两个令牌控制器在两台设备上, 一台的主令牌控制器工作, 另一台的备令牌控制器闲置, 在两台设备上都装有 双机控制软件, 两个令牌控制器对外显示为一个浮动 IP。对于分布式内存数据 库中的一个集群内各 MMDB而言, 只有一个令牌控制器, 只需要配一个令牌 控制器的 IP, 与该令牌控制器保持心跳。 如果主令牌控制器发生故障, 通过 双机控制软件的切换功能,备令牌控制器可接管该主令牌控制器的工作, 并且 仍旧以浮动 IP呈现给 MMDB。 这样对于 MMDB而言, 集群内仍就是一个令 — — 牌控制器, 感觉不到主备令牌控制器发生的切换。
但是, 这种方法还是有不足之处。 当主令牌控制器发生故障时, 如果手工 切换,还存在着延时的风险, 而自动检测也使令牌故障需要在两台令牌控制器 外的第三个点检测令牌控制器的心跳以判定其状态,该第三个点也存在单点故 障的风险, 该种方案部署较复杂, 可靠性和稳定性较差。 发明内容
本发明的实施例提供一种分布式 MMDB的实现方法、 系统、 令牌控制器 及 MMDB , 可提高分布式 MMDB的可靠性。
为达到上述目的, 本发明的实施例采用如下技术方案:
一种分布式 MMDB的实现方法, 包括:
发送包含节点 MMDB信息的消息到至少两个令牌控制器;
分别接收来自所述至少两个令牌控制器的包含 MMDB列表的消息,其中, 所述 MMDB列表中包括根据至少一个所述节点 MMDB信息整理的集群内信 息;
根据所述 MMDB列表中的集群内信息处理所述集群内的事务。
一种分布式 MMDB的实现方法, 包括:
接收来自至少一个 MMDB的包含节点内存数据信息的消息;
根据所述节点 MMDB信息获取 MMDB列表, 其中, 所述 MMDB列表中 包括根据至少一个所述节点 MMDB信息整理的集群内信息;
将包含所述 MMDB列表的消息发送到所述至少一个 MMDB ,以便所述至 少一个 MMDB根据所述 MMDB列表中的集群内信息处理所述集群内的事务。
一种内存数据库, 包括: — — 发送模块,用于发送包含节点 MMDB信息的消息到至少两个令牌控制器; 接收模块, 用于分别接收来自所述至少两个令牌控制器的包含 MMDB列 表的消息, 其中, 所述 MMDB列表中包括根据至少一个所述节点 MMDB信 息整理的集群内信息;
处理模块, 用于根据所述 MMDB列表中的集群内信息处理所述集群内的 事务。
一种令牌控制器, 其特征在于, 包括:
接收模块, 用于接收来自至少一个 MMDB的包含节点内存数据信息的消 息;
获取模块, 用于根据所述节点 MMDB信息获取 MMDB列表, 其中所述
MMDB列表中包括根据至少一个所述节点 MMDB信息整理的集群内信息; 发送模块, 用于将包含所述 MMDB 列表的消息发送到所述至少一个 MMDB , 以便所述至少一个 MMDB根据所述 MMDB列表中的集群内信息处 理所述集群内的事务。
一种分布式 MMDB系统,包括:至少两个令牌控制器和至少一个 MMDB; 所述 MMDB,用于发送包含节点 MMDB信息的消息到所述至少两个令牌 控制器,并分别接收来自所述至少两个令牌控制器的包含 MMDB列表的消息, 其中, 所述 MMDB列表中包括根据至少一个所述节点 MMDB信息整理的集 群内信息, 存储所述内测数据列表, 并根据所述 MMDB列表中的集群内信息 处理所述集群内的事务;
所述令牌控制器,用于接收所述 MMDB的包含节点内存数据信息的消息, 并根据所述节点 MMDB信息获取 MMDB列表,再将包含所述 MMDB列表的 — — 消息发送到所述至少一个 MMDB。
一种站点系统, 至少包括: 第一站点和第二站点,
所述第一站点中的令牌控制器,用于从第二站点的令牌控制器接收包含所 述第二站点的主内存数据库信息的消息,并根据所述第二站点的主内存数据库 信息和第一站点的集群内信息获取所述第一站点的内存数据库列表,再将所述 第一站点的内存数据库列表发送到所述第一站点的内存数据库;
所述第一站点中的内存数据库,用于发送包含节点内存数据库信息的消息 到第一站点的令牌控制器,并从所述第一站点的令牌控制器获取所述第一站点 的内存数据库列表, 以及根据所述内存数据库列表处理所述第一站点间的事 务, 或所述第一站点与所述第二站点间的事务; 其中, 所述内存数据库列表中 包括: 作为从内存数据库加入第一站点的第二站点的主内存数据库信息, 以及 根据节点内存数据库信息整理的第一站点的集群内信息。
在本发明实施例提供的上述方案中, 无需双机软件控制 MMDB, 无需主 备双机方案,每个 MMDB可通过与令牌控制器之间的交互获取 MMDB列表, 并根据 MMDB列表处理集群内的事务, 故而避免了为处理主备倒换等事务时 产生的延时问题, 降低了执行复杂度, 无需提供闲置的备用设备, 减少了购机 成本, 提高了分布式 MMDB的可靠性。
附图说明 为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施 例或现有技术描述中所需要使用的附图作筒单地介绍,显而易见地, 下面描述 — — 中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲, 在不付 出创造性劳动的前提下, 还可以根据这些附图获得其他的附图。
图 1为本发明实施例分布式 MMDB的实现方法的流程示意图; 图 2为本发明实施例在 MMDB登入或保持心跳或退出 MMDB集群时的 场景示意图;
图 3为本发明实施例在 MMDB登入时, 分布式 MMDB的实现方法的流 程示意图;
图 4为本发明实施例在 MMDB保持心跳时, 分布式 MMDB的实现方法 的流程示意图;
图 5为本发明实施例在令牌控制器故障时的场景示意图;
图 6为本发明实施例在令牌控制器故障时, 分布式 MMDB的实现方法流 程示意图; 图 7为本发明实施例在令牌控制器重新进入集群内时, 分布式 MMDB的 实现方法流程示意图;
图 8为本发明实施例在接收到写入操作时, 分布式 MMDB的实现方法流 程示意图;
图 9为本发明实施例在 MMDB故障时, 分布式 MMDB的实现方法的流 程示意图;
图 10为本发明实施例在 MMDB故障恢复时,分布式 MMDB的实现方法 的流程示意图;
图 11为本发明实施例提供的 MMDB的结构示意图; — — 图 12为本发明另一实施例提供的 MMDB的结构示意图;
图 13为本发明实施例提供的令牌控制器的结构示意图;
图 14为本发明实施例中分布式 MMDB的实现方法的流程示意图; 图 15为本发明实施例在接收到写入请求时, 站点间分布式 MMDB的实 现方法的流程示意图;
图 16 为本发明实施例提供的方法中不同站点间令牌控制器的交互示意 图;
图 17为本发明实施例在接收到写入请求时, 站点间数据同步的示意图; 图 18为本发明实施例在主 MMDB变更时,站点间分布式 MMDB的实现 方法的流程示意图;
图 19为本发明实施例提供的站点系统的示意图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清 楚、 完整地描述, 显然, 所描述的实施例仅仅是本发明一部分实施例, 而不是 全部的实施例。基于本发明中的实施例, 本领域普通技术人员在没有作出创造 性劳动前提下所获得的所有其他实施例, 都属于本发明保护的范围。 如图 1所示, 本实施例提供一种分布式 MMDB的实现方法, 该方法主要 涉及 MMDB和管理该 MMDB的令牌控制器, 包括:
步骤 101 , MMDB发送包含节点 MMDB信息的消息到至少两个令牌控制 哭. — — 在本实施例以及下述各个实施例中, 上述节点 MMDB信息至少包括: 本 地 MMDB的名称, IP地址, 端口, 数据库优先级别等。
例如: 某集群 1中的 MMDB1将包含本身的节点 MMDB信息发送到管理 集群 1 的令牌控制器 1 和令牌控制器 2, 其中, 该节点 MMDB信息包括: MMDB1的 MMDB名称, IP地址, 端口, 以及 MMDB1的优先级别。
在一个集群内, 一般主 MMDB对设备性能要求最高, 为了能够使这种性 能最高的设备作为主 MMDB工作, 因此在本实施例中还包括: 组成集群的每 个 MMDB 设置有数据库优先级别, 数据库优先级用于指示集群内作为主 MMDB工作的先后顺序。 故而上述 MMDB1的数据库优先级别是用于指示集 群 1内 MMDB1作为主 MMDB工作的优先级别。
一般集群中可以包含有多个 MMDB , 故而若该集群 1 中可以还有 MMDB2, MMDB3....执行方式与上述 MMDB1相似, 在此不赞述。
步骤 102, MMDB 分别接收来自至少两个令牌控制器的包含内存数据库 列表的消息, 其中, 内存数据库列表中包括根据至少一个节点内存数据库信息 整理的集群内信息;
本实施例以及下述实施例中, 该集群内信息至少包括: 组成集群的每个 MMDB的节点 MMDB信息、 组成集群的每个 MMDB的主从模式信息, 以及 发送 MMDB列的令牌控制器的控制器优先级别。
例如:令牌控制器 1接收到集群 1中 MMDB1的节点 MMDB信息以及其 他 MMDB的节点 MMDB信息后, 根据 MMDB1的节点 MMDB信息和以及 其他 MMDB的节点 MMDB信息整理出 MMDB列表, 该 MMDB列表中包括 如: 集群 1中的每个 MMDB的节点 MMDB信息,每个 MMDB的主从模式信 — — 息, 以及令牌控制器 1的控制器优先级别。 同理, 令牌控制器 2也是如此。
在具体的实施例中, 令牌控制器 1将包含该 MMDB列表的消息发送到集 群 1中的每个 MMDB,如 MMDB1。令牌控制器 2也将包含该 MMDB列表的 消息发送到集群 1中的每个 MMDB ,如 MMDB1。以便 MMDB1等根据 MMDB 列表中的集群内信息处理集群内的事务。
步骤 103 , MMDB根据内存数据库列表中的集群内信息处理集群内的事 务。
本实施例以及下述实施例中, 该集群内事务至少包括: 由 MMDB进入或 退出该集群, 该集群内的 MMDB故障, 该故障的 MMDB恢复故障, 管理该 集群的令牌控制器故障, 该故障的令牌控制器恢复故障,有写入操作请求请求 将数据信息写入 MMDB等。
当管理的集群的令牌控制器故障时,为了保证可以有其他令牌控制器接管 该故障的令牌控制器的工作, 并且无需闲置的设备以及复杂的双机软件,故而 在本实施例提供的方法中,还包括: 管理集群的每个令牌控制器设置有控制器 优先级别,控制器优先级别用于指示集群内优先作为主令牌控制器工作的先后 顺序。故而上述令牌控制器 1上也设置有控制器优先级别, 该级别用于指示集 群 1内令牌控制器 1作为主令牌控制器工作的优先级,主令牌控制器即相当于 主令牌控制器, 非工作的从令牌控制器相当于从令牌控制器。 同理, 令牌控制 器 2也是如此。
因为 MMDB会接收到多个令牌控制器发送过来的, MMDB列表,为了降 低方法的难度, 在本实施例的方法中, 还方法包括: 当接收到的包含 MMDB 列表的消息是来自至少两个令牌控制器中的主令牌控制器时, 根据 MMDB列 — — 表中的集群内信息处理集群内事务包括:
以来自主令牌控制器的 MMDB 列表中的集群内信息为准处理集群内事 务。 即以主令牌控制器发送而来的 MMDB列表为准, 其他的从令牌控制器发 送而来的 MMDB列表作备用存储,以便主令牌控制器故障时,用作不时之需。
例如: MMDB 1接收到令牌控制器 1包含 MMDB列表的消息, 该 MMDB 列表中包括根据集群 1中 MMDB1及其他多个 MMDB的节点 MMDB信息整 理的集群内信息,如:集群 1中的每个 MMDB的节点 MMDB信息,每个 MMDB 的主从模式信息, 以及令牌控制器 1的控制器优先级别。 同理, MMDB接收 到令牌控制去 2 的包含 MMDB 列表的消息, 该列表中包含根据集群 1 中 MMDB1及其他多个 MMDB的节点 MMDB信息整理的集群内信息, 如: 集 群 1中的每个 MMDB的节点 MMDB信息,每个 MMDB的主从模式信息, 以 及令牌控制器 2的控制器优先级别。 设令牌控制器 1的控制器优先级别最高, 为主令牌控制器, 因此 MMDB1将以令牌控制器 1的 MMDB列表为准, 从令 牌控制器, 即令牌控制器 2的 MMDB作为备份保存。
需要说明的是,本实施例中提供的非工作的令牌控制器所在的设备并非闲 置, 也就说, 即便是作为非工作的令牌控制器也不会不工作, 等待主令牌控制 器故障, 并接替其工作, 故而非工作的令牌控制器也是正常工作的设备(即热 机), 因此不会产生需要购置多台设备的问题, 也不需要采用双机软件控制。
在本实施例提供的方法中, 通过与令牌控制器的交互获取到的 MMDB列 表, 并根据该列表处理如设备故障, 或写入操作请求等集群事务的技术手段, 可解决现有技术中采用双机软件处理故障时产生的需要冷机备份, 过程复杂, 易故障, 可靠性差的技术问题, 进而取得了可实现热机备份, 无需双机软件操 — — 控, 不易故障, 可靠性较高的技术效果<
本实施例提供一种分布式 MMDB的实现方法, 在该方法中, 包括一个分 布式 MMDB集群,该集群中包括至少两个以上的 MMDB , 以及管理该集群中 MMDB的至少两个以上的令牌控制器,并且 MMDB既可以与令牌控制器合设 在相同设备, 也可以部署在不同的设备上, 其中, 扩展各个 MMDB与令牌控 制器间的通信协议, 包括: 每个令牌控制器设置有一个名称(该名称在集群内唯一), 设置有在集群 中唯一的控制器优先级别, 设置有该集群中每个 MMDB 的地址信息; 每个 MMDB设置有一个名称(该名称在集群内唯一),设置有在集群中唯一的数据 库优先级别, 以及设置有管理该集群的每个令牌控制器的地址信息。
如图 2所示的场景,描述一种 MMDB在登入或保持心跳或退出该集群时, 分布式数据库的实现方法。 包括:
(一) 当有 MMDB登入集群时, 该 MMDB启动后向每个令牌控制器均 注册, 下面以该 MMDB是 MMDB1为例进行描述, 如图 3所示, 包括:
步骤 201 , MMDB1向每个令牌控制器发送注册消息, 以便与每个令牌控 制器建立连接,该注册消息包含 MMDB1的节点 MMDB信息,具体可以包括: MMDB1名称, MMDB 1的 IP地址, MMDB端口, MMDB 1的数据库优先级 别等。
步骤 202, 令牌控制器在接收到该注册消息后, 将包含该集群的集群内信 息的 MMDB列表在集群内广播, 以便响应 MMDB1 , 同时将 MMDB1加入该 集群的这一状态通知集群中的其他 MMDB。这样,每个在网的 MMDB都可以 — — 获知新加入的 MMDB, 并且才艮据新加入的 MMDB 的控制器优先级别进行调 其中, 该 MMDB的列表包括: 每个 MMDB的名称, IP地址及端口, 主 从模式信息, 以及本令牌控制器的控制器优先级别。 这里主从模式信息可以包 括了本网络中,哪个令牌控制器是主令牌控制器,哪些令牌是从令牌控制器等。
如图 4所示, (二) 当 MMDB1登入集群后, 需要与令牌控制器保存心跳 步骤 301 , MMDB1定时向所有令牌控制器发起心跳消息, 该心跳消息包 括 MMDB 1的节点 MMDB信息。
上述所有令牌控制器包括令牌控制器 1 , 令牌控制器 2和令牌控制器 3。 该 MMDB信息具体可参照下表一
Figure imgf000013_0002
Figure imgf000013_0001
其中, MMDB名称: MMDB 1集群内唯一名称
MMDB IP地址: MMDB1集群内 IP地址
MMDB 端口: MMDB1集群 IP端口号
MMDB 优先级: MMDB的控制器优先级, 可由 1开始增加, 数字越小, 优先级越高。
步骤 302 , 各令牌控制器接收到该 MMDB1 的心跳消息后, 广播包含 MMDB列表的响应消息到集群中的所有 MMDB。
每个 MMDB接收到 MMDB列表后均保存该列表, 并根据定时接收到的 心跳消息时时更新 MMDB列表中的集群内信息。
该 MMDB列表具体可参照下表二 - -
Figure imgf000014_0002
Figure imgf000014_0001
其中, MMDB名称: 分布式 MMDB系统内唯一名称
MMDB IP地址: 分布式 MMDB系统内 IP地址
MMDB 端口: 分布式 MMDB系统 IP端口号
MMDB 优先级: MMDB 数据库优先级, 可由 1开始增加的整数, 数字 越小, 优先级越高。
属性: 该 MMDB的主从模式信息, 由令牌控制器计算指定。
令牌控制器的优先级别: 广播该 MMDB列表的令牌控制器的控制器优先 级别。
上述实施例仅以 MMDB1 为例描述了其定时发送心跳消息与令牌控制器 保持交互的过程, 实际上, 该过程是每个 MMDB均执行的步骤, 具体执行方 式与 MMDB1类似, 在此不赞述。
每个 MMDB通过上述注册及上述与令牌控制器的心跳流程, 可以与令牌 — — 控制器交互彼此信息,了解集群中各 MMDB以及各令牌控制器的状况获取到: 所有令牌控制器的信息, 包括每个令牌控制器的控制器优先级; 集群中所有 MMDB, 每个 MMDB名称, IP地址及端口号及其主从模式 信息。
MMDB只以控制器优先级最高的主令牌控制器的 MMDB列表为准,其它 级别令牌控制器播报的集群 MMDB列表数据, 仅做备份, 在主令牌控制器发 生故障心跳丟失时, MMDB选择一个控制器优先级次高的令牌控制器作为主 令牌控制器, 并将其发来的 MMDB列表生效。
(三 )当有 MMDB1退出集群时, 下面以该 MMDB是 MMDB1为例进行 描述, 参照图 3 , 该 MMDB1退出前向每个令牌控制器均注销, 因此 MMDB1 向每个令牌控制器发送注销消息以便与每个令牌控制器撤销连接,注销消息包 含 MMDB的节点 MMDB信息。 具体执行过程与注销时相似。 参照图 5所示的令牌控制器故障的场景, 如果在一段时间内, MMDB没 有收到某令牌控制器发送过来的 MMDB列表, 或者如果令牌控制器也定时发 送心跳消息到 MMDB, 那么当一段时间内, MMDB没有接到该令牌控制器的 心跳消息, 则 MMDB可以认为该令牌控制器故障, 一台令牌控制器发生故障 时, 主要包括以下两种情况:
发生故障的令牌控制器的控制器优先级别最高, 即主令牌控制器故障,但 是其它令牌控制器工作正常, 即从令牌控制器未故障, 此时需要由新的令牌控 制器作为主令牌控制器接管该故障的令牌控制器的工作;
发生故障的控令牌制器的控制器优先级别不是最高, 即从令牌控制器故 — — 障, 此时, 因为只有优先级最高的令牌控制器是工作的主令牌控制控制器, 其 它优先级的令牌控制器只作热备份用, 所以 MMDB可以不作任何特殊处理。
因此, 本实施例提供的分布式 MMDB的实现方法, 是用于当集群内的事 务为: 至少两个令牌控制器中的一个令牌控制器故障时,如图 6所示, MMDB 根据上述 MMDB列表中的集群内信息处理集群内的事务主要包括如下步骤: 步骤 601 , MMDB根据当前最新的 MMDB列表中的集群内信息确定故障 的令牌控制器的控制器优先级别;
步骤 602, 如果故障的令牌控制器的控制器优先级别为最高控制器优先级 另' J , 则执行步骤 603; 否则, 执行步骤 604;
步骤 603 , MMDB根据集群内信息从故障的令牌控制器以外的其它令牌 控制器中选择当前控制器优先级别最高的令牌控制器作为主令牌控制器。
步骤 604, 结束本流程。
具体地, 以 MMDB是 MMDB 1为例,举例来说 MMDB 1发现令牌控制器 1故障, 并根据之前该令牌控制器 1发送过来的 MMDB列表中的集群内信息 确定该令牌控制器 1的控制器优先级别, 假设该控制器优先级别为 A。
如果上述 A是最高控制器优先级别, 则代表故障的令牌控制器 1是工作 的主令牌控制器,因此需要重新确定主令牌控制器,故而 MMDB1根据 MMDB 列表中的集群内信息从除令牌控制器 1 以外的其他有效的从令牌控制器中选 择出控制器优先级别次高的令牌控制器 2, 并以该令牌控制器 2作为新的主令 牌控制器,此后将以令牌控制器 2发送过来的 MMDB列表为准进行事务处理; 如果上述 A不是最高控制器优先级别, 则代表故障的令牌控制器 1是从令牌 控制器, 不会对集群带来过大的影响, 因此可不采取特殊处理而结束流程。 在 — — 这里, H没控制器优先级别 A为最高控制器优先级别来进行说明。
在本实施例提供的方法中, 当有令牌控制器故障时, MMDB可根据该故 障的令牌控制器的优先级别判断是否为主令牌控制器, 若判定是, 则根据 MMDB 列表中的集群内信息可选择出控制器优先级别次高的令牌控制器作为 新的主令牌控制器, 进而保证了主令牌控制器故障时, 可以有从令牌控制器迅 速的接替原主令牌控制器的工作, 并且由于该接替的令牌控制器也是热机, 所 以不会产生延时, 也避免了冷机备份导致的购机成本高, 双机软件复杂易故障 的技术问题, 故而取得了减少购机成本, 筒单方便, 可靠性高的有益效果。 上述描述了集群内事务是令牌控制器故障时,分布式 MMDB的实现方法, 那么相应地, 下面将提供一种当该集群内事务是故障的令牌控制器恢复故障 时, 分布式 MMDB的实现方法。
如果故障的令牌控制器故障恢复重新启动, 该出故障的令牌控制器,将通 过注册流程重新加入集群中, 因此 MMDB能够重新接收到该故障的令牌控制 器发送而来的 MMDB列表, 具体注册流程可参照上述图 3对应的实施例, 在 此不赘述。如果一台故障的令牌控制器重新注册进入集群中, 主要包括以下两 种情况:
故障恢复的令牌控制器的控制器优先级别比当前的主令牌控制器的控制 器优先级别高, 那么该故障恢复的令牌控制器在加入集群后,应该作为新的主 令牌控制器使用;
故障恢复的控令牌制器的控制器优先级别比当前的主令牌控制器的控制 器优先级别低, 那么该故障恢复的令牌控制器在加入集群后,将作为从令牌控 — — 制器使用, 此时, 因为只有优先级最高的令牌控制器是工作控制器, 其它优先 级的令牌控制器只作热备份用, 所以 MMDB可以不作任何特殊处理。
如图 7所示, 当集群内故障恢复的令牌控制器重新进入集群内时, MMDB 根据 MMDB列表中的集群内信息处理集群内的事务包括:
步骤 701 , 在接收到来自故障恢复的令牌控制器的包含 MMDB列表的消 息后, MMDB根据 MMDB列表中的集群内信息确定故障恢复的令牌控制器的 控制器优先级别;
具体地, 以 MMDB是 MMDB1为例, MMDB1接收到故障恢复的令牌 控制器 1发送的包含 MMDB列表的注册消息 (也可以是心跳消息), 并根据 该 MMDB列表中的集群内信息确定故障恢复的令牌控制器 1的控制器优先级 另 ij , 该控制器优先级别为 A。
步骤 702, 如果故障恢复的令牌控制器的控制器优先级别比当前主令牌控 制器的控制器优先级别高, 则执行步骤 703; 否则执行步骤 705。
具体地, 举例来说, 设当前主令牌控制器 2的控制器优先级别是 a, 判断 a是否比 A的控制器优先级别低,如果 a比 A的级别低,则代表故障恢复的令 牌控制器 1应该可以作为新的主令牌控制器使用, 执行步骤 703; 否则代表故 障恢复的令牌控制器 1是从令牌控制器, MMDB可以不做特殊处理, 执行步 骤 705。
步骤 703 , MMDB根据来自当前主令牌控制器的 MMDB列表判断故障恢 复的令牌控制器的 MMDB列表的是否可用; 如果判断故障恢复的令牌控制器 的 MMDB库列可以使用, 则执行步骤 704; 否则在下一次接收到故障恢复的 令牌控制器的 MMDB列表时, 继续执行步骤 703。 — — 具体地, 例如: MMDB1根据主令牌控制器 2的 MMDB列表核对故障恢 复的令牌控制器 1是否一致, 即令牌控制器 2的 MMDB列表上的数据是否与 令牌控制器 1的 MMDB列表上的数据一致, 若不一致, 说明该令牌控制器 1 还未与集群内所有 MMDB建立正常心跳, 不可以使用, 因此需要对下一次心 跳消息发送过来的 MMDB 列表进行继续核对, 确定是否与令牌控制器 1 的 MMDB列表数据一致;若一致,则说明该令牌控制器 1已与集群内所有 MMDB 建立正常心跳,进入正常工作状态, 因此该 MMDB可以使用,可执行步骤 704 步骤 704, MMDB选择故障恢复的令牌控制器作为新的主令牌控制器。 具体地, 例如: MMDB1切换到故障恢复的令牌控制器 1 , 将故障恢复的 令牌控制器 1作为新的工作的主令牌控制器,并以该令牌控制器 1发送过来的 MMDB列表为准进行集群内事务处理,令牌控制器 2作为从令牌控制器使用。
步骤 705 , 结束本流程。
本实施例提供的方法,可保证控制器优先级别高的令牌控制器在故障恢复 后继续作为主令牌控制器使用, 因为优先级别高的令牌控制器其配置, 或性能 可能更优越, 更适合作为主令牌控制器工作, 故而在故障恢复后, 可继续使用 该性能优越的令牌控制器作为主令牌控制器的技术方案,有助于保证令牌控制 器的处理能力, 进而提高可靠性。 如图 8所示,提供一种当有写入操作请求时,分布式 MMDB的实现方法, 在分布式 MMDB的集群中, 主 MMDB 已从来自令牌控制器的消息中获得集 群内的 MMDB列表, 那么当集群内的事务为: 接收到写入操作请求时, 根据 MMDB列表中的集群内信息处理集群内的事务包括: — — 步骤 801 , 主 MMDB根据写入操作请求更新本地 MMDB中的数据信息; 具体地, 主 MMDB根据写入操作请求中的插入, 删除, 更新等操作内存 更新本地 MMDB中的数据信息, 并对每个写入操作请求按接收到的顺序添加 操作序号。
步骤 802,主 MMDB根据 MMDB列表中的集群内信息将写入操作请求更 新到从 MMDB , 以便从 MMDB根据写入操作请求更新其本地 MMDB中的数 据信息
具体地, 主 MMDB在更新完本地 MMDB后, 将该写入操作请按照各从 MMDB数据库优先级高低由先到后的顺序, 发送到各从 MMDB, 可确保数据 库优先级高的从 MMDB先收到该写操作请求,收到该写操作请求的从 MMDB 根据写入操作请求中的插入, 删除, 更新等操作内存更新本地 MMDB中的数 据信息, 并同样对每个接收到的写入操作请求按接收到的顺序添加操作序号。 例如: 从 MMDB1接收到第五个写入操作请求, 故而添加序号 5到更新后的 MMDB1的数据信息上,从 MMDB2接收到该第五个写入操作请求,添加序号 5到更新后的 MMDB2的数据信息上。
一般 MMDB的可靠性是这样保证的: 如果一台从 MMDB发生故障, 对 MMDB所属集群没有大的影响,仅仅影响集群 MMDB并发查询效率,增加一 个从 MMDB, 效率就恢复。但是如果主 MMDB发生故障, 这时整个集群就没 有 MMDB能够执行写操作的数据库, 因此这样的故障是必须解决的。 在本实 施例中, 当集群事务为: 至少一个 MMDB中其中某一 MMDB故障时, 如图 9 所示, 分布式 MMDB的实现方法包括:
步骤 901 ,令牌控制器根据 MMDB列表中集群内信息确定故障的 MMDB — — 的数据库优先级别;
例如: 令牌控制器 1 (可以是工作的主令牌控制器, 也可以是从令牌控制 器 )根据 MMDB列表中的集群内信息, 确定故障的 MMDB1的数据库优先级 另' J , 设故障的 MMDB1的数据库优先级别为 B。
步骤 902,如果故障的 MMDB的数据库优先级别为最高控制器优先级别, 则执行步骤 903; 否则执行步骤 904;
步骤 903 , 令牌控制器根据集群内信息从故障的 MMDB 以外的其它 MMDB中选择当前数据库优先级别最高的 MMDB作为新的主 MMDB , 并根 据选择过程更新 MMDB列表中的主从模式信息。
步骤 904, 令牌控制器发送该 MMDB列表到集群中的各 MMDB。
举例来说, 如果令牌控制器 1 确定 B 为最高数据库优先级别, 则代表 MMDB1为主 MMDB, 故而需要由新的 MMDB接管该 MMDB1的工作, 因 此根据集群内信息从除 MMDB 1以外的其他从 MMDB中选择出当前数据库优 先级别最高的 MMDB2 , 即与 B相比, 数据库优先级别次高的 MMDB2作为 新的主 MMDB接替 MMDB1 的工作, 并根据选择出 MMDB2 的过程更新 MMDB列表, 包括更新 MMDB2的主从模式信息, 即将 MMDB2由 "从" 改 为 "主", 标识 MMDB1故障等。 并发送该更新后的 MMDB列表到集群中的 各 MMDB , 成为新的主 MMDB的 MMDB2将接管 MMDB1的工作, 如执行 写操作等;如果令牌控制器 1确定 B不是最高数据库优先级别,则代表 MMDB1 为从 MMDB , 故而可以无需采取特殊处理, 仅在发送的 MMDB列表中标识 MMDB1故障即可。
在本实施例中,令牌控制器会可在各从 MMDB中选择一个 MMDB ,作为 — — 新的主 MMDB, 并通过广播 MMDB列表的方式通知集群中的各 MMDB。 当 从 MMDB接收到写入操作请求后, 将转发到新的主 MMDB; 新的主 MMDB 根据该写入操作请求更新数据信息后,在将该写入操作请求同步各从 MMDB。 但这里有个限制:我们应该主动选择哪一个 MMDB为新的主 MMDB。一般在 一个集群内会部署若干 MMDB,但承载这些 MMDB的设备能力不一样,有的 设备 CPU及内存性能更好, 成本很高, 我们更希望用这样的设备承担 MMDB 写操作, 因为写操作是读操作性能的四分之一左右, 因此为了实现自动的完成 故障切换的操作过程, 必须确定原则。 为此, 按承载 MMDB设备的性能的高 到低或其它因素,为各设备安装的 MMDB配置一个数据库优先级。令牌控制器 能够动态选择数据库优先级别最高的 MMDB ,将其指定为主 MMDB使用,并 广播通知这一指定到集群内各 MMDB , 即可降低手工切换带来的延时, 也可 提高分布式 MMDB的可靠性。
上面描述了当有 MMDB故障时, 分布式 MMDB的实现方法, 那么下面 将继续介绍当故障的 MMDB恢复, 即 MMDB为成为故障恢复的 MMDB时, 本实施例提供的分布式 MMDB的实现方法如图 10所示, 包括:
步骤 1001 , 故障恢复的 MMDB向令牌控制器发送包含其节点 MMDB信 息的消息, 令牌控制器在接收来自故障恢复的 MMDB的包含节点内存数据信 息的消息后, 根据故障恢复的 MMDB 的节点 MMDB 信息确定故障恢复的 MMDB的数据库优先级别,并将该 MMDB的节点信息整理到 MMDB列表中, 发送到每个 MMDB。 — — 例如: 故障恢复的 MMDBl加入集群, 首先向令牌控制器 1 (该令牌控制 器 1 可以是主令牌控制器, 也可以是从令牌控制器)注册。 注册消息中包括 MMDB1的节点 MMDB信息。令牌控制器 1收到该注册消息后,确定 MMDB1 的数据库优先级别, 因为当前集群中已有主 MMDB2 正常工作, 所以即便 MMDB1 的数据库优先级别比 MMDB2 的数据库优先级别高, 令牌控制器 1 也不会立刻将 MMDB 1选择为新的主 MMDB , 因为需要 MMDB 1先完成数据 信息更新, 当 MMDB 1中的数据信息与当前主 MMDB2数据信息一致时, 才 能被选择为新的主 MMDB,故而,令牌控制器 1仅需将 MMDB1的节点 MMDB 信息整理到 MMDB列表中, 并将该列表发送到每个 MMDB。
步骤 1002, 如果故障恢复的 MMDB的数据库优先级别比当前主 MMDB 的数据库优先级别高, 则该故障恢复的 MMDB根据 MMDB列表中集群内信 息向主 MMDB发送数据更新请求, 数据更新请求中包括故障恢复的 MMDB 中最后记录的数据信息的操作序号, 以便当前主 MMDB返回接续操作序号的 数据信息; 否则, 该故障恢复的 MMDB可无需采取特殊处理, 不进行下述步 骤, 而是结束本流程。
例如: 接收到令牌控制器 1发送的 MMDB列表的 MMDB1 , 根据集群内 信息获知当前集群内的主 MMDB是 MMDB2。
如果故障恢复的 MMDB1的数据库优先级别比当前主 MMDB2的数据库 优先级别高, 则 MMDB2向 MMDB2发送数据更新请求, 该数据更新请求中 包括 MMDB1中最后记录的数据信息的操作序号。
如果故障恢复的 MMDB1的数据库优先级别比当前主 MMDB2的数据库 优先级别氏, MMDB1可直接结束本流程。 — — 步骤 1003 , 当前主 MMDB在收到该数据更新请求后, 返回接续操作序号 的数据信息到该故障恢复的 MMDB;
例如: 当前的主 MMDB2接收到数据更新请求中的操作序号是 10, 则代 表故障恢复的 MMDB1在故障前最后执行的写入操作的操作序号是 10。 故而 MMDB2将操作序号 11到当前最新的操作序号 30的数据信息发送到 MMDB1。
步骤 1004,该故障恢复的 MMDB根据返回的接续操作序号的数据信息更 新故障恢复的 MMDB的本地 MMDB , 并发送更新完成响应到主 MMDB以便 主 MMDB执行退出主 MMDB模式的处理。
例如: 故障恢复的 MMDB1接收到当前主 MMDB2返回的数据信息后, 更新 MMDB1的本地 MMDB, 完成数据同步过程, 并发送更新完成响应消息 到 MMDB2。
步骤 1005 , 该当前主 MMDB接收到该更新完成响应消息后, 执行退出主 MMDB模式的处理,包括:该当前主 MMDB向令牌控制器发起退出主 MMDB 模式的请求, 同时将本地写功能禁止, 一旦有新的写入操作请求, 转给上述 故障恢复的, 也是数据库优先级最高的 MMDB。
例如: 当前主 MMDB2接收到更新完成响应消息后, 向令牌控制器 1发 起退出主 MMDB模式的请求, 同时将 MMDB2的本地写功能禁止, 一旦有 新的写入操作请求, 转给上述故障恢复的 MMDB1。
步骤 1006 , 令牌控制器在当前主 MMDB的退出主 MMDB模式后, 选择 故障恢复的 MMDB为新的主 MMDB ,将故障恢复的 MMDB为新的主 MMDB 的主从模式信息更新到 MMDB 列表中, 并将该 MMDB 列表广播给每个 MMDB, 每个 MMDB可通过该 MMDB列表获知当前主 MMDB已被切换为 — — 新的 MMDB。
例如: 令牌控制器 1在当前主 MMDB2的退出主 MMDB模式后, 选择故 障恢复的 MMDB1为新的主 MMDB。 将该信息整理到 MMDB列表, 并广播 该 MMDB列表给每个 MMDB, 每个 MMDB获知当前主 MMDB已被切换为 MMDB1 , 此后, 写入操作请求由最高优先数据库级 MMDB1执行。 集群内其 它 MMDB收到写入操作请求, 都将转给 MMDB1执行。
在本实施例提供的方法中, 当数据库优先级最高的 MMDB故障恢复, 重 新启动时向令牌控制器注册, 此刻还不能立即将其选择为主 MMDB, 先要完 成数据信息复制过程, 只能当前主 MMDB 同步数据到该数据库优先级最高 MMDB并达到数据一致时, 该当前主 MMDB 才会向令牌控制器申请放弃主 席。 这时令牌控制器重新将新注册的数据库最高优先级的 MMDB 确定为主 MMDB 并广播 MMDB 列表到集群内所有 MMDB。 因此可实现性能优越的 MMDB在故障恢复后仍能再次作为主 MMDB使用的目的。
本实施例提供一种 MMDB ,如图 11所示,该 MMDB包括:发送模块 11 , 接收模块 12, 处理模块 13。
发送模块 11 ,用于发送包含节点 MMDB信息的消息到至少两个令牌控制 器; 接收模块 12, 用于分别接收来自至少两个令牌控制器的包含 MMDB列表 的消息,其中, MMDB列表中包括根据至少一个节点 MMDB信息整理的集群 内信息; 处理模块 13 , 用于根据 MMDB列表中的集群内信息处理集群内的事 务。 — — 在发明的另一本实施例中, 如图 12所示, 在该 MMDB中, 处理模块 13 可以包括: 故障确定单元 131 , 第一选择单元 132。
故障确定单元 131 , 用于当有令牌控制器故障时, 根据 MMDB列表中的 集群内信息确定故障的令牌控制器的控制器优先级别;
第一选择单元 132, 用于当故障确定单元 131确定故障的令牌控制器的控 制器优先级别为最高控制器优先级别时,根据集群内信息从故障的令牌控制器 以外的其它令牌控制器中选择当前控制器优先级别最高的令牌控制器作为主 令牌控制器。
如图 12, 处理模块还可以包括: 恢复确定单元 134, 可用确定单元 135 , 第二选择单元 136。
恢复确定单元 134, 用于当有故障恢复的令牌控制器重新进入集群内时, 根据接收模块接收到的来自故障恢复的令牌控制器的 MMDB列表中的集群内 信息确定故障恢复的令牌控制器的控制器优先级别;
可用确定单元 135 , 用于当恢复确定单元 134确定故障恢复的令牌控制器 的控制器优先级别比当前主令牌控制器的控制器优先级别高时,根据来自当前 主令牌控制器的 MMDB列表确定故障恢复的令牌控制器的 MMDB列表的可 用性;
第二选择单元 136, 用于当时可用确定单元 135确定定故障恢复的令牌控 制器的 MMDB列具有可用性时, 选择故障恢复的令牌控制器作为新的主令牌 控制器。
如图 12, 处理模块还可以包括: 写入单元 133 , 同步恢复单元 137。
写入单元 133 , 用于在处于主 MMDB状态时, 接收写入操作请求, 并根 - - 据写入操作请求更新本地 MMDB中的数据信息, 再根据 MMDB列表中的集 群内信息将写入操作请求更新到从 MMDB ,以便从 MMDB根据写入操作请求 更新其本地 MMDB中的数据信息。
同步恢复单元 137, 用于在数据库优先级别比当前主 MMDB的数据库优 先级别更高时, 根据 MMDB列表中集群内信息向主 MMDB发送数据更新请 求, 数据更新请求中包括更高的 MMDB中最后记录的数据信息的操作序号, 以便主 MMDB返回接续操作序号的数据信息, 再根据返回的接续操作序号的 数据信息更新本地 MMDB的数据信息,并发送更新完成响应到主 MMDB, 以 便主 MMDB执行退出主 MMDB模式的处理。
本实施例提供的 MMDB可以与令牌控制器合设在同一设备上, 也可以部 署在不同的设备上, 组网十分灵活。 不需要用 Active-Standby双机部署, 不用 执行双机切换动作, 较筒单, 不易故障, 切换过程可是自动完成, 可避免手动 切换产生的延时, 提高了分布式 MMDB的可靠性。
本实施例提供一种令牌控制器, 如图 13所示, 该令牌控制器包括: 接收 模块 21 , 获取模块 22, 发送模块 23。
接收模块 21 ,用于接收来自至少一个 MMDB的包含节点内存数据信息的 消息;获取模块 22,用于根据节点 MMDB信息获取 MMDB列表,其中 MMDB 列表中包括根据至少一个节点 MMDB信息整理的集群内信息; 发送模块 23 , 用于将包含 MMDB列表的消息发送到至少一个 MMDB ,以便至少一个 MMDB 根据 MMDB列表中的集群内信息处理集群内的事务。 — — 在本实施例中, 如图 13所示, 该令牌控制器还包括: 故障确定单元 24, 第一选择单元 25。
故障确定单元 24 , 用于当至少一个 MMDB中其中一 MMDB故障时, 根 据 MMDB列表中集群内信息确定故障的 MMDB的数据库优先级别;
第一选择单元 25 , 用于当故障确定单元 24确定故障的 MMDB的数据库 优先级别为最高控制器优先级别时, 根据集群内信息从故障的 MMDB以外的 其它 MMDB中选择当前数据库优先级别最高的 MMDB作为新的主 MMDB。
进一步地, 该令牌控制器还可以包括: 恢复确定单元 26, 第二选择单元
27。
恢复确定单元 26,用于在从故障恢复的 MMDB接收到包含节点内存数据 信息的消息后, 根据故障恢复的 MMDB的节点 MMDB信息确定故障恢复的 MMDB的数据库优先级别;
第二选择单元 27 , 用于当恢复确定单元 26确定故障恢复的 MMDB的数 据库优先级别比当前主 MMDB的数据库优先级别高时, 在当前主 MMDB的 退出主 MMDB模式后, 选择故障恢复的 MMDB为新的主 MMDB。
本实施例提供的令牌控制器适合部署在工作的设备上, 即热机, 因此, 可 避免部署复杂的双机软件到冷机, 由此导致主备切换时启动冷机,产生延时的 技术问题, 进而取得了当需要进行令牌控制器切换时, 可以减少延时, 提高可 靠性, 降低购机成本的技术效果。
本实施例提供一种分布式 MMDB系统, 如图 2所示, 包括: MMDB集群 — — 和令牌控制器集群, 其中, MMDB 集群包括至少两个令牌控制器, 令牌控制 器集群包括: 至少一个 MMDB;
其中,每个 MMDB ,用于发送包含节点 MMDB信息的消息到至少两个令 牌控制器, 并分别接收来自至少两个令牌控制器的包含 MMDB列表的消息, 其中, MMDB列表中包括根据至少一个节点 MMDB信息整理的集群内信息, 存储内测数据列表, 并根据 MMDB列表中的集群内信息处理集群内的事务; 每个令牌控制器, 用于接收 MMDB的包含节点内存数据信息的消息, 并 根据节点 MMDB信息获取 MMDB列表,再将包含 MMDB列表的消息发送到 至少一个 MMDB。
本实施例提供的分布式 MMDB系统,无需双机软件控制 MMDB,无需主 备双机方案,每个 MMDB可通过与令牌控制器之间的交互获取 MMDB列表, 并根据 MMDB列表处理集群内的事务, 故而避免了为处理主备倒换等事务时 产生的延时问题, 降低了执行复杂度, 无需提供闲置的备用设备, 减少了购机 成本, 提高了分布式 MMDB的可靠性。 本实施例还提供一种分布式 MMDB的实现方法, 在该方法中, 包括至少 两个站点, 第一站点和第二站点, 每个站点中部署至少一个 MMDB集群, 和 管理 MMDB集群的令牌控制器集群。 其中, 每个 MMDB集群由多个 MMDB 组成,每个令牌控制器集群由多个令牌控制器组成,且每个令牌控制器上配置 了异地站点的令牌控制器的 IP地址及端口。
因为一个 MMDB只能属于一个 MMDB集群, 并且写操作请求仅能在其 所属 MMDB 集群内的主 MMDB 上操作, 故而为了保证对其所属集群外的 — —
MMDB不进行复制, 因此本实施例中, 需要做如下工作:
在执行本实施例的下述步骤前, 扩展 MMDB集群的定义
1 , 将一个站点定义为一个域, 域名全局唯一, 例如: 站点 1的域名, 即 全局站点名为 mmdb_Sitel , 站点 2的域名, 即全局站点名为 mmdb_Site2;
2, 站点内的每个 MMDB 集群配置有集群名称, 该名称为字符串, 且在 站点内唯一, 该集群的 MMDB全局集群名称是该集群名称与所属站点的全局 站点名的组合, 格式为: 集群名称@全局站点名。
3 , 站点内的每个令牌控制器都有令牌名称, 该名称为字符串, 且在站点 内唯一, 例如 mmdb_ringl, 该令牌控制器的全局名称是该令牌控制器在站点 内的令牌名称与其所属站点的全局站点名的组合, 格式为: 令牌名称@全局站 点名,例: ¾口: "mmdb_ringl @ mmdb_Sitel"。
4, 站点内的每个 MMDB 都有内存名称, 该内存名称为字符串, 且在站 点内唯一,例如 mmdbl,该 MMDB的全局名称是该站点内名称与站点域名组合, 格式为: MMDB名 @站点域名,例如: "mmdbl @ mmdb_Sitel"
综上, 在本实施例中, 每个站点配置有全局站点名;
站点中的每个 MMDB集群配置有集群名称, 集群名称与全局站点名组合 成 MMDB集群的全局集群名称;
站点中的每个令牌控制器配置有令牌名称,令牌名称与全局站点名组合成 令牌控制器的全局令牌器名称;
站点中的每个 MMDB 配置有内存名称, 内存名称与全局站点名组合成
MMDB的全局内存名称。
故而, 通过比较的全局站点名这个后缀,, 可以判断 MMDB或者令牌控制 — — 器是本地站点还是异地站点, 并且还可根据 @后面的全局站点名区分不同站 点。 .
进一步的, 在 MMDB集群中的每个 MMDB上设置数据库优先级别, 还 可以在每个令牌控制器上设置控制器优先级别,具体该设置出的数据库优先级 别和控制器优先级别在站点内的实施方式可参考上述图 1至图 10所对应的实 施例, 在此不赘述。
在做了上述扩展以及相应部署后, 如图 14所示, 该方法主要包括: 步骤 1401 , 第一站点的 MMDB发送包含节点 MMDB信息的消息到第一 站点的令牌控制器;
具体地, 第一站点的每个 MMDB发送包含其节点 MMDB信息的消息到 第一站点的令牌控制集群, 即每个令牌控制器。 该包含其节点 MMDB信息的 消息可以是需要周期性发送的心跳消息, 也可以是在加入该 MMDB集群时发 送的注册消息。
上述节点 MMDB信息本实施例以及下述实施例中至少包括: 所属集群名 称, 本地 MMDB的名称, IP地址, 端口, 数据库优先级别。
例如:第一站点的 MMDB1发送包含 MMDB 1的节点 MMDB信息的心跳 消息到第一站点的令牌控制器 1 , 其中, 节点 MMDB信息包括: MMDB 1所 属集群的名称, MMDB 1的本地 MMDB的名称, IP地址, 端口, 数据库优先 级别。
第一站点的 MMDB2发送包含 MMDB2的节点 MMDB信息的心跳消息到 第一站点的令牌控制器 1 , 其中, 节点 MMDB信息包括: MMDB2所属集群 的名称, MMDB2的本地 MMDB的名称, IP地址, 端口, 数据库优先级别。 — — 第一站点的 MMDB3同样如此。
步骤 1402, 第一站点的令牌控制器从第二站点的令牌控制器接收包含第 二站点的主 MMDB信息的消息;
具体地, 如图 16所示, 第一站点的每个令牌控制器与第二站点的每个令 牌控制器的通过心跳消息交互管理各自的 MMDB集群的主 MMDB信息, 进 一步的, 还可以交互彼此的令牌控制器信息。 也就是说, 通过心跳消息, 第一 站点的每个令牌控制器可以获取到发送该心跳消息的第二站点令牌控制器的 令牌控制器信息以及其管理的 MMDB集群中主 MMDB的信息。
其中, 令牌控制器信息包括: 该令牌控制器所属站点的全局站点名, 该令 牌控制器的全局名称, 该令牌控制器的控制器优先级别, 该令牌控制器的 IP 地址和端口。
其中, 该主 MMDB信息包括: 主 MMDB所属的集群的全局集群名称, 主 MMDB的全局内存名称, 以及主 MMDB的 IP地址和端口。
例如:站点 1的令牌控制器 1与站点 2的令牌控制器 1通过心跳消息交互, 通过该交互, 令牌控制器 1获取到站点 1的主 MMDB信息, 和令牌控制器 2 的令牌控制器信息。 其中, 站点 1的主 MMDB信息包括: 主 MMDB所属的 集群的全局集群名称, 主 MMDB的全局内存名称, 以及主 MMDB的 IP地址 和端口; 令牌控制器 2的令牌控制器信息包括: 站点 2的全局站点名, 令牌控 制器 2的全局名称, 令牌控制器 2的控制器优先级别, 令牌控制器 2的 IP地 址和端口。
同理, 令牌控制器 2也可以的通过该交互获取到站点 2的令牌控制器 1 的主 MMDB信息, 以及令牌控制器 1的令牌控制器信息。 — — 步骤 1403 ,第一站点的令牌控制器根据第二站点的主 MMDB信息和第一 站点的集群内信息获取第一站点的 MMDB列表, 其中, 第一站点的集群内信 息是根据来自第一站点的至少一个 MMDB的节点 MMDB信息整理而得; 其中, 上述集群内信息可至少包括: 组成 MMDB集群的每个 MMDB的 节点 MMDB信息、组成 MMDB集群的每个 MMDB的主从模式信息, 以及发 送 MMDB列的令牌控制器的控制器优先级别。
例如: 站点 1的令牌控制器 1根据上述来自站点 2的令牌控制器 2的主 MMDB信息和站点 1的集群内信息获取站点 1的 MMDB列表。其中,该站点 1 的 MMDB 列表中的集群内信息是根据来自站点 1 的多个 MMDB 的节点 MMDB信息整理而得;
并且, 需要说明的是: 根据站点 2的令牌控制器 2的主 MMDB信息获取 MMDB列表的具体意义是指: 如果根据站点 2的令牌控制器 2的主 MMDB 信息确定如果该站点 2的主 MMDB不在该 MMDB站点 1的 MMDB集群中, 则将站点 2的主 MMDB作为站点 1的 MMDB集群中的从 MMDB加入该站点 1的 MMDB集群。
步骤 1404,第一站点的令牌控制器将第一站点的 MMDB列表发送到第一 站点中的至少一个 MMDB , 以便 MMDB根据 MMDB列表处理站点间或站点 内的事务。
其中,上述站点间或站点内的事务是指:第一站点与第二站点之间的事务, 或第一站点内的事务,具体可包括:第一站点的写入操作请求同步到第二站点, 第二站点的写入操作请求同步到第一站点, 第一站点或第二站点的主 MMDB 故障时的写入操作请求同步处理,第一站点接收到来自应用程序的写入操作请 — — 求处理等。
例如: 站点 1的令牌控制器 1 将上述站点 1的 MMDB列表发送到站点 1 的 MMDB 1 , MMDB2, MMDB3等, 以便 MMDB 1 , MMDB2 , MMDB3才艮据 该 MMD列表处理站点 1与站点 2之间的事务, 或者站点 1内的事务。
步骤 1405 ,第一站点的 MMDB从第一站点的令牌控制器获取第一站点的
MMDB列表, 其中, MMDB列表中包括作为从 MMDB加入第一站点的第二 站点的主 MMDB信息, 以及才艮据至少一个节点 MMDB信息整理的第一站点 的集群内信息; 并根据 MMDB列表处理站点间或站点内的事务。
具体地, 第一站点的 MMDB获取到第一站点的 MMDB列表, 并根据该 MMDB列表处理第一站点与第二站点间的事务, 或者第一站点内的事务。
例如: 站点 1的 MMDB1 (该 MMDB1可以是任意的 MMDB )从站点 1 的令牌控制器 1 (该令牌控制器 1 可以是任意的令牌控制器)获取站点 1 的 MMDB列表, 其中, 该 MMDB列表中包括: 站点 1根据 MMDB集群中每个 MMDB的节点 MMDB信息整理的集群内信息, 以及作为站点 1该 MMDB集 群中的从 MMDB加入的站点 2的主 MMDB的主 MMDB信息。其中, 集群内 信息包括: 每个 MMDB的节点 MMDB信息、 每个 MMDB的主从模式信息, 以及发送 MMDB列的令牌控制器的控制器优先级别; 站点 2的主 MMDB的 主 MMDB信息包括: 该主 MMDB所属的集群的全局集群名称, 该主 MMDB 的全局内存名称, 以及该主 MMDB的 IP地址和端口。
需要说明的是: 上述步骤 1401到步骤 1405过程均是以站点 1和站点 2 为例进行描述的, 实际上还可以包括更多的站点, 如站点 3 , 站点 4等, 其它 站点的工作方式与本实施例中的站点 2相似, 如步骤 1405中, 站点 1接收的 — —
MMDB列表中还可以包括: 作为站点 1的从 MMDB加入该 MMDB集群的站 点 3的主 MMDB信息等。
并且上述步骤 1401到步骤 1405中根据 MMDB列表处理站点间或站点内 的事务之前的流程是以一个周期为例进行描述的, 在实际应用中, 站点 1的令 牌控制器与站点 2的令牌控制器是周期性的通过心跳消息进行交互的, 站点 1 的 MMDB与站点 1的令牌控制器也可以是周期性的通过心跳消息进行交互。
在本实施例提供的方法中, 通过站点间令牌控制器的交互获取彼此主 MMDB信息, 并将该对方的主 MMDB信息整理到站点的 MMDB列表中, 再 根据该 MMDB列表处理站点间或站点内的数据同步等事务, 因此解决了现有 技术中必须通过运行同步软件管理复杂的数据同步的技术问题,进而降低了站 点间数据同步的复杂度, 在保证了站点的容灾能力的同时,提高了站点间的可 靠性, 适合应用在包含多个站点的大型分布式 MMDB场景。
如图 15所示, 当站点间或站点内的事务为: 站点内的主 MMDB接收到 写入操作请求时, 根据 MDDB列表处理站点间或站点内的事务包括:
步骤 1501 , 在主 MMDB接收到来自应用程序的写入操作请求时, 第一站 点内的主 MMDB才艮据该写入操作请求更新主 MMDB的数据信息;
优选地, 步骤 1501可以通过如下方式实现:
第一站点内的主 MMDB在接收到来自应用程序的写入操作请求时, 对接 收到的写入操作请求添加操作序号, 再根据该写入操作请求更新主 MMDB的 数据信息。 — — 步骤 1502, 第一站点根据写入操作请求更新各从 MMDB的数据信息, 其 中, 各从 MMDB包括: 根据集群内信息获取的第一站点中的从 MMDB, 以及 根据主 MMDB信息获取的第二站点中的主 MMDB;
具体地, 步骤 1502 包括: 第一站点根据写入操作请求更新各从 MMDB 的数据信息, 其中, 写入请求中携带写入操作所属站点的全局站点名以及写入 操作请求的操作序号, 以便各从 MMDB根据全局站点名记录写入操作请求的 操作序号。
步骤 1503 , 第二站点的主 MMDB根据写入操作请求更新过数据信息后, 根据写入操作请求更新第二站点的从 MMDB的数据信息。
具体地, 步骤 1503 包括: 第二站点的主 MMDB根据第一站点的全局站 点名将该写入操作请求存储到第二站点的主 MMDB中用于存放第一站点的数 据信息的位置, 其中, 在该位置中, 该写入操作请求更新的数据信息对应的操 作序号即是该写入操作请求中携带的操作序号。
上述仅是以第一站点和第二站点为例进行描述,实际上还可以包括更多的 站点, 如第三站点, 此时第三站点的执行方式与第二站点相似。
例如: 参照图 17, 站点 1的主 MMDB接收到来自应用程序的第 100个写 入操作请求, 对该写入操作请求添加操作序号 100, 并该根据该写入操作请求 更新主 MMDB的数据信息, 包括插入, 删除, 更新等写入操作;
站点 1根据站点 1的 MMDB列表中个从 MMDB的 IP地址和端口可将该 写入操作请求同步到站点 1的从 MMDB1 , 从 MMDB2, 从 MMDB3 , 该写入 操作请求中携带站点 1的全局站点名, 操作序号 100, 以及插入, 删除, 更新; 其中, 从 MMDB3以从 MMDB的身份加入站点 1的站点 2的主 MMDB, 从 — —
MMDB4以从 MMDB的身份加入站点 1的站点 3的主 MMDB。
从 MMDB1根据该写入操作请求在从 MMDB1中用于存储站点 1的位置 更新从 MMDB 1的数据信息, 并将该部分的操作序号记录为 100; 从 MMDB2 根据该写入操作请求在从 MMDB2中用于存储站点 1的数据信息位置更新从 MMDB2的数据信息, 并将该部分的操作序号记录为 100; 同理, 从 MMDB3 根据该写入操作请求在从 MMDB3 中用于存储站点 1的数据信息的位置更新 从 MMDB3的数据信息,并将该部分的操作序号记录为 100;从 MMDB4根据 该写入操作请求在从 MMDB4 中用于存储站点 1 的数据信息的位置更新从 MMDB4的数据信息, 并将该部分的操作序号记录为 100;
特别的, 因为从 MMDB3同时也是站点 2的主 MMDB , 故而还会将该写 入操作请求同步到站点 2的各从 MMDB , 该写入操作请求中携带站点 1的全 局站点名, 操作序号 100, 以及插入, 删除, 更新等写入操作; 站点 2的各从 MMDB在接收到站点 2的主 MMDB , 即 MMDB3的写入操作请求后, 站点 2 的各从 MMDB根据该写入操作请求分别在各自用于存储站点 1数据信息的位 置更新对应的数据信息, 并将该部分的操作序号记录为 100; 同理, 因为从 MMDB4同时也是站点 3的主 MMDB , 故而还会将该写入操作请求同步到站 点 3的各从 MMDB, 站点 3的各从 MMDB在接收到站点 3的主 MMDB , 即 MMDB4的写入操作请求后, 站点 3的各从 MMDB根据该写入操作请求分别 在各自用于存储站点 1数据信息的位置更新对应的数据信息,并将该部分的操 作序号记录为 100。
在本实施例提供的方法中, 第一站点中的主 MMDB仅将写入操作请求同 步到第二站点的主 MMDB,再由第二站点的主 MMDB负责将该写入操作请求 - - 同步到第二站点的各从 MMDB , 而不是分别同步给第二站点的主和各从 MMDB , 故而可减少站点间的数据流量, 降低站点之间数据同步的复杂度, 即可保证容灾性, 有可提高站点间数据同步的可靠性。 如图 18所示, 本实施例提供的方法, 结合当站点间与站点内的事务为: 第二站点的主 MMDB变更时,在本实施例提供的方法中,第一站点的 MMDB 根据 MMDB列表处理站点间或站点内的事务包括:
步骤 1801 , 第二站点的令牌控制器根据心跳消息可获知主 MMDB故障, 或者有比该主 MMDB 的数据库优先级别更高的 MMDB 加入第二站点的 MMDB集群。
例如: 站点 2的令牌控制器 1 (该令牌控制器 1可以是主令牌控制器, 也 可以是从令牌控制器)接收不到当前 MMDB 集群中作为主 MMDB 工作的 MMDB1的心跳消息,或者站点 2接收到比 MMDB1的数据库优先级别更高的 MMDB2加入该 MMDB集群的注册消息。
步骤 1802 , 第二站点的令牌控制器从 MMDB集群中根据各 MMDB的数 据库优先级别选择出变更后的主 MMDB , 即新的主 MMDB , 并将该选出的结 果指示在 MMDB列表中,通过广播该 MMDB列表通知第二站点该 MMDB集 群中各 MMDB。
例如: 站点 2的令牌控制器 1根据 MMDB列表中各 MMDB的数据库优 先级别选择出 MMDB2为新的主 MMDB , 并将该选出的结果指示在 MMDB 列表中, 发送到站点 2MMDD集群中的各个 MMDB , 该各个 MMDB即可获 知 MMDB2是新的主 MMDB。 — — 步骤 1803 , 第二站点中新的主 MMDB将其 MMDB最后记录的操作序号 和主 MMDB信息发送到第二站点的令牌控制器。 该第二站点的令牌控制器将 新的主 MMDB最后记录的操作序号和新的主 MMDB的主 MMDB信息。
例如: 站点 2的 MMDB2作为主 MMDB工作后, MMDB2最后记录的操 作序号 100和 MMDB2的主 MMDB信息发送到站点 2的令牌控制器 1。 该站 点 2的令牌控制器 1将 MMDB2最后记录的操作信号 100和主 MMDB信息通 知站点 1的令牌控制器 11 (该令牌控制器 11可以是站点 1的主令牌控制器, 也可以是站点 1的从令牌控制器)。 其中, 主 MMDB信息包括: MMDB2所属 的 MMDB集群的全局集群名称, MMDB2的全局内存名称, 以及该 MMDB2 的 IP地址和端口。
步骤 1804, 第一站点的令牌控制器从第二站点的令牌控制器获取第二站 点中故障的 MMDB最后记录的操作序号和新的主 MMDB的主 MMDB信息, 并将携带操作序号和新的主 MMDB的主 MMDB信息的消息发到第一站点的 主 MMDB。
例如: 站点 1的令牌控制器 11接收到站点 2作为新的主 MMDB工作的
MMDB2最后记录的操作序号 100和 MMDB2的主 MMDB信息, 并将这些发 送到站点 1当前作为主 MMDB工作的 MMDB3。
步骤 1805 , 第一站点的主 MMDB获取第二站点中变更后的主 MMDB的 主 MMDB 信息和第二站点的主 MMDB 最后记录的操作序号, 并根据主 MMDB信息和操作序号获取对应的写入操作的数据信息。
例如: 站点 1中当前作为主 MMDB工作的 MMDB3接收到来自站点 1的 令牌控制器 11发送的站点 2新的主 MMDB ,即 MMDB2最后记录的操作序号 — —
100后, 根据 MMDB2的全局集群名或全局内存名称获知该请求来自站点 2, MMDB3中存储站点 2数据信息的位置上获取到对应操作序号 100之后的写入 操作的数据信息。
步骤 1806,第一站点的主 MMDB将写入操作的数据信息更新到第二站点 新的主 MMDB。
例如: 站点 1的 MMDB3将到的对应操作序号 100之后的写入操作的数 据信息发送到站点 2 的 MMDB2, 站点 2 的 MMDB2根据该数据信息更新 MMDB2的 MMDB。
在本发明提供的实施例中, 分布式 MMDB的构架可由多个站点构成, 每 个站点可部署至少一个分布式 MMDB集群, MMDB集群主 MMDB接收应用 程序的写入操作请求, 为每一个操作产生一个递增的唯一 64位数据编号, 该 数据编号即为该写入操作请求的操作序号。 主 MMDB同步数据信息时, 在请 求更新的消息中必须附带此操作序号作为参数。 并且, 因为每个主 MMDB同 时又将作为其他站点 MMDB集群中的一个从 MMDB ,接收该其他站点同步而 来的数据信息, 所以主 MMDB必须记录操作编号和其他站点的全局站点名, 进而完成本站点的数据更新过程, 并将操作编号, 写入操作请求及该写入操作 请求所属的站点名同步给本站点中的从 MMDB。这样,每个 MMDB中除了记 录了本 MMDB集群的操作编号, 还记录了其它站点中 MMDBJ集群的(由全 局站点名区分)操作编号。
故而,站点 1的主 MMDB发生故障时,站点 1的令牌控制器按本地 MMDB 数据库优先级重新选出一个新的主 MMDB ,新的主 MMDB在收到令牌控制器 的 MMDB列表后, 会将最后记录的操作序号等信息返回到该令牌控制器, 该 - - 令牌控制器将此操作序号通知给其他站点的令牌控制器,由该其他站点的令牌 控制器再传递给其 MMDB集群中的主 MMDB。 主 MMDB就可从此该操作序 号断点处继续将数据信息同步到站点 1 的新的主 MMDB , 再有该新的主 MMDB将这些数据信息同步到集群内的复制各从 MMDB。 由此, 站点 1可在 主 MMDB故障时, 通过与其他站点的数据同步过程获取丟失的数据信息, 并 继续其职能, 进而取得了减少数据同步过程中的复杂度, 容灾能力强, 可靠性 高的技术效果。 本实施例提供一种可选的 MMDB , 如图 11所示, 其中发送模块 11 , 还可 以发送包含节点 MMDB信息的消息到第一站点的令牌控制器; 接收模块 12, 还可以用于从第一站点的令牌控制器获取第一站点的 MMDB 列表, MMDB 列表中包括作为从 MMDB加入第一站点的第二站点的主 MMDB信息, 以及 根据至少一个节点 MMDB信息整理的第一站点的集群内信息; 处理模块 13 , 还可以用于根据 MMDB列表处理站点间或站点内的事务。
本实施例提供一种可选的 MMDB , 如图 11所示, 其中处理模块 13还可 以用于当该 MMDB装置处于主 MMDB状态时, 接收写入操作请求, 并根据 写入操作请求更新各从 MMDB的数据信息, 其中, 各从 MMDB包括: 根据 集群内信息获取的第一站点中的从 MMDB ,以及根据主 MMDB信息获取的第 二站点中的主 MMDB; 以及还可以用于当写入操作请求来自第二站点的主 MMDB时,根据第二站点的写入操作请求更新第一站点中从 MMDB的数据信 息。
本实施例提供一种可选的 MMDB , 如图 11所示, 其中处理模块 13还可 - - 以用于在接收到写入操作请求时,对接收到的写入操作请求添加操作序号; 以 及还用于在写入操作请求中携带写入操作所属站点的全局站点名以及写入操 作请求的操作序号, 以便各从 MMDB根据全局站点名记录写入操作请求的操 作序号。
本实施例提供一种可选的 MMDB , 如图 11所示, 其中处理模块 13还可 以用于在第二站点的主 MMDB 变更时, 获取第二站点中变更后的主 MMDB 的主 MMDB 信息和第二站点的主 MMDB 最后记录的操作序号, 并根据主 MMDB信息和操作序号获取对应的写入操作的数据信息, 再将写入操作的数 据信息更新到第二站点变更后的主 MMDB。
本实施例提供的 MMDB装置无需同步软件的控制即可执行站点间数据同 步的过程, 在提高了容灾性的同时, 也确保了可靠性, 并且适用于大型跨站点 分布式 MMDB场景, 可降低解决方案成本, 提升产品竟力。 本实施例提供一种可选的令牌控制器, 如图 13所示, 其中接收模块 21 , 还用于从第二站点的令牌控制器接收包含第二站点的主 MMDB信息的消息; 获取模块 22,还用于根据第二站点的主 MMDB信息和第一站点的集群内信息 获取第一站点的 MMDB列表, 其中, 第一站点的集群内信息是根据来自第一 站点的至少一个 MMDB的节点 MMDB信息整理而得; 发送模块 23 , 还用于 将第一站点的 MMDB列表发送到第一站点的至少一个 MMDB , 以便 MMDB 根据 MMDB列表处理站点间或站点内事务。
本实施例提供一种可选的令牌控制器, 如图 13所示, 故障确定单元 24, 还用于当第二站点的主 MMDB变更时, 从第二站点的令牌控制器获取第二站 — — 点中变更后的主 MMDB最后记录的操作序号和主 MMDB信息, 并将携带操 作序号和主 MMDB的主 MMDB信息的消息发到第一站点的主 MMDB。
本实施例提供的令牌控制器可替代同步软件控制站点间数据同步的过程, 降低了站点间实现控制数据同步的复杂度, 加强了容灾能力, 提高了可靠性。 如图 19, 本实施例提供一种站点系统, 该系统中至少包括: 第一站点 61 和第二站点 62。
第一站点 61中的令牌控制器,用于从第二站点 62的令牌控制器接收包含 第二站点 62的主 MMDB信息的消息, 并根据第二站点 62的主 MMDB信息 和第一站点 61的集群内信息获取第一站点 61的 MMDB列表, 再将第一站点 61的 MMDB列表发送到第一站点 61的 MMDB;
第一站点 61中的 MMDB , 用于发送包含节点 MMDB信息的消息到第一 站点 61 的令牌控制器, 并从第一站点 61 的令牌控制器获取第一站点 61 的 MMDB列表, 以及根据 MMDB列表处理第一站点 61间的事务, 或第一站点 61与第二站点 62间的事务。
其中, MMDB列表中包括: 作为从 MMDB加入第一站点 61的第二站点 62的主 MMDB信息,以及根据节点 MMDB信息整理的第一站点 61的集群内 信息。
另外, 第二站点中的 MMDB 和令牌控制器同样可以像第一站点中的 MMDB和令牌控制器一样执行, 以便完成第一站点与第二站点间或第二站点 内的事务。
在现有技术中, 由同步应用程序操控不同站点间的数据同步, 以便保证分 — — 布式 MMDB的容灾性, 但该过程复杂, 可拓展性差, 因此易故障, 可靠性差, 而本发明实施例提供的方案,采用两个不同的站点间可通过其令牌控制器的交 互获取对方的主 MMDB信息, 并根据包含该信息的 MMDB信息处理以及集 群内信息处理站点间或站点内的事务的技术手段,可避免因采用同步应用软件 带来的复杂度高, 可拓展性差的技术问题, 故而可以取得提供可能性, 增强容 灾能力的技术效果。 通过以上的实施方式的描述,所属领域的技术人员可以清楚地了解到本发 明可借助软件加必需的通用硬件平台的方式来实现, 当然也可以通过硬件,但 很多情况下前者是更佳的实施方式。基于这样的理解, 本发明的技术方案本质 上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算 机软件产品存储在可读取的存储介质中, 如计算机的软盘, 硬盘或光盘等, 包 括若干指令用以便得一台设备 (可以是笔记本电脑等)执行本发明各个实施例 的方法。
以上, 仅为本发明的具体实施方式, 但本发明的保护范围并不局限于此, 任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到变化 或替换, 都应涵盖在本发明的保护范围之内。 因此, 本发明的保护范围应以权 利要求的保护范围为准。

Claims

权 利 要 求
1、 一种分布式内存数据库的实现方法, 其特征在于, 包括:
发送包含节点内存数据库信息的消息到至少两个令牌控制器;
分别接收来自所述至少两个令牌控制器的包含内存数据库列表的消息,其 中,所述内存数据库列表中包括根据至少一个所述节点内存数据库信息整理的 集群内信息;
根据所述内存数据库列表中的集群内信息处理所述集群内的事务。
2、 根据权利要求 1所述的方法, 其特征在于, 所述节点内存数据库信息 包括中一个或多个: 本地内存数据库的名称, 因特网协议 IP地址, 端口和数 据库优先级别;
所述集群内信息包括一个或多个:组成所述集群的每个内存数据库的所述 节点内存数据库信息、组成所述集群的每个内存数据库的主从模式信息, 和发 送所述内存数据库列表的令牌控制器的控制器优先级别。
3、 根据权利要求 1或 2所述的方法, 其特征在于, 当接收到的包含内存 数据库列表的消息是来自所述至少两个令牌控制器中的主令牌控制器时,所述 根据内存数据库列表中的集群内信息处理集群内事务包括:
以来自所述主令牌控制器的内存数据库列表中的集群内信息为准处理集 群内事务。
4、 根据权利要求 1所述的方法, 其特征在于, 当内存数据库为主内存数 据,且所述集群内的事务为所述至少两个令牌控制器中的一个令牌控制器故障 时, 所述根据所述内存数据库列表中的集群内信息处理所述集群内的事务包 括: 根据所述内存数据库列表中的集群内信息确定所述故障的令牌控制器的 控制器优先级别;
如果所述故障的令牌控制器的控制器优先级别为最高控制器优先级别,则 根据所述集群内信息从所述故障的令牌控制器以外的其它令牌控制器中选择 当前控制器优先级别最高的令牌控制器作为主令牌控制器。
5、 根据权利要求 4所述的方法, 其特征在于, 当内存数据库为主内存数 据,且所述集群内的事务为故障恢复的令牌控制器重新进入所述集群内时, 所 述根据所述内存数据库列表中的集群内信息处理所述集群内的事务包括: 在接收到来自所述故障恢复的令牌控制器的包含内存数据库列表的消息 后,根据所述内存数据库列表中的集群内信息确定故障恢复的令牌控制器的控 制器优先级别;
如果所述故障恢复的令牌控制器的控制器优先级别比当前主令牌控制器 的控制器优先级别高,则根据来自所述当前主令牌控制器的内存数据库列表确 定所述故障恢复的令牌控制器的内存数据库列表的可用性;
如果确定所述故障恢复的令牌控制器的内存数据库列具有可用性,则选择 所述故障恢复的令牌控制器作为新的主令牌控制器。
6、 根据权利要求 1所述的方法, 其特征在于, 当内存数据库为主内存数 据库,且所述集群内的事务为接收写入操作请求时, 所述根据所述内存数据库 列表中的集群内信息处理所述集群内的事务包括:
根据所述写入操作请求更新本地内存数据库中的数据信息;
根据所述内存数据库列表中的集群内信息将所述写入操作请求更新到从 内存数据库,以便所述从内存数据库根据所述写入操作请求更新所述其本地内 存数据库中的数据信息。
7、 根据权利要求 1所述的方法, 其特征在于, 当内存数据库为比主内存 数据库的数据库优先级别更高的内存数据库,且所述集群内的事务为所述更高 的内存数据库进入所述集群内时,所述根据所述内存数据库列表中的集群内信 息处理所述集群内的事务包括:
根据所述内存数据库列表中集群内信息向所述主内存数据库发送数据更 新请求,所述数据更新请求中包括所述更高的内存数据库中最后记录的数据信 息的操作序号, 以便所述主内存数据库返回接续所述操作序号的数据信息; 根据返回的接续所述操作序号的数据信息更新所述更高的内存数据库的 本地内存数据库,并发送更新完成响应到所述主内存数据库以便所述主内存数 据库执行退出主内存数据库模式的处理。
8、 根据权利要求 1所述的方法, 其特征在于, 还包括:
发送包含节点内存数据库信息的消息到第一站点的令牌控制器; 从所述第一站点的令牌控制器获取所述第一站点的内存数据库列表, 其 中,所述内存数据库列表中包括作为从内存数据库加入第一站点的第二站点的 主内存数据库信息,以及根据至少一个所述节点内存数据库信息整理的第一站 点的集群内信息;
根据所述内存数据库列表处理站点间的事务。
9、 根据权利要求 8所述的方法, 其特征在于, 当所述站点间事务为接收 到写入操作请求时, 所述根据所述内存数据库列表处理站点间的事务包括: 根据所述写入操作请求更新所述各从内存数据库的数据信息, 其中, 所述 各从内存数据库包括: 根据所述集群内信息获取的第一站点中的从内存数据 库, 以及根据所述主内存数据库信息获取的第二站点中的主内存数据库; 所述第二站点的主内存数据库根据所述写入操作请求更新过数据信息后, 根据所述写入操作请求更新所述第二站点的从内存数据库的数据信息。
10、根据权利要求 9所述的方法,其特征在于,在接收到写入操作请求时, 该方法还包括: 对接收到的写入操作请求添加操作序号;
所述根据所述写入操作请求更新所述各从内存数据库的数据信息包括: 根据所述写入操作请求更新所述各从内存数据库的数据信息, 其中, 所述 写入请求中携带所述写入操作所属站点的全局站点名以及所述写入操作请求 的操作序号,以便所述各从内存数据库根据所述全局站点名记录所述写入操作 请求的操作序号。
11、 根据权利要求 9所述的方法, 其特征在于, 当所述站点间的事务为所 述第二站点的主内存数据库变更时,所述根据所述内存数据库列表处理站点间 的事务包括:
获取所述第二站点中变更后的主内存数据库的主内存数据库信息和所述 第二站点的主内存数据库最后记录的操作序号;
根据所述主内存数据库信息和操作序号获取对应的写入操作的数据信息; 将所述写入操作的数据信息更新到所述第二站点变更后的主内存数据库。
12、 一种分布式内存数据库的实现方法, 其特征在于, 包括:
接收来自至少一个内存数据库的包含节点内存数据信息的消息;
根据所述节点内存数据库信息获取内存数据库列表, 其中, 所述内存数据 库列表中包括根据至少一个所述节点内存数据库信息整理的集群内信息;
将包含所述内存数据库列表的消息发送到所述至少一个内存数据库,以便 所述至少一个内存数据库根据所述内存数据库列表中的集群内信息处理所述 集群内的事务。
13、 根据权利要求 12所述的方法, 其特征在于, 当所述至少一个内存数 据库中其中一内存数据库故障时, 该方法还包括:
根据所述内存数据库列表中集群内信息确定所述故障的内存数据库的数 据库优先级别;
如果所述故障的内存数据库的数据库优先级别为最高控制器优先级别,则 根据所述集群内信息从所述故障的内存数据库以外的其它内存数据库中选择 当前数据库优先级别最高的内存数据库作为新的主内存数据库。
14、 根据权利要求 12所述的方法, 其特征在于, 当所述至少一个内存数 据库为故障恢复的内存数据库时, 该方法还包括:
在接收来自所述故障恢复的内存数据库的包含节点内存数据信息的消息 后,根据故障恢复的内存数据库的节点内存数据库信息确定所述故障恢复的内 存数据库的数据库优先级别;
如果所述故障恢复的内存数据库的数据库优先级别比当前主内存数据库 的数据库优先级别高, 则在所述当前主内存数据库的退出主内存数据库模式 后, 选择所述故障恢复的内存数据库为新的主内存数据库。
15、 一种内存数据库, 其特征在于, 包括:
发送模块,用于发送包含节点内存数据库信息的消息到至少两个令牌控制 器;
接收模块,用于分别接收来自所述至少两个令牌控制器的包含内存数据库 列表的消息, 其中, 所述内存数据库列表中包括根据至少一个所述节点内存数 据库信息整理的集群内信息;
处理模块,用于根据所述内存数据库列表中的集群内信息处理所述集群内 的事务。
16、 根据权利要求 15所述的内存数据库, 其特征在于, 所述处理模块包 括:
故障确定单元, 用于当有令牌控制器故障时,根据所述内存数据库列表中 的集群内信息确定所述故障的令牌控制器的控制器优先级别;
第一选择单元,用于当所述故障确定单元确定所述故障的令牌控制器的控 制器优先级别为最高控制器优先级别时,根据所述集群内信息从所述故障的令 牌控制器以外的其它令牌控制器中选择当前控制器优先级别最高的令牌控制 器作为主令牌控制器。
17、 根据权利要求 15所述的内存数据库, 其特征在于, 所述处理模块包 括:
恢复确定单元, 用于当有故障恢复的令牌控制器重新进入所述集群内时, 根据接收模块接收到的来自所述故障恢复的令牌控制器的内存数据库列表中 的集群内信息确定所述故障恢复的令牌控制器的控制器优先级别;
可用确定单元,用于当所述恢复确定单元确定所述故障恢复的令牌控制器 的控制器优先级别比当前主令牌控制器的控制器优先级别高时,根据来自所述 当前主令牌控制器的内存数据库列表确定所述故障恢复的令牌控制器的内存 数据库列表的可用性;
第二选择单元,用于当时所述可用确定单元确定定所述故障恢复的令牌控 制器的内存数据库列具有可用性时,选择所述故障恢复的令牌控制器作为新的 主令牌控制器。
18、 根据权利要求 15所述的内存数据库, 其特征在于, 所述处理模块包 括:
写入单元, 用于在处于主内存数据库状态时, 接收写入操作请求, 并根据 所述写入操作请求更新本地内存数据库中的数据信息,再根据所述内存数据库 列表中的集群内信息将所述写入操作请求更新到从内存数据库,以便所述从内 存数据库根据所述写入操作请求更新所述其本地内存数据库中的数据信息。
19、 根据权利要求 16所述的内存数据库, 其特征在于, 所述处理模块包 括:
同步恢复单元,用于在数据库优先级别比当前主内存数据库的数据库优先 级别更高时,根据所述内存数据库列表中集群内信息向所述主内存数据库发送 数据更新请求,所述数据更新请求中包括所述更高的内存数据库中最后记录的 数据信息的操作序号,以便所述主内存数据库返回接续所述操作序号的数据信 息,再根据返回的接续所述操作序号的数据信息更新本地内存数据库的数据信 息, 并发送更新完成响应到所述主内存数据库, 以便所述主内存数据库执行退 出主内存数据库模式的处理。
20、 一种令牌控制器, 其特征在于, 包括:
接收模块,用于接收来自至少一个内存数据库的包含节点内存数据信息的 消息;
获取模块, 用于根据所述节点内存数据库信息获取内存数据库列表, 其中 所述内存数据库列表中包括根据至少一个所述节点内存数据库信息整理的集 群内信息; 发送模块,用于将包含所述内存数据库列表的消息发送到所述至少一个内 存数据库,以便所述至少一个内存数据库根据所述内存数据库列表中的集群内 信息处理所述集群内的事务。
21、 根据权利要求 20所述的令牌控制器, 其特征在于, 该令牌控制器还 包括:
故障确定单元,用于当所述至少一个内存数据库中其中一内存数据库故障 时,根据所述内存数据库列表中集群内信息确定所述故障的内存数据库的数据 库优先级别; 据库优先级别为最高控制器优先级别时,根据所述集群内信息从所述故障的内 存数据库以外的其它内存数据库中选择当前数据库优先级别最高的内存数据 库作为新的主内存数据库。
22、 根据权利要求 20所述的令牌控制器, 其特征在于, 该令牌控制器还 包括:
恢复确定单元,用于在从故障恢复的内存数据库接收到包含节点内存数据 信息的消息后,根据所述故障恢复的内存数据库的节点内存数据库信息确定所 述故障恢复的内存数据库的数据库优先级别;
第二选择单元,用于当所述恢复确定单元确定所述故障恢复的内存数据库 的数据库优先级别比当前主内存数据库的数据库优先级别高时,在所述当前主 内存数据库的退出主内存数据库模式后,选择所述故障恢复的内存数据库为新 的主内存数据库。
23、 一种分布式内存数据库系统, 其特征在于, 包括: 至少两个令牌控制 器和至少一个内存数据库;
所述内存数据库,用于发送包含节点内存数据库信息的消息到所述至少两 个令牌控制器,并分别接收来自所述至少两个令牌控制器的包含内存数据库列 表的消息, 其中, 所述内存数据库列表中包括根据至少一个所述节点内存数据 库信息整理的集群内信息,存储所述内测数据列表, 并根据所述内存数据库列 表中的集群内信息处理所述集群内的事务;
所述令牌控制器,用于接收所述内存数据库的包含节点内存数据信息的消 息, 并根据所述节点内存数据库信息获取内存数据库列表,再将包含所述内存 数据库列表的消息发送到所述至少一个内存数据库。
24、 一种站点系统, 至少包括: 第一站点和第二站点, 其特征在于, 所述第一站点中的令牌控制器,用于从第二站点的令牌控制器接收包含所 述第二站点的主内存数据库信息的消息,并根据所述第二站点的主内存数据库 信息和第一站点的集群内信息获取所述第一站点的内存数据库列表,再将所述 第一站点的内存数据库列表发送到所述第一站点的内存数据库;
所述第一站点中的内存数据库,用于发送包含节点内存数据库信息的消息 到第一站点的令牌控制器,并从所述第一站点的令牌控制器获取所述第一站点 的内存数据库列表, 以及根据所述内存数据库列表处理所述第一站点间的事 务, 或所述第一站点与所述第二站点间的事务;
其中, 所述内存数据库列表中包括: 作为从内存数据库加入第一站点的第 二站点的主内存数据库信息,以及根据节点内存数据库信息整理的第一站点的 集群内信息。
PCT/CN2011/079418 2010-12-02 2011-09-07 分布式内存数据库的实现方法、系统、令牌控制器及内存数据库 WO2012071920A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP11845808.2A EP2648114B1 (en) 2010-12-02 2011-09-07 Method, system, token conreoller and memory database for implementing distribute-type main memory database system
US13/866,467 US20130238676A1 (en) 2010-12-02 2013-04-19 Method, system, token conreoller and memory database for implementing distribute-type main memory database system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201010570252.X 2010-12-02
CN201010570252XA CN102142008B (zh) 2010-12-02 2010-12-02 分布式内存数据库的实现方法、系统、令牌控制器及内存数据库

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/866,467 Continuation US20130238676A1 (en) 2010-12-02 2013-04-19 Method, system, token conreoller and memory database for implementing distribute-type main memory database system

Publications (1)

Publication Number Publication Date
WO2012071920A1 true WO2012071920A1 (zh) 2012-06-07

Family

ID=44409531

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2011/079418 WO2012071920A1 (zh) 2010-12-02 2011-09-07 分布式内存数据库的实现方法、系统、令牌控制器及内存数据库

Country Status (4)

Country Link
US (1) US20130238676A1 (zh)
EP (1) EP2648114B1 (zh)
CN (1) CN102142008B (zh)
WO (1) WO2012071920A1 (zh)

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102142008B (zh) * 2010-12-02 2013-04-17 华为技术有限公司 分布式内存数据库的实现方法、系统、令牌控制器及内存数据库
CN102508881B (zh) * 2011-10-18 2014-07-02 国网电力科学研究院 一种电力信息系统内存数据库的多节点集群系统
CN103095766A (zh) * 2011-11-03 2013-05-08 上海宝信软件股份有限公司 通信前置机的端口级冗余管理方法
CN102404390B (zh) * 2011-11-07 2013-11-27 广东电网公司电力科学研究院 高速实时数据库的智能化动态负载均衡方法
CN102929744B (zh) * 2011-12-27 2016-06-08 许继电气股份有限公司 一种区域网络实时库数据存储方法及系统
US9489443B1 (en) * 2013-05-24 2016-11-08 Amazon Technologies, Inc. Scheduling of splits and moves of database partitions
CN104965862A (zh) * 2015-06-03 2015-10-07 深圳市创梦天地科技有限公司 一种内存数据库集群的同步方法及内存数据库主机
CN104899284B (zh) * 2015-06-05 2018-09-04 北京京东尚科信息技术有限公司 一种基于元数据驱动调度系统的方法及装置
US20170032300A1 (en) * 2015-07-31 2017-02-02 International Business Machines Corporation Dynamic selection of resources on which an action is performed
US10169172B2 (en) * 2015-08-11 2019-01-01 International Business Machines Corporation Passive detection of live systems during controller failover in distributed environments
CN105550309A (zh) * 2015-12-12 2016-05-04 天津南大通用数据技术股份有限公司 Mpp架构数据库集群序列系统及序列管理方法
CN108090095B (zh) * 2016-11-23 2020-09-15 北京国双科技有限公司 批量重建数据库的方法和装置
CN107247784B (zh) * 2017-06-14 2020-05-15 苏州浪潮智能科技有限公司 一种分布式事务的控制方法及事务管理器
CN109167831A (zh) * 2018-08-31 2019-01-08 北京航天云路有限公司 多站点用户行为信息同步方法及系统
CN109445717B (zh) * 2018-11-15 2022-01-11 北京国电通网络技术有限公司 一种双机备份时的数据存储方法及装置
US11531321B2 (en) * 2018-11-26 2022-12-20 Embraer S.A. Multidimensional quantization and distributed automatic systems management
CN110309163A (zh) * 2019-06-28 2019-10-08 杭州复杂美科技有限公司 区块链关系型数据库维护方法和数据查询方法
CN110297867B (zh) * 2019-06-28 2021-08-17 浪潮软件集团有限公司 基于国产cpu和分布式容器集群的数据库集群运行方法及系统
US11907543B2 (en) 2020-01-07 2024-02-20 International Business Machines Corporation Managing swappable data structures in a plurality of memory devices based on access counts of the data structures
US11573709B2 (en) 2020-01-07 2023-02-07 International Business Machines Corporation Maintaining data structures in a memory subsystem comprised of a plurality of memory devices
US11620055B2 (en) 2020-01-07 2023-04-04 International Business Machines Corporation Managing data structures in a plurality of memory devices that are indicated to demote after initialization of the data structures
CN111917664A (zh) * 2020-06-30 2020-11-10 北京瀚诺半导体科技有限公司 一种队列管理方法及系统
US20230131643A1 (en) * 2021-10-26 2023-04-27 Druva Inc. System and method for reference-aware application identification in container deployment environments
CN115242856B (zh) * 2022-06-15 2024-01-23 飞诺门阵(北京)科技有限公司 集群重建方法及系统
CN116455830A (zh) * 2023-06-16 2023-07-18 深圳市杉岩数据技术有限公司 实现存储网关高可用分布式qos的方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101118509A (zh) * 2007-09-12 2008-02-06 华为技术有限公司 内存数据库远程容灾的方法、装置和系统
CN101493826A (zh) * 2008-12-23 2009-07-29 中兴通讯股份有限公司 基于web应用的数据库系统及其数据管理方法
CN101751394A (zh) * 2008-12-16 2010-06-23 青岛海信传媒网络技术有限公司 数据同步方法和数据同步系统
CN101887388A (zh) * 2010-06-18 2010-11-17 中兴通讯股份有限公司 基于内存数据库的数据备份系统和方法
CN102142008A (zh) * 2010-12-02 2011-08-03 华为技术有限公司 分布式内存数据库的实现方法、系统、令牌控制器及内存数据库

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4432057A (en) * 1981-11-27 1984-02-14 International Business Machines Corporation Method for the dynamic replication of data under distributed system control to control utilization of resources in a multiprocessing, distributed data base system
WO2001082678A2 (en) * 2000-05-02 2001-11-08 Sun Microsystems, Inc. Cluster membership monitor
US7370223B2 (en) * 2000-09-08 2008-05-06 Goahead Software, Inc. System and method for managing clusters containing multiple nodes
US6922791B2 (en) * 2001-08-09 2005-07-26 Dell Products L.P. Failover system and method for cluster environment
US7120690B1 (en) * 2001-09-27 2006-10-10 Emc Corporation Managing a distributed directory database
JP4158534B2 (ja) * 2003-01-21 2008-10-01 修平 西山 分散型データベースシステム
JP2005018510A (ja) * 2003-06-27 2005-01-20 Hitachi Ltd データセンタシステム及びその制御方法
US7805407B1 (en) * 2004-06-16 2010-09-28 Oracle America, Inc. System and method for dynamic configuration of replicated database servers
US8458467B2 (en) * 2005-06-21 2013-06-04 Cisco Technology, Inc. Method and apparatus for adaptive application message payload content transformation in a network infrastructure element
CA2615324A1 (en) * 2005-07-14 2007-07-05 Yotta Yotta, Inc. Maintaining write order fidelity on a multi-writer system
WO2007095587A2 (en) * 2006-02-14 2007-08-23 Yottayotta, Inc. Systems and methods for obtaining ultra-high data availability and geographic disaster tolerance
EP2171619A1 (en) * 2007-07-23 2010-04-07 Telefonaktiebolaget LM Ericsson (PUBL) Database system with multiple layer distribution
US8306951B2 (en) * 2009-09-18 2012-11-06 Oracle International Corporation Automated integrated high availability of the in-memory database cache and the backend enterprise database
CN101656624B (zh) * 2008-08-18 2011-12-07 中兴通讯股份有限公司 一种多节点应用级容灾系统及容灾方法
CN101826073B (zh) * 2009-03-06 2013-08-28 华为技术有限公司 分布式数据库同步方法、设备及系统
CN101854373B (zh) * 2009-04-01 2013-10-09 华为技术有限公司 任务切换方法、服务器节点及集群系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101118509A (zh) * 2007-09-12 2008-02-06 华为技术有限公司 内存数据库远程容灾的方法、装置和系统
CN101751394A (zh) * 2008-12-16 2010-06-23 青岛海信传媒网络技术有限公司 数据同步方法和数据同步系统
CN101493826A (zh) * 2008-12-23 2009-07-29 中兴通讯股份有限公司 基于web应用的数据库系统及其数据管理方法
CN101887388A (zh) * 2010-06-18 2010-11-17 中兴通讯股份有限公司 基于内存数据库的数据备份系统和方法
CN102142008A (zh) * 2010-12-02 2011-08-03 华为技术有限公司 分布式内存数据库的实现方法、系统、令牌控制器及内存数据库

Also Published As

Publication number Publication date
EP2648114A1 (en) 2013-10-09
EP2648114A4 (en) 2014-01-01
EP2648114B1 (en) 2017-12-13
US20130238676A1 (en) 2013-09-12
CN102142008A (zh) 2011-08-03
CN102142008B (zh) 2013-04-17

Similar Documents

Publication Publication Date Title
WO2012071920A1 (zh) 分布式内存数据库的实现方法、系统、令牌控制器及内存数据库
JP6382454B2 (ja) 分散ストレージ及びレプリケーションシステム、並びに方法
WO2019085875A1 (zh) 存储集群的配置修改方法、存储集群及计算机系统
CN111581284B (zh) 一种数据库高可用性方法、装置、系统和存储介质
US20190095293A1 (en) Data disaster recovery method, device and system
US8055711B2 (en) Non-blocking commit protocol systems and methods
US9934242B2 (en) Replication of data between mirrored data sites
WO2018171565A1 (zh) 容灾部署方法、装置及系统
CN109005045B (zh) 主备服务系统及主节点故障恢复方法
JP2019219954A (ja) クラスタストレージシステム、データ管理制御方法、データ管理制御プログラム
WO2010115373A1 (zh) 基于对等网络的资源信息备份操作方法及对等网络
TWI677797B (zh) 主備資料庫的管理方法、系統及其設備
CN102394914A (zh) 集群脑裂处理方法和装置
WO2017152736A1 (zh) 一种分布式文件系统hdfs的管理方法、装置及系统
WO2007048319A1 (fr) Systeme et procede de recuperation sur sinistre de dispositif de commande de service dans un reseau intelligent
WO2014177085A1 (zh) 分布式多副本数据存储方法及装置
CN115794499B (zh) 一种用于分布式块存储集群间双活复制数据的方法和系统
CN112783694B (zh) 一种高可用Redis的异地灾备方法
WO2015196692A1 (zh) 一种云计算系统以及云计算系统的处理方法和装置
TWI669605B (zh) 虛擬機器群組的容錯方法及其容錯系統
CN113064768B (zh) 在区块链系统中切换分片节点的方法和装置
CN112667440A (zh) 一种高可用MySQL的异地灾备方法
CN112019601B (zh) 一种基于分布式存储Ceph的两节点实现方法及系统
CN115905270B (zh) 数据库中主用数据节点的确定方法、装置及存储介质
WO2023125412A1 (en) Method and system for synchronous data replication

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11845808

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2011845808

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE