CN112667449A - Cluster management method and device - Google Patents
Cluster management method and device Download PDFInfo
- Publication number
- CN112667449A CN112667449A CN202011589634.7A CN202011589634A CN112667449A CN 112667449 A CN112667449 A CN 112667449A CN 202011589634 A CN202011589634 A CN 202011589634A CN 112667449 A CN112667449 A CN 112667449A
- Authority
- CN
- China
- Prior art keywords
- cluster
- nodes
- database
- node
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000007726 management method Methods 0.000 title claims abstract description 21
- 238000000034 method Methods 0.000 claims abstract description 17
- 238000001514 detection method Methods 0.000 claims description 7
- 238000010586 diagram Methods 0.000 description 8
- 230000006870 function Effects 0.000 description 5
- 238000012986 modification Methods 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 230000001360 synchronised effect Effects 0.000 description 4
- 230000009286 beneficial effect Effects 0.000 description 3
- 238000013459 approach Methods 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 238000013515 script Methods 0.000 description 1
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The specification provides a cluster management method and a device, wherein the method is applied to a database cluster, and the method comprises the following steps: the database nodes in the cluster send heartbeat messages to each other; and if the first database node senses that most nodes in the cluster leave the cluster according to the heartbeat message, the database node automatically exits the cluster and does not update data. If the database in the cluster detects that most database nodes leave the cluster, the rest database nodes automatically exit the cluster, so that the aim that the rest database nodes do not update data any more is fulfilled, and therefore the most database nodes in the cluster can be ensured to be restarted to be capable of ensuring that the database nodes with the latest data can be found.
Description
Technical Field
The present disclosure relates to the field of communications technologies, and in particular, to a cluster management method and apparatus.
Background
A traditional deployment of applications is to install the applications through plug-ins or scripts. The disadvantage of this is that the running, configuration, management, and all life cycles of the application will be bound to the current operating system, which is not beneficial to the upgrade update/rollback and other operations of the application, and certainly, some functions can be implemented by creating a virtual machine, but the virtual machine is very heavy and not beneficial to portability.
The new mode is realized by deploying containers, each container is isolated from each other, each container has a file system, processes among the containers cannot influence each other, and computing resources can be distinguished. Compared with a virtual machine, the container can be deployed rapidly, and the container can be migrated among different clouds and different versions of operating systems because the container is decoupled from underlying facilities and a machine file system.
As the task demand is continuously enhanced, the database needs to have certain high availability, the states of all nodes in the cluster need to be monitored among the database nodes, when a certain node leaves the cluster, the database cluster can sense the node in time, and the node is removed from the cluster; when a certain leaving node is recovered, the database cluster can sense the joining of the node in time; when all nodes in the cluster are abnormally closed, after the cluster is restarted again, self-detection can be realized, the nodes of the main database are selected, and other nodes are added into the cluster by the identity of the standby database. Under the micro-service framework, the leaving and recovery of the database nodes are related to the state of the micro-service.
In the prior art, if one database node in a database cluster fails, the cluster has 2 database nodes, and if one database node in the cluster is restarted or 2 database nodes in the cluster are restarted, the cluster can be established only by requiring all the database nodes in the cluster to be started.
Disclosure of Invention
In order to overcome the problems in the related art, the present specification provides a cluster management method and apparatus.
According to a first aspect of embodiments of the present specification, there is provided a cluster management method, including:
the database nodes in the cluster send heartbeat messages to each other;
and if the first database node senses that most nodes in the cluster leave the cluster according to the heartbeat message, the database node automatically exits the cluster and does not update data.
Optionally, after the first database node is restarted, if it is detected that most nodes in the cluster are started, collecting a transaction identifier, where the transaction identifier is used to identify a new state and an old state of database node data;
and determining the primary database node in the cluster according to the transaction identifier.
Optionally, when a database node in the cluster receives new data, the transaction identifier corresponding to the database node is incremented by one.
Optionally, if the first database node senses that a few nodes leave the cluster according to the heartbeat message, deleting the few nodes from a locally stored cluster list;
and when a cluster joining request sent by a few nodes is received, synchronizing data to the few nodes.
Optionally, the majority of nodes are nodes that are greater than one-half of the nodes of the database in the cluster; the few nodes are less than one-half of the nodes of the database in the cluster.
According to a second aspect of embodiments herein, there is provided a cluster management apparatus, the apparatus being applied to a first database node in a database cluster, the apparatus comprising: the device comprises a sending module and a data updating module;
the sending module is used for sending heartbeat messages to other database nodes in the cluster;
and the data updating module is used for prompting the first database node to automatically exit the cluster without updating data when sensing that most nodes in the cluster leave the cluster according to the heartbeat message.
Optionally, the apparatus further includes a restart module, a detection module, and an election module;
the restarting module is used for starting a first database node, and after the first database node is restarted, if the detection module detects that most nodes in the cluster are started, transaction identifiers are collected, wherein the transaction identifiers are used for identifying the old and new states of database node data;
and the election module is used for determining the primary database node in the cluster according to the transaction identifier.
Optionally, the election module is further configured to, when a first database node in the cluster receives new data, add one to the transaction identifier corresponding to the first database node.
Optionally, the apparatus further comprises a receiving module;
if the data updating module senses that a few nodes leave the cluster according to the heartbeat message, the data updating module deletes the few nodes from a locally stored cluster list;
and when the receiving module receives the cluster joining request sent by the minority node, synchronizing data to the minority node.
Optionally, the majority of nodes are nodes that are greater than one-half of the nodes of the database in the cluster; the few nodes are less than one-half of the nodes of the database in the cluster.
The technical scheme provided by the embodiment of the specification can have the following beneficial effects: if the database in the cluster detects that most database nodes leave the cluster, the rest database nodes automatically exit the cluster, so that the aim that the rest database nodes do not update data any more is fulfilled, and therefore the most database nodes in the cluster can be ensured to be restarted to be capable of ensuring that the database nodes with the latest data can be found.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the specification.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present specification and together with the description, serve to explain the principles of the specification.
Fig. 1 is a schematic flow chart of a cluster management method provided by the present disclosure;
fig. 2 is a schematic flowchart of a cluster management method according to another embodiment of the present disclosure;
3a-3d are processes by which all nodes in a cluster leave to reconstitute the cluster;
fig. 4 is a schematic structural diagram of a cluster management apparatus provided in the present disclosure;
fig. 5 is a schematic structural diagram of a cluster management apparatus according to another embodiment of the present disclosure.
Detailed Description
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the specification, as detailed in the appended claims.
In the prior art, if most database nodes in a cluster leave the cluster due to a failure or the like, and the remaining few database nodes still work, the data on the working few nodes is newer, and the data on the failed most nodes is older, so that in the prior art, after all the failed nodes need to be repaired, the database nodes with newer data are manually determined to be used as a primary database to be started first, and then the primary database synchronizes data to other database nodes. This approach may result in the entire database cluster being unavailable.
In order to solve the above problem, the present disclosure provides a cluster management method, which may be applied to a database cluster, where the database cluster may include a plurality of database nodes, and data is backed up between the database nodes. According to the method, if the database in the cluster detects that most database nodes leave the cluster, the rest database nodes automatically exit the cluster, so that the purpose that the rest database nodes do not update data any more is achieved, and therefore the fact that the most database nodes in the cluster restart can be guaranteed to find the database nodes with the latest data.
Before describing the method of the present disclosure, it should be noted that the majority of nodes referred to in the embodiments of the present disclosure refer to nodes that are larger than database node 1/2 in the cluster, and the minority of nodes refer to nodes that are smaller than database node 1/2 in the cluster. For example, if the cluster includes five database nodes, most of the nodes are nodes greater than 5/2, and since the nodes are positive numbers, most of the nodes are 3. A few nodes are fewer than 5/2 nodes, i.e., 2.
If the cluster comprises 3 database nodes, most nodes are 2, and few nodes are 1.
For the convenience of election, an even number of nodes in a cluster are rarely formed.
The database nodes of the present disclosure may be deployed in containers, one database node deployed in each container. While other monitoring processes may be run in the container, etc.
Specifically, fig. 1 shows a schematic flow chart of the cluster management method provided by the present disclosure, and as shown in fig. 1, the cluster management method provided by the present disclosure includes:
And 102, if the first database node senses that most nodes in the cluster leave the cluster according to the heartbeat message, the database node automatically exits the cluster and does not update data.
When the database cluster works normally, heartbeat messages can be mutually sent among all database nodes in the cluster so as to sense whether other nodes in the cluster work normally or not.
If sensing that most nodes in the cluster leave the cluster, the database node automatically exits the cluster at the moment, so that the data of the database node is basically the same as the data of most database nodes leaving the cluster.
For example, if a cluster is composed of 3 database nodes (A, B, C), when B, C two database nodes fail and leave the cluster at substantially the same time, and another database node a senses that the other two database nodes B, C leave the cluster, then the database node a may exit the cluster and no longer update the data. At this point it is ensured that the data on database node a is substantially identical to the data in database node B, C.
Therefore, after the fault of the database node B, C is repaired, even if only two devices in A, B, C are started, it can be ensured that the devices with the latest data in the cluster can be always started, and the devices can still normally join the cluster when the subsequent database node a is restarted. However, in the prior art, if the database node a does not exit the cluster and is working after the failure of the database node B, C, the data on the database node B, C after the database node B, C is started is old, and the data on the database node a when the database node a is restarted is more completely updated than the data on the database node B, C, and the database node a cannot join the cluster.
On the basis of the foregoing embodiment, fig. 2 shows a schematic flowchart of another cluster management method provided by the present disclosure, and as shown in fig. 2, the method includes:
Step 201 and step 202 in this embodiment are the same as step 101 and step 102 in the above embodiment, and are not described again here.
Following the above embodiment, the present embodiment takes the first database node as the database node a as an example for explanation.
After the database node A is restarted, if detecting that most nodes, namely B and C, in the cluster are started, collecting transaction identifications of other database nodes in the cluster, wherein the transaction identifications are used for identifying the old state and the new state of the database node data.
Finally, the database node A can obtain the database node with the largest transaction identifier, the database node is elected as a main database, and the main database node synchronizes data to other database nodes.
In an alternative embodiment, when a database node in the cluster receives new data, the transaction identifier corresponding to the database node is increased by one. For example, after the database node B in the cluster receives the new synchronized data, the transaction id is incremented by one at the database node B. Therefore, the latest and latest database nodes in the cluster can be found in the database cluster according to the transaction identification.
In another embodiment, it is also possible that only a few nodes in the cluster leave the cluster. For example, if the database node B in the cluster leaves the cluster, the database node A, C senses that a few nodes (i.e., less than 3/2 database nodes) leave the cluster, and at this time, the cluster may also work normally, meanwhile, the database node a and the database node C delete the database node B from the local cluster list, the cluster list stores the address information of other database nodes in the cluster to which each database node is added, and each database node may communicate with other nodes, synchronize data, and the like according to the address information in the locally stored cluster list. The address information may include an IP address and/or a MAC address.
When the database node B is started again, the database node B determines whether there is a node in an active state (active) in the cluster according to the locally stored cluster list, and if so, requests to join the cluster. After joining the cluster, database node a or database node C synchronizes information to database node B. For the case that a few nodes rejoin the cluster, it is not necessary to search for the primary database node, because the data between the database node a and the database node C are the same when the cluster is working normally, the database node B can request the synchronous data from any one of the database nodes after restarting.
In this embodiment, for an example that all nodes in the cluster leave the cluster, the method disclosed in this embodiment is further described. Fig. 3a-3d show the process of all nodes in a cluster leaving to recompose the cluster.
As shown in fig. 3a, if both database nodes A, B, C in the cluster are powered off, as shown in fig. 3B, if any two nodes are restarted after the failure is repaired, in this embodiment, taking restarting of database node a and database node B as an example, database node a and database node B may detect that 2 nodes in the cluster, that is, most nodes have been restarted, as shown in fig. 3c, at this time, database node a and database node B automatically collect transaction identifiers of each database node, select the node with the largest transaction identifier as the primary database node, as shown in fig. 3d, add another node to the cluster with the identity of the backup database node, request the primary database node for synchronous data, and at this time, the cluster may work normally.
On the basis of the foregoing embodiments, the present disclosure provides a cluster management device, and fig. 4 is a schematic structural diagram of the cluster management device provided in the present disclosure, and as shown in fig. 4, the device includes: a sending module 401 and a data updating module 402;
a sending module 401, configured to send a heartbeat message to other database nodes in the cluster;
the data updating module 402 is configured to, according to the heartbeat packet, prompt the first database node to automatically exit the cluster without updating data when it is sensed that most nodes in the cluster have left the cluster.
Optionally, fig. 5 is a schematic diagram of another cluster management apparatus provided in the present disclosure, and as shown in fig. 5, the apparatus further includes a restart module 403, a detection module 404, and an election module 405;
the restarting module 403 is configured to start a first database node, and after the first database node is restarted, if the detection module 404 detects that most nodes in the cluster are started, collect a transaction identifier, where the transaction identifier is used to identify a new state and an old state of database node data;
the election module 405 is configured to determine a primary database node in the cluster according to the transaction identifier.
Optionally, the election module 405 is further configured to, when a first database node in the cluster receives new data, add one to the transaction identifier corresponding to the first database node.
Optionally, the apparatus may further include a receiving module 406;
if the data updating module 402 senses that a few nodes leave the cluster according to the heartbeat message, the data updating module 402 deletes the few nodes from a locally stored cluster list;
when the receiving module 406 receives the cluster join request sent by the minority node, the data is synchronized to the minority node.
Optionally, the majority of nodes are nodes that are greater than one-half of the nodes of the database in the cluster; the few nodes are less than one-half of the nodes of the database in the cluster.
If the data updating module 402 senses that most of the nodes in the cluster leave the cluster according to the heartbeat message, the first database node is prompted to automatically quit the cluster, the data is not updated, that is, when most of the nodes already quit the cluster, the rest of the database nodes automatically quit the cluster, so that the purpose that the rest of the database nodes do not update the data any more is achieved, and therefore the fact that the most of the database nodes in the cluster restart can be guaranteed, and the database nodes with the latest data can be found can be guaranteed.
In the embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other ways. The apparatus embodiments described above are merely illustrative, and for example, the flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods and computer program products according to embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
In addition, functional modules in the embodiments of the present application may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.
The functions, if implemented in the form of software functional modules and sold or used as a stand-alone product, may be stored in a readable storage medium. Based on such understanding, the technical solution of the present application or portions thereof that substantially contribute to the prior art may be embodied in the form of a software product stored in a readable storage medium, which includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method described in the embodiments of the present application. And the aforementioned readable storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.
It will be understood that the present description is not limited to the precise arrangements described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present description is limited only by the appended claims.
The above description is only a preferred embodiment of the present disclosure, and should not be taken as limiting the present disclosure, and any modifications, equivalents, improvements, etc. made within the spirit and principle of the present disclosure should be included in the scope of the present disclosure.
It will be understood that the present description is not limited to the precise arrangements described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present description is limited only by the appended claims.
The above description is only a preferred embodiment of the present disclosure, and should not be taken as limiting the present disclosure, and any modifications, equivalents, improvements, etc. made within the spirit and principle of the present disclosure should be included in the scope of the present disclosure.
Claims (10)
1. A cluster management method is applied to a database cluster, and comprises the following steps:
the database nodes in the cluster send heartbeat messages to each other;
and if the first database node senses that most nodes in the cluster leave the cluster according to the heartbeat message, the database node automatically exits the cluster and does not update data.
2. The method of claim 1, wherein after the first database node is restarted, if it is detected that most nodes in the cluster have started, collecting a transaction identifier, wherein the transaction identifier is used for identifying old and new states of database node data;
and determining the primary database node in the cluster according to the transaction identifier.
3. The method of claim 1, wherein when a database node in the cluster receives new data, the transaction identifier corresponding to the database node is incremented by one.
4. The method of claim 1, wherein if a first database node senses that a minority node leaves a cluster according to the heartbeat packet, the minority node is deleted from a locally stored cluster list;
and when a cluster joining request sent by a few nodes is received, synchronizing data to the few nodes.
5. The method according to any one of claims 1 to 4, wherein the majority of nodes are nodes that are more than one-half of the nodes of the database in the cluster; the few nodes are less than one-half of the nodes of the database in the cluster.
6. A cluster management apparatus, applied to a first database node in a database cluster, the apparatus comprising: the device comprises a sending module and a data updating module;
the sending module is used for sending heartbeat messages to other database nodes in the cluster;
and the data updating module is used for prompting the first database node to automatically exit the cluster without updating data when sensing that most nodes in the cluster leave the cluster according to the heartbeat message.
7. The apparatus of claim 6, further comprising a restart module, and a detection module, an election module;
the restarting module is used for starting a first database node, and after the first database node is restarted, if the detection module detects that most nodes in the cluster are started, transaction identifiers are collected, wherein the transaction identifiers are used for identifying the old and new states of database node data;
and the election module is used for determining the primary database node in the cluster according to the transaction identifier.
8. The apparatus of claim 6, wherein the election module is further configured to increment a transaction identifier corresponding to a first database node in the cluster by one when the first database node receives new data.
9. The apparatus according to claim 6, wherein if the data update module senses that a minority node leaves a cluster according to the heartbeat packet, the data update module deletes the minority node from a locally stored cluster list;
and when the receiving module receives the cluster joining request sent by the minority node, synchronizing data to the minority node.
10. The apparatus according to any one of claims 6 to 9, wherein the majority of nodes are nodes that are more than one half of the nodes of the database in the cluster; the few nodes are less than one-half of the nodes of the database in the cluster.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011589634.7A CN112667449B (en) | 2020-12-29 | 2020-12-29 | Cluster management method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011589634.7A CN112667449B (en) | 2020-12-29 | 2020-12-29 | Cluster management method and device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112667449A true CN112667449A (en) | 2021-04-16 |
| CN112667449B CN112667449B (en) | 2024-03-08 |
Family
ID=75411713
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011589634.7A Active CN112667449B (en) | 2020-12-29 | 2020-12-29 | Cluster management method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112667449B (en) |
Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6014669A (en) * | 1997-10-01 | 2000-01-11 | Sun Microsystems, Inc. | Highly-available distributed cluster configuration database |
| US20150161016A1 (en) * | 2011-04-26 | 2015-06-11 | Brian J. Bulkowski | Method and system of self-managing nodes of a distributed database cluster with a consensus algorithm |
| CN106960060A (en) * | 2017-04-10 | 2017-07-18 | 聚好看科技股份有限公司 | The management method and device of a kind of data-base cluster |
| US20180367610A1 (en) * | 2017-06-19 | 2018-12-20 | Beijing Baidu Netcom Science And Technology Co., Ltd. | Data storage method and server applicable to distributed server cluster |
| CN109286529A (en) * | 2018-10-31 | 2019-01-29 | 武汉烽火信息集成技术有限公司 | A kind of method and system for restoring RabbitMQ network partition |
| CN109412875A (en) * | 2018-12-26 | 2019-03-01 | 杭州云英网络科技有限公司 | Zookeeper cluster automatic maintenance method and device |
| CN109729129A (en) * | 2017-10-31 | 2019-05-07 | 华为技术有限公司 | Configuration modification method, storage cluster and the computer system of storage cluster |
| CN110750379A (en) * | 2019-10-28 | 2020-02-04 | 无锡华云数据技术服务有限公司 | ETCD cluster recovery method, system, equipment and computer medium |
| CN111240901A (en) * | 2020-01-13 | 2020-06-05 | 苏州浪潮智能科技有限公司 | Node dynamic expansion system, method and equipment of distributed block storage system |
| CN111367998A (en) * | 2020-03-04 | 2020-07-03 | 安超云软件有限公司 | Database cluster recovery method based on Galera and terminal equipment |
-
2020
- 2020-12-29 CN CN202011589634.7A patent/CN112667449B/en active Active
Patent Citations (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6014669A (en) * | 1997-10-01 | 2000-01-11 | Sun Microsystems, Inc. | Highly-available distributed cluster configuration database |
| US20150161016A1 (en) * | 2011-04-26 | 2015-06-11 | Brian J. Bulkowski | Method and system of self-managing nodes of a distributed database cluster with a consensus algorithm |
| CN106960060A (en) * | 2017-04-10 | 2017-07-18 | 聚好看科技股份有限公司 | The management method and device of a kind of data-base cluster |
| US20180367610A1 (en) * | 2017-06-19 | 2018-12-20 | Beijing Baidu Netcom Science And Technology Co., Ltd. | Data storage method and server applicable to distributed server cluster |
| CN109729129A (en) * | 2017-10-31 | 2019-05-07 | 华为技术有限公司 | Configuration modification method, storage cluster and the computer system of storage cluster |
| WO2019085875A1 (en) * | 2017-10-31 | 2019-05-09 | 华为技术有限公司 | Configuration modification method for storage cluster, storage cluster and computer system |
| CN109286529A (en) * | 2018-10-31 | 2019-01-29 | 武汉烽火信息集成技术有限公司 | A kind of method and system for restoring RabbitMQ network partition |
| CN109412875A (en) * | 2018-12-26 | 2019-03-01 | 杭州云英网络科技有限公司 | Zookeeper cluster automatic maintenance method and device |
| CN110750379A (en) * | 2019-10-28 | 2020-02-04 | 无锡华云数据技术服务有限公司 | ETCD cluster recovery method, system, equipment and computer medium |
| CN111240901A (en) * | 2020-01-13 | 2020-06-05 | 苏州浪潮智能科技有限公司 | Node dynamic expansion system, method and equipment of distributed block storage system |
| CN111367998A (en) * | 2020-03-04 | 2020-07-03 | 安超云软件有限公司 | Database cluster recovery method based on Galera and terminal equipment |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112667449B (en) | 2024-03-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107291787B (en) | Main and standby database switching method and device | |
| US7197632B2 (en) | Storage system and cluster maintenance | |
| CN111427728B (en) | State management method, main/standby switching method and electronic equipment | |
| CN105933407B (en) | method and system for realizing high availability of Redis cluster | |
| CN102394914A (en) | Cluster brain-split processing method and device | |
| CN112506702B (en) | Disaster recovery method, device, equipment and storage medium for data center | |
| CN112579354B (en) | Method for backup and recovery of edge cloud collaborative software | |
| CN110545203B (en) | Method for establishing initial resource backup pool and self-healing repair of cloud platform by cloud platform | |
| CN111752488B (en) | Management method and device of storage cluster, management node and storage medium | |
| CN108600284B (en) | Ceph-based virtual machine high-availability implementation method and system | |
| CN114138732A (en) | Data processing method and device | |
| CN113986450A (en) | Virtual machine backup method and device | |
| CN109189854B (en) | Method and node equipment for providing continuous service | |
| CN105323271B (en) | Cloud computing system and processing method and device thereof | |
| CN110858168A (en) | Cluster node fault processing method and device and cluster node | |
| WO2002001347A2 (en) | Method and system for automatic re-assignment of software components of a failed host | |
| CN110716828B (en) | Database real-time backup method | |
| CN107181608B (en) | Method for recovering service and improving performance and operation and maintenance management system | |
| CN112667449B (en) | Cluster management method and device | |
| CN115878361A (en) | Node management method and device for database cluster and electronic equipment | |
| CN114363356B (en) | Data synchronization method, system, device, computer equipment and storage medium | |
| CN112698926B (en) | Data processing method, device, equipment, storage medium and system | |
| CN112231150B (en) | Method and device for recovering fault database in database cluster | |
| CN113890880A (en) | Method, system, equipment and storage medium for data synchronization among multiple nodes | |
| CN112612652A (en) | Distributed storage system abnormal node restarting method and system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |