Local message middleware disaster recovery cloud method and device

Abstract

The invention relates to the technical field of IT and software development, and discloses a local message middleware disaster recovery cloud method and device, and the method comprises the steps: obtaining local metadata sent by a disaster recovery agent; the local metadata is obtained by calling from the local message middleware by the disaster recovery agent; performing format conversion on the local metadata, packaging the format-converted local metadata into recovered snapshot data, and storing the recovered snapshot data into a backup warehouse; the recovery snapshot data in the backup warehouse is used for disaster recovery drilling, and disaster recovery examples on the cloud are reserved based on the disaster recovery drilling result; and when the local message middleware has a fault, switching the local metadata in the local message middleware to the cloud disaster recovery instance. According to the method, the manual operation complexity of cloud migration is reduced, and a unified disaster recovery cloud scheme is provided.

Description

Technical Field

[0001] The present invention relates to the technical field of IT and software development, and particularly relates to a method and device for disaster recovery and cloud migration of a local message middleware. Background Art

[0002] A message middleware is a middleware that provides an efficient and reliable message passing service, realizes decoupling between producers and consumers, effectively solves communication problems in distributed systems, and is commonly used in business scenarios such as data synchronization, log collection, and stream computing processing.

[0003] Enterprise users hope to build a disaster recovery cluster of message middleware on the cloud, but currently there is a lack of a unified disaster recovery and cloud migration solution, and the data formats of the cloud version and the open source version are not fully compatible, making it difficult for users to manually migrate to the cloud. Summary of the Invention

[0004] In view of this, the present invention provides a method and device for disaster recovery and cloud migration of a local message middleware to solve the problems of lack of a unified disaster recovery and cloud migration solution and great difficulty in manual migration to the cloud.

[0005] In a first aspect, the present invention provides a method for disaster recovery and cloud migration of a local message middleware, which is applied to a disaster recovery platform. The disaster recovery platform is connected to a backup repository, both the disaster recovery platform and the backup repository are deployed on a cloud site, the cloud site is connected to a local site, and the local site includes a disaster recovery agent and a local message middleware. The method includes:

[0006] Obtain local metadata sent by the disaster recovery agent; the local metadata is obtained by the disaster recovery agent from the local message middleware;

[0007] Convert the format of the local metadata, encapsulate the format-converted local metadata into recovery snapshot data, and save the recovery snapshot data to the backup repository;

[0008] Perform a disaster recovery drill using the recovery snapshot data in the backup repository, and retain a cloud disaster recovery instance based on the disaster recovery drill result;

[0009] When a failure occurs in the local message middleware, switch the local metadata in the local message middleware to the cloud disaster recovery instance.

[0010] The method for disaster recovery and cloud migration of the local message middleware provided in this embodiment. Under normal circumstances, the message middleware only runs at the local site, and no instances are deployed at the cloud site. The backup repository can use low - configuration hosts, reducing resource redundancy and the cost of purchasing and maintaining hardware devices. Secondly, by converting the format of the local metadata of the local message middleware to adapt to the message middleware version on the cloud, it enables the smooth import of local metadata into the cloud disaster recovery instance after disaster recovery switching, reducing both the complexity of manual operations for migration to the cloud and ensuring the consistency of metadata. Additionally, during the failure switching process, a message cluster is quickly deployed through cloud services, and only the local metadata necessary for business access is restored, helping users resume production operations in a short time. Finally, disaster recovery drills are carried out using the recovery snapshot data in the backup repository to verify the disaster recovery plan and the availability of cloud instances without affecting production, helping users discover potential problems in the disaster recovery switching process in advance, and providing a unified disaster recovery and cloud migration solution.

[0011] In an alternative embodiment, obtaining the local metadata sent by the disaster recovery proxy includes:

[0012] Obtain the preset backup frequency, and generate backup tasks regularly based on the backup frequency;

[0013] Send a backup data instruction to the disaster recovery proxy based on the backup task; wherein, the backup data instruction is used to control the disaster recovery proxy to call the management interface of the local message middleware to obtain the local metadata;

[0014] Receive the local metadata sent by the disaster recovery proxy.

[0015] The method for disaster recovery and cloud migration of the local message middleware provided in this embodiment realizes the regular update of the local metadata in the cloud site by regularly obtaining the local metadata, providing a data basis for subsequent disaster recovery drills and disaster recovery switching.

[0016] In an alternative embodiment, using the recovery snapshot data in the backup repository for disaster recovery drills and retaining the cloud disaster recovery instance based on the disaster recovery drill results includes:

[0017] Create a cloud disaster recovery instance; wherein, the node type and the number of nodes of the cloud disaster recovery instance are the same as those of the message middleware instance corresponding to the local message middleware;

[0018] Configure the authentication parameters of the cloud disaster recovery instance, and read the recovery snapshot data from the backup repository;

[0019] Extract the topic list, subscription group list, and user permission list based on the recovery snapshot data, and configure the topic list, subscription group list, and user permission list for the cloud disaster recovery instance;

[0020] Perform availability verification on the configured cloud-based disaster recovery instance, obtain the disaster recovery drill results, and retain the configured cloud-based disaster recovery instance.

[0021] For the method of migrating the local message middleware disaster recovery to the cloud provided in this embodiment, since the relevant disaster recovery switching solutions generally lack advance verification, in many cases, the switching process is actually executed for the first time only after a production-side failure occurs. Therefore, by simulating the failure switching process through a disaster recovery drill, potential problems in the disaster recovery switching process can be discovered, helping users discover potential hazards in advance, improving the success rate of service switching, and ensuring the feasibility of the disaster recovery plan and the availability of the cloud-based disaster recovery instance.

[0022] In an optional implementation manner, performing availability verification on the configured cloud-based disaster recovery instance and retaining the configured cloud-based disaster recovery instance based on the availability verification result includes:

[0023] Conduct production dial testing on the topics in the topic list to obtain production dial testing results;

[0024] Conduct consumption dial testing on the subscribed topics corresponding to the subscription group list to obtain consumption dial testing results;

[0025] Obtain the account password of the local message cluster, and use the account password of the local message cluster to connect to the configured cloud-based disaster recovery instance;

[0026] Determine the topic permissions and subscription group permissions corresponding to the account password of the local message cluster based on the user permission list, and conduct topic testing and subscription group testing based on the topic permissions and subscription group permissions to obtain test results;

[0027] Determine the disaster recovery drill results based on the production dial testing results, consumption dial testing results, and test results, and retain the configured cloud-based disaster recovery instance.

[0028] For the method of migrating the local message middleware disaster recovery to the cloud provided in this embodiment, by testing the topic list, subscription group list, and user permission list, and accurately simulating the failure switching process, a comprehensive verification of the availability of the cloud-based disaster recovery instance is achieved, potential problems in the disaster recovery switching process can be discovered, helping users discover potential hazards in advance, and improving the success rate of service switching.

[0029] In an optional implementation manner, when the local message middleware fails, switch the local metadata in the local message middleware to the cloud-based disaster recovery instance, including:

[0030] When the local message middleware fails, start the configured cloud-based disaster recovery instance;

[0031] Read the specified recovery snapshot data in the backup repository and import the specified recovery snapshot data into the configured cloud disaster recovery instance; wherein, the specified recovery snapshot data includes the local metadata corresponding to the faulty local message middleware.

[0032] For the method of local message middleware disaster recovery to the cloud provided in this embodiment, when a failure occurs at the local site, a cloud disaster recovery instance can be quickly enabled through the cloud service, and the local metadata necessary for business access can be restored, enabling the business to quickly switch to the disaster recovery message service as soon as possible to ensure business continuity. At the same time, the backup repository for storing local metadata can be deployed on a low-configuration host, reducing the resource usage cost.

[0033] In a second aspect, the present invention provides a device for local message middleware disaster recovery to the cloud, which is applied to a disaster recovery platform. The device includes:

[0034] An acquisition module, configured to acquire local metadata sent by a disaster recovery agent; the local metadata is obtained by the disaster recovery agent from the local message middleware;

[0035] A backup module, configured to convert the format of the local metadata, encapsulate the locally metadata after format conversion into recovery snapshot data, and save the recovery snapshot data to the backup repository;

[0036] A disaster recovery drill module, configured to perform a disaster recovery drill using the recovery snapshot data in the backup repository and retain the cloud disaster recovery instance based on the disaster recovery drill results;

[0037] A disaster recovery switching module, configured to switch the local metadata in the local message middleware to the cloud disaster recovery instance when the local message middleware fails.

[0038] In a third aspect, the present invention provides a system for local message middleware disaster recovery to the cloud, including: a cloud site and a local site; the cloud site includes a disaster recovery platform and a backup repository, and the local site includes a disaster recovery agent and a local message middleware, and the disaster recovery platform is connected to the disaster recovery agent;

[0039] A disaster recovery agent, configured to call local metadata from the local message middleware and transmit the local metadata to the disaster recovery platform;

[0040] The disaster recovery platform is configured to execute the method for local message middleware disaster recovery to the cloud according to the first aspect or any corresponding embodiment thereof.

[0041] In a fourth aspect, the present invention provides a computer device, including: a memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to execute the method for local message middleware disaster recovery to the cloud according to the first aspect or any corresponding embodiment thereof.

[0042] Fifth aspect, the present invention provides a computer-readable storage medium, on which computer instructions are stored, and the computer instructions are used to cause a computer to execute the method for disaster recovery and cloud migration of the local message middleware according to the first aspect or any corresponding embodiment thereof.

[0043] Sixth aspect, the present invention provides a computer program product, including computer instructions, and the computer instructions are used to cause a computer to execute the method for disaster recovery and cloud migration of the local message middleware according to the first aspect or any corresponding embodiment thereof. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following will briefly introduce the drawings required for the description of the specific embodiments or the prior art. Obviously, the drawings in the following description are some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0045] Figure 1 is a schematic structural diagram of a system for disaster recovery and cloud migration of a local message middleware according to an embodiment of the present invention;

[0046] Figure 2 is a schematic flowchart of a method for disaster recovery and cloud migration of a local message middleware according to an embodiment of the present invention;

[0047] Figure 3 is a schematic flowchart of another method for disaster recovery and cloud migration of a local message middleware according to an embodiment of the present invention;

[0048] Figure 4 is a schematic flowchart of periodically obtaining local metadata of the message middleware of a local site according to an embodiment of the present invention;

[0049] Figure 5 is a schematic flowchart of converting and saving local metadata according to an embodiment of the present invention;

[0050] Figure 6 is a schematic flowchart of yet another method for disaster recovery and cloud migration of a local message middleware according to an embodiment of the present invention;

[0051] Figure 7 is a schematic flowchart of a disaster recovery drill according to an embodiment of the present invention;

[0052] Figure 8 is a schematic flowchart of still another method for disaster recovery and cloud migration of a local message middleware according to an embodiment of the present invention;

[0053] Figure 9 is a schematic block diagram of a device for disaster recovery and cloud migration of a local message middleware according to an embodiment of the present invention;

[0054] Figure 10 It is a schematic diagram of the hardware structure of the computer device according to an embodiment of the present invention. Detailed implementation manners

[0055] To make the objectives, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Apparently, the described embodiments are some but not all of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0056] With the increasing popularity of distributed systems, message middleware has become an indispensable part of most business systems. Message middleware includes RocketMQ (a unified message engine and lightweight data processing platform), Kafka (an open-source stream processing platform), RabbitMQ (open-source message broker software), etc. Most message middleware clusters are deployed in local self-managed computer rooms. For local message clusters, relevant disaster recovery methods are to build a set of disaster recovery clusters with the same functions in computer rooms in one or more regions. When the local system stops unexpectedly, the entire application system can switch to the disaster recovery cluster to continue providing message services. In the above solutions, the cost of purchasing hardware by users is relatively high, the deployment cycle is also long, and the disaster recovery sites are idle most of the time, resulting in redundant waste of resources.

[0057] In recent years, the proportion of enterprise services moving to the cloud has been increasing, and disaster recovery in the cloud has become another disaster recovery solution, that is, using cloud services to deploy disaster recovery sites. For message middleware, when a local cluster fails, by subscribing to message products in the cloud resource pool and migrating data to the cloud, etc., business can be quickly taken over in the cloud. The main advantages of disaster recovery in the cloud are as follows:

[0058] 1) Cost savings: Related disaster recovery solutions require purchasing more basic hardware devices and related IT resources, and at the same time, these infrastructure need to be maintained by oneself. Disaster recovery in the cloud can effectively reduce the hardware cost and operation and maintenance cost, and can also avoid the waste of resources caused by the idleness of the disaster recovery computer room.

[0059] 2) Quick recovery: Many enterprises have relatively high requirements for business continuity and real-time performance. After an accident, the longer the recovery time, the greater the loss. If related disaster recovery solutions are used, it still takes a long time to operate the remote computer room, recover data and restart the business during disaster recovery switching. Cloud disaster recovery can make full use of the capabilities of the cloud to quickly start the business in the cloud.

[0060] 3) Conduct drills at any time: By using cloud services, a disaster recovery drill environment can be built without affecting production operations, simulating the failover scenario to test the feasibility and effectiveness of the disaster recovery plan and detect problems in the plan early. At the same time, the verified cloud-based cluster can also be retained to further improve the recovery speed during actual switching.

[0061] Currently, message middleware such as Kafka and RocketMQ with cloud versions has been launched. Compared with the open-source versions, there are various optimizations in functions and performance. Therefore, more and more users hope to build disaster recovery clusters on the cloud.

[0062] However, when users actually migrate local message middleware to the cloud, due to the lack of operation guidelines, the operation is difficult. On the other hand, the metadata formats of the cloud version and the open-source version of the message middleware are not completely compatible, and users need to manually perform format conversion, increasing the operation cost of migrating to the cloud.

[0063] To solve the above problems, the embodiments of the present invention provide a method for migrating local message middleware for disaster recovery to the cloud. When the message middleware at the local site is unavailable, the business can be quickly taken over by rapidly deploying a cloud-based message cluster. During the deployment process of the disaster recovery site, only the metadata necessary for business access is restored, compressing the recovery time and thus minimizing the business interruption time of users. At the same time, through the method of disaster recovery drills, the feasibility and effectiveness of the disaster recovery plan are tested, ensuring that the business can normally use the message service after failover.

[0064] The embodiments of the present invention provide a method for migrating local message middleware for disaster recovery to the cloud. It should be noted that for the method for migrating local message middleware for disaster recovery provided by the embodiments of the present invention, the execution subject can be the disaster recovery platform 101, as Figure 1 shown, the disaster recovery platform 101 is connected to the backup repository 102. Both the disaster recovery platform 101 and the backup repository 102 are deployed on the cloud site 103, and the cloud site 103 is connected to the local site 104. The local site 104 includes a disaster recovery agent 105 and local message middleware 106.

[0065] Among them, the local site 104 is the site where the user's production business is located, including the local message middleware 106 used for production and the disaster recovery proxy 105; the disaster recovery proxy 105 is mainly responsible for collecting the data required for message cluster disaster recovery and reporting it to the disaster recovery platform 101 of the cloud site 103; the cloud site 103 is the site where the cloud disaster recovery instance is deployed, including the disaster recovery platform 101 and the backup repository 102. During a failover, a cloud message middleware is deployed at this site. The disaster recovery platform 101 is mainly responsible for controlling the processes of data backup and disaster recovery switching. When the production cluster is running normally, it receives the backup data reported by the disaster recovery proxy 105 and saves it to the backup repository 102. When a failure occurs, the disaster recovery platform 101 will activate the message cluster, read the local metadata of the local message middleware 106 backed up previously from the backup repository 102, and restore the data to the cluster to achieve business takeover; the network between the local site 104 and the cloud site 103 can be established through services such as cloud dedicated lines and cloud gateways.

[0066] According to an embodiment of the present invention, there is provided an embodiment of a method for disaster recovery and cloud migration of a local message middleware. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than here.

[0067] In this embodiment, a method for disaster recovery and cloud migration of a local message middleware is provided, which can be used for the above-mentioned disaster recovery platform 101. Figure 2 It is a flowchart of the method for disaster recovery and cloud migration of a local message middleware according to an embodiment of the present invention, as Figure 2 shown, and the process includes the following steps:

[0068] Step S201, obtain the local metadata sent by the disaster recovery proxy; the local metadata is obtained by the disaster recovery proxy from the local message middleware.

[0069] Specifically, the local metadata includes: topic list, subscription group list, user permissions, etc.

[0070] Step S202, convert the format of the local metadata, encapsulate the local metadata after format conversion into recovery snapshot data, and save the recovery snapshot data to the backup repository.

[0071] Specifically, the disaster recovery platform obtains the local metadata of the local message middleware through a backup task. Since there are differences in the metadata formats between local open-source Kafka, RocketMQ and Kafka, RocketMQ on the cloud and they cannot be directly applied to the message middleware on the cloud version, it is necessary to convert and adapt the local metadata format to make it suitable for the cloud version.

[0072] Further, convert the locally obtained metadata backed up regularly into a data format compatible with the target message product, encapsulate it as a recovery snapshot, and save it to the backup repository.

[0073] Step S203: Use the recovery snapshot data in the backup repository to conduct disaster recovery drills, and retain the cloud disaster recovery instances based on the results of the disaster recovery drills.

[0074] Specifically, the purpose of the disaster recovery drill is to simulate the failover scenario in advance, ensure that the message middleware on the cloud can be successfully launched and provide services at the cloud disaster recovery site, and discover potential problems such as unavailable hosts and network disconnections in advance.

[0075] 0]]Further, when the production business is normal, a failover scenario can be simulated on the disaster recovery platform, a message middleware instance (i.e., a cloud disaster recovery instance) can be launched at the cloud site, metadata can be created according to the latest recovery snapshot, and production and consumption tests can be conducted. After the drill, the cloud disaster recovery instance at the disaster recovery site can be selected to be retained.

[0076] Step S204: When there is a failure in the local message middleware, switch the local metadata in the local message middleware to the cloud disaster recovery instance.

[0077] Specifically, when the local service is unavailable, a message middleware instance is launched at the cloud site (if it was retained during the previous disaster recovery drill, it is directly started), the corresponding metadata is created according to the recovery snapshot specified by the user, and then the user can switch the business to the disaster recovery site to use the message service.

[0078] For the method of local message middleware disaster recovery to the cloud provided in this embodiment, under normal circumstances, the message middleware only runs at the local site, no instance is deployed at the cloud site, and the backup repository can use low - configuration hosts, reducing resource redundancy and the cost of purchasing and maintaining hardware devices; secondly, by converting the format of the local metadata of the local message middleware to adapt to the message middleware on the cloud version, it enables the local metadata to be successfully imported into the cloud disaster recovery instance after the disaster recovery switch, reducing both the complexity of manual operations for migration to the cloud and ensuring the consistency of metadata; in addition, during the failover process, a message cluster is quickly deployed through cloud services, and only the local metadata necessary for business access is restored, helping users to resume production business in a short time; finally, using the recovery snapshot data in the backup repository to conduct disaster recovery drills to verify the availability of the disaster recovery plan and cloud instances without affecting production, helping users to discover potential problems in the disaster recovery switch process in advance, and providing a unified disaster recovery to the cloud solution.

[0079] In this embodiment, a method for local message middleware disaster recovery to the cloud is provided, which can be used for the above - mentioned disaster recovery platform 101. Figure 3It is a flowchart of the method for disaster recovery and cloud migration of the local message middleware according to an embodiment of the present invention. As Figure 3 shown, the process includes the following steps:

[0080] Step S301: Obtain the local metadata sent by the disaster recovery agent; the local metadata is obtained by the disaster recovery agent from the local message middleware.

[0081] Specifically, the above step S301 includes:

[0082] Step S3011: Obtain the pre-set backup frequency, and generate backup tasks regularly based on the backup frequency.

[0083] Specifically, as Figure 4 shown, the user can specify the backup frequency, that is, how often to execute the instruction to collect metadata. After reaching the specified time point, the disaster recovery platform generates a backup task and sends a backup data instruction to the disaster recovery agent.

[0084] Step S3012: Send a backup data instruction to the disaster recovery agent based on the backup task; wherein, the backup data instruction is used to control the disaster recovery agent to call the management interface of the local message middleware to obtain the local metadata.

[0085] Specifically, as Figure 4 shown, after receiving the backup data instruction, the disaster recovery agent obtains the local metadata such as topics, subscription groups, and user permissions by calling the management interfaces of the local message components (Kafka, RocketMQ), and reports the above local metadata to the disaster recovery platform; wherein, a topic is a logical grouping of message queues, used to classify and manage a group of related messages. Producers publish messages by specifying topics, while consumers receive messages by subscribing to topics. There can be multiple partitions under a topic, and the data in different partitions are non-repetitive; a subscription group, also known as a consumer group, is used to identify a set of consumers. A group of consumers jointly consume the messages under the same topic, and each consumer group can subscribe to one or more topics.

[0086] Step S3013: Receive the local metadata sent by the disaster recovery agent.

[0087] Specifically, as Figure 4 shown, after receiving the local metadata, the disaster recovery platform ends the current backup task.

[0088] Taking Kafka and RocketMQ as examples, the disaster recovery proxy obtains the following local metadata from the local message middleware: topic list, subscription group list, and user permissions. There will be some differences in the data formats obtained by different types of local message middleware. Tables 1 to 6 below list the metadata formats obtained from Kafka and RocketMQ, and mark whether the corresponding cloud versions are compatible with these attributes.

[0089] Among them, each item in the Kafka topic list represents a topic, and the structure of each item is shown in Table 1 below.

[0090] Table 1:

[0091] Attribute Name Attribute Type Description Whether Required for Cloud Instance topicName String Topic Name Yes partitionNum Integer Number of Queues Yes

[0092] Each item in the Kafka subscription group list represents a subscription group, and the structure of each item is shown in Table 2 below.

[0093] Table 2:

[0094] Attribute Name Attribute Type Description Whether Required for Cloud Instance groupName String Consumer Group Name Yes

[0095] Each item in the Kafka user permission list represents a user permission, and the format of each item is shown in Table 3 below.

[0096] Table 3:

[0097]

[0098]

[0099] Each item in the RocketMQ topic list represents a topic, and the structure of each item is shown in Table 4 below.

[0100] Table 4:

[0101] Attribute Name Attribute Type Description Whether Required for Cloud Instance topicName String Topic Name Yes readQueueNums Integer Number of Read Queues Yes writeQueueNums Integer Number of Write Queues Yes perm Integer Permission Yes topicSysFlag Integer Topic System Flag No order Boolean Whether Ordered Yes topicFilterType TopiciFilterType Topic Filter Type No

[0102] Each item in the RocketMQ subscription group list represents a subscription group, and the structure of each item is shown in Table 5 below.

[0103] Table 5:

[0104]

[0105]

[0106] The format of RocketMQ user permissions is shown in Table 6 below.

[0107] Table 6:

[0108]

[0109] Step S302: Convert the local metadata, encapsulate the converted local metadata into recovery snapshot data, and save the recovery snapshot data to the backup repository.

[0110] Specifically, taking the metadata formats used by Kafka and RocketMQ in the cloud version as an example, the "Conversion Source" column indicates how the attributes are converted. Attributes with names marked are directly assigned from the corresponding attributes of the local message middleware metadata. For non-essential attributes, if not specified in the "Conversion Source", they are generally left blank.

[0111] Among them, the cloud version of Kafka topics is shown in Table 7 below.

[0112] Table 7:

[0113]

[0114] In Table 7, the isPrivate attribute needs to be judged in combination with the user permission metadata of the local Kafka: If the principal of a certain user permission is not "User:*", the permissionType is "allow" and the resourceType is "TOPIC", then the topic corresponding to the name attribute of this user permission is private and isPrivate is true; in other cases, isPrivate is false.

[0115] The cloud version of Kafka subscription groups is shown in Table 8 below.

[0116] Table 8:

[0117]

[0118] Similar to the cloud version of Kafka topics above, in Table 8, the isPrivate attribute of the subscription group also needs to be judged in combination with the user permissions of the local Kafka: If the principal is not "User:*", the permissionType is "allow" and the resourceType is "GROUP", then the subscription group corresponding to the name attribute of this user permission is private and isPrivate is true; in other cases, isPrivate is false.

[0119] The cloud version of Kafka user permissions is shown in Table 9 below.

[0120] Table 9:

[0121]

[0122] In Table 9, since the user permissions of the cloud version do not distinguish between permission types (deny, allow) and the default is "allow" for both, only the user permissions with the permissionType attribute of "allow" in the local metadata are converted, and the user permissions of "deny" are discarded.

[0123] The RocketMQ topics of the cloud version are shown in Table 10 below.

[0124] Table 10:

[0125]

[0126]

[0127] The RocketMQ subscription groups of the cloud version are shown in Table 11.

[0128] Table 11:

[0129]

[0130] The RocketMQ user permissions of the cloud version are shown in Table 12 below.

[0131] Table 12:

[0132]

[0133]

[0134] Furthermore, the relatively special local metadata is the authentication parameters configured by the user locally. The user access methods supported by the cloud Kafka cluster are PLAINTEXT and SASL_PLAINTEXT: If the production service accesses the local Kafka using the PLAINTEXT method, there is no need to configure authentication parameters and the cloud disaster recovery instance can be accessed directly; if the production service accesses the local Kafka using the SASL_PLAINTEXT method, the disaster recovery platform needs to obtain the account password for access. This embodiment does not limit the acquisition method. For example, the user can directly enter the account password on the web page of the disaster recovery platform.

[0135] Among them, PLAINTEXT means that data is transmitted in plain text, that is, when the data is transmitted over the network, it is not encrypted at all and is directly transmitted in the original text format; SASL_PLAINTEXT is a specific implementation method in the SASL (Simple Authentication and Security Layer) mechanism. It adds certain authentication functions on the basis of PLAINTEXT, but the data transmission is still in plain text.

[0136] Further, as shown in Figure 5 , after the local metadata format conversion is completed, the disaster recovery platform attaches the creation time to the local metadata and encapsulates it into a recovery snapshot, which is saved on the backup repository. The form of the backup repository in this embodiment is not limited. For example, files or databases can be used for saving.

[0137] Among them, since the volume of the local metadata of the local message middleware is usually not too large, a low-configuration cloud host or cloud database service can be selected as the backup repository to save resources.

[0138] Further, as shown in Figure 5 , the user can specify the number of recovery snapshots to be retained. When saving a recovery snapshot each time, it is checked whether the number of existing recovery snapshots on the backup repository has exceeded the limit. If so, the oldest recovery snapshots are deleted in sequence according to the creation time until the number meets the requirements. For example, if the user sets to retain 5 recovery snapshots, then each time a new recovery snapshot is created, it will check all the existing saved recovery snapshots. If the number is not greater than 5, no action is required; if the number is greater than 5, they will be sorted by the creation time, and the latest 5 snapshots will be retained, and the rest will be deleted.

[0139] Step S303: Use the recovery snapshot data in the backup repository to conduct a disaster recovery drill, and retain the cloud disaster recovery instance based on the disaster recovery drill result. For details, please refer to step S203 of the embodiment shown in Figure 2 , which will not be elaborated here.

[0140] Step S304: When a failure occurs in the local message middleware, switch the local metadata in the local message middleware to the cloud disaster recovery instance. For details, please refer to step S204 of the embodiment shown in Figure 2 , which will not be elaborated here.

[0141] The method for disaster recovery to the cloud of the local message middleware provided in this embodiment realizes the regular update of the local metadata in the cloud site by regularly obtaining the local metadata, providing a data basis for subsequent disaster recovery drills and disaster recovery switches. Secondly, the local metadata of the local message middleware is converted to adapt to the message middleware of the cloud version, so that the local metadata can be smoothly imported into the cloud disaster recovery instance after the disaster recovery switch, reducing the complexity of manual operations and ensuring the consistency of the metadata. In addition, for the local message middleware with authentication enabled, the same authentication parameters can be configured on the disaster recovery instance, enabling the service to access the message service in the original authentication manner.

[0142] In this embodiment, a method for disaster recovery to the cloud of the local message middleware is provided, which can be used for the above-mentioned disaster recovery platform 101. Figure 6It is a flowchart of a method for disaster recovery and cloud migration of a local message middleware according to an embodiment of the present invention. As Figure 6 shown, the process includes the following steps:

[0143] Step S601, obtain the local metadata sent by the disaster recovery proxy; the local metadata is obtained by the disaster recovery proxy from the local message middleware. For details, please refer to Figure 3 step S301 of the embodiment shown here, which will not be elaborated here.

[0144] Step S602, convert the format of the local metadata, encapsulate the local metadata after format conversion into recovery snapshot data, and save the recovery snapshot data to the backup repository. For details, please refer to Figure 3 step S302 of the embodiment shown here, which will not be elaborated here.

[0145] Step S603, perform a disaster recovery drill using the recovery snapshot data in the backup repository, and retain the cloud-based disaster recovery instance based on the results of the disaster recovery drill.

[0146] Specifically, the above step S603 includes:

[0147] Step S6031, create a cloud-based disaster recovery instance; among them, the node type and the number of nodes of the cloud-based disaster recovery instance are the same as those of the message middleware instance corresponding to the local message middleware.

[0148] Specifically, after the disaster recovery drill starts, the disaster recovery platform opens a message middleware instance (i.e., the cloud-based disaster recovery instance) with the same specifications as the local site on the cloud site. The specifications mainly refer to the node type and the number of nodes.

[0149] For example, for RocketMQ, the number of NameServer nodes, the number of broker master nodes, and the number of broker slave nodes of the cloud-based disaster recovery instance should be the same as those of the local site; among them, the broker is the core component of the message middleware, mainly responsible for processing requests from producers and consumers. Generally, a broker cluster will be deployed on multiple servers. By distributing messages to different brokers, the message cluster can achieve high availability.

[0150] Step S6032, configure the authentication parameters of the cloud-based disaster recovery instance, and read the recovery snapshot data from the backup repository.

[0151] Specifically, as Figure 7 shown, since the production service usually needs to go through authentication to access the local message cluster, if the cloud-based message cluster lacks authentication information, it will cause the service to be unable to access in the original way after the disaster recovery switchover. Therefore, before the disaster recovery drill starts, it is necessary to first obtain the authentication parameters in the local metadata.

[0152] Further, taking Kafka on the cloud as an example, after the Kafka instance on the cloud is created, the disaster recovery platform creates Kafka user metadata by calling the openapi interface (open application programming interface), and the data structure is shown in Table 13 below.

[0153] Table 13:

[0154]

[0155] Further, the RocketMQ cluster on the cloud requires that the service must access through acl (access control lists) users: if the production service does not use acl when accessing the local RocketMQ, the user must configure the self-created acl account password (i.e., the authentication parameter) on the disaster recovery platform in advance. After the RocketMQ instance on the cloud is created, this account password will be imported as user permission metadata; if the production service uses acl when accessing the local RocketMQ, no additional processing is required, and the user permissions exported when collecting metadata include acl information.

[0156] Further, the user can specify to restore the snapshot data. If not specified, the latest restored snapshot data is read by default.

[0157] Step S6033, extract the topic list, subscription group list, and user permission list based on the restored snapshot data, and configure the topic list, subscription group list, and user permission list for the disaster recovery instance on the cloud.

[0158] Specifically, the disaster recovery platform extracts the topic list, subscription group list, and user permission list from the restored snapshot data, and imports them into the disaster recovery instance on the cloud through the openapi interface provided by the management platform, thereby creating topics, subscription groups, and user permissions consistent with the local message cluster.

[0159] Step S6034, perform an availability verification on the configured disaster recovery instance on the cloud. If the availability verification passes, obtain the disaster recovery drill result and retain the configured disaster recovery instance on the cloud.

[0160] In some alternative embodiments, the above step S6034 includes:

[0161] Step a1, perform production testing on the topics in the topic list to obtain the production testing result.

[0162] Step a2, perform consumption testing on the subscribed topics corresponding to the subscription group list to obtain the consumption testing result.

[0163] Step a3: Obtain the account password of the local message cluster, and use the account password of the local message cluster to connect to the configured cloud disaster recovery instance.

[0164] Step a4: Determine the topic permissions and subscription group permissions corresponding to the account password of the local message cluster based on the user permission list, and conduct topic tests and subscription group tests based on the topic permissions and subscription group permissions to obtain test results.

[0165] Specifically, use the account password of the local message cluster to connect to the cloud message middleware, and conduct production and consumption tests on the corresponding topics and consumption tests on the corresponding subscription groups according to the topics and subscription group permissions listed in the user permission metadata.

[0166] Step a5: Determine the disaster recovery drill result based on the production dial test result, consumption dial test result, and test result, and retain the configured cloud disaster recovery instance.

[0167] Specifically, first, message data can be normally written to the topic, and when using the subscription group to consume the subscribed topic, message data can be normally read from the topic. In addition, when using the account password to connect to the cloud disaster recovery instance, for the topics with production permissions for this account, message data can be normally written, for the topics with consumption permissions for this account, message data can be normally read, and for the subscription groups with consumption permissions for this account, message data can be normally read from the subscribed topics, which indicates that the cloud disaster recovery instance is available.

[0168] Furthermore, as Figure 7 shown, the user can choose whether to retain the cloud disaster recovery instance. If not retained, the cloud disaster recovery instance will be recycled by the disaster recovery platform and the resources will be released. Otherwise, only the data (including messages, topics, subscription groups, users, etc.) will be cleared, and the cloud disaster recovery instance will be stopped. At the next disaster recovery drill, if there is a retained cloud disaster recovery instance, it does not need to be re-opened, and the instance can be directly started and the subsequent steps can be carried out.

[0169] Or, if the availability verification of the cloud disaster recovery instance passes, the cloud disaster recovery instance will be retained; if it is unavailable, the cloud disaster recovery instance will be recycled.

[0170] Step S604: When the local message middleware fails, switch the local metadata in the local message middleware to the cloud disaster recovery instance. For details, please refer to Figure 3 the steps of Embodiment shown in S304, which will not be elaborated here.

[0171] The method for disaster recovery and cloud migration of the local message middleware provided in this embodiment can, due to the general lack of prior verification in relevant disaster recovery switching solutions, often only actually execute the switching process for the first time after a production-side failure occurs. Therefore, by simulating the failure switching process through disaster recovery drills, potential problems in the disaster recovery switching process can be discovered, helping users detect potential hazards in advance, improving the success rate of service switching, and ensuring the feasibility of the disaster recovery plan and the availability of the disaster recovery instance on the cloud.

[0172] In this embodiment, a method for disaster recovery and cloud migration of the local message middleware is provided, which can be used in the above-mentioned disaster recovery platform 101. Figure 8 It is a flowchart of the method for disaster recovery and cloud migration of the local message middleware according to an embodiment of the present invention, as Figure 8 shown. The process includes the following steps: <(

[0173] Step S801, obtain the local metadata sent by the disaster recovery agent; the local metadata is obtained by the disaster recovery agent from the local message middleware. For details, please refer to Figure 6 Step S601 of the embodiment shown, which will not be elaborated here.

[0174] Step S802, convert the format of the local metadata, encapsulate the locally metadata after format conversion into recovery snapshot data, and save the recovery snapshot data to the backup repository. For details, please refer to Figure 6 Step S602 of the embodiment shown, which will not be elaborated here.

[0175] Step S803, perform a disaster recovery drill using the recovery snapshot data in the backup repository, and retain the disaster recovery instance on the cloud based on the disaster recovery drill result. For details, please refer to Figure 6 Step S603 of the embodiment shown, which will not be elaborated here.

[0176] Step S804, when a failure occurs in the local message middleware, switch the local metadata in the local message middleware to the disaster recovery instance on the cloud.

[0177] Specifically, the above step S804 includes:

[0178] Step S8041, when a failure occurs in the local message middleware, start the configured disaster recovery instance on the cloud.

[0179] Specifically, when the local message middleware in the local site is unavailable, open a message middleware instance on the cloud site with the same specifications as the local site; if the disaster recovery drill has been retained before, the existing disaster recovery instance on the cloud can be directly started without redeployment.

[0180] Step S8042: Read the specified recovery snapshot data in the backup repository and import the specified recovery snapshot data into the configured cloud disaster recovery instance; the specified recovery snapshot data includes the local metadata corresponding to the faulty local message middleware.

[0181] Specifically, after the cloud disaster recovery instance is started, it reads the recovery snapshot specified by the user from the backup repository and imports the local metadata, including topics, subscription groups, and user permissions, through the interface of the cloud message component management console. Subsequently, the business layer can switch to use the message service of the cloud site.

[0182] For the method of local message middleware disaster recovery to the cloud provided in this embodiment, when a failure occurs at the local site, a cloud disaster recovery instance can be quickly enabled through the cloud service, and the local metadata necessary for business access can be restored, enabling the business to quickly switch to the disaster recovery message service as soon as possible to ensure business continuity. At the same time, the backup repository for storing local metadata can be deployed on a low-configuration host, reducing the resource usage cost.

[0183] In this embodiment, there is also provided a device for local message middleware disaster recovery to the cloud. This device is used to implement the above embodiments and preferred implementation manners, and those that have been described will not be elaborated again. As used hereinafter, the term "module" can be a combination of software and / or hardware that can achieve a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware is also possible and contemplated.

[0184] This embodiment provides a device for local message middleware disaster recovery to the cloud, which is applied to the disaster recovery platform 101, as Figure 9 shown, including:

[0185] An acquisition module 901, configured to acquire local metadata sent by a disaster recovery agent; the local metadata is obtained by the disaster recovery agent from the local message middleware;

[0186] A backup module 902, configured to convert the format of the local metadata, encapsulate the locally metadata after format conversion into recovery snapshot data, and save the recovery snapshot data to the backup repository;

[0187] A disaster recovery drill module 903, configured to perform a disaster recovery drill using the recovery snapshot data in the backup repository and retain the cloud disaster recovery instance based on the disaster recovery drill result;

[0188] A disaster recovery switching module 904, configured to switch the local metadata in the local message middleware to the cloud disaster recovery instance when a failure occurs in the local message middleware.

[0189] In some alternative implementation manners, the acquisition module 901 includes:

[0190] An acquisition unit, configured to acquire a preset backup frequency and generate backup tasks at regular intervals based on the backup frequency;

[0191] A distribution unit, configured to distribute a backup data instruction to a disaster recovery agent based on the backup task; wherein, the backup data instruction is used to control the disaster recovery agent to call the management interface of the local message middleware to obtain local metadata;

[0192] A receiving unit, configured to receive the local metadata sent by the disaster recovery agent.

[0193] In some alternative embodiments, the disaster recovery drill module 903 includes:

[0194] A creation unit, which creates a disaster recovery instance on the cloud; wherein, the disaster recovery instance on the cloud has the same node type and number of nodes as the message middleware instance corresponding to the local message middleware;

[0195] A configuration unit, configured to configure the authentication parameters of the disaster recovery instance on the cloud and read the recovery snapshot data from the backup repository;

[0196] An extraction unit, configured to extract a topic list, a subscription group list, and a user permission list based on the recovery snapshot data, and configure the topic list, the subscription group list, and the user permission list for the disaster recovery instance on the cloud;

[0197] A verification unit, configured to perform an availability verification on the configured disaster recovery instance on the cloud to obtain a disaster recovery drill result, and retain the configured disaster recovery instance on the cloud.

[0198] In some alternative embodiments, the verification unit includes:

[0199] A first test subunit, configured to perform production dial testing on the topics in the topic list to obtain a production dial testing result;

[0200] A second test subunit, configured to perform consumption dial testing on the subscribed topics corresponding to the subscription group list to obtain a consumption dial testing result;

[0201] A connection subunit, configured to obtain the account password of the local message cluster and connect to the configured disaster recovery instance on the cloud by using the account password of the local message cluster;

[0202] A third test subunit, configured to determine the topic permissions and subscription group permissions corresponding to the account password of the local message cluster based on the user permission list, and perform topic testing and subscription group testing based on the topic permissions and subscription group permissions to obtain a test result;

[0203] A retention subunit, configured to determine the disaster recovery drill result based on the production dial testing result, the consumption dial testing result, and the test result, and retain the configured disaster recovery instance on the cloud.

[0204] In some alternative embodiments, the disaster recovery switching module 904 includes:

[0205] A startup unit, configured to start the configured cloud-based disaster recovery instance when a failure occurs in the local message middleware;

[0206] A reading unit, configured to read specified recovery snapshot data from the backup repository and import the specified recovery snapshot data into the configured cloud-based disaster recovery instance; wherein the specified recovery snapshot data includes local metadata corresponding to the failed local message middleware.

[0207] The further function descriptions of the above-mentioned various modules and units are the same as those in the corresponding foregoing embodiments, and will not be elaborated herein.

[0208] The device for local message middleware disaster recovery to the cloud in this embodiment is presented in the form of functional units. Here, the unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and a memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0209] An embodiment of the present invention further provides a system for local message middleware disaster recovery to the cloud, as Figure 1 shown, including: a cloud site 103 and a local site 104; the cloud site 103 includes a disaster recovery platform 101 and a backup repository 102, the local site 104 includes a disaster recovery agent 105 and a local message middleware 106, and the disaster recovery platform 101 is connected to the disaster recovery agent 105;

[0210] The disaster recovery agent 105 is configured to call local metadata from the local message middleware 106 and transmit the local metadata to the disaster recovery platform 101;

[0211] The disaster recovery platform 101 is configured to execute the method for local message middleware disaster recovery to the cloud.

[0212] An embodiment of the present invention further provides a computer device having the above-mentioned Figure 9 device for local message middleware disaster recovery to the cloud.

[0213] Please refer to Figure 10 , Figure 10 which is a schematic structural diagram of a computer device provided by an alternative embodiment of the present invention, as Figure 10As shown, the computer device includes: one or more processors 10, a memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. Each component communicates with each other using different buses and can be installed on a common motherboard or installed in other ways as needed. The processor can process instructions executed within the computer device, including instructions stored in the memory or on the memory to display graphical information of the GUI on an external input / output device (such as a display device coupled to the interface). In some alternative embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories. Similarly, multiple computer devices can be connected, and each device provides part of the necessary operations (for example, as a server array, a set of blade servers, or a multi-processor system). Figure 10 In this example, a single processor 10 is taken as an example.

[0214] The processor 10 can be a central processing unit, a network processor, or a combination thereof. Among them, the processor 10 can further include a hardware chip. The above-mentioned hardware chip can be an application-specific integrated circuit, a programmable logic device, or a combination thereof. The above-mentioned programmable logic device can be a complex programmable logic device, a field-programmable gate array, a generic array logic, or any combination thereof.

[0215] Among them, the memory 20 stores instructions executable by at least one processor 10, so that the at least one processor 10 executes the methods shown in the above embodiments.

[0216] The memory 20 can include a program storage area and a data storage area. Among them, the program storage area can store an operating system and application programs required for at least one function; the data storage area can store data created according to the use of the computer device. In addition, the memory 20 can include high-speed random access memory and can also include non-transitory memory, such as at least one disk storage device, a flash memory device, or other non-transitory solid-state storage devices. In some alternative embodiments, the memory 20 can optionally include a memory remotely set relative to the processor 10, and these remote memories can be connected to the computer device through a network. Examples of the above-mentioned network include but are not limited to the Internet, an enterprise intranet, a local area network, a mobile communication network, and combinations thereof.

[0217] The memory 20 can include volatile memory, such as random access memory; the memory can also include non-volatile memory, such as flash memory, a hard disk, or a solid-state drive; the memory 20 can also include a combination of the above types of memory.

[0218] The computer device further includes an input device 30 and an output device 40. The processor 10, the memory 20, the input device 30, and the output device 40 can be connected through a bus or other means.Figure 10 Take the bus connection as an example.

[0219] The input device 30 can receive input digital or character information, and generate key signal inputs related to the user settings and function controls of the computer device, such as a touch screen, a keypad, a mouse, a trackpad, a touchpad, a pointing stick, one or more mouse buttons, a trackball, a joystick, etc. The output device 40 may include a display device, an auxiliary lighting device (e.g., an LED), and a haptic feedback device (e.g., a vibration motor), etc. The above display device includes but is not limited to a liquid crystal display, a light emitting diode, a display, and a plasma display. In some alternative embodiments, the display device may be a touch screen.

[0220] The embodiments of the present invention also provide a computer-readable storage medium. The methods according to the embodiments of the present invention can be implemented in hardware, firmware, or be implemented as computer code that can be recorded on a storage medium, or be implemented as computer code originally stored in a remote storage medium or a non-transitory machine-readable storage medium and downloaded through a network and to be stored in a local storage medium, so that the methods described herein can be stored in such software processes on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only memory, a random access memory, a flash memory, a hard disk, or a solid-state drive, etc.; further, the storage medium can also include a combination of the above-mentioned types of memories. It can be understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by the computer, the processor, or the hardware, the methods shown in the above embodiments are implemented.

[0221] A part of the present invention can be applied as a computer program product, such as computer program instructions. When executed by a computer, through the operation of the computer, the methods and / or technical solutions according to the present invention can be invoked or provided. Those skilled in the art should be able to understand that the forms in which computer program instructions exist in a computer-readable medium include but are not limited to source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include but are not limited to: the computer directly executes the instruction, or the computer compiles the instruction and then executes the corresponding compiled program, or the computer reads and executes the instruction, or the computer reads and installs the instruction and then executes the corresponding installed program. Herein, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible by the computer.

[0222] Although embodiments of the present invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the present invention, and such modifications and variations fall within the scope defined by the appended claims.

Claims

1. A method for disaster recovery and cloud migration of a local message middleware, characterized in that, Applied to a disaster recovery platform, the disaster recovery platform is connected to a backup repository, both the disaster recovery platform and the backup repository are deployed on a cloud site, the cloud site is connected to a local site, and the local site includes a disaster recovery agent and a local message middleware; the method includes: Obtain local metadata sent by the disaster recovery agent; the local metadata is obtained by the disaster recovery agent by invoking the local message middleware; Convert the format of the local metadata, encapsulate the local metadata after format conversion into recovery snapshot data, and save the recovery snapshot data to the backup repository; Perform disaster recovery drills using the recovery snapshot data in the backup repository, and retain the cloud disaster recovery instance based on the disaster recovery drill results; When a failure occurs in the local message middleware, switch the local metadata in the local message middleware to the cloud disaster recovery instance.

2. The method according to claim 1, characterized in that The obtaining the local metadata sent by the disaster recovery agent includes: Obtain a pre-set backup frequency, and generate backup tasks regularly based on the backup frequency; Send a backup data instruction to the disaster recovery agent based on the backup task; wherein, the backup data instruction is used to control the disaster recovery agent to invoke the management interface of the local message middleware to obtain the local metadata; Receive the local metadata sent by the disaster recovery agent.

3. The method according to claim 1, characterized in that, The performing disaster recovery drills using the recovery snapshot data in the backup repository, and retaining the cloud disaster recovery instance based on the disaster recovery drill results includes: Create the cloud disaster recovery instance; wherein, the node type and the number of nodes of the cloud disaster recovery instance are the same as those of the message middleware instance corresponding to the local message middleware; Configure the authentication parameters of the cloud disaster recovery instance, and read the recovery snapshot data from the backup repository; Extract a topic list, a subscription group list, and a user permission list based on the recovery snapshot data, and configure the topic list, the subscription group list, and the user permission list for the cloud disaster recovery instance; Perform an availability verification on the configured cloud disaster recovery instance to obtain the disaster recovery drill results, and retain the configured cloud disaster recovery instance.

4. The method according to claim 3, wherein The performing an availability verification on the configured cloud disaster recovery instance, and retaining the configured cloud disaster recovery instance based on the availability verification results includes: Perform production probing on the topics in the topic list to obtain production probing results; Perform consumption probing on the subscribed topics corresponding to the subscription group list to obtain consumption probing results; Obtain the account password of the local message cluster, and connect to the configured cloud disaster recovery instance using the account password of the local message cluster; Determine the topic permissions and subscription group permissions corresponding to the account password of the local message cluster based on the user permission list, and perform topic testing and subscription group testing based on the topic permissions and the subscription group permissions to obtain test results; Determine the disaster recovery drill results based on the production probing results, the consumption probing results, and the test results, and retain the configured cloud disaster recovery instance.

5. The method according to claim 3, characterized in that The when a failure occurs in the local message middleware, switching the local metadata in the local message middleware to the cloud disaster recovery instance includes: When the local message middleware fails, start the configured cloud disaster recovery instance; Read the specified recovery snapshot data in the backup repository and import the specified recovery snapshot data into the configured cloud disaster recovery instance; wherein, the specified recovery snapshot data includes the local metadata corresponding to the failed local message middleware.

6. A device for disaster recovery and cloud migration of a local message middleware, characterized in that, Applied to a disaster recovery platform, the device includes: An acquisition module, configured to acquire local metadata sent by a disaster recovery agent; the local metadata is obtained by the disaster recovery agent from the local message middleware; A backup module, configured to convert the format of the local metadata, encapsulate the local metadata after format conversion into recovery snapshot data, and save the recovery snapshot data to a backup repository; A disaster recovery drill module, configured to perform a disaster recovery drill using the recovery snapshot data in the backup repository and retain the cloud disaster recovery instance based on the disaster recovery drill result; A disaster recovery switch module, configured to switch the local metadata in the local message middleware to the cloud disaster recovery instance when the local message middleware fails.

7. A system for disaster recovery and cloud migration of a local message middleware, characterized in that Including: A cloud site and a local site; the cloud site includes a disaster recovery platform and a backup repository, the local site includes a disaster recovery agent and a local message middleware, and the disaster recovery platform is connected to the disaster recovery agent; The disaster recovery agent is configured to call local metadata from the local message middleware and transmit the local metadata to the disaster recovery platform; The disaster recovery platform is configured to execute the method for migrating the local message middleware to the cloud for disaster recovery according to any one of claims 1 to 5.

8. A computer device, characterized in that: Including: A memory and a processor, the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to execute the method for migrating the local message middleware to the cloud for disaster recovery according to any one of claims 1 to 5.

9. A computer-readable storage medium, characterized in that Computer instructions are stored on the computer-readable storage medium, and the computer instructions are used to cause a computer to execute the method for migrating the local message middleware to the cloud for disaster recovery according to any one of claims 1 to 5.

10. A computer program product, characterized in that, Including computer instructions, the computer instructions are used to cause a computer to execute the method for migrating the local message middleware to the cloud for disaster recovery according to any one of claims 1 to 5.

Images