Distributed database system migration method and device supporting active transaction online migration

Abstract

The invention provides a distributed database system migration method and device supporting online migration of active transactions. The method and device are suitable for a distributed database to complete dynamic migration of fragmented or tenant-level data and transactions under the condition that services are not interrupted. The method comprises the following steps: generating a consistency snapshot of a source node and transmitting the consistency snapshot to a target node; capturing an incremental transaction log after snapshot in real time; a log is efficiently synchronized to a target node through a remote direct memory access (RDMA) mechanism; the logs are played back in parallel at the target node to construct a complete data state; identifying active transactions in the source node and migrating their context; the target node continues to execute the transaction until submission is completed; and finally updating system routing information to complete migration takeover. According to the method, migration delay is effectively reduced, online transaction migration is realized, and the method has the advantages of high availability, low overhead, high adaptability and the like, and is suitable for database scenes such as elastic capacity expansion and contraction, load balancing and the like.

Description

Technical Field

[0001] The present invention relates to the technical field of database systems, and in particular to a distributed database system migration method that supports online migration of active transactions. Specifically, the method is an online migration solution that combines a remote direct memory access (RDMA) mechanism to achieve efficient data migration and transaction state takeover without interrupting services. Background Art

[0002] With the rapid development of cloud computing and distributed systems, distributed databases have become critical infrastructure supporting multi-tenant services, high-availability systems, and elastic resource scheduling. In multi-tenant environments, user workloads fluctuate frequently. To ensure system performance and resource utilization, database systems must be able to dynamically scale up and down, enabling shard-level online data migration and load rebalancing based on tenant resource requirements. Migrating data from source nodes to target nodes without interrupting online transactions is a key challenge in designing elastic database architectures.

[0003] Existing online migration technologies are mainly categorized into pull and push methods. Pull-based migration, exemplified by Zephyr, relies on preemptively switching data ownership to the target node, which then pulls missing data from the source node on demand. This approach ensures complete transaction execution, but because data loss detection and remote pull processes occur within the transaction execution path, communication delays can accumulate, significantly increasing transaction response times in hotspot access scenarios or long transactions. Furthermore, as the amount of data being migrated increases, the overall migration process also significantly lengthens. Some research attempts to leverage deterministic database architectures to achieve transaction-consistent migration through a predefined transaction execution order. However, this approach places high demands on the database system's execution model, making it difficult to broadly adapt to existing database products.

[0004] Push-based migration first completes the batch transfer of data snapshots and incremental data, and then performs the migration of active transactions and data ownership switching, which is suitable for more general database system architectures. Although push-based migration has good engineering practicality and can shorten the system response delay during the migration period, there are still challenges in handling the migration of active transactions and the consistent transfer of hot data. Existing research often uses short downtime in exchange for instantaneous transfer of ownership between source and target nodes to meet the external consistency requirements of distributed systems. Recent studies have attempted to achieve non-interruption migration of active transactions, but due to the use of optimistic transaction migration, frequent transaction rollbacks have occurred, and the migration success rate is extremely low, especially in long transaction scenarios.

[0005] Furthermore, current mainstream log replication and data synchronization still mostly utilize TCP-based communication protocols, which face issues such as frequent kernel context switches, high data copying costs, and large transmission latency fluctuations, becoming performance bottlenecks in online migration systems. To address this issue, the introduction of RDMA (Remote Direct Memory Access) technology can significantly improve log transmission efficiency. RDMA supports user-mode remote memory write operations and offers "zero copy, high throughput, and low latency," making it particularly well-suited for the frequent, small-grained, yet highly concurrent data push tasks required for log synchronization. Therefore, integrating RDMA into the log synchronization mechanism within database migration and establishing an efficient and stable migration infrastructure communication channel has become a key area for improving online migration performance. Summary of the Invention

[0006] The present invention aims to provide a distributed database system migration method and apparatus that supports online migration of active transactions. Specifically, the method involves efficiently migrating sharded or tenant-level data and active transactions from a source node to a target node in a distributed database without interrupting normal database service. The method, incorporating Remote Direct Memory Access (RDMA) technology, ensures high availability, low latency, and transaction integrity throughout the migration process by constructing consistent snapshots, capturing incremental logs in real time, rapidly transmitting log data, and performing high-performance log replay and active transaction context takeover at the target node. This method is particularly suitable for distributed database systems such as cloud databases and multi-tenant platforms that have high real-time requirements for dynamic load balancing and elastic scaling, significantly improving service continuity and performance stability during the migration process.

[0007] The specific technical solution for achieving the purpose of the present invention is:

[0008] A distributed database system migration method supporting online migration of active transactions, the method comprising the following specific steps: Step 1: when a migration task is initiated, a data snapshot of a target shard is constructed from a source node, and the snapshot is asynchronously transmitted to a target node;

[0009] Step 2: While transmitting the snapshot, the source node captures the incremental transaction logs submitted after the snapshot in real time; Step 3: The source node writes the captured incremental transaction logs directly to the log buffer preset by the target node through remote direct memory access (RDMA); Step 4: The target node parses and replays the received logs to ensure that the data state of the target node is consistent with that of the source node; Step 5: When it is determined that the data difference between the source node and the target node is less than the preset threshold, the active transaction migration process is triggered, the context information of the active transaction is transferred to the target node and continued to execute; Step 6: After the target node completes the transaction takeover, the global routing information is updated to redirect new request traffic to the target node.

[0010] Furthermore, the step 1 specifically includes:

[0011] Without blocking the source node's transaction execution, a snapshot page is generated through the Copy-on-Write mechanism. The snapshot page is encapsulated into a transmittable data unit at the page granularity. The snapshot data is compressed and sent to the target node's receiving buffer using an asynchronous thread and written to disk.

[0012] Furthermore, step 2 specifically includes: monitoring the commit operation of the source node's write-ahead log (WAL) buffer; immediately copying the log record to the log synchronization queue after the log is written to the buffer; encapsulating the log in the synchronization queue into batch data blocks, and initiating the log synchronization operation after the transmission trigger condition is met.

[0013] Furthermore, step 3 specifically includes: establishing an RDMA Queue Pair (QP) connection between the source node and the target node; writing the encapsulated log batch data blocks into the target node memory area through an RDMA Write operation; and confirming the completion of the transmission through signal notification or polling after the writing is completed.

[0014] Furthermore, step 4 specifically includes: pre-registering a log receiving buffer at the target node and continuously polling the log writing status; extracting the arrived log data and inserting it into the to-be-replayed queue in log order; concurrently executing log replay operations in a multi-threaded manner to restore transaction execution operations; and ensuring the consistency of operation order based on transaction boundaries, timestamps, or version numbers in the log.

[0015] Furthermore, in step 5, when it is determined that the data difference between the source node and the target node is less than a preset threshold, the active transaction migration process is triggered, which specifically includes: the source node extracts the execution context of the active transaction, including the current SQL, target table, execution plan, and lock status information; prioritizes the transactions based on their execution time and status to form a transaction transfer queue;

[0016] The transaction context is transferred to the target node according to the transfer queue, and the target node resumes and continues execution;

[0017] After the target node completes the transaction, it collaborates with the source node through the two-phase commit protocol to complete the transaction commit.

[0018] Furthermore, step 6 specifically includes: the migration controller broadcasts the latest routing mapping metadata to the database cluster so that subsequent requests are routed to the target node; the source node releases the data and resources corresponding to the migrated shards, completing the entire migration process.

[0019] A distributed database system migration device based on the above method includes:

[0020] The snapshot building module is used to generate a data snapshot of a specified shard in the source node during the initial migration phase and transfer it to the target node.

[0021] The incremental log collection module is used to capture all incremental log information after the snapshot based on the submission log monitoring mechanism;

[0022] RDMA transport module, used to achieve high-speed, non-interrupted data synchronization of logs through RDMA channels;

[0023] The log replay module is used to parse logs and replay them to the target node through multi-threading to achieve data state consistency;

[0024] The transaction takeover module is used to capture and migrate the context information of active transactions on the source node and continue execution on the target node;

[0025] The routing switching module is used to complete the redirection and resource release of global transaction routing.

[0026] The beneficial effects of the present invention include:

[0027] The proposed database system migration method, which supports online transaction migration and efficient log replication, achieves efficient migration of data and active transactions in distributed systems while ensuring uninterrupted database service. This method offers significant technical advantages and practical engineering value. By introducing a dual-track synchronization mechanism of consistent snapshots and incremental logs, the target node can quickly catch up with the data state of the source node, significantly shortening the migration window. Combined with Remote Direct Memory Access (RDMA) technology, it enables high-speed, "zero-copy" transmission of log data, significantly reducing network latency and resource overhead compared to traditional TCP protocols. Regarding transaction processing, the method supports context migration and state recovery for active transactions, avoiding the frequent transaction aborts and restarts associated with traditional methods. This method is particularly suitable for long or concurrently transaction-intensive scenarios. Furthermore, the method utilizes a unified migration control module to coordinate the scheduling of various phases, including snapshot creation, log synchronization, transaction takeover, and routing switching, demonstrating excellent phase-awareness and scheduling capabilities. The overall solution is platform-independent and adaptable to a variety of mainstream distributed database systems. It is suitable for a variety of typical application scenarios, including elastic scaling, load balancing, and node failover, demonstrating promising promotional value and industrial deployment prospects. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 It is a schematic flow chart of the method of the present invention;

[0029] Figure 2 This is a schematic diagram of an embodiment of the present invention;

[0030] Figure 3 It is a schematic diagram of the structure of the device of the present invention. DETAILED DESCRIPTION

[0031] The present invention is further described in detail with reference to the following specific examples and accompanying drawings. The processes, conditions, experimental methods, etc. for implementing the present invention, except for those specifically mentioned below, are common knowledge and common common sense in the art and are not particularly limited by the present invention.

[0032] See Figure 1The present invention provides a distributed database system migration method that supports online migration of active transactions, including: when a migration task is initiated, building a data snapshot of a target shard from a source node, and asynchronously transmitting the snapshot to a target node; while transmitting the snapshot, the source node captures in real time the incremental transaction log submitted after the snapshot; the source node directly writes the captured incremental log into a log buffer preset by the target node through remote direct memory access (RDMA); the target node parses and replays the received log to ensure that the data state of the target node is consistent with that of the source node; when it is determined that the data difference between the source node and the target node is less than a preset threshold, triggering the active transaction migration process, transmitting the context information of the active transaction to the target node and continuing execution; after the target node completes the transaction takeover, updating the global routing information and redirecting the relevant request traffic to the target node.

[0033] The specific steps are as follows:

[0034] A1: Initiate a migration task and create a snapshot data copy;

[0035] A11: After the migration controller issues the migration instruction, the source node constructs a snapshot of the target data range based on the predefined sharding or partitioning, and records the timestamp when the snapshot was generated as the start timestamp to generate a consistent static data view; A12: The snapshot is written to the transmission buffer asynchronously and sent to the target node. The target node writes the received snapshot data into the local data file to construct the initial copy.

[0036] A2: Capturing and Preparing Incremental Logs A21: After the snapshot is built, the source node starts the incremental log capture process and monitors the submitted log records based on the Write-Ahead Logging (WAL) mechanism in the database system. A22: The logs are written to the log capture buffer pool in the order in which they were submitted and packaged into log synchronization units according to the transaction dimension.

[0037] A3: RDMA-based log synchronization mechanism A31: Establish an RDMA QueuePair (QP) communication channel between the source node and the target node, and the target node pre-registers the log receiving buffer; A32: When the number or time threshold of log synchronization units is met, the source node triggers an RDMA write operation and writes the log directly to the target node's memory area, achieving "zero-copy" transmission; A33: The target node detects the arrival of logs through polling and completes log arrival confirmation.

[0038] A4: Parallel replay of logs is aligned with data status. A41: The target node parses the received logs into a specific operation sequence and reconstructs transaction operations based on transaction boundaries, key values, timestamps, and other information in the logs. A42: Log replay is performed in a multi-threaded parallel manner to ensure concurrent execution of different transactions while maintaining a consistent order of operations for the same data item. A43: The system monitors the data status differences between the source and target nodes. When the data version gap narrows to a safe threshold, it is determined to be in a takeover state.

[0039] A5: Active Transaction State Transfer and Takeover Execution A51: When the source node is in the takeover state, it captures the execution content of the active transaction that is still in progress, such as the database and table information saved in the thread context, the current transaction execution duration, the current SQL statement, and the executed physical execution plan in the cache.

[0040] A52: Transaction transfer priorities are sorted based on transaction execution duration and execution status (blocked or active) to form a transaction transfer queue. A53: The context of each transaction in the transaction transfer queue is transferred to the target node through the transaction transfer controller. The target node restores the transaction status and maintains synchronization between the two parties through the relationship between the distributed transaction coordinator and participants, while continuously receiving operations from the source node. A54: After the target node completes the transaction execution, it collaborates with the source node to complete the two-phase commit process to ensure transaction atomicity and consistency.

[0041] A6: Routing information switching and migration completed. A61: After the transaction takeover is completed, the migration controller broadcasts the latest routing mapping information metadata to the database cluster, minimizing the impact of metadata modifications on cluster services and allowing subsequent requests to be routed directly to the target node. A62: The source node releases the corresponding data and resources, completing the entire migration process.

[0042] See Figure 3 , a database online migration device supporting the above method, the device comprising:

[0043] The snapshot building module is used to generate a data snapshot of a specified shard in the source node during the initial migration phase and transfer it to the target node.

[0044] The incremental log collection module is used to capture all incremental log information after the snapshot based on the submission log monitoring mechanism;

[0045] RDMA transport module, used to achieve high-speed, non-interrupted data synchronization of logs through RDMA channels;

[0046] The log replay module is used to parse logs and replay them to the target node through multi-threading to achieve data state consistency;

[0047] The transaction takeover module is used to capture and migrate the context information of active transactions on the source node and continue execution on the target node;

[0048] The routing switching module is used to complete the redirection and resource release of global transaction routing.

[0049] Example

[0050] See Figure 2 The distributed database system migration method supporting online migration of active transactions involved in this embodiment includes the following steps:

[0051] Step 101: Initiate a migration task and generate a source node snapshot. When the database system detects a continuous increase in tenant load, intensive access to hotspot shards, or the emergence of node resource bottlenecks or fault warnings, the migration controller in the system automatically triggers the migration task. The migration controller first locates the data shards or tenant instances to be migrated and issues a migration instruction to the source node.

[0052] The source node constructs a snapshot based on the specified data range. This snapshot construction uses the MVCC (Multi-Version Concurrency Control) mechanism for Copy On Write. This allows the creation of a consistent data view and the recording of the timestamp Tstart when snapshot generation begins, without interrupting current read and write transactions. Snapshot data is typically copied in page units and compressed and transmitted to the target node using an asynchronous thread. After receiving the snapshot data, the target node persists it, laying the data foundation for subsequent log playback. At this stage, the snapshot construction and transmission process must be decoupled from the database scheduling mechanism to avoid affecting the normal service performance of the source node. The snapshot start timestamp must also be recorded for boundary control during subsequent log capture.

[0053] Step 102: Real-time capture of incremental logs. During the snapshot transmission process, to ensure data timeliness, the source node monitors the database log module in real time, capturing incremental transaction logs generated since the snapshot start point. The system uses the database's write-ahead logging mechanism to implement streaming log reading.

[0054] Each log record contains metadata such as the transaction ID, operation type (e.g., insert, update, delete), target table and primary key value, data version number, and timestamp. Log capture methods append logs to a dedicated memory buffer and logically segment them by transaction boundaries or number of log entries, providing a well-organized structure for subsequent transmission and playback. Furthermore, log capture methods must ensure log sequential consistency and handle the asynchrony between log storage and replication to prevent log loss or duplicate playback.

[0055] Step 103: Push incremental logs via RDMA. To accelerate log synchronization and reduce resource overhead on source nodes, the system uses RDMA (Remote Direct Memory Access) technology to implement an efficient log transmission mechanism. RDMA bypasses the kernel protocol stack, enabling direct user-mode access to remote memory. Its zero-copy and low-latency features make it particularly suitable for frequent, small-volume log synchronization.

[0056] During the migration initialization phase, a ReliableConnection (RC) mode Queue Pair is established between the source and target nodes via RDMA. The target node pre-registers a log receive buffer. Log transfer is initiated by the source node when the log buffer meets the batch threshold or timeout threshold. Log blocks are written directly to the target node's memory address using RDMA Write operations, avoiding intermediate copies and protocol stack processing.

[0057] After the transfer is completed, the source node sends a completion signal through the sideband channel, or the target node actively detects the write mark through polling to synchronize the log transfer status.

[0058] Step 104: Parallel log playback at the target node. After the logs arrive at the target node, the log processing module parses, sorts, and replays them. To improve log replay throughput, the system utilizes a multi-threaded parallel playback architecture, partitioning tasks based on transaction granularity. Each thread can independently process log sequences for one or more transactions.

[0059] The replay process needs to address the following key points: replay in the order of transaction submission to maintain consistency; support conflict detection to avoid concurrent writes to the same key value; under the support of multi-version mechanisms (such as MVCC), log replay can be executed in parallel to improve efficiency; log replay must be decoupled from the local transaction scheduling mechanism of the target node to avoid interference with normal requests.

[0060] During the replay process, the target node continuously maintains its local data state and compares it with the source node's version synchronization progress. When the system detects that the version difference between the two has converged to a specified safety threshold, it enters the transaction takeover preparation phase.

[0061] Step 105: Perform active transaction context migration and execution takeover. When data state synchronization is essentially complete, the system begins executing active transaction context migration and takeover operations. The source node first identifies all uncommitted active transactions, including long transactions, complex update transactions, or transactions containing multiple statements. The system extracts the execution context of each active transaction, including: a list of executed and unexecuted statements; the transaction's lock acquisition status (row lock / table lock) and lock holding time; the current cursor position and cache variables; the transaction ID, timestamp, and concurrency control metadata. Based on the transaction execution duration, the source transaction transfer order can be sorted, allowing long transactions to be executed first, avoiding conflicts with new transactions routed to the target after route switching and resulting in execution failures. Based on the transaction execution status (whether locks were acquired), transactions with overlapping read-write sets can be postponed on the target to avoid deadlocks and transaction rollbacks.

[0062] The above context is transmitted to the target node via an internal control channel. After loading the transaction context, the target node locally restores the transaction state and resumes execution from the point of interruption. To ensure atomicity and consistency, the migration process uses a two-phase commit protocol to collaboratively commit transactions on the target and source nodes. In the prepare phase, the source node sends a prepare request to the target node, which confirms successful execution and returns. In the commit phase, the source node sends a commit request to the target node, which then returns. The source node then completes the collaborative commit, ensuring transaction consistency.

[0063] Step 106: Complete routing switch and resource release. Once all active transactions have successfully completed the takeover and the system has no historical transactions dependent on the source node, the migration controller issues routing update instructions to the entire database cluster. The system updates the global tenant or shard routing table so that subsequent client requests are automatically routed to the target node.

[0064] To avoid request traversal and performance impacts, the source node closes the old routing channel and releases data resources, including local caches, indexes, and locked tables. Temporary migration space is reclaimed, marking the official completion of the migration process. The entire process is invisible to external users and does not affect normal transaction submission, ensuring highly available, consistent, and scalable online migration capabilities.

[0065] See Figure 3The present invention relates to a structure diagram of a distributed database system migration device that supports online migration of active transactions, comprising the following six modules: a snapshot construction module, an incremental log collection module, an RDMA transmission module, a log replay module, a transaction takeover module, and a routing switching module. The snapshot construction module is used to generate a consistent snapshot of a specified data range of a source node and asynchronously transmit it to a target node without affecting online services; the incremental log collection module is used to capture new transaction logs in real time during snapshot construction and organize them into transferable log units; the RDMA transmission module is used to synchronize log data to the target node buffer with zero copy based on remote direct memory access technology; the log replay module is used to execute log replay operations in parallel on the target node through multiple threads to quickly rebuild the data status; the transaction takeover module is used to extract the active transaction execution context of the source node and resume execution and complete submission on the target node; the routing switching module is used to update the global request route and release the source node resources after the migration is completed, thus completing the online migration closed loop.

[0066] The method provided by this invention is particularly suitable for scenarios such as multi-tenant platforms, elastic scaling, and load balancing. This method combines RDMA to improve data transmission efficiency, avoiding system bottlenecks caused by traditional TCP. It also supports transparent migration of transaction contexts, effectively improving database system performance stability and transaction success rates during the migration process.

[0067] The protection scope of the present invention is not limited to the above-mentioned specific embodiments. Any equivalent modifications, replacements and improvements made within the spirit and essential principles of the present invention should be included in the protection scope of the present invention, and the specific details shall be subject to the appended claims.

Claims

1. A distributed database system migration method that supports online migration of active transactions, characterized in that: The method comprises the following specific steps: Step 1: When the migration task is initiated, a data snapshot of the target shard is constructed from the source node and asynchronously transferred to the target node. Step 2: While transmitting the snapshot, the source node captures the incremental transaction logs submitted after the snapshot in real time; Step 3: The source node directly writes the captured incremental transaction log into the log buffer preset by the target node through remote memory direct access; Step 4: The target node parses and replays the received logs to ensure that the data status of the target node is consistent with that of the source node; Step 5: When it is determined that the data difference between the source node and the target node is less than the preset threshold, the active transaction migration process is triggered, the context information of the active transaction is transferred to the target node, and execution continues; Step 6: After the target node completes transaction takeover, the global routing information is updated to redirect new request traffic to the target node.

2. The distributed database system migration method according to claim 1, characterized in that: The step 1 specifically includes: Generate snapshot pages through the Copy-on-Write mechanism without blocking transaction execution on the source node; Encapsulating the snapshot page into a transmittable data unit according to page granularity; The snapshot data is compressed and sent to the receiving buffer of the target node using an asynchronous thread and written to the disk.

3. The distributed database system migration method according to claim 1, characterized in that: The step 2 specifically includes: Monitor the commit operation of the source node's write-ahead log buffer; After the log is written to the buffer, the log record is immediately copied to the log synchronization queue; Encapsulate the logs in the synchronization queue into batch data blocks, and initiate the log synchronization operation after the transmission trigger conditions are met.

4. The distributed database system migration method according to claim 1, characterized in that: The step 3 specifically includes: Establish an RDMA Queue Pair connection between the source node and the target node; Write the encapsulated log batch data blocks to the target node memory area through the RDMA Write operation; After writing is completed, the transfer is confirmed to be complete through signal notification or polling.

5. The distributed database system migration method according to claim 1, characterized in that: The step 4 specifically includes: Pre-register the log receiving buffer on the target node and continuously poll the log writing status; Extract the arrived log data and insert it into the queue for playback in log order; Execute log playback operations concurrently through multiple threads to restore transaction execution operations; Ensures sequential consistency of operations based on transaction boundaries, timestamps, or version numbers in the log.

6. The distributed database system migration method according to claim 1, characterized in that: In step 5, when it is determined that the data difference between the source node and the target node is less than a preset threshold, the active transaction migration process is triggered, which specifically includes: The source node extracts the execution context of the active transaction, including the current SQL, target table, execution plan, and lock status information; Prioritize transactions based on their execution time and status to form a transaction transfer queue; The transaction context is transferred to the target node according to the transfer queue, and the target node resumes and continues execution; After the target node completes the transaction, it collaborates with the source node through the two-phase commit protocol to complete the transaction commit.

7. The distributed database system migration method according to claim 1, characterized in that: The step 6 specifically includes: The migration controller broadcasts the latest routing mapping metadata to the database cluster so that subsequent requests are routed to the target node; The source node releases the data and resources corresponding to the migrated shards, completing the entire migration process.

8. A distributed database system migration device based on the method of claim 1, characterized in that: include: The snapshot building module is used to generate a data snapshot of a specified shard in the source node during the initial migration phase and transfer it to the target node. The incremental log collection module is used to capture all incremental log information after the snapshot based on the submission log monitoring mechanism; RDMA transport module, used to achieve high-speed, non-interrupted data synchronization of logs through RDMA channels; The log replay module is used to parse logs and replay them to the target node through multi-threading to achieve data state consistency; The transaction takeover module is used to capture and migrate the context information of active transactions on the source node and continue execution on the target node; The routing switching module is used to complete the redirection and resource release of global transaction routing.

Images