Database migration method and electronic device

Abstract

The application discloses a database migration method and electronic equipment, relates to the technical field of data migration, and is applied to a target system and includes the following steps: synchronizing current inventory data in a source database of the target system to a target database; obtaining a data request routed to the source database of the target system after the synchronization operation as a to-be-replayed data request; obtaining a request interface of the to-be-replayed data request, replaying the to-be-replayed data request in units of the request interface, verifying compatibility of the target database to the request interface, and obtaining a verification result; and switching a request route of the request interface to the target database based on the verification result. The application solves the problems of long downtime and concentrated switching risks in the traditional scheme, realizes sufficient verification and repair of compatibility before switching, significantly reduces the overall risk of database transplantation, and provides reliable support for smooth migration in a high-availability business scenario.

Description

Technical Field

[0001] This application relates to the field of data migration technology, and in particular to a database migration method and electronic device. Background Technology

[0002] With the rapid development of information technology, enterprise applications are increasingly reliant on database systems. As the core data asset production and storage center, database architecture upgrades, version iterations, and platform migrations have become crucial aspects of enterprise digital transformation. Especially in industries such as finance, where data consistency and service continuity are extremely important, the reliability of database migration operations directly affects the stable operation of business systems and customer experience.

[0003] Currently, mainstream database migration solutions typically employ a general process of "downtime-data migration-switchover-service recovery." While this approach is relatively mature at the operational level, its core logic relies on suspending business writes to ensure data consistency. This requires interrupting all or part of business services during the operation, making it difficult to meet the stringent business continuity requirements of enterprises. Furthermore, existing solutions often employ a "one-time overall switchover" strategy, where all business traffic is switched from the source database to the target database at a single moment. If the target database has performance defects or compatibility issues, this will result in the complete unavailability of all services, leading to a highly concentrated risk. Therefore, existing database migration solutions suffer from poor business continuity and concentrated switching risks, making it difficult to meet the smooth migration requirements of high-availability business scenarios.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide a database migration method and electronic device, which aims to solve the technical problems of poor business continuity and concentrated switching risks in existing database migration solutions.

[0006] To achieve the above objectives, this application proposes a database migration method, which is applied to a target system and includes: Synchronize the current existing data in the source database of the target system to the target database; After obtaining the synchronization operation, the data request routed by the target system to the source database is used as a data request to be replayed. Obtain the request interface of the data to be replayed, and replay the data to be replayed in units of the request interface to verify the compatibility of the target database with the request interface and obtain the verification result; Based on the verification results, the request route of the request interface is switched to the target database.

[0007] In one embodiment, the step of receiving the data request routed by the target system to the source database as a data request to be replayed after obtaining the synchronization operation includes: The database driver layer of the target system obtains the data request routed from the target system to the source database, which is used as a candidate replay data request. Obtain the transaction status of the transaction to which the candidate replay data request belongs in the source database; When the transaction status is in progress, the candidate replay data request and the interface identifier of the candidate replay data request are assembled into a replay task and temporarily stored in the replay queue. When the transaction status is committed, the replay task is retrieved from the replay queue as the data request to be replayed.

[0008] In one embodiment, the step of obtaining the request interface for the data to be replayed, replaying the data to be replayed on a per-replay-interface basis to verify the compatibility of the target database with the request interface, and obtaining the verification result includes: The request interface for the data to be replayed is determined based on the interface identifier of the data to be replayed request. All replay tasks belonging to the request interface are retrieved from the replay queue and used as interface replay tasks; The interface replay task is executed in the target database to synchronize incremental data related to the request interface in the source database of the target system to the target database. At the same time, the execution result of the interface replay task is monitored to obtain the verification result of the request interface in the target database.

[0009] In one embodiment, the step of switching the request route of the request interface to the target database based on the verification result includes: In the target system's cache, the data source identifier of the requested interface is updated from the source database to the target database; When a subsequent data request arrives at the request interface, the subsequent data request is routed to the target database according to the data source identifier.

[0010] In one embodiment, after the step of updating the data source identifier of the request interface from the source database to the target database, the method further includes: Retrieve existing replay tasks belonging to the requested interface but not yet executed from the replay queue of the target system; The existing playback task is maintained and continues to execute in the target database.

[0011] In one embodiment, before the step of replaying the data request to be replayed on a per-request-interface basis, the method further includes: Obtain the version number of the playback task corresponding to the request for the data to be played back; Obtain the current version number of the target database; If the version number of the playback task is less than the current version number of the target database, the request for the data to be played back will be terminated.

[0012] In one embodiment, before the step of obtaining the data request routed by the target system to the source database after the synchronization operation as the data request to be replayed, the method further includes: The request interface of the target system is used as the pointcut to construct the aspect, and the request interface of the target system is intercepted through the aspect; Before the method of the request interface is executed, the interface identifier of the request interface is obtained through reflection and the interface identifier is encapsulated into the context container.

[0013] In one embodiment, the step of obtaining the data request routed from the target system to the source database at the database driver layer of the target system as a candidate replay data request includes: Obtain data requests from the target system at the database driver layer of the target system; Obtain the interface identifier of the data request from the context container; Based on the interface identifier, determine whether the request interface has completed the data source switch to the target database; If the request interface fails to complete the data source switch to the target database, it is determined whether the request interface is in a traffic replay state. If the requested interface is in a traffic replay state, then the data request will be used as a candidate replay data request.

[0014] In one embodiment, the step of assembling the candidate replay data request and the interface identifier of the candidate replay data request into a replay task and temporarily storing it in the replay queue includes: The input parameter object of the candidate playback data request is cloned to obtain a cloned object; The cloned object, the candidate replay data request, and the interface identifier of the candidate replay data request are assembled into a replay task and temporarily stored in the replay queue.

[0015] In addition, to achieve the above objectives, this application also proposes an electronic device, the device comprising: a memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the database migration method as described above.

[0016] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and which, when executed by a processor, implements the steps of the database migration method described above.

[0017] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the database migration method described above.

[0018] One or more technical solutions proposed in this application have at least the following technical effects: In this embodiment, data from the source database of the target system is first synchronized to the target database, laying the data foundation for subsequent switching. Then, data requests routed from the target system to the source database after the synchronization operation are acquired as data requests to be replayed. By continuously capturing traffic without interrupting business operations, this replaces the traditional method of downtime migration, ensuring business continuity throughout the migration process. Next, the request interface of the data requests to be replayed is acquired, and the data requests are replayed on a per-interface basis to verify the target database's compatibility with the request interface. Verification results are obtained, and this pre-replay verification mechanism identifies potential problems such as compatibility differences, syntax incompatibility, and data type mismatches in the target database's data requests, eliminating the unknown risk of discovering anomalies only after switching. Finally, based on the verification results, the request routing of the request interface is switched to the target database. Through fine-grained switching control at the interface level, the switching risk is dispersed from full business unavailability to the level of a single or partial interface, achieving effective risk isolation and controllability.

[0019] This embodiment ensures zero business interruption through end-to-end online migration, achieves fine-grained risk control through interface-level switching, and proactively identifies and eliminates compatibility risks through a replay verification mechanism. It not only solves the problems of long downtime and concentrated switching risks in traditional solutions, but also achieves full verification and repair of compatibility before switching, significantly reducing the overall risk of database migration and providing reliable support for smooth migration in high-availability business scenarios. Attached Figure Description

[0020] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

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

[0022] Figure 1 This is a flowchart illustrating an embodiment of the database migration method of this application. Figure 2 This is a schematic diagram of the transaction management of the target system of this application; Figure 3 The context management architecture for this application is designed with aspect-oriented principles in mind. Figure 4 This is a schematic diagram of the traffic replay verification system based on SQL execution interception in this application; Figure 5 This is a schematic diagram illustrating the interface granularity compatibility verification of this application; Figure 6 This is a schematic diagram of incremental synchronization in this application; Figure 7 This is a schematic diagram of the system architecture for the interface-level real-time traffic switching strategy in this application; Figure 8 This is a schematic diagram of the overall switching process for this application; Figure 9 This is a schematic diagram illustrating the specific process of the grayscale phase of this application; Figure 10 This is a schematic diagram of the device structure of the hardware operating environment involved in the database management method in this application embodiment.

[0023] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0024] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0025] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0026] The existing common database migration solution is: (downtime -> data migration -> switch to the new database -> service activation). This solution often impacts business continuity due to downtime. Furthermore, in this common solution, the database switch is a one-time event (either all data is switched to the new database or none is switched at all), making it impossible to verify SQL (Structured Query Language) compatibility beforehand, leading to many unknown risks after the switch. Therefore, the existing database migration method has the following problems: 1. The risk of the entire database becoming unusable after a one-time migration.

[0027] 2. Service interruption during the migration and data transfer process affects business continuity.

[0028] 3. Unable to identify SQL compatibility risks in advance.

[0029] Based on this, the embodiments of this application provide a database migration method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the database migration method of this application.

[0030] In this embodiment, the database migration method is applied to the target system and includes steps S1 to S4: S1: Synchronize the current existing data in the source database of the target system to the target database; It should be noted that the target system is a computer system running business applications, the source database is the source database currently in use by the target system, and the target database is the new database to which the system is to be migrated.

[0031] Additionally, it should be noted that data synchronization refers to the process of copying and transferring existing data from the source database to the target database. Data synchronization can be performed using a full synchronization method, which involves copying all data from the source database to the target database completely at once; or it can be performed using a combination of full and incremental synchronization, where the initial copy of existing data is completed through full synchronization, and then incremental synchronization is used to catch up with continuously generated new data in real time or periodically to the target database.

[0032] As an example, step S1 is initiated Tn days before the official switchover. Its main purpose is to synchronize historical data from the source database up to day T-1 to the target database. This step can be implemented using database migration tools or data synchronization middleware, such as data replication services or open-source data synchronization components. After the data migration is complete, a comparison tool is used to check whether the data volume and MD5 (Message-Digest Algorithm 5) values ​​of the source and target databases are consistent to ensure the integrity and accuracy of data synchronization. If inconsistencies are found, the data in the target database can be deleted and a full synchronization can be re-executed, or incremental synchronization can be used to catch up on the discrepancies. The steps for synchronizing the current existing data in the source database of the target system to the target database include: obtaining the full data in the source database of the target system, synchronizing the full data to the target database to obtain a preliminary synchronized database; comparing the data volume of the source database of the target system with the data volume of the preliminary synchronized database; and comparing the MD5 value of the source database of the target system with the MD5 value of the preliminary synchronized database; if the data volume of the source database of the target system and the data volume of the preliminary synchronized database are the same, and the MD5 value of the source database of the target system and the MD5 value of the preliminary synchronized database are the same, the preliminary synchronized database is used as the target database; otherwise, the data in the source database of the target system is resynchronized, or the preliminary synchronized database is incrementally synchronized to obtain the target database.

[0033] S2: After obtaining the synchronization operation, the data request routed by the target system to the source database is used as a data request to be replayed; It's important to clarify that data requests routed to the source database refer to the database operation requests actually sent by the target system's data access layer to the source database during business processing. These include SQL (Structured Query Language) statements such as query, insert, update, and delete requests. Understandably, throughout the entire database migration process, the target system's business services remain uninterrupted and operational, continuously providing normal business functions to the outside world, thereby ensuring the continuity of the target system's operation and making the migration process seamless for users.

[0034] In one feasible implementation, step S2: After obtaining the synchronization operation, the data request routed by the target system to the source database, as a data request to be replayed, may include steps S21~S24: S21: Obtain the data request routed from the target system to the source database in the database driver layer of the target system as a candidate replay data request; It should be noted that the database driver layer is the lowest level in the target system's data access architecture. It is responsible for converting the data access operations generated by the business layer into specific database communication protocols and sending them to the database server. Traffic capture at this layer can ensure that the acquired data requests are the closest to the original requests executed by the database, containing complete SQL statements and execution parameters. This avoids the distortion of SQL information caused by factors such as lazy loading, caching mechanisms, or dynamic proxies of the ORM (Object Relational Mapping) framework when captured at the business layer. Candidate replay data requests refer to data requests that have been successfully captured by the replay traffic capture device and are awaiting further processing.

[0035] Specifically, the replay traffic acquirer of the target system is used to acquire candidate replay data requests at the database driver layer. The replay traffic acquirer is a traffic capture component built into the target system, which is used to intercept and acquire data requests sent to the source database in real time at the database driver layer.

[0036] In one feasible implementation, after obtaining the synchronization operation in step S2, before the step of routing the data request from the target system to the source database as a data request to be replayed, steps S201-202 are further included: S201: Construct an aspect using the request interface of the target system as a pointcut, and intercept the request interface of the target system through the aspect; It's important to note that a request interface refers to the business function entry point provided by the target system for external invocation. This includes interfaces that provide services to the outside world and interfaces for scheduled tasks. Interfaces that provide services to the outside world handle real-time business requests initiated by external clients or front-ends, such as "create order" or "check balance." Interfaces for scheduled tasks handle batch business operations triggered at predetermined time intervals within the system, such as "daily reconciliation" or "batch payroll disbursement." Whether it's an interface that provides services to the outside world or a scheduled task interface, each request interface corresponds to a specific business function. The interface identifier uniquely distinguishes data requests for different business functions, forming the basis for implementing flow control and replay verification at the interface level.

[0037] Additionally, it's important to note that pointcuts are a core concept in aspect-oriented programming (AOP). They refer to a set of specific join points in the target system that can be intercepted. In this implementation, the pointcut is the method calls of all request interfaces. As an example, a unified pointcut is used to intercept all request interfaces. A unified pointcut means matching all request interfaces with a single pointcut expression, thus avoiding defining a separate pointcut for each interface. Intercepting all request interfaces with a unified pointcut means matching all request interfaces with a single pointcut expression, intercepting method calls of all request interfaces in a unified way, without needing to configure each interface individually, reducing configuration complexity and maintenance costs.

[0038] Specifically, step S201 is implemented using aspect-oriented programming (AOP) technology. The target system implements a context management architecture based on AOP design, defining a unified pointcut through the AOP framework. This unified pointcut matches all request interfaces of the target system to achieve full interception of all interfaces and scheduled tasks. Through this unified pointcut, the system can fully intercept method calls of all request interfaces, that is, trigger unified interception logic before the execution of each request interface's method. It should be noted that the full interception achieved through the unified pointcut is non-intrusive, does not change the structure and logic of the original business code, and newly added request interfaces can be automatically intercepted as long as they meet the matching rules of the pointcut expression without additional configuration, exhibiting good scalability.

[0039] S202: Before the method of the request interface is executed, the interface identifier of the request interface is obtained through reflection mechanism, and the interface identifier is encapsulated into the context container.

[0040] It should be noted that the interface identifier refers to the information used to uniquely identify the request interface, including the interface name and method signature; the interface name refers to the logical name of the request interface in the system, and the method signature refers to the complete signature information of the method corresponding to the request interface, including the method name, parameter type list and return value type; the context container refers to the thread-local variable (ThreadLocal) of the currently executing thread, used to store the context information of the current request, so that this information can be accessed from any position in the same thread throughout the entire life cycle of the request, thereby achieving thread isolation of request-level data.

[0041] Specifically, when the unified pointcut intervenes in a method call of the request interface, before the method execution, the system obtains the Method object of the currently executing method through Java reflection. From the Method object, it extracts the class name, method name, and parameter type list of the method, and combines them according to a predetermined format to generate an interface identifier. The system stores the generated interface identifier in the context container (ThreadLocal) of the currently executing thread, in key-value pairs. The key is a predefined context key name, and the value is the interface identifier string. After the interface identifier is encapsulated in the context container, the system can obtain the interface identifier of the current request through this context container during subsequent processing of the current request (such as requests to retrieve candidate replay data) without explicitly passing it in the parameters of the business method, thus avoiding code intrusion and parameter pollution.

[0042] It is important to note that the interface identifier stored in the context container should be cleared at the end of the request lifecycle of the requested interface. The request lifecycle refers to the complete processing from when the request arrives at the target system to when the response is returned to the client. Clearing the interface identifier stored in the context container ensures the timeliness and isolation of thread-local variables, preventing memory leaks or context crosstalk caused by thread pool reuse. Threads that process requests typically come from a thread pool; a thread is recycled after processing one request and used to process the next. If the data stored in ThreadLocal is not cleared at the end of the request, the thread may incorrectly obtain the interface identifier of the previous request when processing the next request, leading to interface identifier corruption and data security risks.

[0043] For example, refer to Figure 2 In the asynchronous replay to the new database (target database) phase, to ensure that the new database replay can only be executed after the original database (source database) transaction has been successfully executed and committed, the `afterDoCleanup` method is added to the `cleanAfterCompletion` phase in the transaction manager. This method (which indicates the state after the transaction has been committed or rolled back, and the connection to the original execution database has been recycled, allowing us to know whether the transaction has been committed or rolled back) performs traffic replay. This method is triggered after the transaction is committed / rolled back, and the final state of the transaction is determined by the connection pool state, which then decides whether to execute the new database replay. In asynchronous execution scenarios, if the original database transaction has been successfully committed, even if the new database replay fails, it will not affect the consistency of the original database data. This design, through a transaction state-driven replay mechanism, effectively isolates the main business process from the replay process, ensuring system reliability.

[0044] Additionally, it's worth noting that when creating a child thread to execute an asynchronous task, the thread pool decorator passes data from the main thread's context container to the child thread. The thread pool decorator is a component that enhances the native thread pool by automatically capturing the main thread's current context data when a task is submitted to the thread pool and passing it to the child thread. The context data includes at least the interface identifier. A child thread is a thread managed by the thread pool used to execute asynchronous tasks. To achieve context passing in a multi-threaded environment, the system enhances the native thread pool through a custom thread pool adapter. When the main thread submits an asynchronous task, the thread pool decorator automatically captures the main thread's current ThreadLocal data. When creating a child thread to execute the task, the captured context data is copied and bound to the child thread's ThreadLocal, enabling the child thread to obtain the currently requested interface identifier when executing asynchronous tasks. This ensures end-to-end traceability of the API (Application Programming Interface) identifier in asynchronous execution scenarios.

[0045] For example, refer to Figure 3 This module achieves full access to all interfaces and scheduled tasks by defining a unified pointcut. Before method execution, it obtains the API identifier (including interface name and method signature) via reflection, encapsulates it in a ThreadLocal context container, and performs context cleanup at the end of the request lifecycle to ensure the timeliness and isolation of thread-local variables and prevent memory leaks. To enable context passing in a multi-threaded environment, a thread pool decorator mechanism is introduced. A custom thread pool adapter securely passes the ThreadLocal data from the main thread to child threads, ensuring the traceability of API identifiers in asynchronous execution scenarios. This aspect module serves as a fundamental component, providing crucial context support for subsequent traffic switching and traffic replay functions.

[0046] In this embodiment, a unified pointcut is defined to fully intercept all request interfaces. Newly added interfaces can be automatically intercepted without separate configuration, demonstrating good scalability. Before the interface method is executed, the interface identifier is automatically obtained using reflection and encapsulated into a context container (ThreadLocal). This decouples the interface identifier acquisition from the business logic, allowing the interface identifier to be transparently obtained from any position in the same thread throughout the entire lifecycle of the request. Subsequent steps such as data request capture and replay task assembly do not need to be explicitly passed through method parameters, avoiding parameter pollution and ensuring data isolation between threads. This provides crucial API identifier context support for subsequent traffic replay and traffic switching functions.

[0047] In one feasible implementation, step S21: Obtaining the data request routed from the target system to the source database at the database driver layer of the target system, as a candidate replay data request, includes steps S211~S215: S211: Obtain the data request from the target system at the database driver layer of the target system; Specifically, the database driver layer interceptor of the replay traffic acquirer acquires data requests from the target system. The database driver layer interceptor is an interception component embedded in the target system's database driver layer, used to intercept and capture data requests before execution. The data requests acquired by the database driver layer interceptor include data requests routed to the source database and data requests routed to the target database; that is, all data requests sent to the database are captured. The replay traffic acquirer is a traffic capture component built into the target system, with the database driver layer interceptor as its core sub-component, responsible for performing specific data request capture operations. The replay traffic acquirer further filters the data requests acquired by the database driver layer interceptor through steps S212-S215, selecting data requests currently routed to the source database that require replay verification as candidate replay data requests.

[0048] It is worth noting that step S211 is used to capture data requests from the target system in real time and in full at the database driver layer. The database driver layer interceptor is embedded in the target system's database driver layer as an interceptor or listener. When the business layer initiates a database operation, the database driver layer interceptor intercepts the operation before it is sent to the database server via the driver layer, and extracts complete information about the data request from the current request context. This information includes, but is not limited to: the SQL statement type (such as SELECT, INSERT, UPDATE, DELETE), the original SQL statement, the bound parameter values ​​in the parameterized query, and the transaction identifier of the transaction to which the request belongs. It should be noted that the database driver layer interceptor only performs the capture and recording operations of the data request; it does not block or change the execution process of the data request. The captured data request is still sent to the corresponding database for execution normally along the original path, ensuring that the business logic is not affected in any way.

[0049] S212: Obtain the interface identifier of the data request from the context container; It should be noted that the context container refers to the thread-local variable (ThreadLocal) of the currently executing thread, used to store the context information of the current request, including the interface identifier stored in step S202. Retrieving the interface identifier of the data request from the context container means reading the interface identifier string from the current thread's ThreadLocal using a predefined context key name to determine the business interface to which the current data request belongs.

[0050] S213: Based on the interface identifier, determine whether the request interface has completed the data source switch to the target database; It's important to note that data source switching refers to the process of changing the target database for a request interface from the source database to the target database. For request interfaces that have completed data source switching, subsequent data requests will be directly routed to the target database for execution, eliminating the need for replay verification. For request interfaces that haven't completed data source switching, data requests will still be routed to the source database, requiring further determination to determine whether replay verification is necessary. This determination step allows the system to distinguish between switched and non-switched request interfaces, preventing switched requests from still entering the replay process and causing duplicate data execution.

[0051] Specifically, the system queries the configuration cache based on the interface identifier to obtain the current data source switching strategy for the requested interface. The configuration cache stores the data source identifiers (source database or target database) for each requested interface. The system compares the current data source identifier with the target database identifier to determine whether the requested interface has completed the switch. If the data source identifier of the requested interface is now the target database, the system determines that the switch has been completed, terminates the processing flow, and the request is not included in subsequent replay verification. If the data source identifier of the requested interface is still the source database, the system determines that the switch has not been completed, and proceeds to step S214 for further judgment.

[0052] S214: If the request interface has not completed the data source switch to the target database, then determine whether the request interface is in a traffic replay state; It's important to note that traffic replay status refers to the state where a request interface is configured to perform traffic replay verification. For request interfaces in traffic replay status, data requests routed to the source database will be captured and replayed in the target database. For request interfaces not in traffic replay status, data requests, even if routed to the source database, will not be captured or replayed. Traffic replay status and data source switching status are independent, controlling the strategies for "whether to replay" and "whether to switch," respectively. This step excludes requests that do not need replay, avoiding unnecessary capture and storage operations on requests that are not replay targets.

[0053] Specifically, the configuration cache is queried based on the interface identifier to determine whether the request interface is currently in a traffic replay state. If the request interface is in a traffic replay state, step S215 is taken as a candidate replay data request; if the request interface is not in a traffic replay state, the processing flow is terminated and the data request is not replay captured.

[0054] S215: If the request interface is in a traffic replay state, then the data request will be used as a candidate replay data request.

[0055] It should be noted that data requests that pass all the aforementioned judgment steps are identified as candidate replay data requests—that is, the data request is currently routed to the source database, the request interface has not completed the data source switch and is in the traffic replay state. Data requests that meet the above three conditions will be further processed in subsequent steps and finally replayed to the target database for verification.

[0056] For example, refer to Figure 4 The API interface-level SQL traffic replay verification mechanism constructs a traffic replay verification system based on SQL execution interception. It captures the complete execution statement before SQL execution through a database driver layer interceptor. The system first extracts the current API identifier from the ThreadLocal context and executes a two-layer verification logic: first, it determines whether the target API has completed data source switching; if so, it terminates the repetitive processing flow; second, it verifies whether the API is in a traffic replay state; if replay is required, it further determines whether the SQL execution context is at the transaction boundary. For SQL operations within a transaction, the system performs a deep copy of the execution parameter object and serializes it to the replay queue. To ensure the independence of the replay data, the system uses deep cloning technology to copy the structure of the input parameter object, ensuring that the replay process is not affected by changes in the original transaction context. After the original transaction is committed, the replay operation is executed in the target database according to the queue order, ensuring the complete reproduction of the ACID (Atomicity, Consistency, Isolation, Durability) characteristics of the transaction in the new database. It is particularly important to note that the replay of SQL statements within a transaction must strictly follow the execution order of the original transaction. If the SQL is executed asynchronously in a new database, it may lead to the breach of transaction isolation and thus the risk of data inconsistency.

[0057] In this embodiment, by capturing all data requests at the database driver layer and using a three-layer filtering logic in the replay traffic acquirer, it is possible to finely filter out candidate replay data requests that are currently routed to the source database, have not completed the switch, and are in the replay state from all data requests. This avoids the problem of repeated data execution caused by switched requests entering the replay process, and also avoids unnecessary capture and storage of non-replay target requests, saving system resources. At the same time, the judgment order of judging the switch first and then the replay clearly reflects the logical architecture that the switch has a higher priority than the replay, providing a foundation for the subsequent implementation of fine-grained traffic control.

[0058] S22: Obtain the transaction status of the transaction to which the candidate replay data request belongs in the source database; It's important to note that a transaction refers specifically to a database transaction, which is a logical unit consisting of a set of database operations, possessing the characteristics of atomicity, consistency, isolation, and durability. Transaction state refers to the stage a transaction is in during its lifecycle, including at least an in-progress state and a committed state. An in-progress state indicates that the transaction has not yet been committed or rolled back, and the database operations within it are being executed or awaiting execution. A committed state indicates that the transaction has been successfully completed and all changes have been persisted to the database. Obtaining the transaction state of the transaction to which a candidate replay data request belongs is to determine whether the data request belongs to an in-progress transaction and whether that transaction was ultimately successfully committed, thus providing a basis for subsequent replay timing decisions.

[0059] Specifically, the transaction status of the transaction to which the current candidate replay data request belongs is obtained through the transaction synchronization manager of the target system. The transaction synchronization manager is a core component provided by the database transaction management framework, used to trigger corresponding callback notifications at different lifecycle stages of a transaction (such as transaction start, transaction commit, and transaction rollback). The system registers a transaction synchronization listener with the current transaction through the transaction synchronization manager, which can detect changes in the transaction's status in real time. When a candidate replay data request is captured, the system queries the current status of the transaction to which the request belongs through the transaction synchronization manager. If the transaction has not yet been committed or rolled back, the transaction status is in progress; if the transaction has been committed, the transaction status is committed; if the transaction has been rolled back, the transaction status is rolled back.

[0060] S23: When the transaction status is in progress, the candidate replay data request and the interface identifier of the candidate replay data request are assembled into a replay task and temporarily stored in the replay queue. It's important to note that a replay task is an executable unit formed by encapsulating candidate replay data requests and their associated information (including interface identifiers, SQL statements, execution parameters, etc.) for re-execution in the target database. A replay queue is a data structure used to temporarily store replay tasks, supporting a first-in, first-out (FIFO) sequential access method to ensure that replay tasks are processed sequentially according to their original execution order. The reason for assembling candidate replay data requests with an ongoing transaction status into replay tasks and temporarily storing them in the replay queue, rather than immediately executing the replay, is that the transaction to which the request belongs has not yet been committed, and its data changes have not yet taken effect. If the replay were immediately executed in the target database at this point, and the original transaction were eventually rolled back, it would result in dirty data in the target database.

[0061] Specifically, the target system processes each candidate replay data request within an ongoing transaction as follows: First, it extracts the interface identifier from the current request context. This identifier identifies the request interface to which the data request belongs, providing a basis for subsequent replay control at the interface level. Then, it encapsulates the candidate replay data request, its corresponding interface identifier, SQL statement, execution parameters, and other information into a replay task object. Finally, it temporarily stores this replay task object in the replay queue according to the capture time order. It should be noted that multiple candidate replay data requests within the same transaction are queued sequentially according to their execution order within the original transaction to ensure that the original transaction's operation order can be restored during replay. For multiple requests within the same transaction, they are arranged consecutively in the replay queue, and their order strictly matches the original execution order.

[0062] In a feasible implementation, step S23, which assembles the candidate replay data request and the interface identifier of the candidate replay data request into a replay task and temporarily stores it in the replay queue, includes steps S231 to S232: S231: Clone the input parameter object of the candidate playback data request to obtain a cloned object; It's important to note that the input parameter object refers to the parameter object that the SQL statement corresponding to the candidate replay data request depends on during execution, including information such as the bound parameter values ​​and parameter types in the SQL statement. Cloning refers to creating an independent copy of the input parameter object. This copy has its own independent storage space in memory, and its content is completely identical to the original input parameter object. However, any modification to the cloned object will not affect the original input parameter object. Through the cloning operation, the replay task carries an independent copy of the input parameter object, rather than a reference to the original object, thus ensuring that the replay process is not affected by changes in the source database transaction context.

[0063] S232: Assemble the cloned object, the candidate replay data request, and the interface identifier of the candidate replay data request into a replay task and temporarily store it in the replay queue.

[0064] It's important to note that a replay task is an executable unit used to perform replay in the target database. It contains all the information required for replay, including at least: the cloned input parameter object (ensuring data independence), the original SQL statement (the database operation to be replayed), the interface identifier (used for replay control at the interface level), and the version number (to prevent old data from overwriting new data). Assembling the cloned object, candidate replay data requests, and interface identifier into a replay task means encapsulating this information into a complete task object so that it can be retrieved and executed as needed in subsequent steps. Temporarily storing it in the replay queue means storing the assembled replay task in the replay queue, waiting for the transaction to be committed before being retrieved and executed by the replay execution engine.

[0065] In this embodiment, by performing a deep clone of the input parameter object of the candidate replay data request, the replay task carries an independent copy of the input parameter object instead of the original reference. Any modification to the cloned object during replay will not affect the transaction context being executed in the source database, thus achieving complete isolation between the replay data and the source database transaction context. At the same time, the cloned object, the candidate replay data request, and the interface identifier are assembled into a replay task and temporarily stored in the replay queue. This ensures that the replay task contains all the information required to execute the replay, providing a complete data foundation for subsequent interface-level replay, asynchronous execution after transaction commit, and version verification. Furthermore, since the enqueue operation occurs during the transaction rather than after the transaction commit, it does not affect the normal execution flow of the source database transaction, ensuring the efficient operation of the main business.

[0066] S24: When the transaction status is committed, the replay task is retrieved from the replay queue as the data request to be replayed.

[0067] It's important to note that a committed transaction status indicates that the transaction has been successfully executed in the source database and all data changes have been persisted. At this point, all data operations within the transaction are effective and will not be rolled back. Therefore, only after the transaction has been confirmed as committed should the corresponding replay task be removed from the replay queue and executed in the target database to ensure data consistency between the target and source databases. If the transaction is eventually rolled back, the corresponding replay task should be removed from the replay queue and not replayed.

[0068] Specifically, the target system senses the final execution status of a transaction through a transaction synchronization listener: when a transaction is successfully committed, the transaction synchronization listener is triggered, and the target system retrieves all replay tasks corresponding to that transaction from the replay queue as data requests to be replayed, for subsequent execution in the target database; when a transaction is rolled back, the transaction synchronization listener is also triggered, and the target system removes all replay tasks corresponding to that transaction from the replay queue, preventing replay. It should be noted that step S24 retrieves the replay tasks only after the transaction has been committed, ensuring the sequential relationship between the replay operation and the original transaction commit—that is, commit first, then replay—thus ensuring that even if an exception occurs during replay, the correctness of the committed transaction data in the source database is not affected. Furthermore, once a replay task is retrieved from the replay queue, the task is cleared from the queue, preventing the same task from being retrieved and executed repeatedly.

[0069] For example, refer to Figure 5First, the traffic replay interceptor (replay traffic acquirer) performs syntax recognition to obtain information such as the SQL type, original SQL, and SQL parameters. If the SQL is within a transaction, the system assembles it into a replay task and temporarily stores it in the replay queue. After the transaction ends, tasks are retrieved from the queue one by one for replay. The task is only retrieved from the queue and replayed after the old database transaction is successfully executed and committed. Failure to execute the replay on the new database will not affect the committed transactions on the old database. During this stage, SQL compatibility can be continuously monitored for any SQL incompatibility errors on the new database. If any problems are found, intervention can be carried out to fix them.

[0070] In this embodiment, by capturing all data requests at the database driver layer and combining this with filtering logic that extracts interface identifiers, determines whether a data source switch has been completed, and determines whether a traffic replay state is in progress, a refined filtering of candidate replay data requests that are currently routed to the source database, have not completed a switch, and are in a replay state is achieved. This avoids the problem of duplicate data execution caused by switched requests entering the replay process, and also avoids unnecessary capture and storage of non-replay target requests. Simultaneously, by obtaining the transaction status of the transaction to which the candidate replay data request belongs in the source database, the corresponding replay task is only retrieved from the replay queue when the transaction status is committed. For data requests awaiting replay, it is ensured that replay operations are only executed after the source database transaction is confirmed and committed, avoiding the problem of dirty data in the target database due to the rollback of the source database transaction. By temporarily storing candidate replay data requests in the process of a transaction into a replay queue according to the capture order, and retrieving and executing them in the queue order after the transaction is committed, it is ensured that multiple data operations within the same transaction strictly follow the original execution order during replay, fully preserving the ACID properties of the source database transaction. Thus, while ensuring business continuity, transaction-level data consistency between the target database and the source database is achieved, laying a reliable data foundation for subsequent interface-level replay verification.

[0071] S3: Obtain the request interface of the data to be replayed, and replay the data to be replayed in units of the request interface to verify the compatibility of the target database with the request interface and obtain the verification result; It should be noted that, in terms of the requested interface, replaying the data request to be replayed refers to re-executing the data request to be replayed in the target database using a single interface or scheduled task of the target system as the smallest control unit, rather than replaying all interface requests in a batch. Compatibility refers to the degree of compatibility support and correct execution of the data request to be replayed in the target database, including at least: SQL syntax compatibility, data type matching, correctness of stored procedures and functions, atomicity of transaction processing, and accuracy of returned results.

[0072] Specifically, before the formal switchover, a pre-verification of the target database using real business traffic is performed to identify and fix compatibility issues in advance. This includes the following sub-steps: First, extract the interface identifier of the data request to be replayed, and determine the interface to which the data request belongs based on this identifier; then, retrieve all data requests belonging to the same interface from the replay queue and organize them into interface replay tasks according to the execution order of the original transactions; finally, execute the interface replay task in the target database, re-executing the SQL statements corresponding to the data request to be replayed on the target database. During execution, the system monitors and records the execution result of each SQL statement in real time, including execution success, execution exception, and differences in returned data; simultaneously, this step can also synchronize the incremental data corresponding to the data request to be replayed to the target database, ensuring that the data state of the target database remains ultimately consistent with the source database. If compatibility errors or abnormal execution results occur during replay, operations personnel can locate and fix the problem (such as adjusting SQL syntax, modifying data type mappings, etc.). After the fix is ​​completed, the replay verification can be re-executed until it is confirmed that there are no compatibility issues.

[0073] Additionally, it should be noted that after step S3, which involves replaying the data request to be replayed on a per-request-interface basis, it also includes performing a data consistency check between the target database and the source database. If the check results are inconsistent, incremental data synchronization is performed and the check steps are repeated until consistency is achieved. It is understandable that, due to the time difference between the preparation phase of step S1 and the gray-scale phases of steps S2 and S3, only the existing data prior to day T-1 is synchronized upon completion of the preparation phase. New data generated from day T-1 to the present has not yet been synchronized to the target database. Therefore, incremental synchronization is required after traffic replay is enabled to synchronize the incremental data within the time difference between the two phases to the target database.

[0074] For example, refer to Figure 6 After enabling traffic replay, since the data synchronized during the preparation phase is not comprehensive, incremental synchronization is required to incrementally synchronize the data within the time difference between the two phases. After synchronization, a comparison is performed. If inconsistencies are found, the incremental synchronization steps are repeated until the data is consistent. That is, a data consistency check is performed between the target database and the database in use. If the check results are inconsistent, incremental data synchronization is performed and the check steps are repeated until consistency is achieved.

[0075] In one feasible implementation, step S3: obtaining the request interface of the data request to be replayed, and replaying the data request to be replayed in units of the request interface to verify the compatibility of the target database with the request interface, and obtaining the verification result includes steps S31~S33: S31: Determine the request interface for the data to be replayed based on the interface identifier of the data to be replayed request; It should be noted that the interface identifier is a unique identifier for the requested interface, containing the interface name and method signature. Data requests to be replayed are data requests retrieved from the replay queue and prepared for replay in the target database. Each data request to be replayed carries a corresponding interface identifier. Determining the requested interface based on the interface identifier of the data request to be replayed means identifying the business interface to which the data request belongs by reading the interface identifier field carried in the data request, thereby providing a basis for subsequent replay control at the interface granularity.

[0076] Specifically, the target system reads the interface identifier field from the data request to be replayed (this field is written during the assembly of the replay task in step S23), and determines the request interface to which the data request belongs based on the interface name in the interface identifier. Through this step, the system can identify the business interface to which each data request to be replayed belongs, laying the foundation for subsequent organization of replay tasks at the interface granularity.

[0077] S32: Obtain all replay tasks belonging to the request interface from the replay queue, and use them as interface replay tasks; It should be noted that an interface replay task refers to the collection of all replay tasks belonging to the same request interface. Since the replay queue temporarily stores multiple replay tasks from different request interfaces (such as the replay task for the "Create Order" interface, the replay task for the "Query Balance" interface, etc.), when replaying at the interface level, it is necessary to filter out all replay tasks belonging to the same request interface from the replay queue, aggregate them into an interface replay task, and then execute them uniformly to achieve fine-grained replay control at the interface level.

[0078] Additionally, it should be noted that replay tasks belonging to the same request interface in the replay queue may come from different transactions. The system organizes these replay tasks according to the order of transaction commits to ensure that the replay execution order is consistent with the transaction commit order in the source database.

[0079] S33: Execute the interface replay task in the target database to synchronize the incremental data related to the request interface in the source database of the target system to the target database, and monitor the execution result of the interface replay task to obtain the verification result of the request interface in the target database.

[0080] It should be noted that executing the interface replay task refers to re-executing the SQL statements corresponding to each replay task on the target database sequentially. The verification result refers to the target database's feedback on its processing capabilities for each data request during the interface replay task execution, including at least: whether the SQL statements executed successfully, whether compatibility errors occurred (such as syntax errors, missing functions, data type mismatches, etc.), whether the returned result set matches expectations, and whether transaction processing was normal. By monitoring the execution results, the system can assess the target database's business processing support capabilities for specific request interfaces, providing a basis for subsequent traffic switching decisions.

[0081] Specifically, the target system re-executes each replay task in the interface replay task sequentially in the target database according to its original execution order in the source database. During execution, the target system monitors and records the execution results of each SQL statement in real time, including information such as execution success, execution exception, and differences in returned data. Simultaneously, the system persists the data changes generated by the replay execution to the target database, ensuring that the target database continuously synchronizes incremental data related to the request interface from the source database. If a compatibility error occurs during replay (such as the target database not supporting specific SQL syntax, functions, or data types in the source database), the system immediately captures the exception, records the error details, and generates a compatibility report. Operations personnel can use this report to locate and repair the problem (such as adjusting SQL syntax, modifying data type mappings, replacing incompatible functions, etc.). After repair, the replay verification of the request interface is re-executed until no compatibility issues are confirmed. If all replays are successful and the execution results meet expectations, it confirms that the target database has complete processing capabilities for the data requests of the request interface. The request interface passes verification and can proceed to the subsequent traffic switching steps.

[0082] In this embodiment, the request interface to which the requested data belongs is determined based on the interface identifier of the data to be replayed. All replay tasks belonging to the same request interface are retrieved from the replay queue and aggregated into an interface replay task. This enables the organization and execution of replay tasks at the interface level, making the replay verification scope precise to the individual interface level. The replay verification of different interfaces is isolated from each other and does not affect each other, effectively avoiding the shortcomings of difficult problem localization and large fault impact in the global batch replay mode. By executing the interface replay task in the target database, the incremental data related to the request interface in the source database is synchronized to the target database. At the same time, the execution results are monitored in real time and verification results are generated. Potential problems such as SQL compatibility differences, syntax incompatibility, and data type mismatch are identified and located in advance before the formal switch. This provides a time window for repair work and avoids the risk of business interruption caused by discovering compatibility problems only after the switch is completed in traditional solutions. This provides a reliable decision basis for subsequent traffic switching at the interface level.

[0083] In one feasible implementation, step S3, which involves replaying the data request to be replayed on a per-request-interface basis, further includes steps S301 to S303: S301: Obtain the version number of the playback task corresponding to the request for the data to be played back; It should be noted that the version number is a monotonically increasing identifier used to identify the sequence of data updates. Each replay task is assigned a version number when it is assembled and queued. This version number reflects the execution sequence of the data request corresponding to the replay task in the source database. The version number can be a sequence number generated based on a timestamp, or an increasing sequence number assigned by a globally unique ID generation service, as long as it can uniquely identify the order in which data changes occur. The version number of the replay task is written to the replay task object when the replay task is assembled in step S23, and is temporarily stored in the replay queue along with the replay task.

[0084] S302: Obtain the current version number of the target database; It should be noted that the current version number of the target database refers to the latest version identifier corresponding to the current data in the target database. This version number is updated with each change to the data in the target database. Each time the target database completes a replay task and modifies the data, the current version number of the target database is updated to the version number of that replay task. The current version number of the target database can be stored in a dedicated version information table within the target database, or it can be stored in a distributed cache, with the system reading and writing through a unified version manager.

[0085] S303: If the version number of the playback task is less than the current version number of the target database, then the request for the data to be played back is terminated.

[0086] It's important to note that if the version number of the replay task is less than the current version number of the target database, it means that the data changes corresponding to this replay task are earlier in time than the latest data changes already executed in the target database. Continuing to execute the replay task would cause old data to overwrite new data, resulting in data rollback and compromising data consistency. Therefore, when the system detects that the version number of the replay task is less than the current version number of the target database, it should terminate the execution of the data replay request and discard the replay task to prevent data anomalies.

[0087] As an example, the specific implementation of version number verification is as follows: When the target system generates a replay task, it stores the current version number as a task attribute in the replay task object. When executing the replay task, the system appends the version number of the replay task to the SQL statement to be executed as a comment or conditional parameter. When the target database executes the SQL statement, if it detects that the version number carried in the SQL statement is less than the current version number of the target database, it refuses to execute the SQL statement and returns a version expiration error message.

[0088] For example, refer to Figure 7 The system employs AOP (Aspect-Oriented Programming) to implement API-level data source routing control for real-time traffic switching at the interface level. At the interface entry point, the data source switching strategy is retrieved through configuration caching, dynamically adjusting the data source route. Because the judgment and switching occur at the AOP level rather than the database level, this operation does not affect currently executing requests, ensuring isolation. To ensure data source consistency for asynchronous threads, the thread pool decorator must pass the data source switching instruction to the child thread. After the switch is complete, the data source context must be synchronously cleared to prevent residual state from affecting subsequent operations. A cache refresh mechanism enables rapid application of data source configuration, ensuring the atomicity of data source switching at the interface layer. Finally, to ensure eventual consistency between the old and new databases, the system injects a version number verification mechanism before SQL execution: when the new database version number is detected to be greater than the replay version number, the execution of the SQL is automatically terminated to prevent data anomalies caused by version overwriting.

[0089] In this embodiment, a version number is assigned to the replay task when it is enqueued, and the version number of the replay task is compared with the current version number of the target database before the replay is executed. The replay is only executed if the version number of the replay task is not less than the current version number of the target database. This effectively avoids the problem of old version data overwriting new version data due to task backlog or network latency. It ensures the data integrity and consistency of the target database from the data version level and prevents the occurrence of data rollback anomalies.

[0090] S4: Based on the verification result, switch the request route of the request interface to the target database.

[0091] It's important to note that request routing switching refers to changing the target database address of a data request from the original source database to the target database. Subsequent new data requests for this interface will be automatically sent to the target database for execution. "Interface-based" means that the smallest unit of the switching operation is a single interface or scheduled task, not the entire database or all business traffic.

[0092] As an example, AOP aspects are used to dynamically control data source routing at the entry point of the request interface. Specifically: First, based on the verification results, the data source identifier corresponding to the verified request interface is updated from the source database to the target database in the configuration center or management terminal. Then, the configuration center pushes the updated configuration to each application node of the target system, and each node loads the updated configuration into its local cache. When subsequent data requests arrive at this interface, the forwarding traffic interceptor routes the request directly to the target database based on the data source identifier in the local cache, thus achieving seamless switching. It should be noted that after the switch is completed, subsequent data requests from the switched interface are directly routed to the target database by the forwarding traffic interceptor and do not enter the replay capture process in step S2, thereby avoiding the data duplication problem caused by the same traffic being replayed repeatedly. At the same time, existing replay tasks that have been stored in the replay queue but have not yet been executed continue to be executed without being forcibly interrupted, to ensure data consistency at the moment of switching.

[0093] In one feasible implementation, step S4: based on the verification result, switching the request route of the request interface to the target database includes steps S41-42: S41: In the cache of the target system, update the data source identifier of the requested interface from the source database to the target database; It's important to note that caching refers to a distributed or local cache within the target system used to store configuration information. This cache stores the data source identifiers for each request interface, allowing the forwarding traffic interceptor to query them in real-time. The data source identifier is configuration information used to uniquely identify a database instance, and includes at least a source database identifier and a target database identifier. Updating the data source identifier for a request interface from the source database to the target database involves modifying the data source identifier configuration item in the cache corresponding to that request interface, thus issuing a switching command. This operation does not involve application restarts or service interruptions.

[0094] Specifically, after confirming that the target database has full processing capabilities for the target request interface, the data source identifier corresponding to the target request interface is updated from the source database to the target database in the configuration center or management terminal. The configuration center pushes the updated configuration to each application node of the target system, and each application node loads the updated configuration into its local cache. It should be noted that the cache update operation is atomic, meaning that the data source identifier is either the source database or the target database, with no intermediate state, ensuring the consistency of the switching decision. Furthermore, the cache update takes effect immediately, and subsequent data requests will be automatically routed according to the new data source identifier.

[0095] S42: When a subsequent data request arrives at the request interface, the subsequent data request is routed to the target database according to the data source identifier.

[0096] It's important to note that the forwarding traffic interceptor is a routing interception component built into the target system. It dynamically determines the target database for data requests at the request interface entry point based on the data source identifier in the configuration cache. The forwarding traffic interceptor and the replay traffic acquirer are two independent components. The forwarding traffic interceptor operates at the request interface entry layer (AOP layer) and is responsible for routing decisions; the replay traffic acquirer operates at the database driver layer and is responsible for traffic capture. The forwarding traffic interceptor dynamically routes data requests to the corresponding database by querying the data source identifier of the target request interface in the cache. The forwarding traffic interceptor has a higher priority than the replay traffic acquirer. That is, a data request first undergoes routing judgment by the forwarding traffic interceptor. If the request interface has already completed data source switching, the request is directly routed to the target database and does not enter the capture and replay process of the replay traffic acquirer, thus avoiding data duplication or errors caused by the same traffic being replayed repeatedly after a switch.

[0097] Specifically, when a subsequent data request arrives at the target request interface, the forwarding traffic interceptor intercepts the request at the request entry point, obtains the interface identifier of the current request, and queries the corresponding data source identifier in the local cache based on the interface identifier. If the data source identifier is the target database, the forwarding traffic interceptor routes the database connection of the data request to the target database, allowing the request to be executed on the target database. If the data source identifier is still the source database, the forwarding traffic interceptor routes the request to the source database. It should be noted that the forwarding traffic interceptor only applies to new requests following requests to request interfaces that have already completed cache updates. For existing requests that entered the system and are being processed before the cache update, they continue to be executed according to the original route and are not affected by the switching operation, thus ensuring the integrity of requests already processed during the switching process.

[0098] Additionally, it's important to note that the data source context must be cleared synchronously after the switch is complete to prevent residual state from affecting subsequent operations. The data source context refers to the data source routing instructions stored in the currently executing thread. These instructions may still remain in the thread-local variables of the current thread after the cache update is completed in step S41. If this residual state is not cleared, the same thread may incorrectly reuse these data source routing instructions when processing other requests, leading to routing errors.

[0099] In this embodiment, by updating the data source identifier corresponding to the request interface from the source database to the target database in the target system's cache, and by using a configuration push mechanism to make the updated configuration take effect quickly in the local cache of each application node, the switching command is issued and takes effect in milliseconds, and the switching operation does not require restarting the application or interrupting the service. By setting a forwarding traffic interceptor at the entry point of the request interface, subsequent data requests are dynamically routed according to the data source identifier corresponding to the interface in the cache, and the switching control is precise to the level of a single interface, realizing fine-grained traffic switching at the interface level and avoiding the risk of full service unavailability caused by global switching.

[0100] In one feasible implementation, after step S4: updating the data source identifier of the request interface from the source database to the target database, steps S51-S52 are further included: S51: Obtain existing replay tasks belonging to the requested interface but not yet executed from the replay queue of the target system; It should be noted that existing replay tasks refer to replay tasks that have been stored in the replay queue before the data source identifier is updated, but have not yet been retrieved and executed. The replay queue is a data structure that operates independently of the switchover process. Its enqueue operation is completed in step S23 (temporarily stored during the transaction), and its dequeue operation is completed in step S24 (retrieved after the transaction is committed). Since the enqueueing and dequeueing of replay tasks are executed asynchronously and in parallel with the switchover operation, at the moment the switchover is completed, there may still be replay tasks belonging to the request interface in the replay queue that have not yet been retrieved and executed. These tasks are the existing replay tasks.

[0101] S52: Maintain the continued execution of the existing playback task in the target database.

[0102] It's important to note that maintaining the continued execution of existing replay tasks means not interrupting or clearing them, but allowing them to flow normally into the execution phase according to their original queuing order and complete the replay in the target database. This step is used to ensure data consistency during the switchover and avoid data loss or inconsistency issues caused by forcibly interrupting replay tasks.

[0103] In this embodiment, after the data source identifier is updated, existing replay tasks belonging to the request interface but not yet executed are retrieved from the replay queue, and the execution of these existing replay tasks continues in the target database without forced interruption. This avoids the risk of data loss or inconsistency caused by interrupting replay tasks. At the same time, after the cache is updated, new data requests are directly routed to the target database by the forwarding traffic interceptor. Existing replay tasks that were queued before the switch continue to be replayed on the target database. Both new requests and existing replay tasks are executed with the target database as the target, avoiding the data splitting problem caused by parallel writing to the new and old databases after the traffic switch. This achieves a smooth data transition and consistency guarantee at the moment of switch.

[0104] To help understand the database migration method in this embodiment, please refer to... Figure 8 The overall switching process in this embodiment is divided into three stages: preparation stage, gray-scale stage, and formal stage. Traffic playback and switching are controlled at the API level, thereby achieving a smooth switching and personalized migration process.

[0105] 1. Preparation Phase: Data Migration. The preparation phase takes place Tn days before the official switchover. Its main purpose is to synchronize data from the old database up to day T-1 to the new database, laying the foundation for the subsequent switchover. After the data migration is complete, a comparison tool is used to check whether the data volume and MD5 values ​​of the old and new databases are consistent. If inconsistencies are found, consider deleting the data in the new database and resynchronizing, or using incremental synchronization. Because the application remains running during this phase, inconsistencies may occur between the old and new databases during synchronization; these issues will be addressed during the gray-scale rollout phase.

[0106] 2. Gray-scale phase, traffic replay verification. This phase involves gray-scale verification steps, refer to... Figure 9 First, the traffic replay interceptor performs syntax recognition to obtain information such as the SQL type, original SQL, and SQL parameters. If the SQL is within a transaction, the system assembles it into a replay task and temporarily stores it in the replay queue. After the transaction ends, tasks are retrieved from the queue one by one for replay. The task is only retrieved from the queue and replayed after the old database transaction is successfully executed and committed. Failure to execute the replay on the new database will not affect the committed transactions on the old database. During this stage, SQL compatibility can be continuously monitored for any SQL incompatibility errors on the new database. If any problems are found, intervention can be carried out to fix them.

[0107] 3. During the formal phase, traffic switching is performed. The forwarding interceptor operates on an API-based basis (both interfaces and scheduled tasks are APIs). By refreshing the configuration cache, newly arriving API traffic is directly switched to the new database. Furthermore, the forwarding interceptor has higher priority than the traffic replay interceptor; after the switch, no new traffic replay tasks are accepted, preventing data issues caused by repeated replays of the same traffic. Before traffic replay, the provided version number is appended to the executed SQL conditions. If the version number is lower than the new database version number during traffic replay, the replay will not be executed. After the traffic switch, any unfinished existing replay tasks will continue to execute without being forcibly interrupted. Through this mechanism, a smooth transition for traffic switching is achieved.

[0108] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the database migration method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0109] This application provides an electronic device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the database migration method in Embodiment 1 above.

[0110] The following is for reference. Figure 10 The diagram illustrates a structural schematic of an electronic device suitable for implementing embodiments of this application. The electronic devices in these embodiments may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 10 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0111] like Figure 10As shown, the electronic device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the electronic device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. The communication device 1009 allows the electronic device to communicate wirelessly or wiredly with other devices to exchange data. Although the diagrams show electronic devices with various systems, it should be understood that it is not required to implement or have all of the systems shown. More or fewer systems may be implemented alternatively.

[0112] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0113] The electronic device provided in this application, employing the database migration method described in the above embodiments, can solve the technical problems of poor business continuity and concentrated switching risks in existing database migration solutions. Compared with the prior art, the beneficial effects of the electronic device provided in this application are the same as those of the database migration method provided in the above embodiments, and other technical features of the electronic device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0114] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0115] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0116] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A database migration method, characterized in that, Applied to the target system, the database migration method includes: Synchronize the current existing data in the source database of the target system to the target database; After obtaining the synchronization operation, the data request routed by the target system to the source database is used as a data request to be replayed. Obtain the request interface of the data to be replayed, and replay the data to be replayed in units of the request interface to verify the compatibility of the target database with the request interface and obtain the verification result; Based on the verification results, the request route of the request interface is switched to the target database.

2. The database migration method as described in claim 1, characterized in that, The step of receiving the synchronization operation and routing the data request from the target system to the source database as a data request to be replayed includes: The database driver layer of the target system obtains the data request routed from the target system to the source database, which is used as a candidate replay data request. Obtain the transaction status of the transaction to which the candidate replay data request belongs in the source database; When the transaction status is in progress, the candidate replay data request and the interface identifier of the candidate replay data request are assembled into a replay task and temporarily stored in the replay queue. When the transaction status is committed, the replay task is retrieved from the replay queue as the data request to be replayed.

3. The database migration method as described in claim 2, characterized in that, The steps of obtaining the request interface for the data to be replayed, replaying the data to be replayed on a per-replay basis to verify the compatibility of the target database with the request interface, and obtaining the verification result include: The request interface for the data to be replayed is determined based on the interface identifier of the data to be replayed request. All replay tasks belonging to the request interface are retrieved from the replay queue and used as interface replay tasks; The interface replay task is executed in the target database to synchronize incremental data related to the request interface in the source database of the target system to the target database. At the same time, the execution result of the interface replay task is monitored to obtain the verification result of the request interface in the target database.

4. The database migration method as described in claim 1, characterized in that, The step of switching the request route of the request interface to the target database based on the verification result includes: In the target system's cache, the data source identifier of the requested interface is updated from the source database to the target database; When a subsequent data request arrives at the request interface, the subsequent data request is routed to the target database according to the data source identifier.

5. The database migration method as described in claim 4, characterized in that, The step of updating the data source identifier of the request interface from the source database to the target database further includes: Retrieve existing replay tasks belonging to the requested interface but not yet executed from the replay queue of the target system; The existing playback task is maintained and continues to execute in the target database.

6. The database migration method as described in claim 1, characterized in that, Before the step of replaying the data request to be replayed on a per-request-interface basis, the method further includes: Obtain the version number of the playback task corresponding to the request for the data to be played back; Obtain the current version number of the target database; If the version number of the playback task is less than the current version number of the target database, the request for the data to be played back will be terminated.

7. The database migration method as described in claim 2, characterized in that, Before the step of receiving the synchronization operation and routing the data request from the target system to the source database as a data request to be replayed, the method further includes: The request interface of the target system is used as the pointcut to construct the aspect, and the request interface of the target system is intercepted through the aspect; Before the method of the request interface is executed, the interface identifier of the request interface is obtained through reflection and the interface identifier is encapsulated into the context container.

8. The database migration method as described in claim 7, characterized in that, The step of obtaining the data request routed from the target system to the source database at the database driver layer of the target system as a candidate replay data request includes: Obtain data requests from the target system at the database driver layer of the target system; Obtain the interface identifier of the data request from the context container; Based on the interface identifier, determine whether the request interface has completed the data source switch to the target database; If the request interface fails to complete the data source switch to the target database, it is determined whether the request interface is in a traffic replay state. If the requested interface is in a traffic replay state, then the data request will be used as a candidate replay data request.

9. The database migration method as described in claim 7, characterized in that, The step of assembling the candidate replay data request and the interface identifier of the candidate replay data request into a replay task and temporarily storing it in the replay queue includes: The input parameter object of the candidate playback data request is cloned to obtain a cloned object; The cloned object, the candidate replay data request, and the interface identifier of the candidate replay data request are assembled into a replay task and temporarily stored in the replay queue.

10. An electronic device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the database migration method as described in any one of claims 1 to 9.

Images