CN111752962B - System and method for guaranteeing high availability and consistency of MHA cluster - Google Patents
System and method for guaranteeing high availability and consistency of MHA cluster Download PDFInfo
- Publication number
- CN111752962B CN111752962B CN202010616118.2A CN202010616118A CN111752962B CN 111752962 B CN111752962 B CN 111752962B CN 202010616118 A CN202010616118 A CN 202010616118A CN 111752962 B CN111752962 B CN 111752962B
- Authority
- CN
- China
- Prior art keywords
- mha
- cluster
- configuration
- redis
- switching
- 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.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 24
- 238000013515 script Methods 0.000 claims abstract description 53
- 238000011084 recovery Methods 0.000 claims abstract description 30
- 230000002159 abnormal effect Effects 0.000 claims description 31
- 238000012545 processing Methods 0.000 claims description 21
- 230000008859 change Effects 0.000 claims description 19
- 238000012544 monitoring process Methods 0.000 claims description 15
- 238000012790 confirmation Methods 0.000 claims description 7
- 238000010200 validation analysis Methods 0.000 claims description 7
- 230000009191 jumping Effects 0.000 claims description 6
- 238000010586 diagram Methods 0.000 description 3
- 238000007689 inspection Methods 0.000 description 2
- 230000008439 repair process Effects 0.000 description 2
- 238000011161 development Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000013508 migration Methods 0.000 description 1
- 230000005012 migration Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2308—Concurrency control
- G06F16/2336—Pessimistic concurrency control approaches, e.g. locking or multiple versions without time stamps
- G06F16/2343—Locking methods, e.g. distributed locking or locking implementation details
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2023—Failover techniques
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
Abstract
The invention discloses a system and a method for ensuring high availability and consistency of MHA clusters, which belong to the technical field of database management, and the invention aims to solve the technical problem of avoiding that MySQL clusters cannot be switched normally due to simultaneous failure of MHA and MySQL clusters, and ensure the availability of user application, and adopts the following technical scheme: the system comprises a Redis cluster, a remote server and a remote server, wherein the Redis cluster is used for providing a publicized lock and configuring global notification issuing capability; the MHA module is used for registering exclusive locks in the Redis cluster when disaster recovery switching is executed, avoiding other MHA examples from executing disaster recovery switching operation at the same time, pushing the switching after the switching is completed, configuring the switching to the Redis cluster and releasing the locks; the MHA module is based on an MHA native tool and realizes locking and releasing of an exclusive lock and a configuration pushing function at two custom scripts of a second_check_script and an ip_failover_script; a configuration manager for ensuring that the local configuration of the MHA node remains consistent with other MHA moments.
Description
Technical Field
The invention relates to the technical field of database management, in particular to a system and a method for guaranteeing high availability and consistency of an MHA cluster.
Background
MHA is one of the most commonly used MySQL disaster recovery switching components at present, and can monitor one or more MySQL master-slave clusters, when a MySQL master node fails, promote a slave node to be a master node and switch a virtual IP mounted on the original master node to a new master node, thereby ensuring the availability of the MySQL cluster. The switching speed is high, and the integrity of MySQL data is maintained to be high, so that the method is widely applied to various development, test and production environments.
However, the MHA is originally deployed by a single node, if the main node of the MySQL cluster fails while the MHA node fails, the MySQL cluster cannot be switched normally, resulting in service interruption of the user. At present, most users manually recover the operation of the MHA at the first time when the state of the MHA is detected to be abnormal by monitoring the state of the MHA, and perform inspection at regular time to reduce the probability of simultaneous failure of the MHA and MySQL, but as more and more applications migrate to the cloud, the quantity of the deployed MHA and MySQL clusters also greatly increases, the manual inspection and repair mode can generate huge workload, and meanwhile, smaller RTO (recovery time objective) values are difficult to maintain. Therefore, how to avoid that MySQL clusters cannot be switched normally due to simultaneous failure of MHA and MySQL clusters, and ensure availability of user applications is a technical problem to be solved urgently.
Patent document with the patent number of CN107203617B discloses a mysql online migration system and a method based on MHA, wherein the system comprises three units of an MHA management node, a mysql master-slave node and a new slave node; the MHA management node comprises an MHA management module, an online switching module and an MHA configuration updating module; the mysql master-slave node comprises an online data making module and an offline slave library module; the new slave node includes a slave library module. But this solution does not guarantee a high availability of MHA itself.
Patent document CN104036043B discloses a MYSQL high availability method and management node, the method comprising: after detecting that the host fails, selecting a slave as a new host, and transferring a request of the front end to the new host; and establishing a master-slave corresponding relation between the new host and the slave. But this solution does not guarantee a high availability of MHA itself.
Disclosure of Invention
The technical task of the invention is to provide a system and a method for ensuring high availability and consistency of MHA clusters, so as to solve the problem of how to prevent the MySQL clusters from being switched normally due to the simultaneous failure of the MHA and the MySQL clusters and ensure the availability of user applications.
The technical task of the present invention is achieved in a system for ensuring high availability and consistency of MHA clusters, comprising,
redis cluster, which is used to provide publicized lock and configure global notification issuing capability;
the MHA module is used for registering exclusive locks in the Redis cluster when disaster recovery switching is executed, avoiding other MHA examples from executing disaster recovery switching operation at the same time, pushing the switching after the switching is completed, configuring the switching to the Redis cluster and releasing the locks;
a configuration manager for ensuring that the local configuration of the MHA node remains consistent with other MHA moments.
Preferably, the MHA module is based on an MHA native tool, and implements locking and releasing of an exclusive lock and configuration pushing functions at two custom scripts, namely, secondary_check_script and ip_failover_script.
More preferably, the MHA module processing logic is specifically as follows:
s1, periodically and circularly monitoring the state of a MySQL cluster master node;
s2, checking whether the MySQL cluster master node state is abnormal:
(1) if the MySQL cluster master node state is abnormal, executing the step S3 next;
(2) if the state of the MySQL cluster master node is not abnormal, jumping to the step S1;
s3, executing a secondary_check_script script to carry out state secondary confirmation;
s4, disaster recovery switching operation is carried out on the MySQL cluster;
s5, updating the corresponding relation between a new master node and a new slave node of the MySQL cluster to be monitored in the local MHA configuration;
s6, executing the ip_failover_script script to perform post-switching processing;
s7, ending.
More preferably, the executing the second_check_script script in step S3 performs the second confirmation of the status specifically as follows:
s301, checking whether the master node is abnormal or not again through the MySQL cluster slave node:
if the master node is abnormal, executing step S302;
s302, accessing the Redis cluster to check whether an exclusive lock exists or not to confirm whether other MHA nodes detect MySQL cluster faults and perform disaster recovery switching operation or not:
if there is no exclusive lock, then the next step is to execute step S303;
s303, setting an exclusive lock in the Redis, and exiting the second_check_script script.
More preferably, the step S6 of executing the ip_failover_script to perform post-switching processing specifically includes:
s601, checking whether cluster switching is successful;
s602, switching the virtual IP originally arranged on the fault node to a new main node;
s603, pushing the MySQL master-slave node corresponding relation in the local configuration to an hset with Key being Config in Redis;
s604, releasing the exclusive lock in Redis.
Preferably, the configuration manager is further configured to pull the cluster configuration from the dis at startup, update the local MHA configuration, and restart to take effect, while listening whether the dis cluster configuration changes:
if a change occurs, the local MHA configuration is updated and the validation is restarted.
More preferably, the configuration manager processing logic is specifically as follows:
(1) When in starting, the hset with Key being Config is pulled from Redis, the content of the hset is updated to the local MHA configuration, and the MHA is restarted to be effective;
(2) Setting a watch for the hset of Config by Key, and monitoring the change of the hset;
(3) When the watch receives the change information of hset, the hset with Key being Config is pulled from Redis, the content of the hset is updated to the local MHA configuration, and the MHA is restarted to be effective.
A method for ensuring high availability and consistency of MHA clusters comprises the following steps:
(one), redis cluster provides distributed lock and configuration global notification issuing capability;
secondly, the MHA module registers an exclusive lock in the Redis when disaster recovery switching is executed, so that other MHA examples are prevented from executing disaster recovery switching operation at the same time, and after switching is completed, the MHA module pushes the switching and then is configured to the Redis and releases the lock;
thirdly, when the configuration manager starts, the cluster configuration is pulled from the Redis, the local MHA configuration is updated and restarted to be effective, and meanwhile whether the cluster configuration on the Redis changes or not is monitored:
if a change occurs, the local MHA configuration is updated and the validation is restarted.
Preferably, the MHA module processing logic is specifically as follows:
periodically monitoring the state of a MySQL cluster master node;
(II) checking whether the MySQL cluster master node state is abnormal:
(1) if the MySQL cluster master node state is abnormal, executing the step (III) next;
(2) if the state of the MySQL cluster master node is not abnormal, jumping to the step (I);
(III) executing a secondary_check_script to carry out state secondary confirmation; the method comprises the following steps:
the slave node checks again through MySQL cluster whether the master node is abnormal:
if the master node is abnormal, the next step is executed
The Redis cluster is accessed to see if an exclusive lock exists to confirm if other MHA nodes have detected MySQL cluster failure and are performing disaster recovery switching operations:
if there is no exclusive lock, then the next step is to execute
Setting an exclusive lock in the Redis, and exiting the second_check_script script;
(IV) disaster recovery switching operation is carried out on the MySQL cluster;
(V) updating the corresponding relation between a new master node and a new slave node of the MySQL cluster to be monitored in the local MHA configuration;
executing the ip_failover_script to perform post-switching processing; the method comprises the following steps:
(1) checking whether cluster switching is successful;
(2) switching the virtual IP originally arranged on the fault node to a new master node;
(3) pushing the MySQL master-slave node corresponding relation in the local configuration to an hset with Key of Config in Redis;
(4) releasing the exclusive lock in Redis;
and (VII) ending.
More preferably, the configuration manager processing logic is specifically as follows:
pulling hset with Key being Config from Redis at starting, updating the content of hset to local MHA configuration, restarting MHA to enable MHA to be effective;
(ii) setting a watch for the hset of Config by Key, and monitoring the change of the hset;
(iii) when the watch receives the change information of hset, pulling the hset with Key being Config from Redis, updating the content of the hset to the local MHA configuration, and restarting the MHA to be effective.
The system and the method for ensuring the high availability and consistency of the MHA cluster have the following advantages:
the invention can construct a plurality of MHA examples into a cluster, and avoid that the monitored MySQL cluster can not perform disaster recovery switching due to MHA faults when a single MHA is used for monitoring the MySQL cluster; meanwhile, the consistency of configuration files of each MHA node is maintained by utilizing a configuration manager in cooperation with Redis, so that MySQL switching errors caused by the fact that each MHA is self-administration are avoided;
secondly, according to the invention, a plurality of MHA examples are built into a high-availability cluster, the RTO of the MHA is reduced to 0, so that the condition that the MySQL cluster cannot be switched normally due to the simultaneous failure of the MHA and the MySQL cluster is avoided, and the availability of user application is further ensured; the invention does not destroy the original MHA monitoring system, has simple implementation, can effectively reduce the real-time requirement on manual repair of MHA faults in a large-scale deployment scene, and reduces the manpower cost;
the invention coordinates the working state of each MHA instance by using an exclusive lock in the MHA custom script second_check_script and the ip_failover_script, ensures that only one MHA instance is performing disaster recovery switching operation at the same time, and ensures the consistency of the switching state in the MHA cluster; meanwhile, the changed configuration is pushed to Redis in the MHA custom script ip_failover_script, other nodes monitor the change of the MHA cluster configuration through a configuration manager, the changed configuration is updated to the local of each node, and the configuration consistency of each node in the MHA cluster is ensured.
Drawings
The invention is further described below with reference to the accompanying drawings.
FIG. 1 is a block diagram of a system for ensuring high availability and consistency of MHA clusters;
FIG. 2 is a flow diagram of the MHA module processing logic;
fig. 3 is a flow diagram of configuration manager processing logic.
Detailed Description
A system and method for ensuring high availability and consistency of MHA clusters according to the present invention is described in detail below with reference to the accompanying drawings and specific examples.
Example 1:
as shown in fig. 1, the system of the present invention for ensuring high availability and consistency of MHA clusters, comprises,
redis cluster, which is used to provide publicized lock and configure global notification issuing capability;
the MHA module is used for registering exclusive locks in the Redis cluster when disaster recovery switching is executed, avoiding other MHA examples from executing disaster recovery switching operation at the same time, pushing the switching after the switching is completed, configuring the switching to the Redis cluster and releasing the locks; the MHA module is based on an MHA native tool and realizes locking and releasing of an exclusive lock and configuration pushing functions at two custom scripts of secondary_check_script and ip_failover_script. As shown in fig. 2, the MHA module processing logic is specifically as follows:
s1, periodically and circularly monitoring the state of a MySQL cluster master node;
s2, checking whether the MySQL cluster master node state is abnormal:
(1) if the MySQL cluster master node state is abnormal, executing the step S3 next;
(2) if the state of the MySQL cluster master node is not abnormal, jumping to the step S1;
s3, executing a secondary_check_script script to carry out state secondary confirmation; the method comprises the following steps:
s301, checking whether the master node is abnormal or not again through the MySQL cluster slave node:
if the master node is abnormal, executing step S302;
s302, accessing the Redis cluster to check whether an exclusive lock exists or not to confirm whether other MHA nodes detect MySQL cluster faults and perform disaster recovery switching operation or not:
if there is no exclusive lock, then the next step is to execute step S303;
s303, setting an exclusive lock in the Redis, and exiting the second_check_script script;
s4, disaster recovery switching operation is carried out on the MySQL cluster;
s5, updating the corresponding relation between a new master node and a new slave node of the MySQL cluster to be monitored in the local MHA configuration;
s6, executing the ip_failover_script script to perform post-switching processing; the method comprises the following steps:
s601, checking whether cluster switching is successful;
s602, switching the virtual IP originally arranged on the fault node to a new main node;
s603, pushing the MySQL master-slave node corresponding relation in the local configuration to an hset with Key being Config in Redis;
s604, releasing the exclusive lock in Redis;
s7, ending.
A configuration manager for ensuring that the local configuration of the MHA node remains consistent with other MHA moments. The configuration manager is further configured to pull the cluster configuration from the dis at startup, update the local MHA configuration, and restart to be effective, and monitor whether the dis cluster configuration changes:
if a change occurs, the local MHA configuration is updated and the validation is restarted.
As shown in fig. 3, the configuration manager processing logic is specifically as follows:
(1) When in starting, the hset with Key being Config is pulled from Redis, the content of the hset is updated to the local MHA configuration, and the MHA is restarted to be effective;
(2) Setting a watch for the hset of Config by Key, and monitoring the change of the hset;
(3) When the watch receives the change information of hset, the hset with Key being Config is pulled from Redis, the content of the hset is updated to the local MHA configuration, and the MHA is restarted to be effective.
Example 2:
the invention relates to a method for guaranteeing high availability and consistency of MHA clusters, which comprises the following steps:
(one), redis cluster provides distributed lock and configuration global notification issuing capability;
secondly, the MHA module registers an exclusive lock in the Redis when disaster recovery switching is executed, so that other MHA examples are prevented from executing disaster recovery switching operation at the same time, and after switching is completed, the MHA module pushes the switching and then is configured to the Redis and releases the lock;
thirdly, when the configuration manager starts, the cluster configuration is pulled from the Redis, the local MHA configuration is updated and restarted to be effective, and meanwhile whether the cluster configuration on the Redis changes or not is monitored:
if a change occurs, the local MHA configuration is updated and the validation is restarted.
As shown in fig. 2, the MHA module processing logic is specifically as follows:
periodically monitoring the state of a MySQL cluster master node;
(II) checking whether the MySQL cluster master node state is abnormal:
(1) if the MySQL cluster master node state is abnormal, executing the step (III) next;
(2) if the state of the MySQL cluster master node is not abnormal, jumping to the step (I);
(III) executing a secondary_check_script to carry out state secondary confirmation; the method comprises the following steps:
the slave node checks again through MySQL cluster whether the master node is abnormal:
if the master node is abnormal, the next step is executed
The Redis cluster is accessed to see if an exclusive lock exists to confirm if other MHA nodes have detected MySQL cluster failure and are performing disaster recovery switching operations:
if there is no exclusive lock, then the next step is to execute
Setting an exclusive lock in the Redis, and exiting the second_check_script script;
(IV) disaster recovery switching operation is carried out on the MySQL cluster;
(V) updating the corresponding relation between a new master node and a new slave node of the MySQL cluster to be monitored in the local MHA configuration;
executing the ip_failover_script to perform post-switching processing; the method comprises the following steps:
(1) checking whether cluster switching is successful;
(2) switching the virtual IP originally arranged on the fault node to a new master node;
(3) pushing the MySQL master-slave node corresponding relation in the local configuration to an hset with Key of Config in Redis;
(4) releasing the exclusive lock in Redis;
and (VII) ending.
As shown in fig. 3, the configuration manager processing logic is specifically as follows:
pulling hset with Key being Config from Redis at starting, updating the content of hset to local MHA configuration, restarting MHA to enable MHA to be effective;
(ii) setting a watch for the hset of Config by Key, and monitoring the change of the hset;
(iii) when the watch receives the change information of hset, pulling the hset with Key being Config from Redis, updating the content of the hset to the local MHA configuration, and restarting the MHA to be effective.
Finally, it should be noted that: the above embodiments are only for illustrating the technical solution of the present invention, and not for limiting the same; although the invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some or all of the technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit of the invention.
Claims (8)
1. A system for ensuring high availability and consistency of MHA clusters, characterized in that it comprises,
redis cluster, which is used to provide publicized lock and configure global notification issuing capability;
the MHA module is used for registering exclusive locks in the Redis cluster when disaster recovery switching is executed, avoiding other MHA examples from executing disaster recovery switching operation at the same time, pushing the switching after the switching is completed, configuring the switching to the Redis cluster and releasing the locks;
a configuration manager for ensuring that the local configuration of the MHA node is consistent with other MHA moments;
the MHA module processing logic specifically includes:
s1, periodically and circularly monitoring the state of a MySQL cluster master node;
s2, checking whether the MySQL cluster master node state is abnormal:
(1) if the MySQL cluster master node state is abnormal, executing the step S3 next;
(2) if the state of the MySQL cluster master node is not abnormal, jumping to the step S1;
s3, executing a secondary_check_script script to carry out state secondary confirmation;
s4, disaster recovery switching operation is carried out on the MySQL cluster;
s5, updating the corresponding relation between a new master node and a new slave node of the MySQL cluster to be monitored in the local MHA configuration;
s6, executing the ip_failover_script script to perform post-switching processing;
s7, ending.
2. The system of claim 1, wherein the MHA module is based on MHA native tools and implements exclusive lock and release and configuration push functions at two custom scripts, secondary_check_script and ip_failover_script.
3. The system for ensuring high availability and consistency of MHA clusters according to claim 1, wherein the executing of the secondary_check_script script in step S3 performs a state secondary validation as follows:
s301, checking whether the master node is abnormal or not again through the MySQL cluster slave node:
if the master node is abnormal, executing step S302;
s302, accessing the Redis cluster to check whether an exclusive lock exists or not to confirm whether other MHA nodes detect MySQL cluster faults and perform disaster recovery switching operation or not:
if there is no exclusive lock, then the next step is to execute step S303;
s303, setting an exclusive lock in the Redis, and exiting the second_check_script script.
4. The system for ensuring high availability and consistency of MHA clusters according to claim 1, wherein the executing of the ip_failover_script in step S6 performs a post-switch process specifically as follows:
s601, checking whether cluster switching is successful;
s602, switching the virtual IP originally arranged on the fault node to a new main node;
s603, pushing the MySQL master-slave node corresponding relation in the local configuration to an hset with Key being Config in Redis;
s604, releasing the exclusive lock in Redis.
5. The system of claim 1, wherein the configuration manager is further configured to pull the cluster configuration from the dis at startup, update the local MHA configuration and restart validation while listening for changes in the dis cluster configuration:
if a change occurs, the local MHA configuration is updated and the validation is restarted.
6. The system for ensuring high availability and consistency of MHA clusters according to claim 1 or 5, characterized in that the configuration manager processing logic is specifically as follows:
(1) When in starting, the hset with Key being Config is pulled from Redis, the content of the hset is updated to the local MHA configuration, and the MHA is restarted to be effective;
(2) Setting a watch for the hset of Config by Key, and monitoring the change of the hset;
(3) When the watch receives the change information of hset, the hset with Key being Config is pulled from Redis, the content of the hset is updated to the local MHA configuration, and the MHA is restarted to be effective.
7. A method for ensuring high availability and consistency of MHA clusters, comprising the steps of:
(one), redis cluster provides distributed lock and configuration global notification issuing capability;
secondly, the MHA module registers an exclusive lock in the Redis when disaster recovery switching is executed, so that other MHA examples are prevented from executing disaster recovery switching operation at the same time, and after switching is completed, the MHA module pushes the switching and then is configured to the Redis and releases the lock;
thirdly, when the configuration manager starts, the cluster configuration is pulled from the Redis, the local MHA configuration is updated and restarted to be effective, and meanwhile whether the cluster configuration on the Redis changes or not is monitored:
if the change occurs, the local MHA configuration is updated and the local MHA configuration is restarted to be effective;
the MHA module processing logic specifically includes:
periodically monitoring the state of a MySQL cluster master node;
(II) checking whether the MySQL cluster master node state is abnormal:
(1) if the MySQL cluster master node state is abnormal, executing the step (III) next;
(2) if the state of the MySQL cluster master node is not abnormal, jumping to the step (I);
(III) executing a secondary_check_script to carry out state secondary confirmation; the method comprises the following steps:
<1>, the slave node checks again through MySQL cluster whether the master node is abnormal:
if the master node is abnormal, executing the step <2> next;
<2>, access to the Redis cluster to see if an exclusive lock exists to confirm if other MHA nodes have detected MySQL cluster failure and are performing disaster recovery switching operations:
if there is no exclusive lock, then the next step is to execute step <3>;
<3>, set an exclusive lock in Redis, and exit the second_check_script script;
(IV) disaster recovery switching operation is carried out on the MySQL cluster;
(V) updating the corresponding relation between a new master node and a new slave node of the MySQL cluster to be monitored in the local MHA configuration;
executing the ip_failover_script to perform post-switching processing; the method comprises the following steps:
(1) checking whether cluster switching is successful;
(2) switching the virtual IP originally arranged on the fault node to a new master node;
(3) pushing the MySQL master-slave node corresponding relation in the local configuration to an hset with Key of Config in Redis;
(4) releasing the exclusive lock in Redis;
and (VII) ending.
8. The method of ensuring high availability and consistency of MHA clusters of claim 7, wherein the configuration manager processing logic is specifically as follows:
pulling hset with Key being Config from Redis at starting, updating the content of hset to local MHA configuration, restarting MHA to enable MHA to be effective;
(ii) setting a watch for the hset of Config by Key, and monitoring the change of the hset;
(iii) when the watch receives the change information of hset, pulling the hset with Key being Config from Redis, updating the content of the hset to the local MHA configuration, and restarting the MHA to be effective.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010616118.2A CN111752962B (en) | 2020-07-01 | 2020-07-01 | System and method for guaranteeing high availability and consistency of MHA cluster |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010616118.2A CN111752962B (en) | 2020-07-01 | 2020-07-01 | System and method for guaranteeing high availability and consistency of MHA cluster |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111752962A CN111752962A (en) | 2020-10-09 |
| CN111752962B true CN111752962B (en) | 2024-01-30 |
Family
ID=72676814
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010616118.2A Active CN111752962B (en) | 2020-07-01 | 2020-07-01 | System and method for guaranteeing high availability and consistency of MHA cluster |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111752962B (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112256443B (en) * | 2020-10-14 | 2024-02-06 | 杭州当虹科技股份有限公司 | Redis-based dynamic cluster lock system |
| CN112100160B (en) * | 2020-11-05 | 2021-09-07 | 四川新网银行股份有限公司 | Elastic Search based double-activity real-time data warehouse construction method |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107203617A (en) * | 2017-05-24 | 2017-09-26 | 杭州铭师堂教育科技发展有限公司 | The online migratory systems of mysql and method based on MHA |
| CN110532278A (en) * | 2019-10-30 | 2019-12-03 | 上海爱可生信息技术股份有限公司 | The MySQL database system high availability method of statement formula |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| TWI235299B (en) * | 2004-04-22 | 2005-07-01 | Univ Nat Cheng Kung | Method for providing application cluster service with fault-detection and failure-recovery capabilities |
-
2020
- 2020-07-01 CN CN202010616118.2A patent/CN111752962B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107203617A (en) * | 2017-05-24 | 2017-09-26 | 杭州铭师堂教育科技发展有限公司 | The online migratory systems of mysql and method based on MHA |
| CN110532278A (en) * | 2019-10-30 | 2019-12-03 | 上海爱可生信息技术股份有限公司 | The MySQL database system high availability method of statement formula |
Non-Patent Citations (2)
| Title |
|---|
| MySQL数据库故障转移工具MHA的研究与应用;刘钊;刘宏志;;广西民族大学学报(自然科学版)(第03期);全文 * |
| 基于Zookeeper框架实现MySQL分布式数据库集群;张旭刚;李东辉;俞俊;朱广新;郑磊;;计算机与数字工程(第09期);全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111752962A (en) | 2020-10-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108234170B (en) | Monitoring method and device for server cluster | |
| US10203992B2 (en) | Worker node rebuild for parallel processing system | |
| US9037899B2 (en) | Automated node fencing integrated within a quorum service of a cluster infrastructure | |
| US7698391B2 (en) | Performing a provisioning operation associated with a software application on a subset of the nodes on which the software application is to operate | |
| CN107343034B (en) | QConf-based Redis high availability system and method | |
| CN108270726B (en) | Application instance deployment method and device | |
| CN111752962B (en) | System and method for guaranteeing high availability and consistency of MHA cluster | |
| CN112100005B (en) | Redis copy set implementation method and device | |
| WO2018120174A1 (en) | Failure recovery method and device, and system | |
| CN111953566B (en) | Distributed fault monitoring-based method and virtual machine high-availability system | |
| CN111324417A (en) | Kubernetes cluster component control method and device, electronic equipment and medium | |
| CN105915391B (en) | The distributed key assignments storage method of self-recovering function is submitted and had based on single phase | |
| CN111752488A (en) | Management method and device of storage cluster, management node and storage medium | |
| CN111597079A (en) | Method and system for detecting and recovering MySQL Galera cluster fault | |
| KR102114339B1 (en) | Method for operating kubernetes system supporting active/standby model | |
| CN114138568A (en) | Scheduling method and system for client fault transfer in Redis sentinel mode | |
| KR100404906B1 (en) | Apparatus and method for embodying high availability in cluster system | |
| CN111708668A (en) | Cluster fault processing method and device and electronic equipment | |
| CN113626252A (en) | City-level disaster recovery method and device based on cluster, electronic equipment and medium | |
| US7644306B2 (en) | Method and system for synchronous operation of an application by a purality of processing units | |
| CN109150941B (en) | Data center physical resource floating method | |
| CN112286441A (en) | Method, apparatus and computer medium for providing a visual representation | |
| CN109995560A (en) | Cloud resource pond management system and method | |
| US11853175B2 (en) | Cluster system and restoration method that performs failover control | |
| CN115499296B (en) | Cloud desktop hot standby management method, device 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 |