CN116010169A - Cloud platform RDS database migration disaster recovery method based on cloud protogenesis technology - Google Patents
Cloud platform RDS database migration disaster recovery method based on cloud protogenesis technology Download PDFInfo
- Publication number
- CN116010169A CN116010169A CN202310038622.2A CN202310038622A CN116010169A CN 116010169 A CN116010169 A CN 116010169A CN 202310038622 A CN202310038622 A CN 202310038622A CN 116010169 A CN116010169 A CN 116010169A
- Authority
- CN
- China
- Prior art keywords
- data
- database
- component
- rds
- disaster recovery
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- Y—GENERAL 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
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention relates to a cloud platform RDS database migration disaster recovery method based on a cloud protogenesis technology, which is operated in a server and comprises the following steps: acquiring real-time states of the source RDS database and the target RDS database, and constructing a data synchronization link from the source RDS database to the target RDS database when the real-time states are normal, wherein the data synchronization link comprises a data acquisition component, a message queue component and a data synchronization component which are sequentially connected; and invoking the data synchronization link, acquiring data of a database table level from the source RDS database by the data acquisition component, storing the acquired data into the message queue component, forwarding the acquired data by the message queue component, and synchronizing the acquired data into the target RDS database in real time after the data synchronization component performs data preprocessing on the acquired data. Compared with the prior art, the method has the advantages of occupying less database resources, having low cost, realizing transaction level migration disaster recovery capability and the like.
Description
Technical Field
The invention relates to the technical field of database migration disaster recovery, in particular to a cloud platform RDS database migration disaster recovery method based on a cloud native technology.
Background
Under the cloud primordial age, ecology of various cloud platforms is increasingly perfect, the utilization rate of RDS databases of users is increased year by year, different cloud platforms provide different cloud platform RDS database services, and solutions such as migration disaster recovery backup are provided. However, the cloud platform migration disaster recovery solution only realizes migration disaster recovery of the RDS database in the cloud platform, and cannot recover and migrate data of the cloud database to other cloud platforms or local physical machine databases, so that users lose effective supervision and utilization capacity on the data of the public cloud.
The RDS database is provided for users in service mode, and the data acquisition service is required to remotely acquire data in agent-free mode in the disaster recovery migration process. In the data acquisition process, incremental data of the database is required to be acquired through a scheme of transaction log analysis, otherwise, a large amount of resources occupying the database can occur, and the problem that the normal service is influenced due to the performance reduction of the database is caused. The two-point RDS database migration disaster recovery process needs to simultaneously realize agent-free mode acquisition and incremental acquisition based on transaction log analysis. The existing migration disaster recovery scheme cannot be well compatible with the two capabilities.
Most of traditional disaster recovery services are developed based on non-cloud native architecture, the service can not be improved based on rapid telescopic node data, the service can not be automatically recovered when abnormality occurs, the isolation strategy of service computing resources is inflexible, and when abnormality occurs in the service of a certain link of disaster recovery migration, all disaster recovery migration operations using the service can fail simultaneously. The enterprise needs to input a large amount of manual operation and development work, so that the disaster recovery migration cost of the enterprise is greatly increased.
Disclosure of Invention
The invention aims to overcome the defects of the prior art and provide a cloud platform RDS database migration disaster recovery method based on a cloud primary technology, which has the advantages of less occupied database resources and low cost, and solves the problem of database migration disaster recovery between different cloud platforms and between a cloud platform database and a physical machine database.
The aim of the invention can be achieved by the following technical scheme:
the cloud platform RDS database migration disaster recovery method based on the cloud native technology is operated in a server and is used for realizing the migration or disaster recovery task from a source end RDS database to a target end RDS database, and comprises the following steps of:
acquiring real-time states of the source RDS database and the target RDS database, and constructing a data synchronization link from the source RDS database to the target RDS database when the real-time states are normal, wherein the data synchronization link comprises a data acquisition component, a message queue component and a data synchronization component which are sequentially connected;
and invoking the data synchronization link, wherein the data acquisition component acquires data of a database table level from the source RDS database, the acquired data is stored in the message queue component, the message queue component forwards the acquired data, and the data synchronization component performs data preprocessing on the acquired data and then synchronizes the acquired data to the target RDS database in real time.
Further, the data acquisition component, message queue component, and data synchronization component are containerized by a Docker and deployed based on Kubernetes.
Further, the data synchronization link is dynamically created based on the Kubernetes API, the resource use condition of each component in the data synchronization link is monitored in real time, and each component is dynamically expanded and contracted based on the resource use condition.
Further, the method further comprises:
and judging the survival ready state of each component in the data synchronous link through Kubernetes, and restarting the component when abnormality exists.
Further, the constructed data synchronization link is applied to one migration or disaster recovery task or a plurality of migration or disaster recovery tasks.
Further, when the data of the database table level is collected, the collected data is full data or incremental data captured according to a database log.
Further, the message queue component employs a subscription and publication mode of Kafka to effect data forwarding.
Further, the message queue component employs clustered deployment.
Further, the data preprocessing includes one or more of filtering, washing, desensitizing, encrypting, and converting.
Further, the source RDS database and the target RDS database are Mysql database, SQL Server database or PostgreSQL database.
The invention also provides a cloud platform RDS database migration disaster recovery system based on the cloud native technology, which is used for realizing the migration or disaster recovery task from a source end RDS database to a target end RDS database, and comprises a server and a data synchronization link constructed and connected by the server, wherein the server is configured to:
the method comprises the steps of acquiring real-time states of a source RDS database and a target RDS database, and when the real-time states are normal, constructing a data synchronization link from the source RDS database to the target RDS database, wherein the data synchronization link comprises a data acquisition component, a message queue component and a data synchronization component which are sequentially connected, invoking the data synchronization link, the data acquisition component acquires data of a database table level from the source RDS database, the acquired data is stored in the message queue component, the message queue component forwards the acquired data, and the data synchronization component performs data preprocessing on the acquired data and then synchronizes the acquired data to the target RDS database in real time.
Compared with the prior art, the invention has the following beneficial effects:
1. the migration disaster recovery service realizes the transaction-level migration disaster recovery capacity through the data real-time acquisition and real-time processing capacity.
2. According to the invention, RDS database data of different cloud platforms are acquired through the non-proxy mode acquisition and the increment acquisition based on transaction log analysis, so that the data acquisition of the database table level is realized, the proxy is not required to be installed in the acquired database or the system where the acquired database is located based on the non-proxy mode acquisition, the increment data is acquired through the analysis of the transaction log in the increment acquisition process, the occupied database resources are less, and the normal service capability of the acquired database is not influenced.
3. The data acquisition component, the message queue component and the data synchronization component in the data synchronization link are deployed based on the Kubernetes, the Kubernetes dynamically expands the component service by monitoring the CPU and the memory resources of all component services, when the CPU or the memory of the component service exceeds a threshold value, the Kubernetes dynamically expands the component service, when the CPU or the memory of the component service is smaller than the threshold value, the Kubernetes dynamically contracts the component service, thereby realizing the dynamic expansion capacity of the service so as to improve the service capacity, and the problems of dynamic expansion, resource isolation and abnormal recovery of the traditional migration disaster recovery service can be solved through the Kubernetes. When the service is busy, the whole service capacity can be increased by increasing the number of nodes for disaster recovery migration service, and when the service is not busy, the system automatically reduces the number of service nodes and reduces the occupation of resources.
4. The invention realizes flexible configuration of synchronous link components based on Kubernetes, and migration disaster recovery service can use a set of synchronous links in public or independent mode, so that the resource isolation strategy is more flexible in calculation and storage, and the resource utilization rate is higher.
5. Based on the autonomous capacity of the Kubernetes, the invention can automatically retry and automatically pull up after the service is abnormal, thereby reducing the workload of artificial operation and maintenance.
6. The invention can synchronize data to RDS databases or physical machine databases on different cloud platforms, realizes the migration of RDS databases among different cloud platforms, and can be compatible with the migration disaster tolerance of RDS databases (Mysql, SQL Server, postgreSQL) which are currently mainstream in the market among different cloud platforms and physical machine databases.
7. The invention can synchronize the source end database data after being filtered, cleaned, desensitized, encrypted, converted and the like, and support the breakpoint continuous transmission capability in migration disaster recovery. When the RDS database at the source end is in disaster unavailability, switching to the RDS database or the physical machine database on the cloud platform to replace the operation of the RDS database at the source end, ensuring uninterrupted operation of the original system service and realizing the disaster recovery effect of the RDS database.
Drawings
FIG. 1 is a schematic diagram of a cloud platform RDS database migration disaster recovery system according to the present invention;
FIG. 2 is a flow chart of database migration in an embodiment;
FIG. 3 is a flow chart of database disaster recovery in an embodiment.
Detailed Description
The invention will now be described in detail with reference to the drawings and specific examples. The present embodiment is implemented on the premise of the technical scheme of the present invention, and a detailed implementation manner and a specific operation process are given, but the protection scope of the present invention is not limited to the following examples.
Example 1
Referring to fig. 1, the present embodiment provides a cloud platform RDS (Relational Database Service) database migration disaster recovery method based on a cloud native technology, which is run in a server and is used for implementing migration or disaster recovery tasks from a source end RDS database to a target end RDS database, and includes the following steps:
acquiring real-time states of the source RDS database and the target RDS database, and constructing a data synchronization link from the source RDS database to the target RDS database when the real-time states are normal, wherein the data synchronization link comprises a data acquisition component, a message queue component and a data synchronization component which are sequentially connected;
and invoking the data synchronization link, wherein the data acquisition component acquires data of a database table level from the source RDS database, the acquired data is stored in the message queue component, the message queue component forwards the acquired data, and the data synchronization component performs data preprocessing on the acquired data and then synchronizes the acquired data to the target RDS database in real time.
The data acquisition component, the message queue component and the data synchronization component in the data synchronization link are containerized by a Docker, deployed based on Kubernetes, and realize flexible configuration of the synchronization link component and dynamic expansion and contraction of resources based on the Kubernetes.
According to the method, the data of the source-end RDS databases of different cloud platforms are acquired through the agent-free mode acquisition and the increment based on transaction log analysis, and the data of the source-end RDS databases are synchronized to the target-end RDS databases or the physical machine databases in real time by adopting the data synchronization link constructed based on the Kubernetes, so that the cloud platform database migration disaster tolerance can be conveniently and reliably realized.
The above-described method, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention may be embodied essentially or in a part contributing to the prior art or in a part of the technical solution, in the form of a software product stored in a storage medium, comprising several instructions for causing a computer device (which may be a personal computer, a server, a network device, etc.) to perform all or part of the steps of the method according to the embodiments of the present invention. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), a magnetic disk, or an optical disk, or other various media capable of storing program codes.
Example 2
The present embodiment provides a server, including one or more processors, a memory, and one or more programs stored in the memory, the one or more programs including instructions for performing the cloud platform RDS database migration disaster recovery method based on cloud native technology as described in embodiment 1.
Example 3
The embodiment provides a cloud platform RDS database migration disaster recovery system based on a cloud native technology, which is used for realizing migration or disaster recovery tasks from a source end RDS database to a target end RDS database, and comprises a server and a data synchronization link connected by the server, wherein the server is configured to: the method comprises the steps of acquiring real-time states of a source RDS database and a target RDS database, and when the real-time states are normal, constructing a data synchronization link from the source RDS database to the target RDS database, wherein the data synchronization link comprises a data acquisition component, a message queue component and a data synchronization component which are sequentially connected, invoking the data synchronization link, the data acquisition component acquires data of a database table level from the source RDS database, the acquired data is stored in the message queue component, the message queue component forwards the acquired data, and the data synchronization component performs data preprocessing on the acquired data and then synchronizes the acquired data to the target RDS database in real time.
The structure of the cloud platform RDS database migration disaster recovery system of the present embodiment is shown in fig. 1. In fig. 1, source is a Source data Source of a migration disaster recovery service, and Database in Source is an RDS Database of different cloud platforms. The Target is a Target data source for migrating disaster recovery service, and the Database in the Target can be RDS databases of different cloud platforms or databases deployed in physical machines. The server provides a migration disaster recovery service for the migration disaster recovery system in this embodiment, and includes a management component (management), a data collection component (collection), a Message Queue component (Message Queue), and a data synchronization component (Sync), where the management component serves as a server in this embodiment.
The management component in this embodiment is used as a management console of a service, and is a management unit for migrating disaster recovery service. Service containerization is realized through a Docker, and the flexible expansion, autonomy and high availability of services are realized through Kubernetes, so that tasks of interaction with users are carried out. The management component includes the following three functions:
multi-tenant management: and managing tenant and user information in the migration disaster recovery service, managing the authorities of the tenant and the user, and realizing the resource isolation of the tenant and the user.
And (3) data source management: and managing connection information of the source RDS database and the target RDS database in the service.
Data synchronization link management: the scheduling collection, message Queue and Sync component dynamically generates data synchronization links and manages the data synchronization links in the service.
The management component of the embodiment dynamically creates a data synchronization link based on the Kubernetes API, and the data synchronization link can be used by one task or can be used by a plurality of tasks at the same time, so that the management of the tenant and the data synchronization link by the management of the management component realizes the resource isolation of the service. The Kubernetes dynamically expands the component service by monitoring the CPU and the memory resources of all the component services, when the CPU or the memory of the component service exceeds a threshold value, and when the CPU or the memory of the component service is smaller than the threshold value, the Kubernetes dynamically contracts the component service to realize the dynamic expansion capacity of the service, thereby improving the service capacity. And all component services in the migration disaster recovery service provide corresponding survival and ready interfaces, whether the service is abnormal or not is judged through monitoring the survival and ready interfaces of the service by the Kubernetes, and if the survival and ready interfaces of the service are abnormal, the service is restarted by the Kubernetes to the abnormal component service, so that the abnormal recovery capability of the service is realized.
The data synchronization link is dynamically generated by the Manage component according to the information of the source RDS database and the target RDS database and through the kubernetes automatic scheduling collection, message Queue and Sync component, and realizes the task of synchronizing data from the source RDS database to the target RDS database.
The Collect component in the embodiment realizes service containerization through a Docker, and realizes elastic expansion, autonomy and high availability of services through Kubernetes. The collection component is used for realizing table-level data collection on the source-side database and is responsible for collecting data in the source-side RDS database and sending the collected data to the Message Queue component. The Collect component contains the following three functions:
full data acquisition: the method comprises the steps of performing full-quantity collection on data of a database mode definition language DDL (Data Definition Language) and a data operation language DML (Data Manipulation Language) of a source RDS database, performing locking operation on the database when DDL data of the database are collected, collecting the DML data after DDL data collection is completed, and enabling the collected DML not to lock the database.
Incremental data capture: and capturing DML and DDL data of incremental change of the database based on the database log, and realizing incremental acquisition of the database data.
A variety of data source acquisition: the data of RDS databases such as Mysql, SQL Server, postgreSQL and the like can be collected.
The Message Queue component in the embodiment realizes service containerization through a Docker, and realizes elastic expansion, autonomy and high availability of services through Kubernetes. The Message Queue component is responsible for forwarding data acquired by the collection component, and adopts a high-throughput distributed publish-subscribe Message system Kafka to realize the functions of Message forwarding and data storage of the Message Queue component. The Message Queue component contains the following three functions:
and (3) data storage: and storing the data acquired by the collection component to prevent the data from being lost.
Message forwarding: the Message Queue component forwards the data collected by the collection component to the Sync component in a json data format by adopting a subscription and release mode of Kafka.
Cluster deployment: the cluster deployment of the components improves the high throughput of the component service, realizes the automatic expansion and contraction of the clusters based on the cloud native technology, and improves the high availability of the component service.
The Sync component in the embodiment realizes service containerization through a Docker, and realizes the elastic expansion, autonomy and high availability of the service through Kubernetes. After the Sync component filters, cleans, desensitizes, encrypts, converts and the like the source database data according to the data processing rule of the task, the data in the Message Queue is synchronized to the target RDS database in real time, and the breakpoint continuous transmission capability is supported in the migration disaster tolerance. The Sync component contains the following three functions:
real-time synchronization: the Sync component subscribes to the Message in the Message Queue, and after the Message is released in the Message Queue, the Sync synchronizes the data to the RDS database of the target end in real time.
Data consistency guarantees: the data of the source end database synchronized to the target end database is not lost, the data is not repeated, and the final consistency of the data is ensured.
Synchronization to a variety of databases: synchronizing Message Queue forwarding data to RDS databases such as Mysql, SQL Server, postgreSQL and the like.
In the migration disaster recovery system, each component needs to meet the following settings:
1. the Manage, collect, sync components of the Server must be in the same network and have mutual access rights;
2. the Server, the source terminal RDS database and the target terminal RDS database have mutual access rights;
3. the operator must configure the correct user name and password for the source RDS database, target RDS database instance.
The embodiment can realize database migration and database disaster recovery tasks based on the migration disaster recovery system, and the specific process is described as follows:
1) Database migration instance
As shown in fig. 2, when an operator selects the source RDS database and the destination RDS data to initiate a data migration task, the task is performed as follows:
s101, an operator selects a source RDS database and a target RDS database, and step S102 is executed after a data migration task is initiated.
S102, the management component acquires the states of a source RDS database and a target RDS database, and the step S103 is executed after the acquisition of the states of the source RDS database and the target RDS database is completed.
S103, the management component judges whether the state of the source end RDS database and the target end RDS database is normal. If the state normally executes step S104, otherwise, execute step S108, and the task ends.
S104, the Message component automatically schedules the services of the collection, message Queue and Sync component to dynamically create a data synchronization link through a kubernetes API, and the Message component transmits source RDS data information and Message Queue information to the collection component and transmits Message Queue information and target RDS data information to the Sync component. After the creation of the data synchronization link is completed, step S105 is performed.
S105, the collection component collects the total data of the source end database based on the source end RDS database information transmitted by the management component, transmits the collected data to the Message Queue, and then executes step S106.
S106, the Message Queue component stores the data acquired by Connect into a Message Queue, and then step S107 is executed.
And S107, the Sync component synchronizes the data stored in the Message Queue to the RDS database information of the target terminal transmitted by the Message component. Step S108 is then performed.
S108, the data migration task is successful, and the task is ended.
2) Database disaster recovery instance
As shown in fig. 3, when an operator selects the source RDS database and the destination RDS data to initiate a data disaster recovery task, the task is performed as follows:
s201, an operator selects a source RDS database and a target RDS database, and step S202 is executed after a data disaster recovery task is initiated.
S202, the management component acquires the states of a source RDS database and a target RDS database, and the step S203 is executed after the acquisition of the states of the source RDS database and the target RDS database is completed.
S203, the management component judges whether the state of the source end RDS database and the target end RDS database is normal. If the state normally executes step S204, otherwise, step S215 is executed and the task ends.
S204, the Message component automatically schedules the services of the collection, message Queue and Sync component to dynamically create a data synchronization link through the kubernetes API, and the Message component transmits source RDS data information and Message Queue information to the collection component and transmits Message Queue information and target RDS data information to the Sync component. After the creation of the data synchronization link is completed, step S205 is performed.
S205, judging whether the task is full disaster recovery or incremental disaster recovery, wherein the full disaster recovery can acquire the full data of the source database first, and then acquire the incremental data of the source database based on the log, and the incremental disaster recovery acquires the incremental data of the source data. If the full capacity disaster recovery is selected to execute step S206, otherwise, step S209 is executed.
S206, the collection component collects the total data of the source end database based on the source end RDS database information transmitted by the management component, transmits the collected data to the Message Queue, and then executes step S207.
S207, the Message Queue component stores the data acquired by Connect into a Message Queue, and then step S208 is executed.
S108, the Sync component synchronizes the data stored in the Message Queue to the RDS database information of the target terminal transmitted by the Message component. Step S209 is then performed.
S209, the Collect component monitors the data change of the source RDS database transmitted by the management component in real time, and then step S210 is executed.
S210, if the collection detects that the source RDS database has data change, executing step S211, otherwise, executing step S209.
S211, collecting data of source database changes by a collection component, transmitting the collected data to a Message Queue, and then executing step S212.
S212, the Message Queue component stores the data acquired by Connect into a Message Queue, and then step S213 is executed.
S213, the Sync component synchronizes the data stored in the Message Queue to the destination RDS database information transmitted by the Message component, and then executes step S214.
S214, if the operator selects to stop the task, executing step S215, otherwise executing step S209, and continuing to monitor the data change of the source RDS database.
S215, stopping the data disaster recovery task, and ending the task.
The foregoing describes in detail preferred embodiments of the present invention. It should be understood that numerous modifications and variations can be made in accordance with the concepts of the invention by one of ordinary skill in the art without undue burden. Therefore, all technical solutions which can be obtained by logic analysis, reasoning or limited experiments based on the prior art by the person skilled in the art according to the inventive concept shall be within the scope of protection defined by the claims.
Claims (10)
1. The cloud platform RDS database migration disaster recovery method based on the cloud native technology is operated in a server and is used for realizing the migration or disaster recovery task from a source end RDS database to a target end RDS database, and is characterized by comprising the following steps of:
acquiring real-time states of the source RDS database and the target RDS database, and constructing a data synchronization link from the source RDS database to the target RDS database when the real-time states are normal, wherein the data synchronization link comprises a data acquisition component, a message queue component and a data synchronization component which are sequentially connected;
and invoking the data synchronization link, wherein the data acquisition component acquires data of a database table level from the source RDS database, the acquired data is stored in the message queue component, the message queue component forwards the acquired data, and the data synchronization component performs data preprocessing on the acquired data and then synchronizes the acquired data to the target RDS database in real time.
2. The cloud platform RDS database migration disaster recovery method based on cloud technology of claim 1, wherein the data acquisition component, the message queue component, and the data synchronization component are containerized by a Docker and deployed based on Kubernetes.
3. The cloud platform RDS database migration disaster recovery method based on the cloud native technology according to claim 2, wherein the data synchronization link is dynamically created based on a Kubernetes API, the resource use condition of each component in the data synchronization link is monitored in real time, and each component is dynamically expanded and contracted based on the resource use condition.
4. The cloud platform RDS database migration disaster recovery method based on cloud native technology of claim 2, wherein the method further comprises:
and judging the survival ready state of each component in the data synchronous link through Kubernetes, and restarting the component when abnormality exists.
5. The cloud platform RDS database migration and disaster recovery method based on the cloud native technology of claim 1, wherein the constructed data synchronization link is applied to one migration or disaster recovery task or a plurality of migration or disaster recovery tasks.
6. The cloud platform RDS database migration disaster recovery method based on the cloud native technology of claim 1, wherein when the data collection at the database table level is performed, the collected data is full data or incremental data captured according to a database log.
7. The cloud platform RDS database migration disaster recovery method based on cloud native technology of claim 1, wherein the message queue component implements data forwarding using a subscription and publication mode of Kafka.
8. The cloud platform RDS database migration disaster recovery method based on cloud native technology of claim 1, wherein the message queue component employs clustered deployment.
9. The cloud platform RDS database migration disaster recovery method based on cloud technology of claim 1, wherein the data preprocessing comprises one or more of filtering, cleaning, desensitizing, encrypting, converting.
10. The cloud platform RDS database migration disaster recovery method according to claim 1, wherein the source RDS database and the destination RDS database are Mysql database, SQL Server database, or PostgreSQL database.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310038622.2A CN116010169A (en) | 2023-01-11 | 2023-01-11 | Cloud platform RDS database migration disaster recovery method based on cloud protogenesis technology |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310038622.2A CN116010169A (en) | 2023-01-11 | 2023-01-11 | Cloud platform RDS database migration disaster recovery method based on cloud protogenesis technology |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116010169A true CN116010169A (en) | 2023-04-25 |
Family
ID=86020965
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310038622.2A Pending CN116010169A (en) | 2023-01-11 | 2023-01-11 | Cloud platform RDS database migration disaster recovery method based on cloud protogenesis technology |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116010169A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117555699A (en) * | 2024-01-11 | 2024-02-13 | 杭州剑齿虎信息技术有限公司 | LCK real-time acquisition system |
-
2023
- 2023-01-11 CN CN202310038622.2A patent/CN116010169A/en active Pending
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117555699A (en) * | 2024-01-11 | 2024-02-13 | 杭州剑齿虎信息技术有限公司 | LCK real-time acquisition system |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP3819757A1 (en) | Edge application management method and system | |
| US9785691B2 (en) | Method and apparatus for sequencing transactions globally in a distributed database cluster | |
| US8615578B2 (en) | Using a standby data storage system to detect the health of a cluster of data storage servers | |
| US8856091B2 (en) | Method and apparatus for sequencing transactions globally in distributed database cluster | |
| CN104657497A (en) | Mass electricity information concurrent computation system and method based on distributed computation | |
| US11057471B2 (en) | Edge application management method and system | |
| CN105915405A (en) | Large-scale cluster node performance monitoring system | |
| CN111953566B (en) | Distributed fault monitoring-based method and virtual machine high-availability system | |
| CN105721582B (en) | Multinode file backup system | |
| CN104461752A (en) | Two-level fault-tolerant multimedia distributed task processing method | |
| CN109684050B (en) | Application method of parallelization transaction executor | |
| JPS61500751A (en) | Method for stopping program processes in multiprocessing systems | |
| CN105589756B (en) | Batch processing group system and method | |
| CN116010169A (en) | Cloud platform RDS database migration disaster recovery method based on cloud protogenesis technology | |
| CN110727508A (en) | Task scheduling system and scheduling method | |
| CN107979498B (en) | Mesh network cluster and large file transmission method based on cluster | |
| CN104573428B (en) | A kind of method and system for improving server cluster resource availability | |
| CN110855481B (en) | Data acquisition system and method | |
| EP3660679B1 (en) | Data backup method, device and system | |
| CN113672452A (en) | Method and system for monitoring operation of data acquisition task | |
| WO2002001347A2 (en) | Method and system for automatic re-assignment of software components of a failed host | |
| CN116185697B (en) | Container cluster management method, device and system, electronic equipment and storage medium | |
| CN111614702B (en) | Edge calculation method and edge calculation system | |
| CN104601693B (en) | The method and apparatus of operational order are responded in a kind of distributed system | |
| CN112417050A (en) | Data synchronization method and device, system, storage medium and electronic device |
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 |