CN112667440A - Long-distance disaster recovery method for high-availability MySQL - Google Patents
Long-distance disaster recovery method for high-availability MySQL Download PDFInfo
- Publication number
- CN112667440A CN112667440A CN202011587261.XA CN202011587261A CN112667440A CN 112667440 A CN112667440 A CN 112667440A CN 202011587261 A CN202011587261 A CN 202011587261A CN 112667440 A CN112667440 A CN 112667440A
- Authority
- CN
- China
- Prior art keywords
- mysql
- server
- data center
- slave
- 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.)
- Pending
Links
- 238000011084 recovery Methods 0.000 title claims abstract description 38
- 238000000034 method Methods 0.000 title claims abstract description 35
- 230000003993 interaction Effects 0.000 claims abstract description 4
- 238000012544 monitoring process Methods 0.000 claims description 10
- 230000008859 change Effects 0.000 claims description 6
- 230000004048 modification Effects 0.000 claims description 4
- 238000012986 modification Methods 0.000 claims description 4
- 230000007246 mechanism Effects 0.000 claims description 3
- 239000013589 supplement Substances 0.000 claims description 2
- 230000001360 synchronised effect Effects 0.000 abstract description 2
- 230000002159 abnormal effect Effects 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 230000010076 replication Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 238000007726 management method Methods 0.000 description 2
- 230000002688 persistence Effects 0.000 description 2
- 241000700605 Viruses Species 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 238000009795 derivation Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000008034 disappearance Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 230000008569 process Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
Images
Abstract
The invention provides a remote disaster recovery method of high-availability MySQL, which comprises a central control area, a data center A and a data center B, wherein a set of MySQL examples of HA is deployed in the data center A, a set of single-node MySQL examples is deployed in the data center B, a high-availability synchronization service Server and a synchronization service Client are deployed in the central control area, the synchronization service Server and the data center A, the synchronization service Client and the data center B are connected through a private network, the synchronization service Server simulates an interaction protocol of MySQL slave, pretends to be MySQL slave, sends a dump protocol to the MySQL master, the MySQL master receives a dump request, starts pushing a binary log to the slave, and the synchronization service Client acquires data to be synchronized from the Server and sends the data to the data center B for backup. The remote disaster recovery method of the high-availability MySQL can realize real-time synchronization with low time delay and even no time delay.
Description
Technical Field
The invention belongs to the technical field of data processing, and particularly relates to a remote disaster recovery method for high-availability MySQL.
Background
With the development of services, the high availability requirements of users on service systems are higher and higher, which is not satisfied with disaster recovery that can only achieve cross-available areas, and users want to continue to provide services through systems of other areas even if the systems of a certain area are unavailable, which is the cross-area disaster recovery. The current common allopatric disaster recovery method is divided into two types, namely a local main backup and a allopatric disaster recovery, wherein the majority of the methods are the local main backup, and the local main backup is in the form of: one master and one standby or one master and multiple standby, the traditional local master and standby (such as dual-computer hot standby) can not effectively cope with unexpected downtime caused by data or software logic faults, such as man-made misoperation, network virus attack and the like, the remote disaster recovery is to place a master library and a standby library at different places and synchronize by crossing IDCs, and the method has the defects of high delay and incapability of performing real-time backup.
Disclosure of Invention
In view of this, the present invention aims to provide a remote disaster recovery method of high-availability MySQL to effectively implement remote data backup and simultaneously implement rapid recovery of services.
In order to achieve the purpose, the technical scheme of the invention is realized as follows:
a remote disaster recovery method of high-availability MySQL comprises a data center and a central control area, wherein the data center is divided into a physically isolated data center A and a data center B, a set of MySQL examples of HA are deployed in the data center A, the MySQL examples of HA are a main N-slave framework, N is more than or equal to 1, a set of MySQL examples of single nodes are deployed in the data center B, the method is used for backing up data of a MySQL instance in a data center A in a different place, a high-availability synchronization service Server and a synchronization service Client are deployed in a central control area, the synchronization service Server and the data center A, the synchronization service Client and the data center B are connected through a private network, the synchronization service Server simulates an interaction protocol of the MySQL slave, pretends to be MySQL slave, sends a dump protocol to the MySQL master, the MySQL master receives the dump request and starts to push a binary log to the slave, and the synchronization service Client acquires data needing synchronization from the Server and sends the data to the data center B for backup.
Further, the central control area is a logic area and is deployed in a data center.
Further, the central control area is a logical area, and is a department host or a virtual machine in a plurality of data centers.
Further, the service servers adopt a cluster deployment mode, and generally an odd number of service servers larger than 3 form a service server cluster.
Further, the work flow of the central control area synchronization service Server and the synchronization service client is as follows:
firstly, when the Server is started, firstly, a starting attempt judgment is carried out on the Zookeeper;
② which Server successfully creates the temporary node, the Zookeeper will inform the Server of successful start-up, and set the Server state as Running. The server starts monitoring the MySQL database in the data center A to acquire the binlog;
setting the Server state as Standby and monitoring the created temporary node so as to timely supplement bits after the Server in Running state is down, namely, the main-Standby switching of the Server;
when the Client is started, the Server in the Running state is firstly obtained from the Zookeeper, and meanwhile, the Client registers the information of the Client into a temporary node of the Zookeeper. The Client needs to register the monitoring of the temporary node, so that when the primary and standby of the Server are switched, the Client can acquire the notification to make corresponding modification so as to connect a new Server;
and fifthly, the Client connects the corresponding Server in Running state, consumes the binlog obtained by the Server and then informs the remote backup library of carrying out binlog alignment.
Further, in the step (i), when the Server is started, firstly, a start-trying judgment is made to the Zookeeper by the specific method that: the Server creates a same temporary node to the Zookeeper, and if the Server is successfully created, the Server is started, and here, the mechanism of the Zookeeper can ensure that only one Server successfully creates the temporary node.
Further, the specific method for starting to push the binary log to the slave after the MySQL master receives the dump request is as follows:
s1, writing the data change into the binary log by the MySQL master;
s2, MySQL slave copies the binary log events of the master to the relay log thereof;
s3, MySQL slave replays the event in the relay log, and reflects the data change to the data of the MySQL slave.
Compared with the prior art, the remote disaster recovery method of the high-availability MySQL has the following advantages:
(1) the remote disaster recovery method of the high-availability MySQL can realize real-time synchronization with low time delay and even no time delay.
(2) The remote disaster recovery method of the high-availability MySQL ensures the high availability of the service without interruption and remote disaster recovery, and can realize disaster recovery
(3) The remote disaster recovery method of the high-availability MySQL supports various HA architectures of MySQL, one master and one slave or one master and multiple slaves and the like.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate an embodiment of the invention and, together with the description, serve to explain the invention and not to limit the invention. In the drawings:
FIG. 1 is a flowchart of a remote disaster recovery method for high-availability MySQL according to an embodiment of the present invention;
fig. 2 is a flow chart of MySQL master-slave synchronization according to the embodiment of the present invention.
Detailed Description
It should be noted that the embodiments and features of the embodiments may be combined with each other without conflict.
In the description of the present invention, it is to be understood that the terms "center", "longitudinal", "lateral", "up", "down", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", and the like, indicate orientations or positional relationships based on those shown in the drawings, and are used only for convenience in describing the present invention and for simplicity in description, and do not indicate or imply that the referenced devices or elements must have a particular orientation, be constructed and operated in a particular orientation, and thus, are not to be construed as limiting the present invention. Furthermore, the terms "first", "second", etc. are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first," "second," etc. may explicitly or implicitly include one or more of that feature. In the description of the present invention, "a plurality" means two or more unless otherwise specified.
In the description of the present invention, it should be noted that, unless otherwise explicitly specified or limited, the terms "mounted," "connected," and "connected" are to be construed broadly, e.g., as meaning either a fixed connection, a removable connection, or an integral connection; can be mechanically or electrically connected; they may be connected directly or indirectly through intervening media, or they may be interconnected between two elements. The specific meaning of the above terms in the present invention can be understood by those of ordinary skill in the art through specific situations.
The present invention will be described in detail below with reference to the embodiments with reference to the attached drawings.
The noun explains:
high Availability (HA): means to minimize down time due to routine maintenance operations (planning) and sudden system crashes (unplanned) by technical means to improve the availability of the system and applications. The common practice in the industry is to adopt a Cluster system (Cluster), and organically combine various host systems, network systems, storage devices (part of high availability systems includes high availability of storage devices), and the like into a group by various means, and provide services to the outside. Redundant high-availability hardware components and software components are combined by creating a cluster system (adopting software for realizing high availability) so as to eliminate single-point failures and reduce downtime when equipment is accidentally generated. Generally, the high availability technology realizes redundancy switching and continuously provides services when the nodes fail by setting different availability monitoring points for a network card, a CPU, a memory and system software.
Disaster Recovery (DR) (often referred to as disaster recovery or disaster recovery in China) belongs to the technical aspect of business continuity. After the information service is interrupted, resources are transferred, an information technology service platform (comprising infrastructure, communication, a system, application and data) is rebuilt in a different place, and disaster recovery also comprises local recovery and rebuilding. Currently, popular disaster recovery systems often include local HA clusters and off-site DR data centers. From the fault point of view, the HA mainly handles the switching of the load among the servers in the cluster due to the fault of a single component, and the DR deals with the switching of the load among the data centers due to the large-scale fault.
MySQL is the most popular relational database management system, and is the best in terms of WEB applications.
One of RDBMS (Relational Database Management System) application software.
A long-distance disaster recovery method of high-availability MySQL is shown in figure 1 and comprises a data center and a central control area,
the data center is divided into a physically isolated data center a and a data center B,
the method comprises the steps that a set of MySQL examples of HA is deployed in a data center A, the MySQL examples are a main N-slave framework, N is larger than or equal to 1, a set of single-node MySQL examples are deployed in a data center B and used for backing up data of the MySQL examples in the data center A in a different place, a highly available synchronization service Server and a synchronization service Client are deployed in a central control area, the synchronization service Server and the data center A, the synchronization service Client and the data center B are connected through a private network, the synchronization service Server simulates an interaction protocol of MySQL slave, pretends to be MySQL slave, sends a dump protocol to a MySQL master, the MySQL master receives the dump request and starts to push a bank log to the slave (namely, the synchronization service Server), and the synchronization service Client acquires data needing synchronization from the Server and sends the data to the data center B (namely, the different place disaster preparation example) for backing up.
The central control area is a logical area, and may be deployed in one data center or may be a central gate host or a virtual machine in multiple data centers according to services or architectures. However, in any architecture, the central control area, the data center a and the data center B are connected through a private network, and the private network is a low-latency network.
The data center A is provided with a set of HA MySQL instances which are a main-slave architecture, the method can support HA-MySQL instances of various architectures, the implementation principle is the same, and the HA-MySQL instances can be a main-slave or multiple slaves, and the main-slave is taken as an example.
MySQL slave: the main stream relational database provides a master-slave hot standby function, and the data of one database server can be updated and synchronized to another server by configuring the master-slave relation of two (or more) databases. Therefore, read-write separation or local disaster recovery is realized. The MySQL database also supports a master-slave structure, the scheme uses the master-slave structure of MySQL with a master node and a slave node, the master node is called MySQLMmaster, and the slave node is called MySQL slave. Note that: recently, MySQL team changes Master to source and slave to reply, so to avoid ambiguity, MySQL slave in the patent can be changed to MySQL slave; the MySQL master can be changed to a MySQL master node.
To reduce the requests for mysql dump, different sync service servers can only have one running and the other in standby state at the same time.
In order to ensure the ordering, the get/ack/rollback operation can be carried out by only one synchronization service client at the same time, otherwise, the client receiving can not ensure the ordering. The method is changed into the method that only one synchronization service client can work at the same time, otherwise, the orderliness of the synchronization data cannot be ensured. Here get, ack, Rollback are all the main functions and work of the service client.
mysql dump is used for backup, recovery and synchronization of data. Because the backup or derivation of the sql statement by the MySQL vamp has the disadvantages of low speed and more resource occupation, the frequency of the MySQL dump needs to be reduced as much as possible in order to not affect the performance of the MySQL master node, only one service server in running state is reserved here, and the MySQL master node only needs the MySQL dump once.
State of service server: comprises that
Running: in operation, logic to perform data synchronization.
Standby: in the preparation, preparation is carried out at any time, if the service server in running is abnormal, the service server in the standby state can be directly converted into the running state, so that the service server cluster can be ensured to be in a working state as much as possible.
Termination: and ending, wherein the service server is in an unavailable state.
In order to ensure high availability of the service servers, the service servers adopt a cluster deployment mode, and an odd number of service servers larger than 3 generally form a service server cluster.
The work flow of the synchronization service Server and the synchronization service client in the central control area is as follows:
starting is attempted. When starting, the Server firstly makes a judgment of starting attempt to the Zookeeper. The specific method is that a same temporary node is created for the Zookeeper, and which Server is created successfully is started, and here, the mechanism of the Zookeeper can ensure that only one Server creates the temporary node successfully.
And the starting is successful. Which Server successfully creates the temporary node, the Zookeeper informs the Server of successful start-up and sets the Server state as Running. The server will start monitoring the MySQL database in the data center a to obtain binlog.
And initiating failure. Other servers have not created a successful temporary node. Setting the Server state as Standby, and monitoring the created temporary node, so that the position is timely supplemented after the Server in Running state is down, which is the main-Standby switch of the Server.
And fourthly, reading the Server currently in the Running state from the Zookeeper, and when the Client is started, firstly acquiring the Server currently in the Running state from the Zookeeper, and simultaneously registering the information of the Client into a temporary node of the Zookeeper. And the Client needs to register the monitoring of the temporary node, so that when the primary and standby servers of the Server are switched, the Client can acquire the notification to make corresponding modification so as to connect a new Server.
Connecting the corresponding Running state Server, consuming the binlog obtained by the Server, and then informing the remote backup library to perform binlog alignment.
The above-mentioned Server master/slave switching: in the operation process of the server, some abnormal conditions inevitably occur, so that the server cannot work normally, and the master/standby switching is required at this time. Based on the characteristics of the Zookeeper temporary node, when the server originally in Running state is ported to the Zookeeper for reasons such as hanging or network, the created temporary node will disappear. Since all the servers in the Standby state have monitored the node, after receiving the notification of node deletion or disappearance sent by the Zookeeper, the steps (i) are repeated, thereby implementing the active-Standby switching.
ZooKeeper is a distributed, open-source distributed application coordination service, is an open-source implementation of Chubby of Google, and is an important component of Hadoop and Hbase. It is a software that provides a consistent service for distributed applications, and the functions provided include: configuration maintenance, domain name service, distributed synchronization, group service, etc. The zookeeper is used for ensuring that one and only one service server in the service server cluster are in running state; and ensuring that if the service server in the running state is abnormal or is down, the service server in the standby state can select a new service server through the zookeeper, so that the service server is converted into the running state to provide service for the service client.
As shown in fig. 2, the MySQL master-slave synchronization flow chart, when receiving the dump request, the MySQL master starts to push the binary log to the slave (i.e. the synchronization service Server) by the following specific method:
s1, the MySQL master writes the data change into a binary log (binary log, wherein the record is called binary log event, and can be viewed through show binary log events); binarylog, also known as Binlog, binary log: the binary log binlog of MySQL, which can be said to be the most important log of MySQL, records all DDL and DML statements (except for data query statements select, show, etc.), records in the form of events, and also contains the time consumed by the execution of the statements, and is transaction-safe. The main purpose of binlog is replication and recovery.
Two of the most important usage scenarios for Binlog logs:
MySQL master-slave replication: the MySQL Replication starts binlog at the Master end, and the Master transmits the binary log to the slave to achieve the aim of Master-slave data consistency;
and (3) data recovery: data was recovered by using the mysql brinlog tool. The binlog of the MySQL main node in the data center A is taken and transmitted to the MySQL instance of the data center B through the method, and the MySQL instance of the data center B can restore data according to the binlog.
S2, MySQL slave copies the register log events of the master to its relay log (relay log);
s3, MySQL slave replays the event in the relay log, and reflects the data change to the data of the MySQL slave.
The MySQL slave node runs a plurality of threads (threads), and the threads together complete the work of the MySQL slave node. Wherein, the I/O Thread is used for reading and writing data in the database and reading binary log from the main node; the SQL Thread is used for executing SQL sentences in the binary to complete the persistence of the data;
relay log: the relay log is a core for connecting the master and the slave;
after acquiring binlog from the MySQL main node, the I/O Thread firstly caches the binlog into a relay log, the SQL Thread acquires SQL from the relay log and performs persistence, and the relay log plays a role in caching.
The above description is only for the purpose of illustrating the preferred embodiments of the present invention and is not to be construed as limiting the invention, and any modifications, equivalents, improvements and the like that fall within the spirit and principle of the present invention are intended to be included therein.
Claims (7)
1. A high-availability MySQL allopatric disaster recovery method is characterized by comprising the following steps: the data center is divided into a data center A and a data center B which are physically isolated, a set of MySQL instances of HA is deployed in the data center A and is a framework of a master N slave, N is more than or equal to 1, a set of single-node MySQL instances are deployed in the data center B and are used for backing up data of the MySQL instances in the data center A in different places, a highly available synchronization service Server and a synchronization service Client are deployed in the central control area, the synchronization service Server, the data center A, the synchronization service Client and the data center B are connected through a private network, the synchronization service Server simulates an interaction protocol of MySQL slave, pretends to be MySQL slave, sends a dump protocol to the MySQL master, the MySQL master receives the dump request, starts to push a bank log to the slave, and the synchronization service Client acquires data needing synchronization from the Server and sends the data to the data center B for backup.
2. The remote disaster recovery method of high-availability MySQL according to claim 1, which is characterized in that: the central control area is a logic area and is deployed in a data center.
3. The remote disaster recovery method of high-availability MySQL according to claim 1, which is characterized in that: the central control area is a logical area and is a department host or a virtual machine in a plurality of data centers.
4. The remote disaster recovery method of high-availability MySQL according to claim 1, which is characterized in that: the service servers adopt a cluster deployment mode, and generally odd service servers larger than 3 form a service server cluster.
5. The remote disaster recovery method of high-availability MySQL according to claim 1, which is characterized in that: the work flow of the synchronization service Server and the synchronization service client in the central control area is as follows:
firstly, when the Server is started, firstly, a starting attempt judgment is carried out on the Zookeeper;
② which Server successfully creates the temporary node, the Zookeeper will inform the Server of successful start-up, and set the Server state as Running. The server starts monitoring the MySQL database in the data center A to acquire the binlog;
setting the Server state as Standby and monitoring the created temporary node so as to timely supplement bits after the Server in Running state is down, namely, the main-Standby switching of the Server;
when the Client is started, the Server in the Running state is firstly obtained from the Zookeeper, and meanwhile, the Client registers the information of the Client into a temporary node of the Zookeeper. The Client needs to register the monitoring of the temporary node, so that when the primary and standby of the Server are switched, the Client can acquire the notification to make corresponding modification so as to connect a new Server;
and fifthly, the Client connects the corresponding Server in Running state, consumes the binlog obtained by the Server and then informs the remote backup library of carrying out binlog alignment.
6. The off-site disaster recovery method for high-availability MySQL according to claim 5, which is characterized in that: in the step i, when the Server is started, firstly, a judgment of trying to start the Zookeeper is made in a specific way: the Server creates a same temporary node to the Zookeeper, and if the Server is successfully created, the Server is started, and here, the mechanism of the Zookeeper can ensure that only one Server successfully creates the temporary node.
7. The remote disaster recovery method of high-availability MySQL according to claim 1, which is characterized in that: the specific method for starting to push the binary log to the slave after the MySQL master receives the dump request is as follows:
s1, writing the data change into the binary log by the MySQL master;
s2, MySQL slave copies the binary log events of the master to the relay log thereof;
s3, MySQL slave replays the event in the relay log, and reflects the data change to the data of the MySQL slave.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011587261.XA CN112667440A (en) | 2020-12-28 | 2020-12-28 | Long-distance disaster recovery method for high-availability MySQL |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011587261.XA CN112667440A (en) | 2020-12-28 | 2020-12-28 | Long-distance disaster recovery method for high-availability MySQL |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112667440A true CN112667440A (en) | 2021-04-16 |
Family
ID=75411480
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011587261.XA Pending CN112667440A (en) | 2020-12-28 | 2020-12-28 | Long-distance disaster recovery method for high-availability MySQL |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112667440A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113722401A (en) * | 2021-11-04 | 2021-11-30 | 树根互联股份有限公司 | Data caching method and device, computer equipment and readable storage medium |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103838646A (en) * | 2014-02-13 | 2014-06-04 | 中国科学院国家天文台 | System and method for big data remote disaster recovery backup of ground application |
| CN106254100A (en) * | 2016-07-27 | 2016-12-21 | 腾讯科技（深圳）有限公司 | A kind of data disaster tolerance methods, devices and systems |
| CN106850260A (en) * | 2016-12-23 | 2017-06-13 | 曙光云计算技术有限公司 | A kind of dispositions method and device of virtual resources management platform |
| CN109947591A (en) * | 2017-12-20 | 2019-06-28 | 腾讯科技（深圳）有限公司 | Database strange land disaster recovery and backup systems and its dispositions method, deployment device |
| CN111026813A (en) * | 2019-12-18 | 2020-04-17 | 紫光云(南京)数字技术有限公司 | High-availability quasi-real-time data synchronization method based on MySQL |
| CN111581026A (en) * | 2020-05-09 | 2020-08-25 | 天津七一二通信广播股份有限公司 | Remote disaster recovery backup method and system based on big data rack perception technology |
| CN112035435A (en) * | 2020-08-26 | 2020-12-04 | 浪潮云信息技术股份公司 | MySQL master-slave cluster installation deployment method and cluster system |
-
2020
- 2020-12-28 CN CN202011587261.XA patent/CN112667440A/en active Pending
Patent Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103838646A (en) * | 2014-02-13 | 2014-06-04 | 中国科学院国家天文台 | System and method for big data remote disaster recovery backup of ground application |
| CN106254100A (en) * | 2016-07-27 | 2016-12-21 | 腾讯科技（深圳）有限公司 | A kind of data disaster tolerance methods, devices and systems |
| WO2018019023A1 (en) * | 2016-07-27 | 2018-02-01 | 腾讯科技（深圳）有限公司 | Data disaster recovery method, apparatus and system |
| EP3493471A4 (en) * | 2016-07-27 | 2019-06-05 | Tencent Technology (Shenzhen) Company Limited | Data disaster recovery method, apparatus and system |
| CN106850260A (en) * | 2016-12-23 | 2017-06-13 | 曙光云计算技术有限公司 | A kind of dispositions method and device of virtual resources management platform |
| CN109947591A (en) * | 2017-12-20 | 2019-06-28 | 腾讯科技（深圳）有限公司 | Database strange land disaster recovery and backup systems and its dispositions method, deployment device |
| CN111026813A (en) * | 2019-12-18 | 2020-04-17 | 紫光云(南京)数字技术有限公司 | High-availability quasi-real-time data synchronization method based on MySQL |
| CN111581026A (en) * | 2020-05-09 | 2020-08-25 | 天津七一二通信广播股份有限公司 | Remote disaster recovery backup method and system based on big data rack perception technology |
| CN112035435A (en) * | 2020-08-26 | 2020-12-04 | 浪潮云信息技术股份公司 | MySQL master-slave cluster installation deployment method and cluster system |
Non-Patent Citations (3)
| Title |
|---|
| ARYAN WIBOWO等: "Building Scalable and Resilient Database System to Mitigate Disaster and Performance Risks", 《PROCEDIA COMPUTER SCIENCE》 * |
| 张金波: "容灾备份与恢复平台的设计与实现", 《中国优秀博硕士学位论文全文数据库(硕士)信息科技辑》 * |
| 杨义先等: "信息系统灾备技术综论", 《北京邮电大学学报》 * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113722401A (en) * | 2021-11-04 | 2021-11-30 | 树根互联股份有限公司 | Data caching method and device, computer equipment and readable storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11360854B2 (en) | Storage cluster configuration change method, storage cluster, and computer system | |
| US10713135B2 (en) | Data disaster recovery method, device and system | |
| CN106062717B (en) | A kind of distributed storage dubbing system and method | |
| EP2521037B1 (en) | Geographically distributed clusters | |
| US8856091B2 (en) | Method and apparatus for sequencing transactions globally in distributed database cluster | |
| CN105814544B (en) | System and method for supporting persistent partition recovery in a distributed data grid | |
| CN103345502B (en) | Transaction processing method and system of distributed type database | |
| CN111581284A (en) | High-availability method, device and system for database and storage medium | |
| CN106156318B (en) | System and method for realizing high availability of multi-node database | |
| WO2007028248A1 (en) | Method and apparatus for sequencing transactions globally in a distributed database cluster | |
| WO2012071920A1 (en) | Method, system, token conreoller and memory database for implementing distribute-type main memory database system | |
| CN105069160A (en) | Autonomous controllable database based high-availability method and architecture | |
| CN104536971A (en) | High-availability database | |
| JP2007518195A (en) | Cluster database using remote data mirroring | |
| Moiz et al. | Database replication: A survey of open source and commercial tools | |
| CN110727709A (en) | Cluster database system | |
| CN115794499B (en) | Method and system for dual-activity replication data among distributed block storage clusters | |
| CN110175089A (en) | A kind of dual-active disaster recovery and backup systems with read and write abruption function | |
| CN112783694B (en) | Long-distance disaster recovery method for high-availability Redis | |
| CN113254275A (en) | MySQL high-availability architecture method based on distributed block device | |
| CN109361777A (en) | Synchronous method, synchronization system and the relevant apparatus of distributed type assemblies node state | |
| CN112667440A (en) | Long-distance disaster recovery method for high-availability MySQL | |
| WO2015196692A1 (en) | Cloud computing system and processing method and apparatus for cloud computing system | |
| CA2619778C (en) | Method and apparatus for sequencing transactions globally in a distributed database cluster with collision monitoring | |
| CN113905054B (en) | RDMA (remote direct memory access) -based Kudu cluster data synchronization 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 | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20210416 |
|
| RJ01 | Rejection of invention patent application after publication |