CN115904808A - Data disaster recovery method and related device - Google Patents

Data disaster recovery method and related device Download PDF

Info

Publication number
CN115904808A
CN115904808A CN202211450646.0A CN202211450646A CN115904808A CN 115904808 A CN115904808 A CN 115904808A CN 202211450646 A CN202211450646 A CN 202211450646A CN 115904808 A CN115904808 A CN 115904808A
Authority
CN
China
Prior art keywords
file
cluster
target
link
configuration information
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
Application number
CN202211450646.0A
Other languages
Chinese (zh)
Inventor
何林欢
欧阳元明
林华春
刘伟
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Merchants Union Consumer Finance Co Ltd
Original Assignee
Merchants Union Consumer Finance Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Merchants Union Consumer Finance Co Ltd filed Critical Merchants Union Consumer Finance Co Ltd
Priority to CN202211450646.0A priority Critical patent/CN115904808A/en
Publication of CN115904808A publication Critical patent/CN115904808A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02ATECHNOLOGIES FOR ADAPTATION TO CLIMATE CHANGE
    • Y02A10/00TECHNOLOGIES FOR ADAPTATION TO CLIMATE CHANGE at coastal zones; at river basins
    • Y02A10/40Controlling or monitoring, e.g. of flood or hurricane; Forecasting, e.g. risk assessment or mapping

Landscapes

  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

The embodiment of the application discloses a data disaster recovery method and a related device, wherein the method comprises the following steps: by receiving a file processing request; if the file processing request is the file synchronization request, executing target operation in the first cluster according to the file synchronization request; acquiring configuration information of a first cluster, determining a target synchronous link according to the configuration information, and jumping to a second cluster to execute target operation according to the target synchronous link; if the file processing request is a file calling request, acquiring a target file from a third cluster according to the file calling request; and if the target file does not exist in the third cluster, determining a target modulation link according to the configuration information of the third cluster, and acquiring the target file in a fourth cluster corresponding to the target modulation link. Therefore, the file synchronization and deletion functions can be adjusted by configuring the file call link and the file synchronization link between the disaster recovery clusters, and multi-environment and multi-instance file backup and smooth disaster recovery switching and file call service can be realized.

Description

Data disaster recovery method and related device
Technical Field
The application relates to the technical field of data processing, in particular to a data disaster recovery method and a related device.
Background
With the development of internet technology, the importance and vulnerability of information resources make disaster recovery backup a problem that enterprises must solve. In order to ensure that data is not lost when a disaster occurs in the system and to continue providing services, disaster recovery backup becomes an important means for ensuring high reliability of the system. Data-level disaster recovery and application-level disaster recovery can be classified according to whether the service is interrupted. The application level disaster tolerance means that the system automatically completes disaster recovery switching, reduces the switching time to the maximum, and ensures that the application runs continuously; the data level disaster tolerance inevitably interrupts the service, and the database cannot work normally during the data recovery period. How to recover the system to normal operation in as short a time as possible and ensure that the data is lost as little as possible is the main research content of the disaster recovery backup technology.
Therefore, a data disaster recovery method is needed to solve the above problems.
Disclosure of Invention
The embodiment of the application provides a data disaster recovery method and a related device, which can realize file calling service and file synchronization function between disaster recovery clusters by configuring a file calling link and a file synchronization link between the disaster recovery clusters; and realizing real-time dynamic switching between the disaster recovery cluster and the backup cluster by starting the disaster recovery cluster service.
In a first aspect, an embodiment of the present application provides a data disaster recovery method, which is applied to a file management system, and the method includes:
receiving a file processing request, wherein the file processing request comprises at least one of a file synchronization request and a file call request;
if the file processing request is the file synchronization request, executing target operation in the first cluster according to the file synchronization request, wherein the target operation comprises at least one of file uploading operation and file deleting operation;
acquiring configuration information of the first cluster, determining a target synchronous link according to the configuration information, and executing the target operation in a second cluster corresponding to the target synchronous link, wherein the target synchronous link is used for realizing the jump between the first cluster and the second cluster;
if the file processing request is the file calling request, acquiring a target file from a third cluster according to the file calling request;
if the target file does not exist in the third cluster, acquiring the configuration information of the third cluster;
and determining a target modulation link according to the configuration information, and acquiring the target file in a fourth cluster corresponding to the target modulation link.
In a second aspect, an embodiment of the present application provides a data disaster recovery device, which is applied to a file management system, and includes a receiving unit, an executing unit, and an obtaining unit, where,
the receiving unit is used for receiving a file processing request, wherein the file processing request comprises at least one of a file synchronization request and a file calling request;
the execution unit is configured to execute a target operation in a first cluster according to the file synchronization request if the file processing request is the file synchronization request, where the target operation includes at least one of a file upload operation and a file delete operation;
the acquiring unit is configured to acquire configuration information of the first cluster, determine a target synchronization link according to the configuration information, and execute the target operation in a second cluster corresponding to the target synchronization link, where the target synchronization link is used to implement a jump between the first cluster and the second cluster; and the file processing module is used for acquiring a target file from a third cluster according to the file calling request if the file processing request is the file calling request;
the obtaining unit is further configured to obtain the configuration information of the third cluster if the target file does not exist in the third cluster;
the execution unit is further configured to determine a target modulation link according to the configuration information, and acquire the target file in a fourth cluster corresponding to the target modulation link.
In a third aspect, an embodiment of the present application provides an electronic device, including a processor, a memory, a communication interface, and one or more programs, where the one or more programs are stored in the memory and configured to be executed by the processor, and the programs include instructions for executing steps in any method in the first aspect of the embodiment of the present application.
In a fourth aspect, the present application provides a computer-readable storage medium, where the computer-readable storage medium stores a computer program for electronic data exchange, where the computer program makes a computer perform part or all of the steps described in any one of the methods of the first aspect of the present application.
In a fifth aspect, embodiments of the present application provide a computer program product, where the computer program product includes a non-transitory computer-readable storage medium storing a computer program, where the computer program is operable to cause a computer to perform some or all of the steps as described in any one of the methods of the first aspect of the embodiments of the present application. The computer program product may be a software installation package.
It can be seen that, in the embodiment of the present application, a file processing request is received, where the file processing request includes at least one of a file synchronization request and a file call request; if the file synchronization request is the file synchronization request, executing target operation in the first cluster according to the file synchronization request; acquiring configuration information of a first cluster, determining a target synchronous link according to the configuration information, and executing target operation in a second cluster corresponding to the target synchronous link; if the file processing request is a file calling request, acquiring a target file from the third cluster according to the file calling request; if the target file does not exist in the third cluster, acquiring configuration information of the third cluster; and determining a target modulation link according to the configuration information, and acquiring a target file in a fourth cluster corresponding to the target modulation link. Therefore, the file synchronization and deletion functions can be adjusted by configuring the file call link and the file synchronization link between the disaster recovery clusters, and further, multi-environment and multi-instance file backup and smooth disaster recovery switching and file call service can be realized.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the embodiments or the prior art descriptions will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings without creative efforts.
FIG. 1 is a system architecture diagram of a document management system according to an embodiment of the present application;
fig. 2 is a schematic flow chart of a data disaster recovery method provided in an embodiment of the present application;
FIG. 3A is an interface diagram of a cluster environment configuration according to an embodiment of the present disclosure;
FIG. 3B is an interface diagram of another cluster environment configuration provided by an embodiment of the present application;
FIG. 4A is a system architecture diagram of a file synchronization request according to an embodiment of the present application;
FIG. 4B is a block diagram illustrating an architecture of a file synchronization request process according to an embodiment of the present disclosure;
FIG. 4C is a flowchart illustrating a process for requesting a file transfer according to an embodiment of the present disclosure;
fig. 5 is a schematic structural diagram of an electronic device provided in an embodiment of the present application;
fig. 6 is a schematic structural diagram of a functional unit of a data disaster recovery device according to an embodiment of the present application.
Detailed Description
In order to make the technical solutions of the present application better understood, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
The terms "first," "second," and the like in the description and claims of the present application and in the foregoing drawings are used for distinguishing between different objects and not for describing a particular sequential order. Furthermore, the terms "include" and "have," as well as any variations thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, system, article, or apparatus that comprises a list of steps or elements is not limited to only those steps or elements but may alternatively include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.
Reference herein to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the application. The appearances of the phrase in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. It is explicitly and implicitly understood by one skilled in the art that the embodiments described herein can be combined with other embodiments.
In order to better understand the solution of the embodiments of the present application, the following first describes the electronic devices, related terms, concepts and related backgrounds to which the embodiments of the present application may relate.
The electronic device may be a portable electronic device, such as a cell phone, a tablet computer, a wearable electronic device with wireless communication capabilities (e.g., a smart watch), etc., that also contains other functionality, such as personal digital assistant and/or music player functionality. Exemplary embodiments of the portable electronic device include, but are not limited to, portable electronic devices that carry an IOS system, an Android system, a Microsoft system, or other operating system. The portable electronic device may also be other portable electronic devices such as a Laptop computer (Laptop) or the like. It should also be understood that in other embodiments, the electronic device may not be a portable electronic device, but may be a desktop computer. The electronic device may include an electronic device for data disaster recovery in the embodiment of the present application.
Disaster recovery is a short term for disaster recovery and backup. No matter natural disaster or artificial disaster, as long as there is a place for data transmission, storage and exchange, risks such as data failure, loss, damage and the like can be generated, and once the risks occur, loss which is difficult to estimate can be brought to a data center; disaster recovery is an important guarantee for the safety of service data.
Disaster recovery definition: two or more sets of IT systems with the same function are established in two places (same city or different places) far away from each other, health status monitoring and function switching can be carried out between the IT systems, when one place stops working due to accidents (natural disasters and human accidents), the whole application system can be switched to the other place, so that the system functions can continue to work normally, and data synchronization and the system can be continuously available.
Definition of backup: the method is characterized in that a user makes one or more copies of important data (or original important data information) generated by an application system so as to enhance the safety of the data and emphasize the backup and the storage of the data.
Referring to fig. 1, fig. 1 is a schematic diagram of a system architecture of a file management system according to an embodiment of the present application. Specifically, the file management system includes one or more system environments (e.g., system environment 1 and system environment 2 shown in fig. 1). Each system environment comprises an instance (such as a file system instance 1 and a file system instance 2 shown in fig. 1), each instance is suitable for an individual cluster (such as a file storage cluster 1 and a file storage cluster 2 shown in fig. 1), and a file storage path is calculated through a file routing rule engine, so that file access and file isolation in the cluster are realized; the file sharing is realized between the instances through file calling; the file backup is realized through the file quasi-real-time synchronization, so that the access and the synchronization of the files can be realized aiming at the smooth switching among the instances.
In order to better understand the above system architecture, the following detailed description is given with reference to specific embodiments.
Referring to fig. 2, fig. 2 is a schematic flowchart of a data disaster recovery method provided in an embodiment of the present application, and the data disaster recovery method is applied to an enterprise resource management system, where the enterprise resource management system includes a local management server, and the local management server is in communication connection with an e-commerce platform server, as shown in fig. 2, the data disaster recovery method specifically includes the following steps:
s201, receiving a file processing request.
Wherein the file processing request comprises at least one of a file synchronization request and a file call request.
Specifically, the file management system is communicated with the calling system through an interface, and receives a file processing request sent by the calling system. Further, the type of the current request is determined from the file processing request. The file processing request comprises a file synchronization request and a file calling request, and the file synchronization request comprises file uploading, file deleting and the like.
S202, if the file processing request is the file synchronization request, executing target operation in the first cluster according to the file synchronization request.
The target operation comprises at least one of file uploading operation and file deleting operation.
Specifically, the file management system determines that the type of the current file processing request is a file synchronization request, and executes a target operation in the first cluster according to the request. And the first cluster is determined according to the file processing request. The file processing request may include, but is not limited to, one or more of the following: cluster name, cluster code, type of file processing request, and type identification of target operation, etc.
Illustratively, the file management system determines a first cluster by obtaining a cluster name and a cluster code in the file request, and executes a target operation in the first cluster according to the type identifier of the target operation.
In another possible example, if the target operation is a file uploading operation, the file management system obtains a file to be uploaded according to the file synchronization request, and stores the file to be uploaded in the first cluster. And if the target operation is a file deleting operation, the file management system determines the file to be deleted according to the file synchronization request and deletes the file to be deleted from the first cluster.
S203, acquiring configuration information of the first cluster, determining a target synchronous link according to the configuration information, and executing the target operation in a second cluster corresponding to the target synchronous link.
Wherein the target synchronization link is to enable a jump from between the first cluster and the second cluster.
Illustratively, the file management system sets corresponding configuration information for each cluster, wherein the configuration information includes but is not limited to: a tune-away link, a synchronization link, etc. for each cluster.
Specifically, the file management system determines a synchronization link corresponding to the first cluster, that is, a target synchronization link, according to the configuration information of the first cluster. And jumping to a second cluster corresponding to the link according to the target synchronous link, and executing target operation in the second cluster. And synchronously uploading and deleting the files of the first cluster and the second cluster by executing the target operation.
And S204, if the file processing request is the file calling request, acquiring a target file from a third cluster according to the file calling request.
Specifically, if the file management system determines that the current file processing request is a file call request, the corresponding third cluster is determined according to the cluster name and the cluster code in the file call request.
Further, the file management system searches and obtains the target file from the third cluster according to the file calling request.
S205, if the target file does not exist in the third cluster, acquiring the configuration information of the third cluster.
Specifically, the file management system searches for the target file in the third cluster according to the file calling request, and if the target file exists in the third cluster, the target file is fed back to the user through the calling system interface. And if the target file cannot be found in the current third cluster, acquiring the configuration information of the third cluster.
S206, determining a target modulation link according to the configuration information, and acquiring the target file in a fourth cluster corresponding to the target modulation link.
Specifically, the file management system determines a tuning link preset by the third cluster, namely the target tuning link, according to the configuration information of the third cluster.
And further, the file management system jumps to a fourth cluster according to the target transfer link and acquires the target file from the fourth cluster according to the file transfer request.
It should be noted that the first cluster, the second cluster, the third cluster, and the fourth cluster are described separately for better understanding of the processing logic of the present application. The cluster is one of a plurality of clusters in the file management system, wherein in practical application, the cluster is divided into a main cluster and a standby cluster by the file management system, that is, in the process, in the file synchronization operation process, jumping among the clusters can be regarded as jumping to the standby cluster (taking a second cluster as an example) for file acquisition if a target cluster does not exist in the current main cluster (taking a first cluster as an example). If the process is a file deletion process, the jumping among the clusters may be regarded as that if the target file is searched and the file deletion operation process is executed in the current main cluster (taking the third cluster as an example), the jumping is performed to the backup cluster (taking the fourth cluster as an example) to perform the file deletion operation process. The first cluster, the second cluster, the third cluster and the fourth cluster are for better understanding the manner of cluster jumping when different operation processes are executed, and are not particularly limited to the above clusters. And the file call request and the file synchronization request may also implement target operations for the same cluster, for example: the number of the primary clusters and the number of the secondary clusters are not particularly limited.
It should be noted that, the number of the transfer links and the synchronization links set in each cluster in the above-mentioned cluster may be one or more, and the file management system implements cluster skipping through one or more links to implement file synchronization and invocation, which is not limited herein.
It can be seen that, by receiving a file processing request, wherein the file processing request includes at least one of a file synchronization request and a file invocation request; if the file synchronization request is the file synchronization request, executing target operation in the first cluster according to the file synchronization request; acquiring configuration information of a first cluster, determining a target synchronous link according to the configuration information, and executing target operation in a second cluster corresponding to the target synchronous link; if the file processing request is a file calling request, acquiring a target file from the third cluster according to the file calling request; if the target file does not exist in the third cluster, acquiring configuration information of the third cluster; and determining a target modulation link according to the configuration information, and acquiring a target file in a fourth cluster corresponding to the target modulation link. Therefore, the file synchronization and deletion functions can be adjusted by configuring the file calling link and the file synchronization link between the disaster recovery clusters, and further, multi-environment and multi-instance file backup, smooth disaster recovery switching and file calling service can be realized.
In one possible example, before receiving the file processing request, the method includes the following specific steps: deploying at least one system environment, wherein each system environment of the at least one system environment comprises an instance and a cluster corresponding to the instance, and the cluster comprises the first cluster, the second cluster, the third cluster and the fourth cluster; setting the service switch configuration information of the cluster, wherein the service switch configuration information includes: the modulation link and modulation switch information corresponding to the modulation link, the synchronous link and synchronous switch information corresponding to the synchronous link are used for realizing the skip among the clusters, the modulation link comprises the target modulation link, and the synchronous link comprises the target synchronous link; setting the routing configuration information of the cluster, wherein the routing configuration information is used for determining a storage path and index information of a file; and determining the configuration information according to the service switch configuration information and the routing configuration information.
Illustratively, the file management system shown in fig. 1, wherein the file management system may deploy one or more system environments, each system environment includes an instance and a cluster corresponding to the instance, and the cluster is used for storing files.
Illustratively, after the file management system deploys each system environment, a cluster corresponding to each instance of the multiple instances is obtained.
Further, the file management system sets corresponding configuration information for each cluster, wherein the configuration information includes service switch configuration information and routing configuration information. For better understanding of the configuration information of the service switch of the cluster, please refer to fig. 3A, where fig. 3A is an interface schematic diagram of a cluster environment configuration provided in an embodiment of the present application, which specifically includes:
configuring cluster name and cluster code, as shown in fig. 3A: cluster a and Clus1, wherein the cluster name and the cluster code are used to distinguish the identification of each cluster.
The service switch information of the configuration cluster specifically comprises a configuration modulation link and switch information of the modulation link, and a synchronous link and synchronous switch information corresponding to the synchronous link. The information of the switch of the modulation connection is used to indicate whether the modulation link can realize cluster skipping currently, the information of the modulation switch includes an open state and a closed state used to indicate an interface corresponding to the modulation link, and fig. 3A shows that one of the states is open, and can be updated to be closed through the side drop-down bar.
In another example, the configuration of the service switch information further includes a default mount directory and a recycle bin mount directory. The system comprises a current cluster file, a default mounting directory, a recycle bin mounting directory and a recycle bin, wherein the default mounting directory is used for indicating a default mounting address of current cluster file storage, and the recycle bin mounting directory is used for indicating a default address of current cluster file recovery.
Illustratively, the configuration information further includes configuration routing configuration information, and the cluster routing configuration information includes a configuration routing algorithm, a routing directory prefix, and a cluster mount instance and path. For better understanding the routing configuration information of the cluster, please refer to fig. 3B, where fig. 3B is an interface schematic diagram of another cluster environment configuration provided in the embodiment of the present application, and specifically includes:
the related configuration under the primary storage shown in fig. 3B includes: storage enablement management settings, including specifically whether to enable the level of storage, yes or no selectable via the right drop-down bar; storing route management, specifically, including setting routing policies, extended routing algorithms, extended directory prefixes, and extended routing algorithm validation levels. Fig. 3B shows a primary storage related to file storage, and the same setting may be performed for a secondary storage, which is not described herein. According to the routing configuration information, the storage path of the file in the cluster and the index information corresponding to the file can be determined.
As can be seen, in this example, by configuring a plurality of environments for the file management system and setting configuration information for the clusters in each environment, when the file management system receives a file processing request, relevant processing operations can be executed in a target environment according to the file processing request. The transfer link and the synchronous link can be determined according to the service switch configuration information, the skipping among the clusters is realized according to the transfer link and the synchronous link, and the routing address of the target file corresponding to the file processing request in the target cluster can be determined according to the routing configuration information, so that the systematic management of the file can be realized.
In one possible example, the file synchronization request includes a type identifier of the target operation, and each system environment further includes a corresponding database; the method for executing the target operation in the first cluster according to the file synchronization request can comprise the following steps: determining the type of the target operation according to the type identification; if the target operation is determined to be the file uploading operation, acquiring a file to be uploaded; determining the storage path and the index information of the file to be uploaded according to the routing configuration information of the first cluster; storing the file to be uploaded into the first cluster according to the storage path, and storing the index information of the file to be uploaded into the database; updating a binary log of the database, wherein the binary log is used for recording an update record of the database; if the target operation is determined to be the file deleting operation, the storage path and the index information of the file to be deleted are obtained; deleting the files to be deleted in the first cluster according to the storage path of the files to be deleted, and deleting the index information of the files to be deleted in the database; updating the binary log.
Exemplarily, the binary binlog file referred in the solution of the present application is a custom file, and is used for recording information details in a file synchronization/deletion process, and in practical application, is used for storing a file in a binary format according to a format of a type identifier, a timestamp, the index information, and a storage path, and is used for implementing a function of file synchronization.
For example, please refer to fig. 4A, where fig. 4A is a system architecture diagram of a file synchronization request according to an embodiment of the present application.
Specifically, a plurality of system environments are deployed in the file management system, and each system environment includes an instance and a cluster and a database corresponding to the instance. Each system environment can realize the synchronization and/or calling operation of the file by the scheduling of the file management system.
Specifically, as shown in fig. 4A, in the operation corresponding to step 1, after the file management system scheduling system environment 1 receives the file synchronization request sent by the calling system. The target operation corresponding to the file synchronization request comprises a file uploading operation and a file deleting operation.
Illustratively, the file management system determines the type of the current target operation according to the type identifier of the target operation in the file synchronization request, wherein the target operation comprises: file uploading operation and file deleting operation.
Illustratively, if the file management system determines that the type of the target operation is a file uploading operation, the file management system obtains a file to be uploaded by calling the system.
Further, according to the routing configuration information in the configuration information of the first cluster, the storage address of the file to be uploaded in the first cluster and the index information of the file are determined. The storage address is used for indicating the corresponding position of the file to be uploaded in the first cluster, and the index information comprises the identification and the storage address of the file to be uploaded, so that the file to be uploaded can be quickly positioned in the first cluster according to the index information.
Further, as shown in step 2, the file management system implements, by the instance 1 in the system environment 1, storing the file to be uploaded in the first cluster according to the storage address.
Further, as shown in step 3, the file management system stores the index information of the file to be uploaded in the database 1 by the example 1 in the system environment 1.
Further, as shown in step 4, the file management system implements updating the binary log of the database 1 according to the file upload operation by the instance 1 in the system environment 1.
Further, as shown in step 5, after the binary log update is finished, the instance 1 reads the incremental data from the binary file through the synchronization thread, where the incremental data includes the index information of the file to be uploaded.
Illustratively, the file management system, via example 1, needs to record data changes into a binary log, i.e., binlog, each time an operation of logging or deleting index information into or from the database is completed. Wherein, the binlog file comprises three formats:
1. the statement format: binlog records the database statements actually executed; i.e. a database statement executed in the database. The database statement includes: data writes, data lookups, data deletes, and the like. The advantage of this storage format is that binlog files are small. It should be noted that the data search statement is used to acquire the target data in the database through the search statement, and in this process, the file in the database is only displayed in the display function, and the substantial content of the file is not substantially changed, so that the binlog file does not record the query record of the data.
2. The row format: binlog records data before and after change (all columns are involved), and the file format has the advantage of being independent of the environment or context function of the system.
3. mixed format: the state format is selected by default and the row format is changed only when needed.
It should be noted that, if the current target operation is a file deletion operation, the processing procedure of the file management system is similar to the above-mentioned processing procedure of file deletion. The file management system deletes the file to be deleted in the first cluster by calling the example 1.
Further, the file management system deletes the index information of the file to be deleted in the database 1 by the example 1, and updates the binary log of the database 1.
In this example, in this embodiment of the present application, the file management system implements, by an instance, file uploading and/or deleting operations in the target cluster according to the type of the target operation in the file synchronization request, and updates the binary log of the database after updating the index information corresponding to the file to be uploaded or the file to be deleted in the database, thereby implementing isolated storage of the file.
In one possible example, each of the instances includes at least one thread, the threads including a synchronization thread; after the binary log is updated, the method may further include the following steps: acquiring incremental data of the binary log through the synchronous thread, wherein the incremental data comprises the type identifier, the timestamp, the index information and the binary data of the storage path of the target operation; and calling a synchronous interface corresponding to the synchronous link of the first cluster through the synchronous thread, and executing the target operation in the execution of the second cluster according to the incremental data and the synchronous interface.
Specifically, please refer to fig. 4B, where fig. 4B is a schematic diagram illustrating an architecture of a file synchronization request process according to an embodiment of the present disclosure. As shown in fig. 4B, the specific processing procedure of the file synchronization request is as follows:
exemplarily, the process of step 1 to step 4 in the left side of fig. 4A is the above process of completing the target operation in the system environment 1, which is implemented by the file management system through example 1, and is not described herein again. The following will be described specifically about step 5 to step 9.
Illustratively, a file management system sets an instance for each environment when deploying one or several environments. The essence of the example is that the software or program for implementing the target function of the file management system comprises a plurality of threads, and the threads comprise a synchronization thread for implementing the file synchronization operation.
Specifically, as shown in step 5 of fig. 4B, the file management system obtains the incremental data after the file synchronization request processing is completed from the binary log through the synchronization thread in example 1. The incremental data includes related information characterizing an update operation in the database 1, and specifically includes:
example 1 every time a transaction related to database update is submitted, recording related information of the transaction in a binary log according to rows, wherein each row is in a format of { file uploading timestamp, request type, file index information and file storage path }, and converting the content into secondary system data to be stored in the binary log. The content format corresponding to the request type is shown in table 1 below:
TABLE 1
Request type encoding Means of
A File upload operation
D File deletion operations
Further, as shown in step 6, after the file management system obtains the incremental data in the binary log corresponding to the database 1 through the synchronization thread of the example 1, the file management system obtains the preset synchronization link of the first cluster according to the configuration information of the first cluster. Through the synchronous link, the jump from the first cluster to the second cluster is realized, and the communication connection is established with the example 2.
Further, example 2 takes the incremental data transmitted by example 1 and parses the incremental data. And acquiring related information generated by file synchronization request processing in the incremental data. And determines the type of the target operation according to the related information.
Further, the specific implementation process of steps 7 to 9 is similar to the process of steps 2 to 4, and the same operation is executed in the system environment 2 according to the type of the target operation, the index information of the file, and the storage path, and the file uploading and/or deleting is performed synchronously by jumping between the first cluster and the second cluster.
It can be seen that in this example, smooth jumping between clusters is realized through the synchronization link of the first cluster, a target operation executed by the file management system in the system environment 1 according to the file synchronization request is determined according to the binary log, the same operation is executed in the second cluster, and uploading and/or deleting of the file are/is synchronously performed in different clusters. Therefore, the backup of the file can be realized, and the purpose of data disaster recovery can be effectively realized. And after the clusters are smoothly jumped, the file management system executes the same target operation in each system environment, so that the consistency and the synchronism of data storage between the clusters and the disaster recovery clusters can be ensured.
In one possible example, before the target operation is executed in the second cluster according to the incremental data and the synchronization interface, the method may include the following steps: obtaining the service switch configuration information of the second cluster, and determining the state of the synchronous interface according to the synchronous switch information, wherein the state includes at least one of the following: an on state and an off state; if the synchronous interface is determined to be in the starting state, executing the target operation in the second cluster to realize the file synchronization of the first cluster and the second cluster; and if the synchronous interface is determined to be in the closed state, ending the synchronous thread.
Illustratively, the service switch configuration information of the cluster as shown in FIG. 3A. The service switch configuration information for each cluster includes, but is not limited to: cluster name, cluster code, modulation link and modulation switch corresponding to the modulation link and synchronous switch corresponding to the synchronous link. Wherein the nature of the modulation link and the synchronization link are different interfaces for realizing the jumping between the clusters.
Illustratively, after receiving a file synchronization request, the file management system needs to call an interface corresponding to the synchronization link through an instance to implement communication connection with other instances. And then, realizing that the target operation is executed in the cluster corresponding to the instance through other instances, and completing file synchronization. However, before making an interface call, it is necessary to determine that the current interface can be called. Therefore, the file management system determines the on-off state of the synchronous link according to the service switch configuration information by acquiring the service switch configuration information of the cluster. And the switch state is used for indicating whether the interface corresponding to the current synchronous link can be called or not. The switch states include: an on state and an off state.
Further, if it is determined that the current synchronous switch is in an on state, that is, the current synchronous interface is in an on state, the communication connection between the instances can be called and established. And if the current synchronization switch is determined to be in the closed state, namely the current synchronization interface is determined to be in the closed state and cannot be called, the current file synchronization request is indicated to be unable to be carried out in the cluster corresponding to the synchronization link at the moment, the current synchronization thread is finished, and the file synchronization request processing process is stopped from being executed through the synchronization link jump.
It can be seen that, in this example, before the file management system implements cluster skipping through the synchronization interface corresponding to the synchronization link, it is determined whether the synchronization switch of the cluster is in an on state through configuration information of the cluster, and then it is determined whether skipping can be implemented according to the state of the synchronization switch, if yes, the interface corresponding to the synchronization link is called to implement cluster skipping and file synchronization, and if not, the current operation is ended. And smooth jump is realized among the clusters through synchronous links, and the physical distance between the corresponding clusters is not limited, so that the timely synchronization of the files can be realized to ensure the timeliness and the stability of the file storage.
In one possible example, after determining the target modulation link according to the configuration information, the method may include the following steps: acquiring the modulation switch information of the target modulation link, and determining the state of a modulation interface corresponding to the target modulation link according to the modulation switch information; if the state of the modulation interface is determined to be the starting state, the target file is obtained from a fourth cluster through the modulation interface; and if the state of the modulation interface is determined to be the closing state, ending the search thread of the current target file.
Illustratively, the file synchronization request processing is similar to that described above. When the file management system carries out a file calling request, firstly, searching files in the third cluster according to the file calling request, and if the target file is not found. And acquiring a modulation link of the third cluster, wherein the modulation link is used for realizing the jump from the third cluster to a fourth cluster corresponding to the modulation link. The essence of the modulation link is to realize an interface of the corresponding instances of the third cluster and the fourth cluster, and the interface realizes the communication connection of the instances so as to realize the smooth jump between the third cluster and the fourth cluster.
Specifically, the file management system determines the state of the transfer interface through the configuration information of the third cluster. And if the current modulation interface is in an open state, when the target file is not acquired in the third cluster, starting a modulation thread to call the modulation interface through an instance corresponding to the third cluster, jumping from the third cluster to the fourth cluster, and acquiring the target file from the fourth cluster. The fourth cluster is a disaster recovery cluster of the third cluster, and is configured to ensure that normal access to data can be ensured when the third cluster is abnormal, and the number of the fourth clusters may be one or more. And if the current modulation interface is in a closed state, ending the execution of the modulation thread.
It can be seen that, in this example, before the file management system implements cluster skipping through the callback interface corresponding to the callback link, it is determined whether the callback switch of the cluster is in an on state through configuration information of the cluster, and then it is determined whether skipping can be implemented according to the state of the callback switch, if so, the interface corresponding to the callback link is called to implement cluster skipping, and a target file is obtained in the cluster.
In one possible example, the obtaining the target file from the fourth cluster through the transferring interface may include: acquiring the index information of the target file; acquiring the binary file of the target file from the fourth cluster according to the index information and the modulation interface; determining the storage path of the target file in the fourth cluster according to the binary file; and acquiring the target file from the fourth cluster according to the storage path.
Specifically, please refer to fig. 4C, where fig. 4C is a flowchart illustrating a processing procedure of a file transfer request according to an embodiment of the present application. The method specifically comprises the following steps:
illustratively, the file management system determines a target cluster (i.e., a third cluster) corresponding to the file transfer request according to the file transfer request. And further, reading the target file from the third cluster according to the identification information of the file.
Further, whether a target file is found in the third cluster is judged, and if the target file is found, the target file is read and then the processing flow of the current file transferring request is ended; and if the target file is not found, acquiring cluster configuration information of a third cluster. And judging whether a modulation switch corresponding to the modulation link is started or not according to the cluster configuration information.
Further, if the current modulation switch is in an on state, jumping to another cluster through the modulation link to obtain the target file, where the other cluster may be the fourth cluster or another cluster corresponding to the modulation link, and is not limited specifically herein.
Illustratively, if it is determined that the current transfer switch is in the off state, the processing flow of the current file call request is ended.
As can be seen, in this example, the file management system first searches for a target file from a target cluster through a file processing request, and when it is determined that the target file does not exist in the current target cluster, the file management system realizes cluster hopping through a transfer link of the target cluster, hops to a disaster recovery cluster of the target cluster, and searches for the target file from the disaster recovery cluster. Therefore, smooth jump between the target cluster and the disaster recovery cluster is realized according to the transfer link, the disaster tolerance of the data is improved, and the experience of a user and the safety of the data are improved.
Referring to fig. 5, fig. 5 is a schematic structural diagram of an electronic device, as shown in fig. 5, the electronic device includes a processor, a memory, a communication interface, and one or more programs, the one or more programs are stored in the memory and configured to be executed by the processor, the server is applied to a data disaster recovery system and applied to a file management system, and the program includes instructions for performing the following steps:
receiving a file processing request, wherein the file processing request comprises at least one of a file synchronization request and a file calling request;
if the file processing request is the file synchronization request, executing target operation in the first cluster according to the file synchronization request, wherein the target operation comprises at least one of file uploading operation and file deleting operation;
acquiring configuration information of the first cluster, determining a target synchronous link according to the configuration information, and executing the target operation in a second cluster corresponding to the target synchronous link, wherein the target synchronous link is used for realizing the jump between the first cluster and the second cluster;
if the file processing request is the file calling request, acquiring a target file from a third cluster according to the file calling request;
if the target file does not exist in the third cluster, acquiring the configuration information of the third cluster;
and determining a target modulation link according to the configuration information, and acquiring the target file in a fourth cluster corresponding to the target modulation link.
It can be seen that, in the data disaster recovery method described in the embodiment of the present application, a file processing request is received, where the file processing request includes at least one of a file synchronization request and a file call request; if the file synchronization request is the file synchronization request, executing target operation in the first cluster according to the file synchronization request; acquiring configuration information of a first cluster, determining a target synchronous link according to the configuration information, and executing target operation in a second cluster corresponding to the target synchronous link; if the file processing request is a file calling request, acquiring a target file from a third cluster according to the file calling request; if the target file does not exist in the third cluster, acquiring configuration information of the third cluster; and determining a target modulation link according to the configuration information, and acquiring a target file in a fourth cluster corresponding to the target modulation link. Therefore, the file synchronization and deletion functions can be adjusted by configuring the file calling link and the file synchronization link between the disaster recovery clusters, and further, multi-environment and multi-instance file backup, smooth disaster recovery switching and file calling service can be realized.
The above description has introduced the solution of the embodiment of the present application mainly from the perspective of the method-side implementation process. It is understood that the server includes hardware structures and/or software modules for performing the respective functions in order to implement the above-described functions. Those of skill in the art will readily appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments provided herein may be implemented as hardware or combinations of hardware and computer software. Whether a function is performed in hardware or computer software drives hardware depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.
In the embodiment of the present application, the server may be divided into the functional units according to the above method example, for example, each functional unit may be divided corresponding to each function, or two or more functions may be integrated into one processing unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit. It should be noted that the division of the unit in the embodiment of the present application is schematic, and is only a logic function division, and there may be another division manner in actual implementation.
In the case of dividing each functional module corresponding to each function, as shown in fig. 6, fig. 6 shows a schematic structural diagram of a functional unit of a data disaster recovery device, and as shown in fig. 6, the data disaster recovery device 600 is applied to a server, and the data disaster recovery device 600 may include a receiving unit 601, an executing unit 602, and an obtaining unit 603:
wherein,
a receiving unit 601, configured to receive a file processing request, where the file processing request includes at least one of a file synchronization request and a file call request;
an executing unit 602, configured to execute a target operation in a first cluster according to the file synchronization request if the file processing request is the file synchronization request, where the target operation includes at least one of a file uploading operation and a file deleting operation;
an obtaining unit 603, configured to obtain configuration information of the first cluster, determine a target synchronous link according to the configuration information, and execute the target operation in a second cluster corresponding to the target synchronous link, where the target synchronous link is used to implement a jump between the first cluster and the second cluster;
an obtaining unit 603, further configured to obtain, if the file processing request is the file call request, a target file from a third cluster according to the file call request;
an obtaining unit 603, further configured to obtain the configuration information of the third cluster if the target file does not exist in the third cluster;
the executing unit 602 is further configured to determine a target modulation link according to the configuration information, and acquire the target file in a fourth cluster corresponding to the target modulation link.
It can be seen that, in the data disaster recovery device provided in the embodiment of the present application, a file processing request is received by an accepting unit, where the file processing request includes at least one of a file synchronization request and a file call request; if the file synchronization request is the file synchronization request, executing target operation in the first cluster through an execution unit according to the file synchronization request; the method comprises the steps that configuration information of a first cluster is obtained through an obtaining unit, a target synchronous link is determined according to the configuration information, and target operation is executed in a second cluster corresponding to the target synchronous link; if the file processing request is a file calling request, acquiring a target file from a third cluster according to the file calling request; if the target file does not exist in the third cluster, acquiring configuration information of the third cluster; and determining a target modulation link according to the configuration information through the execution unit, and acquiring a target file in a fourth cluster corresponding to the target modulation link. Therefore, the file synchronization and deletion functions can be adjusted by configuring the file call link and the file synchronization link between the disaster recovery clusters, and further, multi-environment and multi-instance file backup and smooth disaster recovery switching and file call service can be realized.
It should be noted that all relevant contents of each step related to the above method embodiment may be referred to the functional description of the corresponding functional module, and are not described herein again.
The server provided by the embodiment is used for executing the data disaster recovery method, so that the same effect as the implementation method can be achieved.
Where an integrated unit is employed, the server may include a processing module, a storage module, and a communication module. The processing module may be configured to control and manage actions of the server, for example, may be configured to support the server to execute the steps executed by the execution unit 602. The storage module may be used to support the server in executing stored program code and data, etc. And the communication module can be used for supporting the communication between the server and other equipment.
The processing module may be a processor or a controller. Which may implement or perform the various illustrative logical blocks, modules, and circuits described in connection with the disclosure. A processor may also be a combination of computing functions, e.g., a combination comprising one or more microprocessors, a combination of Digital Signal Processing (DSP) and microprocessors, etc. The storage module may be a memory. The communication module may specifically be a radio frequency circuit, a bluetooth chip, a Wi-Fi chip, or other devices that interact with other servers.
Embodiments of the present application also provide a computer storage medium, wherein the computer storage medium stores a computer program for electronic data exchange, the computer program enables a computer to execute part or all of the steps of any one of the methods described in the above method embodiments, and the computer includes a server.
Embodiments of the present application also provide a computer program product comprising a non-transitory computer readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps of any one of the methods as set out in the above method embodiments. The computer program product may be a software installation package, the computer comprising a server.
It should be noted that, for simplicity of description, the above-mentioned method embodiments are described as a series of acts or combination of acts, but those skilled in the art will recognize that the present application is not limited by the order of acts described, as some steps may occur in other orders or concurrently depending on the application. Further, those skilled in the art should also appreciate that the embodiments described in the specification are preferred embodiments and that the acts and modules referred to are not necessarily required in this application.
In the foregoing embodiments, the descriptions of the respective embodiments have respective emphasis, and for parts that are not described in detail in a certain embodiment, reference may be made to related descriptions of other embodiments.
In the several embodiments provided in the present application, it should be understood that the disclosed apparatus may be implemented in other manners. For example, the above-described embodiments of the apparatus are merely illustrative, and for example, the above-described division of the units is only one type of division of logical functions, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection of some interfaces, devices or units, and may be an electric or other form.
The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one position, or may be distributed on multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.
In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.
The integrated unit may be stored in a computer readable memory if it is implemented in the form of a software functional unit and sold or used as a separate product. Based on such understanding, the technical solutions of the present application, which are essential or part of the technical solutions contributing to the prior art, or all or part of the technical solutions, may be embodied in the form of a software product, which is stored in a memory and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the above methods of the embodiments of the present application. And the aforementioned memory comprises: a U-disk, a Read-only memory (ROM), a Random Access Memory (RAM), a removable hard disk, a magnetic or optical disk, and other various media capable of storing program codes.
Those skilled in the art will appreciate that all or part of the steps in the methods of the above embodiments may be implemented by associated hardware instructed by a program, which may be stored in a computer-readable memory, which may include: flash memory disks, read-only memories (ROMs), random Access Memories (RAMs), magnetic or optical disks, and the like.
The foregoing embodiments have been described in detail, and specific examples are used herein to explain the principles and implementations of the present application, where the above description of the embodiments is only intended to help understand the method and its core ideas of the present application; meanwhile, for a person skilled in the art, according to the idea of the present application, there may be variations in the specific embodiments and the application scope, and in summary, the content of the present specification should not be construed as a limitation to the present application.

Claims (10)

1. A data disaster recovery method is characterized by being applied to a file management system, and comprises the following steps:
receiving a file processing request, wherein the file processing request comprises at least one of a file synchronization request and a file call request;
if the file processing request is the file synchronization request, executing target operation in the first cluster according to the file synchronization request, wherein the target operation comprises at least one of file uploading operation and file deleting operation;
acquiring configuration information of the first cluster, determining a target synchronous link according to the configuration information, and executing the target operation in a second cluster corresponding to the target synchronous link, wherein the target synchronous link is used for realizing the jump between the first cluster and the second cluster;
if the file processing request is the file calling request, acquiring a target file from a third cluster according to the file calling request;
if the target file does not exist in the third cluster, acquiring the configuration information of the third cluster;
and determining a target modulation link according to the configuration information, and acquiring the target file in a fourth cluster corresponding to the target modulation link.
2. The method of claim 1, wherein prior to receiving the file processing request, the method further comprises:
deploying at least one system environment, wherein each system environment of the at least one system environment comprises an instance and a cluster corresponding to the instance, and the cluster comprises the first cluster, the second cluster, the third cluster and the fourth cluster;
setting the configuration information of the clusters, wherein the configuration information comprises a transfer link and a synchronous link, the transfer link and the synchronous link are used for realizing the jump between the clusters, the transfer link comprises the target transfer link, and the synchronous link comprises the target synchronous link;
setting the service switch configuration information of the cluster, wherein the service switch configuration information includes: the modulation link and modulation switch information corresponding to the modulation link, the synchronous link and synchronous switch information corresponding to the synchronous link are used for realizing the skip among the clusters, the modulation link comprises the target modulation link, and the synchronous link comprises the target synchronous link;
setting the routing configuration information of the cluster, wherein the routing configuration information is used for determining a storage path and index information of a file;
and determining the configuration information according to the service switch configuration information and the routing configuration information.
3. The method of claim 2, wherein the file synchronization request includes an identification of a type of the target operation, and wherein each system environment further includes a corresponding database;
the executing the target operation in the first cluster according to the file synchronization request comprises:
determining the type of the target operation according to the type identification;
if the target operation is determined to be the file uploading operation, acquiring a file to be uploaded;
determining the storage path and the index information of the file to be uploaded according to the routing configuration information of the first cluster;
storing the file to be uploaded into the first cluster according to the storage path, and storing the index information of the file to be uploaded into the database;
updating a binary log, wherein the binary log is used for recording an updating record of the database;
if the target operation is determined to be the file deleting operation, the storage path and the index information of the file to be deleted are obtained;
deleting the files to be deleted in the first cluster according to the storage path of the files to be deleted, and deleting the index information of the files to be deleted in the database;
updating the binary log.
4. The method of claim 3, wherein each instance comprises at least one thread, the thread comprising a synchronous thread;
after the updating the binary log, the method further comprises:
obtaining, by the synchronous thread, incremental data of the binary log, where the incremental data includes the type identifier of the target operation, a timestamp, the index information, and binary data of the storage path;
and calling a synchronous interface corresponding to the synchronous link of the first cluster through the synchronous thread, and executing the target operation in the execution of the second cluster according to the incremental data and the synchronous interface.
5. The method of claim 4, wherein prior to performing the target operation in the second cluster execution based on the delta data and the synchronization interface, the method further comprises:
obtaining the service switch configuration information of the second cluster, and determining the state of the synchronous interface according to the synchronous switch information, wherein the state includes at least one of the following: an on state and an off state;
if the synchronous interface is determined to be in the starting state, executing the target operation in the second cluster to realize the file synchronization of the first cluster and the second cluster;
and if the synchronous interface is determined to be in the closed state, ending the synchronous thread.
6. The method of claim 5, wherein after determining a target diversion link according to the configuration information, the method further comprises:
acquiring the modulation switch information of the target modulation link, and determining the state of a modulation interface corresponding to the target modulation link according to the modulation switch information;
if the state of the modulation interface is determined to be the starting state, the target file is obtained from a fourth cluster through the modulation interface;
and if the state of the modulation interface is determined to be the closing state, ending the search thread of the current target file.
7. The method of claim 6, wherein the obtaining the target file from a fourth cluster through the modulation interface comprises:
acquiring the index information of the target file;
acquiring the binary file of the target file from the fourth cluster according to the index information and the modulation interface;
determining the storage path of the target file in the fourth cluster according to the binary file;
and acquiring the target file from the fourth cluster according to the storage path.
8. A data disaster recovery device is characterized in that the device comprises a receiving unit, an execution unit and an acquisition unit, wherein,
the receiving unit is used for receiving a file processing request, wherein the file processing request comprises at least one of a file synchronization request and a file calling request;
the execution unit is configured to execute a target operation in a first cluster according to the file synchronization request if the file processing request is the file synchronization request, where the target operation includes at least one of a file upload operation and a file delete operation;
the obtaining unit is configured to obtain configuration information of the first cluster, determine a target synchronization link according to the configuration information, and execute the target operation in a second cluster corresponding to the target synchronization link, where the target synchronization link is used to implement a jump between the first cluster and the second cluster; and the file processing module is used for acquiring a target file from a third cluster according to the file calling request if the file processing request is the file calling request;
the obtaining unit is further configured to obtain the configuration information of the third cluster if the target file does not exist in the third cluster;
the execution unit is further configured to determine a target modulation link according to the configuration information, and acquire the target file in a fourth cluster corresponding to the target modulation link.
9. An electronic device comprising a processor, memory, a communication interface, and one or more programs stored in the memory and configured to be executed by the processor, the programs including instructions for performing the steps in the method of any of claims 1-7.
10. A computer-readable storage medium, characterized in that a computer program for electronic data exchange is stored, wherein the computer program causes a computer to perform the method according to any one of claims 1-7.
CN202211450646.0A 2022-11-18 2022-11-18 Data disaster recovery method and related device Pending CN115904808A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211450646.0A CN115904808A (en) 2022-11-18 2022-11-18 Data disaster recovery method and related device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211450646.0A CN115904808A (en) 2022-11-18 2022-11-18 Data disaster recovery method and related device

Publications (1)

Publication Number Publication Date
CN115904808A true CN115904808A (en) 2023-04-04

Family

ID=86492214

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211450646.0A Pending CN115904808A (en) 2022-11-18 2022-11-18 Data disaster recovery method and related device

Country Status (1)

Country Link
CN (1) CN115904808A (en)

Similar Documents

Publication Publication Date Title
CN111338854B (en) Kubernetes cluster-based method and system for quickly recovering data
CN107577420B (en) File processing method and device and server
US20150213100A1 (en) Data synchronization method and system
CN103152390B (en) The node configuration method of distributed memory system, device, node and system
US20150302073A1 (en) Method and system for cross-platform application cloning
WO2015183527A1 (en) Synchronization system for multiple client devices
US20130227085A1 (en) Terminal and method for using cloud services
CN111045708B (en) Software upgrading method, electronic device and computer readable storage medium
US20130325932A1 (en) Electronic device and method for storing distributed documents
CN101005676A (en) Method for down loading network resource using mobile terminal
CN108345462B (en) Method and device for upgrading components
CN111240892A (en) Data backup method and device
CN108781189B (en) Load balancing method and related equipment
CN106527979B (en) Data migration method and device
CN107704490A (en) A kind of data processing method and device based on equity storage
CN112988062A (en) Metadata reading limiting method and device, electronic equipment and medium
CN110298031B (en) Dictionary service system and model version consistency distribution method
US20200081869A1 (en) File storage method and storage apparatus
CN115904808A (en) Data disaster recovery method and related device
CN115421976A (en) Remote disaster recovery data processing method and device
CN115033551A (en) Database migration method and device, electronic equipment and storage medium
CN114442952A (en) Cold data migration method and device, storage medium and electronic device
CN113630317A (en) Data transmission method and device, nonvolatile storage medium and electronic device
CN109151016B (en) Flow forwarding method and device, service system, computing device and storage medium
CN113656496A (en) Data processing method and system

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
CB02 Change of applicant information
CB02 Change of applicant information

Country or region after: China

Address after: 518000 18th floor, building A4, Kexing Science Park, Nanshan District, Shenzhen City, Guangdong Province

Applicant after: Zhaolian Consumer Finance Co.,Ltd.

Address before: 518000 18th floor, building A4, Kexing Science Park, Nanshan District, Shenzhen City, Guangdong Province

Applicant before: MERCHANTS UNION CONSUMER FINANCE Co.,Ltd.

Country or region before: China