GoldenDB Database Data Migration Method and Device

Abstract

This invention discloses a GoldenDB database data migration method and apparatus, relating to the field of database data migration technology. The method is applied to a GoldenDB database scenario including a production database and a target database to be migrated. The method includes: establishing a disaster recovery synchronization relationship between the production database and the target database, using the target database as a disaster recovery database, and synchronizing incremental data from the production database in real time using a synchronization mode; during a business downtime window, switching the target database from the disaster recovery database to a new production database to provide services, while simultaneously switching the original production database to a disaster recovery database; and dismantling the disaster recovery synchronization relationship between the target database and the original production database, allowing the target database to operate as an independent production cluster.

Description

Technical Field

[0001] This invention relates to the field of database data migration technology, and more particularly to a GoldenDB database data migration method and apparatus. Background Technology

[0002] With the deepening of digital transformation in the financial industry, distributed database technology has been widely used in banks and other financial institutions. GoldenDB, as an emerging distributed database product, undertakes the storage and processing of critical business data in financial systems. During the operation and maintenance of financial systems, scenarios such as data center renovations, equipment relocation, hardware upgrades or replacements, and software upgrades or modifications are frequently encountered, all of which require database data migration operations.

[0003] Existing database migration technologies have significant shortcomings. As an emerging distributed database product, GoldenDB lacks mature and stable dedicated data migration tools, and existing general-purpose data migration solutions cannot fully adapt to the characteristics of GoldenDB's distributed architecture. Secondly, while centralized databases like Oracle have data migration methods based on disaster recovery, GoldenDB, being a distributed database, contains various node types, including management nodes, compute node clusters, data node clusters, and global transaction management nodes. Its operation methods and technical characteristics are completely different from centralized databases, making existing solutions unsuitable for direct application. Furthermore, financial systems such as banks require 24 / 7 uninterrupted operation, placing extremely high demands on business continuity, downtime, data integrity, and consistency during data migration. Existing technologies struggle to provide accurate, efficient, and reliable GoldenDB database migration solutions to meet these stringent financial-grade requirements. Summary of the Invention

[0004] To address the problems existing in the prior art, this invention proposes a GoldenDB database data migration method and apparatus. This invention connects the various steps of establishing a GoldenDB database disaster recovery synchronization relationship through scripts, enabling automated establishment of the synchronization relationship between the production database and the disaster recovery database. This improves the efficiency and timeliness of disaster recovery synchronization relationship establishment and reduces anomalies caused by human error.

[0005] In a first aspect of this invention, a GoldenDB database data migration method is proposed. This method is applied to a GoldenDB database scenario including a production database and a target database to be migrated, and includes: A disaster recovery synchronization relationship is established between the production database and the target database, with the target database serving as the disaster recovery database, and incremental data of the production database is synchronized in real time in a synchronization mode. During the business downtime window, the target database is switched from the disaster recovery database to a new production database to provide services to the outside world, while the original production database is switched to the disaster recovery database. The disaster recovery synchronization relationship between the target database and the original production database is removed, and the target database is operated as an independent production cluster.

[0006] In a second aspect of the present invention, a GoldenDB database data migration apparatus is provided. This apparatus is applied to a GoldenDB database scenario including a production database and a target database to be migrated, comprising: The disaster recovery setup module is used to establish a disaster recovery synchronization relationship between the production database and the target database, using the target database as the disaster recovery database, and synchronizing the incremental data of the production database in real time in a synchronization mode. The disaster recovery switching module is used to switch the target database from the disaster recovery database to a new production database to provide services during the business downtime window, while simultaneously switching the original production database to the disaster recovery database. The disaster recovery dismantling module is used to dismantle the disaster recovery synchronization relationship between the target database and the original production database, so that the target database can run as an independent production cluster.

[0007] In a third aspect of the present invention, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement a GoldenDB database data migration method.

[0008] In a fourth aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing a computer program that, when executed by a processor, implements a GoldenDB database data migration method.

[0009] In a fifth aspect of the present invention, a computer program product is provided, the computer program product comprising a computer program that, when executed by a processor, implements a GoldenDB database data migration method.

[0010] The GoldenDB database data migration method and apparatus proposed in this invention achieve real-time, accurate, and efficient synchronization of data between the source and target databases through full backup and incremental real-time synchronization, ensuring data consistency between the two databases. Furthermore, it utilizes disaster recovery switching for migration during downtime, significantly reducing downtime and minimizing the impact on business operations, providing strong technical support for data migration scenarios. Attached Figure Description

[0011] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a schematic diagram of the GoldenDB database data migration method according to an embodiment of the present invention.

[0013] Figure 2 This is a schematic diagram of the disaster recovery setup process according to an embodiment of the present invention.

[0014] Figure 3 This is a schematic diagram of the disaster recovery switchover process according to an embodiment of the present invention.

[0015] Figure 4 This is a schematic diagram of the architectural relationship of a specific embodiment of the present invention.

[0016] Figure 5 This is a schematic diagram of the disaster recovery setup process according to a specific embodiment of the present invention.

[0017] Figure 6 This is a schematic diagram of the architecture of a GoldenDB database data migration device according to an embodiment of the present invention.

[0018] Figure 7 This is a schematic diagram of a computer device structure according to an embodiment of the present invention. Detailed Implementation

[0019] The principles and spirit of the invention will now be described with reference to several exemplary embodiments. It should be understood that these embodiments are given merely to enable those skilled in the art to better understand and implement the invention, and are not intended to limit the scope of the invention in any way. Rather, these embodiments are provided to make this disclosure more thorough and complete, and to fully convey the scope of this disclosure to those skilled in the art.

[0020] Those skilled in the art will recognize that embodiments of the present invention can be implemented as a system, apparatus, device, method, or computer program product. Therefore, this disclosure can be specifically implemented in the following forms: entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software.

[0021] According to an embodiment of the present invention, a method and apparatus for migrating data in a GoldenDB database are proposed, relating to the field of database data migration technology.

[0022] In the embodiments of the present invention, the following terms need to be explained: Distributed databases: Distributed database systems typically use smaller computer systems. Each computer can be located in a separate place, and each computer may have a complete copy or a partial copy of the DBMS, and its own local database. Many computers located in different locations are interconnected through a network to form a complete, globally-oriented, logically centralized, but physically distributed large database.

[0023] GoldenDB is a relational distributed database product from a database vendor. It adopts a shared-nothing architecture and provides users with a highly available, highly reliable, and scalable "big data + distributed database" solution.

[0024] Data migration refers to the process of moving data from one storage system, database, application, or computing platform to another. This process typically occurs during hardware upgrades, software replacements or upgrades, and data center relocations or renovations.

[0025] Management node: The management node is responsible for the cluster management process in the distributed database. It is not involved in the business access process and has no load pressure. It is generally deployed in a three-node master-slave configuration.

[0026] Compute Nodes: The compute node cluster layer is the core layer of the distributed database, composed of stateless compute nodes (DBProxy). Compute nodes receive user operations (typically described in Structured Query Language) from the driver layer or management nodes, perform logical and physical optimizations, and generate a distributed query plan that satisfies distributed transaction consistency. While executing the distributed query plan, the compute nodes continuously access data nodes to complete the user's final operation request.

[0027] Data Nodes: A data node cluster is the final storage component for application data. All data nodes form one or more database clusters. User transactions cannot span multiple database clusters; they can only be performed within a single database cluster.

[0028] Global Transaction Management Node: The global transaction manager maintains the entire lifecycle of global transactions in the distributed database, providing the ability to apply for, release, and query global transactions, and is deployed in a cluster.

[0029] Production Database: The GoldenDB system that normally provides services to the outside world and is used to handle business operations.

[0030] Disaster recovery database: Under normal circumstances, GoldenDB does not provide services but replicates data from the production database. It is used to provide emergency startup capabilities in disaster and emergency scenarios, replacing the production database to provide services.

[0031] Service model: Provides services to external parties, undertakes business operations, and provides normal functions of the GoldenDB system.

[0032] Read-only mode: Set read_only on the data node to allow only read statements to be executed.

[0033] Synchronization mode: Based on read-only mode, synchronize data from the peer GoldenDB system, including: data node data, global transaction management node data, and metadata.

[0034] The principles and spirit of the present invention will be explained in detail below with reference to several representative embodiments.

[0035] Figure 1 This is a schematic diagram of a GoldenDB database data migration method according to an embodiment of the present invention. Figure 1 As shown, this method is applied to a GoldenDB database scenario that includes a production database and a target database to be migrated, including: S101, establish a disaster recovery synchronization relationship between the production database and the target database, use the target database as the disaster recovery database, and synchronize the incremental data of the production database in real time in synchronization mode. S102, within the business shutdown window, the target database is switched from the disaster recovery database to a new production database to provide services to the outside world, while the original production database is switched to the disaster recovery database. S103, the disaster recovery synchronization relationship between the target database and the original production database is removed, and the target database is operated as an independent production cluster.

[0036] This invention establishes a process flow for disaster recovery synchronization, role switching during downtime, and dismantling synchronization relationships. Combined with a synchronization mode, it achieves real-time synchronization of incremental data in the production database, ensuring data consistency and integrity. Furthermore, by using a short downtime window to complete role switching, it minimizes the impact of interruptions on 24-hour uninterrupted financial business. Ultimately, it enables the target database to operate independently and stably, meeting the needs for efficient and reliable data migration in scenarios such as data center renovation and equipment upgrades.

[0037] To provide a clearer explanation of the GoldenDB database data migration method described above, each step will be explained in detail below.

[0038] In one embodiment, S101, a disaster recovery synchronization relationship is established between the production database and the target database, and the target database is used as a disaster recovery database to synchronize the incremental data of the production database in real time in a synchronization mode.

[0039] like Figure 2 As shown, the specific methods include: S201, Back up all data of all data nodes in the production database and transfer the backup data to the data node corresponding to the target database; S202, restore the full data on the data node of the target library, and set the data node of the target library to read-only mode; S203, Configure and deploy the disaster recovery synchronization tool to establish a disaster recovery synchronization channel from the production database to the target database; S204, Set the working mode of the target library to synchronization mode, start real-time synchronization of incremental data from the production library, and confirm that the synchronization status is normal.

[0040] By implementing a step-by-step approach involving full data backup and transmission, target database data recovery and read-only settings, synchronization tool configuration, and synchronization mode activation, the system uses full data as the foundation and real-time incremental data synchronization as a supplement to ensure complete alignment between the production and target databases. The read-only mode prevents irrelevant data from interfering with the establishment of the master-slave relationship, and the standardized deployment of the synchronization channel ensures the stability of incremental data transmission, providing a reliable data foundation for subsequent disaster recovery switchover and significantly improving the accuracy and controllability of GoldenDB database migration.

[0041] The process of configuring and deploying backup data, data recovery, and disaster recovery synchronization tools is executed through automated scripts.

[0042] By automating key steps such as backup data, recovery data, and disaster recovery synchronization tool configuration and deployment through scripts, manual intervention is significantly reduced. This not only lowers the risk of disaster recovery synchronization anomalies caused by human error, but also improves the execution efficiency and time consistency of the disaster recovery setup process, meeting the needs of efficient operation and maintenance of financial systems. At the same time, it ensures the standardization and repeatability of the migration process, making it easy to reuse quickly in different scenarios.

[0043] In one embodiment, S102, during the service shutdown window, the target database is switched from the disaster recovery database to a new production database to provide services to the outside world, while the original production database is switched to the disaster recovery database.

[0044] like Figure 3 As shown, the specific methods include: S301, Before disaster recovery switchover, perform a mode check to confirm that the production database is in service mode and the target database is in synchronization mode and the synchronization status is normal. S302, switch the target library to service mode to accept production transactions, and at the same time switch the production library to synchronization mode; S303, After the disaster recovery switchover, a mode check is performed to verify that the target database has become a production database and confirm that its operating status is normal.

[0045] By verifying the mode and synchronization status before the switch, switching roles during the switch, and verifying the running status after the switch, a closed-loop inspection mechanism is formed throughout the entire process, which effectively avoids the problems of switch failure or data inconsistency caused by mode mismatch or synchronization anomalies. The design of the target database smoothly taking over production transactions and the original production database smoothly switching to the disaster recovery database ensures the controllability of business interruption time and further enhances the stability and business continuity of the data migration process.

[0046] In one embodiment, S302, the target library is switched to service mode to accept production transactions, while the production library is switched to synchronization mode, including: Automated disaster recovery switching and checks are performed by calling the disaster recovery synchronization tools provided by the GoldenDB database.

[0047] By leveraging the built-in disaster recovery synchronization tools of the GoldenDB database, automated switching and checks are achieved. This fully utilizes the native compatibility between the tools and the database architecture, reducing the risk of cross-tool adaptation. The automated execution method simplifies the switching process, reduces delays and errors caused by manual intervention, ensures efficient and stable disaster recovery switching, further reduces the business downtime window, and improves the security and convenience of data migration.

[0048] In one embodiment, S103, the disaster recovery synchronization relationship between the target database and the original production database is removed, and the target database is operated as an independent production cluster.

[0049] After dismantling the disaster recovery synchronization relationship between the target database and the original production database, the following is also included: For the target database that is already running as an independent production cluster, a new disaster recovery synchronization relationship is created and a corresponding disaster recovery database is built according to the preset requirements.

[0050] After completing the core data migration and dismantling the original disaster recovery synchronization relationship, it supports the creation of new disaster recovery synchronization relationships for the target database as needed. This not only achieves a closed loop in data migration but also maintains the high availability characteristics of the GoldenDB database. It provides disaster emergency protection for the target database, which runs as an independent production cluster, meets the high reliability requirements of the financial system for the long-term stable operation of the database, and expands the practicality and adaptability of this migration method.

[0051] In practical application scenarios, both the production database and the target database are GoldenDB distributed database clusters. Each production database or target database includes a management node, a computing node cluster, a data node cluster, and a global transaction management node. Specific Implementation Example 1: refer to Figure 4 This is a schematic diagram of the architectural relationship of a specific embodiment of the present invention. Figure 4As shown, the present invention provides a GoldenDB database data migration method, which is applied to a GoldenDB database scenario including a production database and a target database to be migrated. Both the production database and the target database are GoldenDB distributed database clusters. Each production database or target database includes a management node, a compute node cluster, a data node cluster, and a global transaction management node.

[0053] By establishing, switching over, and dismantling disaster recovery systems, data migration from the old GoldenDB database to the target database can be completed. Furthermore, the establishment and switching processes can be automated using scripts, ensuring that critical production data can be accurately, efficiently, and completely migrated to the target database. This invention is designed using a GoldenDB database cluster as the operating object and implemented using the shell language.

[0054] Step 1, Disaster Recovery Setup: refer to Figure 5 This is a schematic diagram illustrating the disaster recovery setup process according to a specific embodiment of the present invention. Figure 5 As shown, the specific process is as follows: S501: Back up the original database data and transfer the full backup data to the target database. This process primarily achieves the following functions and relies entirely on automated scripts: Production cluster data node backup: Obtain the IP addresses and user list of all data nodes in the production cluster, and select a backup node for each shard of data nodes to perform data backup.

[0055] Transfer backup files from the production cluster to the disaster recovery cluster: Obtain the IP addresses and user list of all data nodes in the disaster recovery cluster, and transfer the backup files of each shard in the production cluster to the corresponding data node.

[0056] S502, Restore full data on the target database: This process primarily achieves the following functions and relies entirely on automated scripts: 1) Disaster recovery cluster data node backup and recovery: 1.1 The backup files of the production cluster have been transferred to the disaster recovery cluster. This process will use the backup files to back up and restore all data nodes of the disaster recovery cluster.

[0057] 2) Set data nodes to read-only: Set the disaster recovery cluster data nodes to read-only to prevent background heartbeat detection data from being written, which would affect the establishment of the master-slave relationship.

[0058] S503, configure the disaster recovery synchronization tool provided by the database vendor: This process primarily achieves the following functions and relies entirely on automated scripts: Install the disaster recovery synchronization tool and configure the relevant parameters: Obtain the disaster recovery synchronization tool (drsp) provided by the database vendor, unzip the script package, and obtain all scripts and configuration files, including a configuration file config.ini. Script 3 will modify the parameters in config.ini. Fill in the configuration file according to the specifications.

[0059] Transfer the disaster recovery synchronization script from the production cluster to the disaster recovery cluster: Transfer the disaster recovery synchronization script from the main management node of the production cluster to the main management node of the disaster recovery cluster.

[0060] S504 establishes a disaster recovery synchronization relationship and performs real-time synchronization of incremental data: Disaster recovery cluster enters synchronization mode: Execute the command to switch the disaster recovery cluster to synchronization mode. After entering synchronization mode, it means that the disaster recovery relationship between the original database and the target database has been established, and the target database will automatically synchronize the incremental data of the original database.

[0061] Disaster recovery cluster working mode check: Execute the command to check the working mode of the disaster recovery cluster. The status of sync mode means that the disaster recovery synchronization relationship has been successfully established.

[0062] Specifically, a disaster recovery synchronization relationship is established between the production database and the target database, with the target database serving as the disaster recovery database, and incremental data from the production database is synchronized in real time using a synchronization mode.

[0063] First, back up all data on all data nodes in the production database and transfer the backup data to the corresponding data nodes in the target database. Then, obtain the IP addresses and user lists of all data nodes in the production cluster, select a backup node for each shard's data nodes, and perform data backup. Next, obtain the IP addresses and user lists of all data nodes in the disaster recovery cluster, and transfer the backup files for each shard of the production cluster to the corresponding shard's data nodes.

[0064] Next, restore all data on the target database's data nodes and set the target database's data nodes to read-only mode. Then, use the backup files transferred to the disaster recovery cluster to back up and restore all data nodes in the disaster recovery cluster. Finally, set the disaster recovery cluster's data nodes to read-only mode to prevent background heartbeat detection data from being written, thus avoiding impacting the primary / standby relationship setup.

[0065] Then configure and deploy the disaster recovery synchronization tool to establish a disaster recovery synchronization channel from the production database to the target database. Obtain the disaster recovery synchronization relationship tool drsp provided by the database vendor, unzip the script package, and obtain all scripts and configuration files, including the configuration file config.ini. Modify the parameters in config.ini, fill in the configuration file according to the specifications, and transfer the disaster recovery synchronization relationship script under the production cluster master management node to the disaster recovery master management node.

[0066] Finally, set the target database to synchronous mode and begin synchronizing incremental data from the production database in real time, confirming that the synchronization status is normal. Execute the command to switch the disaster recovery cluster to synchronous mode. Entering synchronous mode signifies the completion of the disaster recovery relationship between the original database and the target database. The target database will automatically synchronize incremental data from the original database. Execute the command to check the disaster recovery cluster's working mode; a status of "sync" indicates that the disaster recovery synchronization relationship has been successfully established.

[0067] The configuration and deployment process of backup data, data recovery, and disaster recovery synchronization tools is executed through automated scripts using shell language, which improves the accuracy and efficiency of the operation.

[0068] Step 2, disaster recovery switchover (business closure required): 1. Pre-switch checks: This process relies on disaster recovery synchronization tools provided by the database vendor and mainly achieves the following functions: 1) Check if the production warehouse is in service mode; 2) Check if the disaster recovery database is in synchronization mode; 3) Check if the disaster recovery database is synchronized normally.

[0069] 2. Disaster preparedness: This process relies on disaster recovery synchronization tools provided by the database vendor and mainly achieves the following functions: 1) Synchronize data from the target database to the original database; 2) The target warehouse receives production transactions.

[0070] 3. Check after switching: After the switch is complete, check the database status of the target database and the original database.

[0071] "Switch forward" refers to the process of switching the disaster recovery repository from synchronization mode to service mode in disaster and emergency scenarios. "Switch back" refers to restoring the production and disaster recovery repositories to their original states, i.e., the production repository is in service mode, providing services to the outside world, while the disaster recovery repository is in synchronization mode, synchronizing data from the production repository.

[0072] Specifically, during the business downtime window, the target database is switched from the disaster recovery database to a new production database to provide services to the public, while the original production database is switched to the disaster recovery database.

[0073] Before disaster recovery failover, perform a mode check to confirm that the production database is in service mode and the target database is in synchronization mode and its synchronization status is normal. Use the disaster recovery synchronization tool provided by GoldenDB database to check whether the production database is in service mode, whether the disaster recovery database is in synchronization mode, and whether the synchronization status of the disaster recovery database is normal.

[0074] The target database is switched to service mode to take over production transactions, while the production database is switched to synchronization mode. Automated disaster recovery failover and checks are performed by calling the disaster recovery synchronization tools provided by GoldenDB, enabling the target database to synchronize data with the original database and take over production transactions.

[0075] After the disaster recovery switchover, a schema check is performed to verify that the target database has become a production database and confirms that its operational status is normal. Once the switchover is complete, the database status of both the target and original databases is checked to ensure the switchover process was successful.

[0076] The third step is disaster recovery and dismantling: This process mainly achieves the following functions: 1. Stop disaster recovery synchronization from the target database to the original database; 2. Stop all nodes in the original database; 3. Build new disaster recovery synchronization relationships for the target database as needed. If necessary, follow the steps in step 1 (Disaster Recovery Setup) to perform the relevant operations.

[0077] Specifically, the disaster recovery synchronization relationship between the target database and the original production database is removed, and the target database operates as an independent production cluster.

[0078] Stop disaster recovery synchronization from the target database to the original database, stop all nodes of the original database, and make the target database run as an independent production cluster.

[0079] For target libraries already running as independent production clusters, establish new disaster recovery synchronization relationships and build corresponding disaster recovery libraries according to preset requirements. Depending on actual needs, the relevant disaster recovery setup work can be performed following the steps in the first step.

[0080] This method achieves data migration through a disaster recovery synchronization mechanism, ensuring that important data in the production environment can be accurately, efficiently, and completely migrated to the target database. At the same time, the use of automated scripts greatly improves the reliability and operational efficiency of the migration process and reduces the risks of manual operation.

[0081] This invention provides a data migration method for GoldenDB database based on disaster recovery setup. Given the current lack of suitable data migration tools for GoldenDB, this invention utilizes a disaster recovery setup method to achieve data synchronization between the source and target databases. The method comprises three steps: disaster recovery setup, disaster recovery switchover, and disaster recovery dismantling. First, disaster recovery setup uses a full backup to transfer the entire data from the source database to the target database. Then, a disaster recovery synchronization relationship is established for real-time, zero-latency incremental data synchronization. Next, a disaster recovery switchover is performed. Since the target database, as the disaster recovery database, can synchronize the latest data from the source database in real time, ensuring data consistency and integrity, the target database's role can be switched during a downtime window, and the target database can then provide services to the outside world as a production database. Finally, the disaster recovery synchronization relationship between the target database and the source database is dismantled.

[0082] Compared with the prior art, this application makes improvements in at least the following aspects: 1. Real-time data synchronization: During the disaster recovery setup process, the method of backup transmission + disaster recovery synchronization is used to achieve one-time transmission of full data and real-time synchronization of incremental data, ensuring real-time, accurate and complete synchronization of data from the original database to the target database.

[0083] 2. Short downtime window: During the disaster recovery switchover process, after real-time data synchronization is achieved based on the disaster recovery setup, the target database can be made available to the outside world through the disaster recovery switchover method. Moreover, the disaster recovery setup process can be carried out online in real time, and business needs to be shut down only during the disaster recovery switchover. The downtime window is expected to be within 30 minutes, which greatly reduces the impact on business.

[0084] In real-world applications, the 24 / 7 operation of banking systems places higher demands on data migration. First, it's crucial to ensure business continuity as much as possible, minimizing downtime to reduce impact and facilitate early business recovery. Second, data integrity must be guaranteed, ensuring no data loss after migration. Third, data consistency must be ensured, guaranteeing data consistency between the new and old databases after migration. While GoldenDB, as a relatively new distributed database product, has limited mature and stable database migration tools available, the increasing number of data center construction projects and hardware / software upgrades necessitates a flexible, efficient, and accurate data migration method to meet the operational needs of various scenarios.

[0085] The data migration method for GoldenDB databases based on disaster recovery in this invention achieves real-time, accurate, and efficient synchronization of data between the source and target databases through full backup and incremental real-time synchronization, ensuring data consistency between the two databases. Furthermore, it utilizes a disaster recovery switchover approach for offline migration, significantly reducing downtime and minimizing the impact on business operations.

[0086] It should be noted that although the operation of the method of the present invention has been described in a specific order in the above embodiments and figures, this does not require or imply that the operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0087] After introducing the method of exemplary embodiments of the present invention, the following references are made. Figure 6 An exemplary embodiment of the GoldenDB database data migration apparatus of the present invention will be described.

[0088] The implementation of the GoldenDB database data migration apparatus can refer to the implementation of the methods described above, and will not be repeated here. The terms "module" or "unit" used below can refer to a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0089] Based on the same inventive concept, this invention also proposes a GoldenDB database data migration device, such as... Figure 6 As shown, this device is applied to a GoldenDB database scenario that includes a production database and a target database to be migrated, including: The disaster recovery setup module 610 is used to establish a disaster recovery synchronization relationship between the production database and the target database, using the target database as the disaster recovery database, and synchronizing the incremental data of the production database in real time in a synchronization mode. The disaster recovery switching module 620 is used to switch the target database from the disaster recovery database to a new production database to provide services to the outside world within the business downtime window, while switching the original production database to the disaster recovery database at the same time. The disaster recovery dismantling module 630 is used to dismantle the disaster recovery synchronization relationship between the target database and the original production database, so that the target database can run as an independent production cluster.

[0090] It should be noted that although several modules of the GoldenDB database data migration apparatus have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of the present invention, the features and functions of two or more modules described above can be embodied in a single module. Conversely, the features and functions of a single module described above can be further divided and embodied by multiple modules.

[0091] Based on the aforementioned inventive concept, such as Figure 7 As shown, the present invention also proposes a computer device 700, including a memory 710, a processor 720, and a computer program 730 stored in the memory 710 and executable on the processor 720. When the processor 720 executes the computer program 730, it implements the aforementioned GoldenDB database data migration method.

[0092] Based on the aforementioned inventive concept, the present invention proposes a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the aforementioned GoldenDB database data migration method.

[0093] Based on the aforementioned inventive concept, this invention proposes a computer program product, which includes a computer program that, when executed by a processor, implements a GoldenDB database data migration method.

[0094] The GoldenDB database data migration method and apparatus proposed in this invention achieve real-time, accurate, and efficient synchronization of data between the source and target databases through full backup and incremental real-time synchronization, ensuring data consistency between the two databases. Furthermore, it utilizes disaster recovery switching for migration during downtime, significantly reducing downtime and minimizing the impact on business operations, providing strong technical support for data migration scenarios.

[0095] The acquisition, storage, use, and processing of data in this application comply with relevant laws and regulations.

[0096] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0097] This invention is described with reference to flowchart illustrations and / or block diagrams of methods and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0098] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0099] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0100] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for migrating data from a GoldenDB database, characterized in that, This method is applied to GoldenDB database scenarios that include both a production database and a target database to be migrated, including: A disaster recovery synchronization relationship is established between the production database and the target database, with the target database serving as the disaster recovery database, and incremental data of the production database is synchronized in real time in a synchronization mode. During the business downtime window, the target database is switched from the disaster recovery database to a new production database to provide services to the outside world, while the original production database is switched to the disaster recovery database. The disaster recovery synchronization relationship between the target database and the original production database is removed, and the target database is operated as an independent production cluster.

2. The method according to claim 1, characterized in that, Establish a disaster recovery synchronization relationship between the production database and the target database, using the target database as the disaster recovery database, and synchronize incremental data of the production database in real time in a synchronization mode, including: Back up all data in all data nodes of the production database and transfer the backup data to the corresponding data node of the target database; Restore the full data on the data node of the target database, and set the data node of the target database to read-only mode; Configure and deploy the disaster recovery synchronization tool to establish a disaster recovery synchronization channel from the production database to the target database; Set the target library to synchronous mode, start synchronizing incremental data from the production library in real time, and confirm that the synchronization status is normal.

3. The method according to claim 2, characterized in that, The process of configuring and deploying backup data, data recovery, and disaster recovery synchronization tools is executed through automated scripts.

4. The method according to claim 1, characterized in that, During the business downtime window, the target database will be switched from a disaster recovery database to a new production database to provide services, while the original production database will be switched to a disaster recovery database, including: Before disaster recovery switchover, perform a mode check to confirm that the production database is in service mode and the target database is in synchronization mode and the synchronization status is normal. Switch the target library to service mode to accept production transactions, and switch the production library to synchronization mode at the same time; After the disaster recovery switchover, a mode check is performed to verify that the target library has become a production library and confirm that its operating status is normal.

5. The method according to claim 4, characterized in that, Switching the target repository to service mode to accept production transactions, and simultaneously switching the production repository to synchronization mode, includes: Automated disaster recovery switching and checks are performed by calling the disaster recovery synchronization tools provided by the GoldenDB database.

6. The method according to claim 1, characterized in that, After dismantling the disaster recovery synchronization relationship between the target database and the original production database, the following is also included: For the target database that is already running as an independent production cluster, a new disaster recovery synchronization relationship is created and a corresponding disaster recovery database is built according to the preset requirements.

7. The method according to claim 1, characterized in that, Both the production database and the target database are GoldenDB distributed database clusters. Each production database or target database includes a management node, a compute node cluster, a data node cluster, and a global transaction management node.

8. A GoldenDB database data migration device, characterized in that, This device is used in GoldenDB database scenarios that include both the production database and the target database to be migrated, including: The disaster recovery setup module is used to establish a disaster recovery synchronization relationship between the production database and the target database, using the target database as the disaster recovery database, and synchronizing the incremental data of the production database in real time in a synchronization mode. The disaster recovery switching module is used to switch the target database from the disaster recovery database to a new production database to provide services during the business downtime window, while simultaneously switching the original production database to the disaster recovery database. The disaster recovery dismantling module is used to dismantle the disaster recovery synchronization relationship between the target database and the original production database, so that the target database can run as an independent production cluster.

9. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method of any one of claims 1 to 7.

11. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 7.

Images