CN108810150B - Data replication method of application-level disaster recovery backup system of cooperative office system - Google Patents
Data replication method of application-level disaster recovery backup system of cooperative office system Download PDFInfo
- Publication number
- CN108810150B CN108810150B CN201810621652.5A CN201810621652A CN108810150B CN 108810150 B CN108810150 B CN 108810150B CN 201810621652 A CN201810621652 A CN 201810621652A CN 108810150 B CN108810150 B CN 108810150B
- Authority
- CN
- China
- Prior art keywords
- data
- disaster recovery
- center
- file
- synchronization
- 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
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
- G06F11/1448—Management of the data involved in backup or backup restore
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention discloses a data replication method of an application-level disaster recovery system of a cooperative office system, which comprises the following steps: the cooperative office system is correspondingly provided with a copying mechanism according to the data type, and copies by adopting an intermediate file asynchronous copying method and an application file redundancy uploading method respectively according to different local file use requirements of the disaster recovery center; local files for task cooperation are more, but the requirement on data copying real-time performance is not high due to regional isolation, and a method for asynchronously copying files among centers is adopted; the official document transmission and data exchange belong to a data exchange center, and the real-time copying pressure is leveled to each business operation process by adopting a method of redundant uploading of application files. The key point of the invention for realizing the dual-active disaster recovery of the cooperative office system is the unification of the back-end data of the two centers.
Description
Technical Field
The invention relates to the technical field of computers, in particular to a data replication method of an application-level disaster recovery system of a cooperative office system.
Background
The service continuity guarantee is the target of application-level disaster recovery construction of the cooperative office system. The objective of remote and allopatric dual-active disaster recovery design and construction is realized by cooperation of national network companies, and the design and construction method belongs to the highest level of disaster recovery construction level. Through the classification of the service interruption event, corresponding emergency countermeasures are necessary for various events. Only if the rapid takeover and recovery aiming at global disasters are realized and the emergency of local faults is considered, an all-around and powerful fault emergency system can be constructed, and the service continuity of enterprises can be powerfully guaranteed. The key of the cooperative office system dual disaster recovery lies in the unification of the backend data of the two centers, which is the focus of application switching (takeover). If there is no guarantee of consistency of the data, then applying double live is a null word. The cooperative office system has many data types and complex applications, each data copy has its own mode and mechanism, including structured data (such as ORACLE), unstructured data (such as data generated by DOMINO application system, SOLR index data and various picture data documents), and cannot cover all data in one copy mode. Therefore, different business data such as DOMINO, ORACLE, Solr and other files need to be copied and planned separately.
Disclosure of Invention
The invention aims to provide a data copying method of an application-level disaster backup system of a cooperative office system, which is used for solving the problem of data copying design of two disaster backup centers of a power grid cooperative office system test point unit in a remote and different place double-active disaster backup.
In order to achieve the above purpose, the invention is realized by the following technical scheme:
a data replication method for an application-level disaster recovery system of a collaborative office system comprises the following steps: in order to realize that any one end of the disaster recovery backup center has full service logic and service data and meet the capability of carrying the whole network service after system switching, the service change data of any one disaster recovery backup center is asynchronously copied to the opposite end disaster recovery backup center according to different service data types.
The cooperative office system is correspondingly provided with a copying mechanism according to the data type, and copies by adopting an intermediate file asynchronous copying method and an application file redundancy uploading method respectively according to different local file use requirements of the disaster recovery center.
Local files for task cooperation are more, but the requirement on data copying real-time performance is not high due to regional isolation, and a method for asynchronously copying files among centers is adopted.
The official document transmission and data exchange belong to a data exchange center, and the real-time copying pressure is leveled to each business operation process by adopting a method of redundant uploading of application files.
Preferably, the method for asynchronously copying the inter-center file comprises the following processes: synchronously initializing application-level disaster recovery system components of the cooperative office system:
and setting a start increment synchronous mark of the task cooperation asynchronous file before starting synchronization.
Developing an automation script, and synchronizing data of a data center task cooperation related directory of a normal disaster recovery center to a host directory corresponding to a data center of an initialization disaster recovery center by using a special tool; and setting task cooperation data synchronization and generating an increment synchronization message.
And respectively adding a Kafka distribution message middleware cluster in the two disaster recovery centers for asynchronous and synchronous control.
When the client uses the task cooperation module to operate the attachment and allows the increment synchronization to start, the task cooperation processing module generates a local file of the disaster recovery center and simultaneously generates a file synchronization kafka message request, wherein the message content comprises a file name, a file path, a file size and information of a host where the file is located.
A synchronization message processing component.
And connecting the data center of the opposite-end disaster recovery center to a corresponding kafka message middleware cluster of the data center of the opposite-end disaster recovery center in a client mode through a kafka interface, acquiring unprocessed message requests from a queue, and processing the message requests one by one until all message processing is completed.
And analyzing the synchronization message request, acquiring the file name and the file path which need to be synchronized, the host where the file is located and the file size information, and synchronizing the corresponding file from the specified directory of the opposite-end disaster recovery center to the local-end disaster recovery center in an ftp mode.
Preferably, the application file redundant uploading copying method includes the following processes: and synchronizing the directory data corresponding to the data center official document transmission and data exchange shared file system of the normal disaster recovery center to the directory of the host corresponding to the data center of the initialized disaster recovery center by using a special tool through an automatic shell script.
When the cooperative office subsystem carries out networking text sending, calling a document transmission assembly of the home-end disaster recovery center to upload document data to a shared file system, calling service of the document transmission assembly of the opposite-end disaster recovery center at the same time, and uploading the document data to a data center shared directory of the opposite-end disaster recovery center at the same time; and if one disaster recovery center fails to call the service, the whole service processing fails.
When the cooperative office subsystem carries out data exchange operation, the data exchange assembly of the local disaster recovery center is called to upload temperature control data to the shared file system, the data exchange transmission assembly of the opposite disaster recovery center is called at the same time, the exchange file is transmitted to the data center shared file system of the opposite disaster recovery center, service calling belongs to the same transaction twice, and if one disaster recovery center fails in service calling, the whole service processing fails.
Preferably, the two disaster recovery centers use the same hardware resources to deploy two identical SolrCloud unified search clusters, and the two SolrCloud clusters in the two centers run simultaneously in daily conditions.
The Solr index data replication method is adopted to realize the Solr cluster data synchronization of the data centers of the two disaster recovery centers, a synchronization network between clusters is independently and newly established in a virtual local area network mode and is separated from a production network, the bandwidth of the synchronization network is limited, and the normal operation of production application is not influenced when the data are synchronized; the Solr index data copying method comprises the following steps: and the cluster synchronization initialization component sets a SolrCloud cluster start increment synchronization mark before starting synchronization.
Through an automatic shell script, index data directory data under a SolrCloud cluster host of a normal data center are synchronized to a host directory corresponding to a data center of an initialization disaster recovery center by using a special tool;
and when the whole SolrCloud cluster data is completely and successfully synchronized, starting and initializing the SolrCloud unified search service application in the data center of the disaster recovery center.
Setting a SolrCloud cluster initialization completion flag; a message middleware cluster component.
A Kafka distributed message middleware cluster is respectively built in a plurality of virtual Linux machines used in two disaster recovery centers.
And transforming a first-level deployment application, generating SolrCloud cluster index data and simultaneously generating index related data into a Kafka message middleware cluster at the same time in a file management, file center and office automation module for processing by a synchronization program.
A synchronization message processing component.
After the SolrCloud cluster is initialized, obtaining unprocessed message requests from a Kafka distributed message middleware queue of a data center of the opposite-end disaster recovery center, and processing the messages one by one until all the messages are processed.
And analyzing the synchronous message to be processed, and writing the message into the SolrCloud cluster of the local disaster recovery center according to the request content.
Preferably, the special tool is a data mirror image backup tool under a Linux-like system under Linux.
Compared with the prior art, the invention has the following advantages:
the disaster recovery backup system can effectively reduce the impact born by the core IT system of the company, accelerate the recovery of the damaged information system, further enhance the safe power supply risk management capability of the whole power network and effectively promote the sustainable development of the economic society. In order to maintain the healthy and stable development of an enterprise IT information system, the construction of a disaster recovery system is an effective method for ensuring the good expansibility and sustainability of business. The national grid company has a wide operating range, the external environment conditions are complicated and intricate, the construction of the disaster recovery system can effectively prevent risks, reduce loss, improve service continuity and high availability, and improve the capability of the IT information management system to cope with various changes at any time. When a disaster occurs in a certain province, immeasurable economic loss can be brought, and the disaster recovery system ensures the safety of data and can reduce the loss to the minimum. Compared with a province and city self-building disaster backup machine room mode, the centralized disaster backup center can be built, so that the resource utilization rate can be improved, and a large amount of resources can be saved. The equipment room matching area, the air conditioner, the power cabinet, the UPS, the equipment cabinet, the IT equipment, the emergency verification area share resources, software license and the like, and a large amount of investment is saved. And a centralized disaster recovery center mode is adopted, so that the equipment maintenance cost can be saved. Because the equipment is reduced, the energy consumption is reduced, the human resource cost is saved, the personnel training cost is reduced, and the disaster recovery management cost is reduced. In addition, in the aspect of data replication, as a key point of dual-active disaster recovery construction, respective logic asynchronous replication strategies including Domino document data, an Oracle database, a file, Solr index data and the like are constructed according to different data types and application characteristics, and the data dual-read-write and application dual-active strategies are realized through logic isolation of a data access range.
Drawings
FIG. 1 is a schematic diagram of an architecture of an application-level double-active disaster recovery system of a collaborative office system according to the present invention;
FIG. 2 is a flowchart of a method for asynchronous replication of files between centers according to the present invention;
FIG. 3 is a flowchart of a method for copying an application file by redundant uploading according to the present invention;
FIG. 4 is a flow chart of a method for copying Solr index data in the present invention.
Detailed Description
The present invention will now be further described by way of the following detailed description of a preferred embodiment thereof, taken in conjunction with the accompanying drawings.
As shown in fig. 1, the present invention is applicable to a collaborative office system application level double-active disaster recovery system, which includes:
the cooperative office system is split, the service of the whole area is distributed to two disaster recovery centers of an area A and an area B, and the service change data is asynchronously copied to an opposite end according to different service data types. Therefore, any end system has full service logic and service data, and the capacity of carrying the whole network service after the system is switched is met.
Each disaster recovery center is provided with the same server group, and the server group comprises an NTP time synchronization server, an ORACLE database replication server, a plurality of application server resource pool hosts and a plurality of database application servers.
The NTP time synchronization server is used for providing uniform synchronization time for each application server and network in the cooperative office system, plays a role of time reference for consistency verification of data replication and data synchronization, and provides time reference for uniform network management and operation and maintenance monitoring of each system. At present, an NTP server deployed at the national network level is adopted to provide a clock synchronization source for a cooperative office system, each application server and a network system of the cooperative office system acquire correct time from the NTP server, and an NTP clock source of a disaster recovery center in a B area is specifically selected as a reference.
Two disaster recovery centers of the system are respectively provided with a storage system and a Continuous Data Protector (CDP), wherein the storage system is used for storing local data in the cooperative office system and performing read-write operation on the local data. The primary role of the Continuous Data Protector (CDP) and accompanying companion flash is to provide local data protection to cope with emergency recovery from local storage failures and logic failures. Wherein the amount of data to be protected relates to only core data (e.g., ORACLE database data).
The ORACLE database replication server is configured with database replication software for performing the following operations: and adopting a non-proxy mode, and analyzing the log to obtain SQL statements so as to realize real-time copying of data in the database.
The database replication software mainly aims at an ORACLE database, and if the disaster recovery center of the area B is far away from the disaster recovery center of the area A, the number of data transmission network nodes is large, and the fault-tolerant capability of the network fault is good; in addition, the performance of the ORACLE database is minimized during product operation. The above-described database replication software has the following advantages. And (3) network failure: and normal work is ensured under the conditions of long-time interruption, short-time interruption and network interruption. Database failure: and under the fault of the target end database, the source end database is not influenced, and after the target end database is repaired, the software continues to work. The method supports the continuous operation after the fault is recovered under the conditions of network fault, server hardware fault, database fault and the like, and supports the breakpoint transmission; the copying software guarantees the accuracy of the data, the consistency of the data is verified in real time in the copying process, and an alarm function is provided if abnormality is found.
The design of the double-active application mainly aims at the specific planning and design of a DOMINO application system, a unified login system, a unified view, national network official document transmission, database synchronous application, database data writing sequence application, database switching notification application and dynamic domain name application, and ensures the unification of the double-active application.
The key of the cooperative office system double-active disaster recovery lies in the unification of the back-end data of the disaster recovery centers in the areas A and B. The completion of disaster take-over and double active reconstruction is two processes: firstly, when a system disaster occurs, the application is switched (taken over) from one end where the disaster occurs to the other end, and the double-activity reconstruction is the back-cut of the application after the recovery and production of one end where the disaster occurs, wherein the back-cut relates to the division standard, decision principle, coping method, response flow and the like of the danger level, and particularly relates to the completion of a data supplementary recording link in the double-activity reconstruction stage, which is a mark for the real production recovery.
The double-active disaster recovery system of the cooperative office system is associated with a plurality of peripheral applications, including a portal system, a unified authority, a digital archive, an electronic file, an unstructured platform, a video teleconference, an IMS and other systems, and generates interaction and calling of various application data. For a Domino node group in the system, node group combination is carried out on an application server, each distributed Domino node has the service and data management capacity of providing more than two nodes, and before switching is carried out after double-activity construction, a server of a disaster recovery center in an area A or an area B provides service of a local terminal, but manages service data of the disaster recovery center in the area B or the area A at the same time.
In live-active operation, part of the service directory provides service access according to actual service access, and the actual service directory provides service access in another data, but provides copy write at the local end. That is, as shown in fig. 2, when the cooperative office system application-level dual-active disaster recovery system is in normal operation, the user in the disaster recovery center in area a reads and writes data in area a. And the A-area disaster recovery center asynchronously copies the data of the B-area disaster recovery center to the A-area disaster recovery center. And the user of the B area disaster recovery center writes and reads the data of the B area, and the B area disaster recovery center asynchronously copies the data of the A area disaster recovery center to the B area disaster recovery center. When the disaster recovery center of the area A or the area B has a fault, after the disaster recovery system starts the disaster recovery operation mode, the users of the area A and the area B can correspondingly read and write data of the area B or the area A from the area B or the area A disaster recovery center.
The disaster recovery centers in the area A and the area B both build the same unified login service, and the functions of the service are completely consistent. But normally, only the unified login service of the disaster recovery center in the area B is started, the unified login service in the area A is started but not actually started, and the service switching during the disaster recovery starting is realized by combining the DNS server. Namely: the services logged in the entries in the dual activities of the collaborative office system are not simultaneously used although they are also simultaneously opened.
The nodes with the local file data have task cooperation, data exchange and official document transmission. The application uses Weblogic middleware, and the file data and the application are in a separated state. The task collaboration has the regional access characteristic and large data volume. Data exchange and official document transmission are data exchange centers which are built for realizing smooth politics and integrated application, belong to services shared by the whole network, and have high requirements on data replication timeliness. The cooperative office system is correspondingly provided with a copying mechanism according to the data type, and the data type in the cooperative office system comprises the following data types: for structured data (e.g., ORACLE), unstructured data (e.g., data generated by DOMINO application system, SOLR index data, and various picture material documents).
According to different use requirements of the local files, the asynchronous copying of the intermediate files and the redundant uploading strategy of the application files are respectively adopted for copying.
Local files for task cooperation are more, but the requirement on data copying real-time performance is not high due to regional isolation, and a file asynchronous copying strategy among centers is adopted.
The official document transmission and data exchange belong to a data exchange center, the data volume is not large due to low integral business proportion, but the real-time requirement is high, and the pressure of real-time copying can be leveled to each business operation process by adopting a mode of uploading redundancy of application files.
As shown in FIG. 2, the inter-center file asynchronous replication policy comprises the following processes: a synchronization initialization component:
setting a task collaboration asynchronous file start increment synchronous mark before starting synchronization;
developing an automation script, and synchronizing task cooperation related directory data of a normal data center into a host directory corresponding to an initialized data center by using a special tool (a data mirror image backup tool under a similar unix system under Linux); and setting task cooperation data synchronization. And generating the increment synchronous message.
And newly adding a Kafka distribution message middleware cluster in the disaster recovery centers of the B area and the A area respectively for asynchronous and synchronous control.
When the client uses the task cooperation module to operate the attachment and allows the increment synchronization to start, the task cooperation processing module generates a local file of the disaster recovery center and simultaneously generates a file synchronization kafka message request, wherein the message content comprises information such as a file name, a file path, a file size, a host where the file is located and the like.
A synchronization message processing component.
Connecting to a corresponding kafka message middleware cluster of the opposite-end data center in a client mode through a kafka interface, acquiring unprocessed message requests from a queue, and processing the message requests one by one until all message processing is completed.
And analyzing the synchronization message request, acquiring information such as a file name, a file path, a host where the file is located, the size of the file and the like which need to be synchronized, and synchronizing the corresponding file from the specified directory of the opposite terminal center to the local center in an ftp mode.
As shown in fig. 3, the initialization of the application file redundant upload copy policy includes the following processes: and synchronizing the normal data center document transmission and the data exchange shared file system corresponding directory data into the initialized data center corresponding host directory by using a special tool (a data mirror image backup tool under a similar unix system under Linux) through an automatic shell script.
When the cooperative office subsystem carries out networking sending, when the official document transmission assembly of the disaster recovery center is called to upload official document data to the shared file system, the service of the official document transmission assembly of the disaster recovery center of the opposite terminal is called at the same time, and the official document data are uploaded to the shared directory of the data center of the opposite terminal at the same time; the disaster recovery center or the opposite terminal disaster recovery center fails to call the document transmission service, belongs to the same transaction, and if a certain disaster recovery center fails to call the service, the whole service processing fails.
When the cooperative office subsystem carries out data exchange operation, the disaster backup center data exchange assembly is called to upload temperature control data to the shared file system, the opposite-end disaster backup center data exchange transmission assembly is called at the same time, the exchange file is transmitted to the opposite-end data center shared file system, service calling belongs to the same transaction twice, and if a certain disaster backup center service calling fails, the whole service processing fails.
As shown in fig. 4, two identical solrtoud unified search clusters are deployed in the disaster recovery centers of the B area and the a area by using the same hardware resources, and the two solrtoud clusters of the two centers run simultaneously in daily conditions;
data synchronization of Solr clusters of data centers of disaster recovery centers of a zone B and a zone A is realized through a central data synchronization component, a synchronization network between the clusters is independently newly built in a virtual local area network mode and is separated from a production network, the bandwidth of the synchronization network is limited, and the normal operation of production application is not influenced when the data synchronization is ensured.
Cluster synchronization initialization component:
and setting SolrCloud cluster start increment synchronous mark before starting synchronization.
Index data directory data under the SolrCloud cluster host of the normal data center are synchronized into a host directory corresponding to the initialized data center by an automatic shell script and a special tool (a data mirror image backup tool under a similar unix system under Linux).
And when the whole SolrCloud cluster data is completely synchronized successfully, starting and initializing the SolrCloud unified search service application in the data center.
And setting a SolrCloud cluster initialization completion flag.
Message middleware cluster component:
a Kafka distributed message middleware cluster is respectively built in a plurality of virtual Linux machines used in a disaster recovery center in a zone B and a zone A.
And transforming a first-level deployment application, generating SolrCloud cluster index data and simultaneously generating index related data into a Kafka message middleware cluster at the same time in a file management, file center and office automation module for processing by a synchronization program.
A synchronization message processing component:
after the SolrCloud cluster is initialized, obtaining unprocessed message requests from a Kafka distributed message middleware queue of an opposite-end data center, and processing the messages one by one until all the messages are processed.
And analyzing the synchronous message to be processed, and writing the message into the SolrCloud cluster of the center according to the request content.
While the present invention has been described in detail with reference to the preferred embodiments, it should be understood that the above description should not be taken as limiting the invention. Various modifications and alterations to this invention will become apparent to those skilled in the art upon reading the foregoing description. Accordingly, the scope of the invention should be determined from the following claims.
Claims (4)
1. A data replication method for an application-level disaster recovery system of a collaborative office system is characterized by comprising the following steps: in order to realize that any one end of the disaster recovery backup center has full service logic and service data and meet the capability of carrying the whole network service after system switching, the service change data of any one disaster recovery backup center is asynchronously copied to the opposite end disaster recovery backup center according to different service data types;
the cooperative office system is correspondingly provided with a copying mechanism according to the data type, and copies are respectively carried out by adopting a method of asynchronous copying of files among centers and redundant uploading of application files according to different requirements of local files of the disaster recovery center;
copying a local file of task cooperation by adopting an inter-center file asynchronous copying method;
the official document transmission and data exchange belong to a data exchange center, and the real-time copying pressure is leveled in each business operation process by adopting an application file redundancy uploading method;
the method for asynchronously copying the files among the centers comprises the following processes: synchronously initializing application-level disaster recovery system components of the cooperative office system:
setting a task collaboration asynchronous file start increment synchronous mark before starting synchronization;
developing an automation script, and synchronizing data of a data center task cooperation related directory of a normal disaster recovery center to a host directory corresponding to a data center of an initialization disaster recovery center by using a special tool; setting task cooperation data synchronization and generating an increment synchronization message;
respectively adding a Kafka distribution message middleware cluster in the two disaster recovery centers for asynchronous and synchronous control;
when a client uses a task cooperation module to operate an attachment and allows increment synchronization to start, a task cooperation processing module generates a local file of the disaster recovery center and simultaneously generates a file synchronization kafka message request, wherein the message content comprises a file name, a file path, a file size and information of a host where the file is located;
a synchronization message processing component;
connecting to a kafka message middleware cluster corresponding to a data center of an opposite-end disaster recovery center in a client mode through a kafka interface, acquiring unprocessed message requests from a queue, and processing the message requests one by one until all message processing is completed;
and analyzing the synchronization message request, acquiring the file name and the file path which need to be synchronized, the host where the file is located and the file size information, and synchronizing the corresponding file from the specified directory of the opposite-end disaster recovery center to the local-end disaster recovery center in an ftp mode.
2. The data replication method of a collaborative office system application-level disaster recovery system according to claim 1, wherein the application file redundancy upload replication method comprises the following processes: synchronizing the directory data corresponding to the data center official document transmission and data exchange shared file system of the normal disaster recovery center to the host directory corresponding to the data center of the initialized disaster recovery center by using a special tool through an automatic shell script;
when the cooperative office subsystem carries out networking text sending, calling a document transmission assembly of the home-end disaster recovery center to upload document data to a shared file system, calling service of the document transmission assembly of the opposite-end disaster recovery center at the same time, and uploading the document data to a data center shared directory of the opposite-end disaster recovery center at the same time; the failure of the local or opposite disaster recovery center document transmission service call belongs to the same transaction, and if one of the disaster recovery centers fails in service call, the whole service processing fails;
when the cooperative office subsystem carries out data exchange operation, the data exchange assembly of the local disaster recovery center is called to upload temperature control data to the shared file system, the data exchange transmission assembly of the opposite disaster recovery center is called at the same time, the exchange file is transmitted to the data center shared file system of the opposite disaster recovery center, service calling belongs to the same transaction twice, and if one disaster recovery center fails in service calling, the whole service processing fails.
3. The data replication method of the cooperative office system application-level disaster recovery system as claimed in claim 2, wherein the two disaster recovery centers use the same hardware resources to deploy two sets of the same SolrCloud unified search clusters, and the two SolrCloud clusters in the two centers run simultaneously in daily conditions;
the Solr index data replication method is adopted to realize the Solr cluster data synchronization of the data centers of the two disaster recovery centers, a synchronization network between clusters is independently and newly established in a virtual local area network mode and is separated from a production network, the bandwidth of the synchronization network is limited, and the normal operation of production application is not influenced when the data are synchronized;
the Solr index data copying method comprises the following steps: the cluster synchronization initialization component sets a SolrCloud cluster start increment synchronization mark before starting synchronization;
through an automatic shell script, index data directory data under a SolrCloud cluster host of a normal data center are synchronized to a host directory corresponding to a data center of an initialization disaster recovery center by using a special tool;
when the whole SolrCloud cluster data are completely and successfully synchronized, starting and initializing SolrCloud unified search service application in a data center of the disaster recovery center;
setting a SolrCloud cluster initialization completion flag; message middleware cluster component:
respectively building Kafka distributed message middleware clusters in a plurality of virtual Linux machines used in two disaster recovery centers;
transforming a first-level deployment application, generating SolrCloud cluster index data and simultaneously generating index related data into a Kafka message middleware cluster at the same time in a file management, file center and office automation module for processing by a synchronization program;
a synchronization message processing component:
after the SolrCloud cluster is initialized, obtaining unprocessed message requests from a Kafka distributed message middleware queue of a data center of an opposite-end disaster recovery center, and processing the messages one by one until all the messages are processed;
and analyzing the synchronous message to be processed, and writing the message into the SolrCloud cluster of the local disaster recovery center according to the request content.
4. The data replication method of the cooperative office system application level disaster recovery system as recited in claim 1, 2 or 3, wherein the special tool is a data mirror backup tool under a Linux-like system under Linux.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810621652.5A CN108810150B (en) | 2018-06-15 | 2018-06-15 | Data replication method of application-level disaster recovery backup system of cooperative office system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810621652.5A CN108810150B (en) | 2018-06-15 | 2018-06-15 | Data replication method of application-level disaster recovery backup system of cooperative office system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN108810150A CN108810150A (en) | 2018-11-13 |
| CN108810150B true CN108810150B (en) | 2020-11-27 |
Family
ID=64086667
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810621652.5A Active CN108810150B (en) | 2018-06-15 | 2018-06-15 | Data replication method of application-level disaster recovery backup system of cooperative office system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN108810150B (en) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110795280A (en) * | 2019-09-11 | 2020-02-14 | 杭州衣科信息技术有限公司 | Remote double-activity disaster recovery system based on mysql asynchronous and bidirectional |
| CN111459724B (en) * | 2020-03-06 | 2023-08-25 | 中国人民财产保险股份有限公司 | Node switching method, device, equipment and computer readable storage medium |
| CN112181723A (en) * | 2020-09-22 | 2021-01-05 | 中国建设银行股份有限公司 | Financial disaster recovery method and device, storage medium and electronic equipment |
| CN113157807B (en) * | 2021-04-19 | 2022-09-23 | 南京南瑞继保工程技术有限公司 | Data copying method, device and storage medium |
| CN113407631B (en) * | 2021-06-24 | 2023-09-08 | 深圳智多豚物联技术有限公司 | Distributed data center based on kafka and hash shared memory |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102306115A (en) * | 2011-05-20 | 2012-01-04 | 成都市华为赛门铁克科技有限公司 | Asynchronous remote copying method, system and equipment |
| CN103631903A (en) * | 2013-11-22 | 2014-03-12 | 曙光信息产业股份有限公司 | System for synchronizing data of database |
| CN106776121A (en) * | 2016-11-23 | 2017-05-31 | 中国工商银行股份有限公司 | A kind of data calamity is for device, system and method |
| CN107682169A (en) * | 2016-08-02 | 2018-02-09 | 北京京东尚科信息技术有限公司 | A kind of method and apparatus using Kafka collection pocket transmission message |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104123198B (en) * | 2013-04-28 | 2018-08-31 | 国际商业机器公司 | The method and apparatus for managing data replication mode |
-
2018
- 2018-06-15 CN CN201810621652.5A patent/CN108810150B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102306115A (en) * | 2011-05-20 | 2012-01-04 | 成都市华为赛门铁克科技有限公司 | Asynchronous remote copying method, system and equipment |
| CN103631903A (en) * | 2013-11-22 | 2014-03-12 | 曙光信息产业股份有限公司 | System for synchronizing data of database |
| CN107682169A (en) * | 2016-08-02 | 2018-02-09 | 北京京东尚科信息技术有限公司 | A kind of method and apparatus using Kafka collection pocket transmission message |
| CN106776121A (en) * | 2016-11-23 | 2017-05-31 | 中国工商银行股份有限公司 | A kind of data calamity is for device, system and method |
Non-Patent Citations (1)
| Title |
|---|
| 企业级信息系统同城灾备平台的研究与实现;王晓燕;《黑龙江科技信息》;20171231(第19期);第2，4，5节 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN108810150A (en) | 2018-11-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108810150B (en) | Data replication method of application-level disaster recovery backup system of cooperative office system | |
| CN108964986B (en) | Application-level double-active disaster recovery system of cooperative office system | |
| US11360854B2 (en) | Storage cluster configuration change method, storage cluster, and computer system | |
| CN109901949B (en) | Application disaster recovery system and method for double-activity data center | |
| US9176823B2 (en) | Data transfer and recovery process | |
| US7120769B2 (en) | Point in time remote copy for multiple sites | |
| JP5102901B2 (en) | Method and system for maintaining data integrity between multiple data servers across a data center | |
| US10019324B2 (en) | Data transfer and recovery | |
| CN107241430A (en) | A kind of enterprise-level disaster tolerance system and disaster tolerant control method based on distributed storage | |
| US7761431B2 (en) | Consolidating session information for a cluster of sessions in a coupled session environment | |
| CN104536971A (en) | High-availability database | |
| US20090063486A1 (en) | Data replication using a shared resource | |
| CN111966467A (en) | Method and device for disaster recovery based on kubernetes container platform | |
| CN115292408A (en) | Master-slave synchronization method, device, equipment and medium for MySQL database | |
| CN103793296A (en) | Method for assisting in backing-up and copying computer system in cluster | |
| CN117076196A (en) | Database disaster recovery management and control method and device | |
| US11042454B1 (en) | Restoration of a data source | |
| CN101448028A (en) | Method for protecting continuous data, device and system thereof | |
| CN116389233A (en) | Container cloud management platform active-standby switching system, method and device and computer equipment | |
| CN115955488A (en) | Distributed storage copy cross-computer room placement method and device based on copy redundancy | |
| Yang et al. | Multi-Active Multi-Datacenter Distributed Database Architecture Design based-on Secondary Development Zookeeper | |
| Wibowo et al. | Building scalable and resilient database system to mitigate disaster and performance risks | |
| US7644306B2 (en) | Method and system for synchronous operation of an application by a purality of processing units | |
| CN112988466A (en) | Data backup method, device, equipment, storage medium and program product | |
| CN114116308A (en) | Disaster tolerance method and device for power data center, computer equipment and storage medium |
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 |