A client database incremental migration method

Abstract

The application relates to the technical field of database migration, and discloses a client database incremental migration method, which comprises the following steps: acquiring client database incremental data, determining a version mark by using a version control algorithm after capturing and block processing, and extracting a migration data block set; performing synchronous processing such as merging, conflict detection and redundancy cleaning on the migration data block set to generate a marked migration data block matrix; extracting migration characteristic parameters, calculating a migration priority after optimizing the synchronous parameters, determining main migration parameters, training a migration decision model to obtain a classifier, and outputting a migration execution result. The method effectively improves the efficiency and data consistency of incremental migration, reduces resource consumption, and is suitable for efficient incremental migration of a client database.

Description

Technical Field

[0001] This invention relates to the field of database migration technology, specifically to a method for incremental migration of client-side databases. Background Technology

[0002] In today's era of rapid information technology development, with the continuous expansion of data scale and the constant changes in business needs, client database migration has become a crucial task in the field of data management. Traditional database migration methods typically employ a full migration approach, meaning that the entire database is retransmitted and restored for each migration. However, this method has several significant drawbacks when dealing with large-scale data.

[0003] A full migration requires the transfer of a large amount of data, which consumes significant network bandwidth. In unstable network environments or with limited bandwidth, the migration process can become extremely slow or even interrupted, severely impacting business continuity. For example, for a client database with tens of gigabytes or even larger amounts of data, a full migration could take hours or even days to complete. During this time, related business systems may need to stop operating, resulting in substantial economic losses and a decline in user experience for the enterprise.

[0004] A full migration also places a significant burden on system resources. During the migration process, the servers hosting the source and target databases need to perform a large number of data read and write operations. This can cause a sharp increase in the utilization of server resources such as CPU and memory, potentially affecting the performance of other running business systems and even causing server failures.

[0005] Full migration cannot effectively handle incremental data. In practical applications, database data is constantly being updated and changing, especially in actively managed systems where incremental data is generated very rapidly. If a full migration method is used, all data needs to be reprocessed for each migration, wasting time and resources and potentially leading to data inconsistencies. For example, if new data is updated in the source database during the migration process, and the full migration fails to capture this incremental data in time, inconsistencies will arise between the target database and the source database, impacting normal business operations.

[0006] To address the problems of traditional full migration methods, incremental migration technology has emerged. Incremental migration only migrates incremental data that has changed in the database, thus significantly reducing data transfer volume and system resource consumption. However, existing incremental migration technologies still face some challenges in practical applications. Efficiently capturing and processing incremental data is a key issue. Different database management systems may use different methods to record data changes, making incremental data capture complex and diverse. Furthermore, incremental data may have version conflicts, complex dependencies, and other issues, requiring effective methods for detection and handling to ensure the accuracy and consistency of the migrated data. Determining the priority of migrated data and optimizing migration strategies is also a challenge. During incremental migration, different data blocks may have different characteristics such as importance, size, and version span. The migration order and method need to be determined based on these characteristics to improve migration efficiency and success rate. Existing migration strategies often lack comprehensive consideration of these characteristics, leading to low migration efficiency and even migration failures.

[0007] Therefore, there is an urgent need for an efficient and reliable incremental migration method for client databases that can effectively capture and process incremental data, resolve data conflicts and dependencies, rationally determine migration priorities, and improve migration efficiency and data consistency to meet the needs of modern data management. Summary of the Invention

[0008] The purpose of this invention is to provide a method for incremental migration of client databases to solve the problems mentioned in the background art.

[0009] To achieve the above objectives, the present invention provides the following technical solution: a method for incremental migration of a client database, the method comprising:

[0010] S1. Obtain incremental data from the client database, generate a set of incremental data to be processed, extract the data blocks to be migrated using the incremental data capture method, obtain the set of incremental data after data segmentation, determine the version identifier of the set of incremental data after segmentation using the version control algorithm, locate and extract the migration data blocks, and obtain the set of migration data blocks.

[0011] S2. Perform data synchronization processing on the set of migration data blocks to obtain a synchronized set of migration data blocks, then generate a synchronized migration data block matrix, set the data block association relationship, mark the migration data blocks, and obtain a marked migration data block matrix.

[0012] S3. Extract the migration feature parameters of the marked migration data block matrix, optimize the synchronization parameters in the feature parameters, calculate the migration priority, determine the main migration parameters according to the migration priority, train the migration decision model using the main migration parameters to obtain the migration decision classifier, output the migration execution results, and realize the incremental migration of the client database.

[0013] Preferably, step S1 includes the following steps:

[0014] S11. Obtain incremental data from the client database, generate a set of incremental data to be processed, and use the incremental data capture method to extract the data blocks to be migrated, thus obtaining a set of data blocks to be migrated.

[0015] S12. The set of data blocks to be migrated is divided by data block processing to obtain the incremental data set after block division.

[0016] S13. Use a version control algorithm to determine the final version identifier of the incremental data set after partitioning;

[0017] S14. Extract migration data blocks using the final version identifier to obtain a migration data block set.

[0018] Preferably, step S13 includes the following steps:

[0019] S131. Calculate the modification time and data block hash value of each data block in the incremental data set after block division to obtain the data block normalization weight; divide the version range according to the data block normalization weight to generate a candidate version identifier set;

[0020] S132. Calculate the time interval of the candidate version identifiers in the candidate version identifier set, merge the candidate version identifiers with the same time interval, and determine the final version identifier of the incremental data set after block division.

[0021] Preferably, step S2 includes the following steps:

[0022] S21. Perform data block merging, conflict detection and redundancy cleanup on the migration data block set to complete the data synchronization process and obtain the synchronized migration data block set.

[0023] S22. Based on the synchronized migration data block set, generate a synchronized migration data block matrix, and use the data block association relationship to perform migration marking on the synchronized migration data block matrix to obtain the marked migration data block matrix.

[0024] Preferably, the step of using data block associations to perform migration marking on the synchronized migration data block matrix includes:

[0025] Mark the associated data block of the first data block in the upper left corner of the synchronized migration data block matrix, generate a migration sequence number, traverse the data block association relationship to the right, update the migration sequence number, until the upper right corner of the synchronized migration data block matrix is ​​reached, and then traverse the entire migration data block matrix in sequence to complete the migration marking.

[0026] Preferably, step S3 includes the following steps:

[0027] S31. Use principal component analysis algorithm to extract migration feature parameters of the labeled migration data block matrix, and use genetic algorithm to optimize the synchronization parameters in the feature parameters to obtain a set of migration feature parameters;

[0028] S32. Calculate the priority weights of the migration feature parameter set and determine the main migration parameters, which include data block size parameters, version span parameters, and dependency parameters.

[0029] S33. Train the migration decision model to obtain the migration decision classifier. Input the data block size parameter, version span parameter, and dependency parameter into the migration decision classifier and output the migration execution result.

[0030] Preferably, the optimization of the synchronization parameter in the feature parameters using a genetic algorithm includes:

[0031] The fitness function is set as a linear combination of synchronization parameters. The k-th individual in the genetic population moves along the parameter space. The mutation probability is set as p. When the individual encounters the parameter boundary during the movement, if the random number r∈[0,1] is greater than p, the mutation direction is positive; otherwise, it is negative. The fitness value is calculated after the individual's position is updated. When the current iteration number reaches the maximum iteration number, the optimization stops and the optimal synchronization parameters are output.

[0032] Preferably, step S33 includes the following steps:

[0033] S331. Obtain new incremental data from the client database, extract new data block size parameters, version span parameters, and dependency parameters to form a new migration sample set, divide the new migration sample set into a migration test set and a migration verification set, set the input node of the migration decision model to 3 and the output node to 1, input the migration test set into the migration decision model, iterate to the maximum number of times and then stop to obtain the trained migration decision model.

[0034] S332. Input the transfer validation set into the trained transfer decision model. If the model error is less than the preset threshold, it is determined to be a transfer decision classifier; otherwise, adjust the model parameters until the error meets the requirements.

[0035] Preferably, the collision detection process in S21 includes the following steps:

[0036] S211. Traverse the synchronized migration data block set, identify data blocks with overlapping versions or dependency conflicts, and generate a list of conflicting data blocks.

[0037] S212. Prioritize conflicting data blocks based on version span parameters, retain data blocks with smaller version spans first, and mark the migration data block matrix after conflict resolution.

[0038] Preferably, the migration marking step further includes:

[0039] A migration dependency graph is generated based on the data block relationships. If a circular dependency structure is detected, the dependency link is forcibly disconnected based on the version span parameter, and the location of the broken link is recorded in the migration log for subsequent manual review.

[0040] Compared with the prior art, the beneficial effects of the present invention are:

[0041] In terms of data processing efficiency, this method accurately extracts the data blocks to be migrated through incremental data capture technology, avoiding full processing of the entire database. Compared to traditional full migrations that require processing massive amounts of unchanged data, this method only operates on incremental data, significantly reducing the amount of data processing. For example, in scenarios with frequent data updates, each migration only needs to process a small number of changed data blocks, reducing migration time to a fraction of that of traditional methods, or even less, greatly improving migration efficiency, reducing system downtime, and ensuring business continuity. Simultaneously, the data block processing technology divides the data to be migrated into reasonable data blocks, and combines this with version control algorithms to determine the version identifier of each data block, enabling the migration process to proceed in an orderly and efficient manner. Through operations such as version range partitioning and candidate version identifier merging, the method can accurately track version changes of data blocks, avoiding migration errors caused by version confusion and ensuring that the latest and most accurate data version is migrated.

[0042] In terms of data consistency and reliability assurance, the conflict detection and redundancy cleanup mechanism in the data synchronization process plays a crucial role. By traversing the synchronized set of migrated data blocks, it can promptly identify data blocks with overlapping versions or dependency conflicts, and prioritize them based on the version span parameter, retaining data blocks with smaller version spans first. This effectively resolves data conflict issues and ensures that the migrated data remains consistent with the source data. For example, in scenarios where multiple clients simultaneously update the same data block, this mechanism can accurately determine data priority, preventing data inconsistencies. Furthermore, the migration dependency graph generated during the migration marking process clearly shows the dependencies between data blocks. When a circular dependency structure is detected, the dependency link is forcibly broken based on the version span parameter, and the break point is recorded. This not only resolves dependency conflicts but also provides a basis for subsequent manual review, further improving the reliability of data migration.

[0043] In intelligent decision-making and optimization, the application of principal component analysis (PCA) and genetic algorithms makes the extraction and optimization of transfer feature parameters more scientific and efficient. PCA can extract key transfer feature parameters from complex transfer data, reducing data dimensionality while retaining essential information and lowering model complexity. Genetic algorithms, as intelligent optimization algorithms, can search for optimal synchronization parameters in the parameter space. By setting fitness functions and mutation probabilities, they continuously optimize synchronization parameters, improving the accuracy and adaptability of the transfer decision model. For example, under different network environments and data characteristics, genetic algorithms can automatically adjust synchronization parameters to keep the transfer process in an optimal state. The transfer decision model, through a trained transfer decision classifier, can intelligently determine transfer priorities and execution strategies based on principal transfer parameters such as data block size, version span, and dependency parameters. This achieves automated and intelligent decision-making in the transfer process, reducing manual intervention and improving the accuracy and efficiency of transfer.

[0044] In terms of resource consumption control, this method significantly reduces data transfer volume and storage resource consumption by processing only incremental data. Compared to traditional full migrations that require transferring and storing the entire database, this method only needs to transfer and store the changed data blocks, reducing the requirements for network bandwidth and storage devices. This advantage is particularly significant for resource-constrained client devices, avoiding system crashes due to insufficient resources and reducing enterprise hardware and operating costs.

[0045] This method also boasts excellent scalability and adaptability. Through flexible data partitioning and version control mechanisms, it can adapt to the migration needs of client databases of varying sizes and types. Whether it's a small application's client database or a large-scale enterprise-level client database, efficient and reliable incremental migration can be achieved by adjusting the partitioning strategy and version control parameters. Furthermore, the training and optimization mechanisms of the migration decision model enable this method to continuously evolve and improve as data characteristics and business needs change, maintaining long-term applicability and advanced nature. Attached Figure Description

[0046] Figure 1 This is a schematic diagram illustrating the working principle of the incremental migration method for client databases described in this invention.

[0047] Figure 2 A flowchart for incremental data capture and version identification;

[0048] Figure 3 A flowchart for data synchronization and tagging processing;

[0049] Figure 4This is a flowchart for training and validating the transfer decision model. Detailed Implementation

[0050] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0051] Please see Figures 1-4 This invention relates to a client-side database incremental migration method, which achieves efficient and accurate database incremental migration through incremental data block processing, version control, data synchronization, and migration decision optimization. The specific implementation steps are as follows:

[0052] S1. Incremental Data Acquisition and Migrating Data Block Extraction: Incremental data from the client database is acquired through database log monitoring or change capture mechanisms (such as triggers or CDC technology), forming a set of incremental data to be processed. Using incremental data capture methods, data blocks to be migrated are extracted from the incremental data set according to preset rules (such as data table partitioning and timestamp range), resulting in a set of data blocks to be migrated.

[0053] Subsequently, the set of data blocks to be migrated is processed by data segmentation. The data is divided into several sub-blocks based on dimensions such as data volume and business relevance, forming a segmented incremental data set. For example, the data can be divided into 1024 data blocks by hashing the row ID of the data table, or the data blocks can be divided by time windows (such as hourly).

[0054] A version control algorithm is used to determine version identifiers for the incremental data set after block partitioning: the modification timestamp and hash value of each data block are calculated to generate standardized weights containing time dimensions and content features. Version intervals are divided according to the weights to generate a candidate version identifier set. The time interval between candidate version identifiers is further calculated, and version identifiers with the same interval are merged to obtain a unique final version identifier. The target migration data block is located and extracted using this version identifier to form a migration data block set.

[0055] S2. Migration Data Block Synchronization and Marking: Perform data synchronization processing on the migration data block set: First, merge data blocks to merge related data blocks of the same business entity into logical units; then, identify data blocks with overlapping versions or dependency conflicts through conflict detection, sort conflicting data blocks based on version span parameters, retain data blocks with smaller version spans and clean up redundant data to obtain the synchronized migration data block set.

[0056] A two-dimensional matrix is ​​generated based on the synchronized set of migrated data blocks, with the rows and columns representing the logical coordinates of the data blocks. Data block relationships are defined (e.g., foreign key relationships, business process order). Marking begins with the first data block in the top left corner of the matrix: first, mark its associated data blocks, generating initial migration sequence numbers; then, traverse the data blocks in the same row to the right, updating the sequence numbers according to the relationships, until the top right corner of the matrix is ​​reached; subsequently, traverse downwards row by row to complete the migration marking of the entire matrix, forming the marked migrated data block matrix.

[0057] S3. Migration Feature Optimization and Decision Execution: Principal Component Analysis (PCA) is used to extract migration feature parameters from the labeled migration data block matrix, including data block size, version span, dependency complexity, etc. The synchronization parameters in the feature parameters are optimized using a genetic algorithm: the fitness function is set as a linear combination of the synchronization parameters. In the genetic population, the k-th individual moves along the parameter space, with a mutation probability of p (e.g., 0.1). When an individual moves to the parameter boundary, if the random number r∈[0,1] is greater than p, the mutation direction is positive; otherwise, it is negative. The fitness value is calculated after each update of the individual's position. Optimization stops when the maximum number of iterations (e.g., 100 generations) is reached, yielding the optimal synchronization parameters.

[0058] Migration priority is calculated based on the optimized feature parameters, and weight allocation can be determined using the Analytic Hierarchy Process (AHP). The data block size parameter, version span parameter, and dependency parameter are used as the primary migration parameters. The migration decision model is trained using these primary migration parameters: The corresponding parameters are extracted from the newly acquired incremental data to form a migration sample set, which is then divided into a test set and a validation set. The model input nodes are set to 3 (corresponding to the three primary parameters), and the output node is set to 1 (the migration execution result). Iterative training is performed using the backpropagation algorithm up to the maximum number of iterations (e.g., 5000). The validation set is input into the model; if the error is less than a preset threshold (e.g., 0.01), it is determined to be the migration decision classifier. Finally, the migration execution result is output, completing the incremental database migration.

[0059] The present invention will be further described below with reference to Examples 1 to 5:

[0060] Example 1: In step S1, after the incremental data set to be processed is generated, the incremental data capture method is used to extract the data blocks to be migrated according to the primary key range of the data table, forming a set of data blocks to be migrated. The data block processing stage adopts a dynamic block partitioning strategy, specifically implemented as follows: First, a data block size threshold is set, for example, 1MB is set as the maximum capacity of a single data block. For files exceeding this threshold, they are split into several smaller data blocks according to the physical storage order or logical relationship of the data records, ensuring that the number of records contained in each data block does not exceed a preset value (e.g., 1000 records). During the partitioning process, the logical relationship between data blocks is preserved. For example, records within a continuous primary key range in the same data table are divided into the same data block, or fields with strong relationships are combined in the same data block according to the business scenario, to reduce dependency conflicts in the subsequent migration process.

[0061] The specific implementation of the version control algorithm includes the following steps: For each data block in the incremental data set after partitioning, calculate its modification time and data block hash value. The modification time is obtained with millisecond precision through the timestamp field of the database system or log records; the data block hash value is generated using the SHA-256 algorithm to verify the integrity of the data block content, ensuring that the data has not been tampered with or corrupted. Through normalization processing, the modification time and hash value are converted into standardized weights for the data blocks. The weight calculation formula is as follows:

[0062]

[0063] Here, "maximum timestamp" is the maximum value of the modification timestamps of all data blocks in the incremental data set after partitioning, and "maximum checksum" is the maximum value of the checksum of the hash values ​​of all data blocks. Through this formula, the time dimension and content characteristics are quantitatively integrated, so that each data block has a unique standardized weight value, reflecting its comprehensive attributes in version control.

[0064] Version intervals are divided based on standardized weights for data blocks. Specifically, weight values ​​are sorted chronologically, and version intervals are divided by calendar day; data blocks generated or modified within the same calendar day belong to the same version interval. Each version interval generates a corresponding candidate version identifier in the format "V + year + month + date + sequence number". For example, the first version interval identifier for May 28, 2025, is "V20250528_01". After generating the candidate version identifier set, time interval calculation and merging are performed. The time interval between any two adjacent candidate version identifiers is calculated. If the time interval is less than a preset threshold (e.g., 1 hour), the two version identifiers are considered to belong to the same logical version and are merged into a single final version identifier. For example, if multiple candidate version identifiers are generated on May 28, 2025, and the time interval between adjacent identifiers is less than 1 hour, they are merged into a single final version identifier "V20250528".

[0065] The process of extracting migration data blocks using the final version identifier is as follows: First, determine the corresponding version range based on the final version identifier and filter out all data blocks within that range. Then, check the integrity and consistency of each data block, excluding any abnormal data blocks that may have appeared during the partitioning or versioning process. Finally, arrange the data blocks that meet the criteria in a standardized weighted order to form a migration data block set. During the extraction process, if a data block's hash value is found to be inconsistent with the original data, or its modification time exceeds the version range, an exception handling process is triggered, an error log is recorded, and the data block is skipped to ensure the accuracy of the migration data.

[0066] In data chunking, dynamic chunking strategies also need to consider the business relevance of data blocks. For example, for order business data, the order header information and details corresponding to the same order number can be divided into the same data block to avoid data dependency breaks during migration. Meanwhile, different chunking rules can be used for historical archived data and real-time newly added data. Historical data can be chunked by a fixed time window (e.g., monthly), while real-time data can be chunked by dynamic thresholds to adapt to different data processing needs.

[0067] The time interval merging mechanism in version control algorithms can effectively reduce the number of version identifiers and avoid the problem of low migration efficiency caused by version fragmentation. For example, in high-concurrency scenarios, multiple small incremental data blocks may be generated in a short period of time. Although these data blocks have different modification times, they belong to continuous updates of the same business operation. By merging version identifiers with smaller time intervals, they can be migrated as a whole, improving migration efficiency and data consistency.

[0068] After extracting the set of migration data blocks, a pre-validation step is required, including counting the number of data blocks, verifying the data size, and conducting preliminary dependency checks. Pre-validation ensures that the set of migration data blocks meets the requirements of subsequent processing flows, such as the number of data blocks not exceeding the system's processing capacity limit, the data size being within the network bandwidth limits, and the dependencies between data blocks being clearly identifiable. If pre-validation fails, the process returns to the data segmentation or version control stage for adjustments until the requirements are met.

[0069] Example 2: In step S2, the specific implementation of data synchronization processing and migration marking is as follows: Data block merging processing is performed on the migration data block set. The merging rules are based on the business relevance and physical storage characteristics of the data blocks. For example, for incremental data blocks of the same data table, adjacent data blocks are merged into contiguous logical units according to the primary key order (e.g., auto-incrementing ID, timestamp) to reduce the number of data blocks and improve migration efficiency. During the merging process, it must be ensured that the merged data block does not exceed the preset maximum capacity (e.g., 2MB). If it exceeds this, the original blocks are retained to avoid transmission or processing delays due to excessively large data blocks. For example, for incremental data in a user table, segments are created according to the hash value of the user ID, and multiple small data blocks within the same hash segment are merged into one logical data block to ensure that related data of the same user are processed as a whole during the migration process.

[0070] Conflict detection and handling is a crucial step in data synchronization. The specific steps are as follows: By traversing the synchronized set of migrated data blocks, the metadata information of each data block is checked one by one, including version number and dependency fields (such as foreign key constraints and business process identifiers). For version numbers, if the version number ranges of two data blocks overlap (e.g., data block A's version number is V3.1-V3.3, and data block B's is V3.2-V3.4), it is determined to be a version conflict. For dependencies, if the primary key of the parent data block referenced by the child data block does not exist in the current set of migrated data blocks, or the version number of the parent data block is lower than that of the child data block, it is determined to be a dependency conflict. After conflict detection is completed, a list of conflicting data blocks is generated, containing the conflicting data block ID, conflict type (version conflict / dependency conflict), version number, and dependency details.

[0071] Conflicting data blocks are prioritized based on a version span parameter, defined as the absolute difference between the version numbers of the data blocks. For conflicting data blocks, those with smaller version spans (i.e., version numbers closer to the target version) are retained. For example, if data block C (version V3.2, span 1) and data block D (version V3.5, span 4) conflict, data block C is retained and marked as valid, while data block D is marked as conflicting and pending. For data blocks with dependency conflicts, migration is prioritized according to dependency hierarchy, processing parent data blocks first, then child data blocks. If a parent data block is not included in the current migration set, an exception handling process is triggered, recording the missing parent data block information and pausing migration until manual confirmation before resuming.

[0072] Redundancy cleanup targets duplicate or invalid data blocks. By comparing hash values, it identifies data blocks with identical content, retains only one, and marks the rest as redundant, removing them from the synchronized migration data block set. For example, if the same business operation generates multiple data blocks with the same content (such as duplicate order data submissions), after confirming redundancy through hash value verification, only the first data block is retained, reducing data transmission and storage overhead.

[0073] After data synchronization is complete, the migration marking phase begins. First, a two-dimensional matrix is ​​generated based on the synchronized migration data block set. The rows and columns of the matrix correspond to the logical grouping of the data blocks (e.g., rows are divided by business module, and columns are divided by data update time order). Each matrix cell stores metadata such as the unique identifier, version number, and dependencies of the data block. Migration marking starts from the first data block in the top left corner of the matrix (coordinate 0,0), and the specific process is as follows:

[0074] Initial Marking: Read the associated data block information of the data block at coordinate (0,0). The associated data block is determined by the foreign key field in the data block metadata or by the business process definition. For example, if the data block is an order header data block and its associated data block is the corresponding order details data block, then mark the associated data block as the first node in the migration path and generate an initial migration sequence number "1".

[0075] Row-wise traversal: Starting from coordinate (0,0), move to the right, processing subsequent data blocks in the same row sequentially. For each data block, check its relationship with currently marked data blocks. If a direct relationship exists (e.g., different details of the same order), update the migration sequence number to the current maximum sequence number plus 1, and mark the association direction (e.g., right or down). If no direct relationship exists, retain the default sequence number (initially 0) for subsequent traversal. For example, order detail data blocks in the same row are arranged in order of creation time. Each time you move one column to the right, the migration sequence number increments by 1, forming a continuous migration sequence.

[0076] Cross-row and column traversal: After completing the first row traversal, move down row by row to the next row (e.g., coordinate 1,0), with the starting migration index of the next row being the last index of the previous row plus 1. Repeat the row-by-row traversal steps until all data blocks in the matrix have been processed. During the traversal, if a labeled associated data block is encountered, skip it to avoid duplicate labeling; if a circular dependency is encountered (e.g., data block E depends on F, and F depends on E), record the dependency relationship but do not label it yet, and process it uniformly after the migration dependency graph is generated.

[0077] During the migration marking process, the allocation of migration sequence numbers follows the principle of "association priority and sequential increment" to ensure that data blocks with strong business dependencies are migrated first, avoiding migration failures caused by dependency inversion. For example, in an e-commerce scenario, the order header data block (sequence number 1) is migrated first, followed by the corresponding order detail data blocks (sequence numbers 2 and 3), and finally the logistics information data block (sequence number 4), forming a migration order that conforms to the business process.

[0078] After migration marking is completed, a marked migration data block matrix is ​​generated. Each data block in the matrix contains a unique migration sequence number, association identifier, and status flag (such as "marked", "pending migration", "conflict resolved"). This matrix serves as the basis for subsequent migration feature extraction and priority calculation, ensuring that the migration process is executed in an orderly manner according to the preset logic.

[0079] In the specific implementation of conflict detection and handling, the consistency of database transactions must also be considered. For example, for transaction operations spanning multiple data blocks, if a conflict occurs in one data block, all data blocks related to the entire transaction must be rolled back to their pre-conflict state and re-segmented or versioned to ensure data transaction integrity. Furthermore, the migrated data block matrix after conflict resolution must record a conflict handling log, including the conflict occurrence time, data block ID, handling method (e.g., retain / delete), and operator (if manual intervention), to facilitate subsequent auditing and problem tracing.

[0080] When handling redundancy, different redundancy judgment strategies can be adopted for data blocks from different business modules. For example, a certain degree of redundancy is allowed for log data blocks (such as retaining the three most recent identical logs), while redundancy is strictly prohibited for transaction data blocks to ensure data uniqueness. The deletion operation of redundant data blocks must be performed within a transaction to avoid data inconsistency caused by partial deletion.

[0081] Example 3: In the feature extraction and parameter optimization stage of step S3, the specific implementation is as follows: Principal Component Analysis (PCA) is used to reduce the dimensionality of the labeled migration data block matrix to extract key migration feature parameters. The core of PCA is to transform the original high-dimensional features into low-dimensional principal components through linear transformation, where the first k principal components can retain the main information of the original data. In this example, the first 3 principal components are selected, and the cumulative variance contribution rate needs to reach a preset threshold (e.g., 95%) to ensure that the extracted features can fully reflect the essential attributes of the migration data. The original features include, but are not limited to, data block size, modification time, version number, dependency complexity, data block hash value, synchronization delay, etc. After PCA, the three principal components are finally determined as follows:

[0082] Principal Component 1: Data Block Size Parameter (unit: KB), reflecting the physical storage scale of the data block;

[0083] Principal Component 2: Version Span Parameter (dimensionless), defined as the absolute value of the difference between the current version number of the data block and the target migration version number;

[0084] Principal component 3: Dependency parameters (dimensionless), calculated from the in-degree and out-degree of the dependency graph, characterize the complexity of the data block in the migration dependency network.

[0085] After feature extraction, a genetic algorithm is used to optimize the synchronization parameters among the feature parameters. A genetic algorithm is a global optimization algorithm that simulates the biological evolution process, iteratively searching for the optimal solution through operations such as selection, crossover, and mutation. In this embodiment, the synchronization parameters include a synchronization delay threshold (x1), a conflict resolution priority coefficient (x2), and a data block merging threshold (x3), where: x1 represents the upper limit of the allowed data block synchronization delay time (unit: ms), used to control the time tolerance range during data synchronization; x2 is a coefficient between 0 and 1, used to adjust the priority weight when resolving conflicting data blocks, with a larger value indicating a higher weight for the version span parameter; x3 represents the maximum capacity threshold for data block merging (unit: MB), used to control the size of the merged data block and avoid affecting migration efficiency due to excessively large data blocks.

[0086] The specific implementation steps of the genetic algorithm are as follows: Population initialization: Generate an initial population containing N individuals, each individual being a three-dimensional vector (x1, x2, x3), where the value of x1 ranges from [x1, x2, x3, x4]. 1min ,x 1max (e.g., 50ms to 100ms), the value range of x2 is [0,1], and the value range of x3 is [1MB,3MB]. The initial values ​​of individuals are generated through a uniform random distribution to ensure the coverage of the search space.

[0087] Fitness function definition: The fitness function is defined as a linear combination of synchronization parameters, and the formula is:

[0088] f(x) = ω1x1 + ω2x2 + ω3x3

[0089] Wherein, ω1, ω2, and ω3 are preset weight coefficients, corresponding to the importance of synchronization delay, conflict resolution priority, and data block merging, respectively. In this embodiment, the weight coefficients are set to ω1 = 0.3, ω2 = 0.5, and ω3 = 0.2, indicating that conflict resolution priority is the core optimization objective, while synchronization delay and data block merging are secondary objectives.

[0090] Selection operation: Individuals are selected from the current population using a roulette wheel selection algorithm, with individuals having a higher fitness value having a greater probability of being selected. Specifically, the proportion of each individual's fitness to the total fitness is calculated, a cumulative probability distribution is generated, and the corresponding individual is selected to enter the next generation of the population using random numbers.

[0091] Crossover operation: with crossover probability P c (e.g., 0.8) Perform pairwise crossovers on the selected individuals, exchanging some genes (parameter values) to generate new individuals. The crossover point is randomly selected between the dimensions of the three-dimensional vector. For example, for individuals A = (a1, a2, a3) and B = (b1, b2, b3), if the crossover is selected in the second dimension, the new individuals after the crossover will be A′ = (a1, b2, a3) and B′ = (b1, a2, b3).

[0092] Mutation operation: For each gene of each individual, a mutation probability P is applied. m (e.g., 0.05) is used for mutation. During mutation, the individual moves in the parameter space. If the current parameter value reaches the boundary (e.g., x1 = x), the mutation occurs. 1min Or x1 = x 1max Then, based on the random number r (r∈[0,1]) and the mutation probability P... m The comparison results determine the direction of mutation: if r > P m If the parameter increases, the mutation direction is positive (moving towards the direction of parameter increase); otherwise, it is negative (moving towards the direction of parameter decrease). For example, when x1 reaches its minimum value of 50ms and r = 0.7 > P... m When r = 0.05, x1 variates in the increasing direction, increasing its value by one step (e.g., 1 ms); if r = 0.03 <P m If the value is not specified, the current value will be retained or the data will be processed according to the preset rules.

[0093] Iterative optimization: After an individual's position is updated, the fitness value is recalculated, and the best individual of the current generation (i.e., the individual with the highest fitness value) is recorded. When the number of iterations reaches the preset maximum number of iterations (e.g., 200 generations), optimization stops, and the optimal combination of synchronization parameters is output.

[0094] In boundary handling of mutation operations, the step size needs to be determined based on the parameter value range and precision requirements. For example, for x1 (unit: ms), a step size of 1ms is set to ensure fine-grained parameter adjustment; for x3 (unit: MB), a step size of 0.1MB is set to balance optimization precision and computational efficiency. Furthermore, to avoid getting trapped in local optima, an elite retention strategy can be introduced during iteration, where the best individual from each generation is retained and directly enters the next generation, ensuring that the optimal solution is not destroyed by crossover or mutation operations.

[0095] The implementation of principal component analysis (PCA) algorithms requires a data standardization preprocessing step, namely, zero-mean and unit-variance normalization of the original features to avoid biases in principal component calculations due to different feature dimensions. The standardization formula is:

[0096]

[0097] Where μ is the mean of the features and σ is the standard deviation of the features. The preprocessed data is used to calculate the covariance matrix, and then the principal component vectors are obtained through eigenvalue decomposition or singular value decomposition.

[0098] Genetic algorithm parameter settings (e.g., population size N=50, crossover probability P) c =0.8, Probability of mutation P m =0.05) needs to be adjusted according to the complexity of the actual problem and computational resources. For example, if the scale of the transferred data is large and the feature space is complex, the population size and the number of iterations can be appropriately increased to improve the probability of finding the global optimum; if computational resources are limited, the population size can be reduced and the number of iterations can be shortened to achieve a balance between accuracy and efficiency.

[0099] The optimized synchronization parameters will be used for subsequent migration priority calculations and migration decision model training. For example, the optimal synchronization delay threshold. It can be used as a basis for judging whether the latency exceeds the standard during data synchronization, and as a conflict resolution priority coefficient. It can be directly used for priority sorting of conflicting data blocks and data block merging threshold. It can guide the adjustment of data block merging strategies to ensure that the merged data blocks meet business relevance requirements without exceeding the system's processing capacity.

[0100] Example 4: In step S3, the specific implementation method for training the transfer decision model and handling conflict detection is as follows:

[0101] In the training phase of the migration decision model, the first step is to acquire new incremental data from the client database. Taking user order data from an e-commerce platform as an example, the new data may include incremental records generated by user operations such as creating orders, modifying shipping addresses, and canceling orders. For each incremental data record, three main migration parameters are extracted:

[0102] Data block size parameter: The order header information and details information are treated as a single data block. Assuming there are 50 order details, the data block size is 800KB (calculated based on the number of serialized data bytes).

[0103] Version span parameter: The current database version is V4.2, the version number of the data block to be migrated is V4.1, and the version span is 1 (i.e., |4.2-4.1|);

[0104] Dependency parameters: The order data block depends on the user basic information data block (foreign key associated with user ID). If the user data block is already included in the migration set, the dependency level is 1 (indicating first-level dependency), otherwise it is 0 (indicating no dependency or missing dependency).

[0105] The extracted parameters are combined into a new transfer sample set, for example, containing 1000 sample data points. The sample set is divided into a transfer test set (700 data points) and a transfer validation set (300 data points) in a 7:3 ratio. The test set is used to train the model, and the validation set is used to evaluate the model performance.

[0106] The transfer decision model uses a three-layer neural network structure:

[0107] Input layer: Set up 3 nodes, corresponding to data block size, version span, and dependency parameters respectively;

[0108] Hidden layer: Set to 10 nodes, using the ReLU activation function to extract non-linear features;

[0109] Output layer: Set up 1 node with an output value of 0 or 1, where 0 means do not migrate the data block for the time being, and 1 means migrate immediately.

[0110] The training process is as follows: Sample data from the transfer test set are input into the model batch by batch. Mean squared error (MSE) is used as the loss function, and the backpropagation algorithm updates the model weights and biases. The maximum number of iterations is set to 3000, and the learning rate is 0.001. In each iteration, the model predicts the input samples based on the current parameters, calculates the error between the predicted value and the actual label (such as manually labeled transfer priority), and adjusts the network parameters to reduce the error.

[0111] After training, the transfer validation set is input into the trained model. Taking a validation sample as an example: the data block size is 1.2MB, the version span is 2, the dependency level is 0 (independent data block), and the model output value is 0.8, which is close to the threshold of 1, and is judged as immediate transfer. If the overall error of the model output (e.g., root mean square error) is less than the preset threshold (e.g., 0.05), the model is judged as a qualified transfer decision classifier and can be used for actual transfer decisions; if the error does not meet the standard, the model parameters are adjusted (e.g., increasing the number of hidden layer nodes to 15, or reducing the learning rate to 0.0005), and retraining is performed until the error meets the requirements.

[0112] The specific implementation of conflict detection and handling takes order data migration as an example: by traversing the synchronized set of migration data blocks, the version number and dependencies of each data block are checked. For example, if it is found that data block A (order ID = 1001, version number V4.1) and data block B (order ID = 1001, version number V4.3) have overlapping versions (both are within the influence range of the current migration version V4.2), a list of conflicting data blocks is generated, recording the conflict type as "version conflict", involving the data block ID, version number, and conflict timestamp.

[0113] Conflicting data blocks are prioritized based on version span parameters: Data block A has a version span of 1 (|4.2-4.1|), and data block B has a version span of 1 (|4.2-4.3|). Since their spans are the same, they can be sorted according to their modification time, retaining data block B with the newer modification time. In the marking matrix, data block A is marked as "conflict resolved - deleted," and data block B is marked as "valid." If the conflicting data blocks are dependency conflicts (such as an order detail data block referencing a non-existent product data block), migration is paused, the missing product data block ID is recorded, and a manual review process is triggered. Conflict detection is then performed again after the parent data block is supplemented.

[0114] After conflict resolution, the migration data block matrix needs to be updated with data block status. For example, locate the coordinates of data block A in the matrix (row = order module, column = column 5), mark its status as "deleted," and adjust the migration sequence number of subsequent data blocks to ensure continuity. Simultaneously, record the conflict handling log, including processing time, operation type (automatic resolution / manual intervention), and processing result, for subsequent auditing purposes.

[0115] When partitioning the sample set, it is necessary to ensure that the data distribution of the test set and the validation set is consistent to avoid insufficient generalization ability of the model due to data bias. For example, if 80% of the incremental data consists of data blocks with a low version span (≤1) and 20% consists of data blocks with a high version span (>1), then the ratio of high and low version span samples in the test set and the validation set should also be maintained at 8:2 to ensure the balance of model training.

[0116] The input parameters of a neural network model need to be normalized. For example, the data block size can be converted from KB to MB and scaled to the [0,1] interval. Version span and dependency parameters can be directly mapped to the [0,1] interval to avoid the impact of different feature units on model training performance. The normalization method uses the min-max scaling method, and the formula is:

[0117]

[0118] Where, x min and x max These are the minimum and maximum values ​​of the feature, respectively.

[0119] In conflict detection, for complex dependencies spanning multiple data tables (such as a three-level dependency of order → user → address), the integrity of the dependency relationship must be checked layer by layer. If the user data block exists but the address data block is missing, the dependency level of the order data block is marked as 2 (second-level dependency), and the missing address data block is recorded in the conflict list, prompting the operations and maintenance personnel to supplement the relevant data before proceeding with the migration.

[0120] Example 5: In the migration marking step of step S2, the specific implementation involves the generation of the migration dependency graph and the handling of circular dependencies. The following is a detailed explanation in conjunction with a specific business scenario:

[0121] Taking the database migration of an Enterprise Resource Planning (ERP) system as an example, assume there are three data blocks: purchase order header data block (D101), purchase order details data block (D102), and supplier information data block (D103). D101 is associated with D103 via a supplier ID foreign key, and D102 is associated with D101 via an order ID foreign key, forming a linear dependency chain D103→D101→D102. Normally, migration markers are generated in sequence according to dependency order: D103 (sequence number 1)→D101 (sequence number 2)→D102 (sequence number 3).

[0122] However, if historical data errors exist in the system, causing D101 to also depend on D102 (such as when the order header references temporary data in the details), a circular dependency structure is formed. At this point, during the migration marking process, when traversing the data block associations, it will be detected that the dependency edge of D101 points to D102, while the dependency edge of D102 points back to D101, forming a circular dependency (circle length is 2).

[0123] The migration dependency graph is generated based on the association fields in the data block metadata. For example, each data block stores a list of its dependent parent data block IDs; D101's dependency list is [D103, D102], D102's dependency list is [D101], and D103 has no dependencies. A directed graph is constructed using a graph traversal algorithm (such as Depth-First Search, DFS), where nodes are data block IDs and directed edges represent dependencies (e.g., D101→D103 indicates that D101 depends on D103). During graph construction, if a duplicate node is detected in the path originating from the current node, a circular dependency is determined.

[0124] Upon detecting a circular dependency, the system performs a forced disconnection operation based on the version span parameter. The version span parameter is the absolute value of the difference between the current version number of the data block and the target migration version number. Assume the target migration version is V5.0, D101's version number is V4.8 (span 0.2), and D102's version number is V4.5 (span 0.5). Following the principle of prioritizing disconnections for data blocks with larger version spans, D102 is selected as the disconnection point, and its dependency edge pointing to D101 is deleted, transforming the dependency graph into D103→D101 and D102 (independent nodes).

[0125] After the chain break, the dependency list of D101 is updated to [D103], and the dependency list of D102 is cleared. Migration marking continues: D103 is marked as sequence number 1, D101 as sequence number 2, and D102 as sequence number 3 (since there is no dependency, it will be migrated as an independent data block). Simultaneously, the system generates a migration log, recording the chain break location: data block ID is D102, dependency relationship is D102→D101, chain break time is May 28, 2025, 14:30:05, and the reason for the chain break is "circular dependency, large version span".

[0126] Another scenario is illustrated in a Customer Relationship Management (CRM) system. Data blocks D201 (customer order), D202 (customer contact), and D203 (order product) form a triangular circular dependency: D201 depends on D202 (customer ID) and D203 (product ID), while D203 depends on D201 (order ID). A circular path D201→D203→D201 is detected, with a length of 2. The version spans of each data block are: D201 (V3.6, span 0.4) and D203 (V3.3, span 0.7). Based on the version span, D203 is selected as the break point, and the dependency edge D203→D201 is deleted, making D203 an independent data block. The migration marking order is D202 (sequence number 1)→D201 (sequence number 2)→D203 (sequence number 3), and a break log is recorded for manual review.

[0127] The handling of independent data blocks after a link break is as follows: If the broken data block is a leaf node (with no downstream dependencies), it is allowed to migrate independently; if it is an intermediate node (with downstream dependencies), its downstream data blocks need to have their dependencies adjusted synchronously, or be marked as independent data blocks together. For example, if D203 is still dependent on D204 (order logistics) after the link break, the dependency of D204 also needs to be adjusted, or D204 and D203 can be migrated together as independent data blocks to ensure that the migration order does not disrupt business logic.

[0128] The migration log storage structure includes: log ID, disconnection time, data block ID, dependency description, disconnection method (version span / manually specified), and processing status (pending review / processed). Operations personnel can manually verify the rationality of the disconnection by querying the logs. For example, in a CRM scenario, a disconnection from D203 to D201 might cause inconsistencies between order product data and order header data. Manual confirmation is needed to determine if there are any business logic errors or if additional constraints (such as transaction locking mechanisms) are required to prevent data inconsistency.

[0129] During the migration marking process, the detection of circular dependencies occurs after the migration data block matrix is ​​generated but before the migration feature parameters are extracted. This marking-then-detection process ensures that all data block relationships are included in the matrix management, avoiding the omission of hidden dependency paths. The detection algorithm employs a stack-based Depth-First Search (DFS) to record the access status of each node (not visited / currently visited / visited). When a node in the "currently visited" state is accessed, a circular dependency is determined, and the path is backtracked to identify the specific node in the cycle.

[0130] For complex business scenarios that may involve multi-layered circular dependencies (such as dependency graphs containing multiple rings), the system handles them using the following strategy: First, detect the shortest ring (the ring with the fewest nodes), and then break the chain by sorting the nodes within the shortest ring according to their version span. If multiple rings of equal length exist, prioritize processing the ring containing the data block with the largest version span. For example, if both ring dependencies have a length of 2 and a length of 3, prioritize processing the ring with the length of 2. If both rings have a length of 2, compare the sum of the version spans of the data blocks within each ring, and break the chain of the ring with the larger sum of spans.

[0131] The essence of chain breaking is to transform unstructured circular dependencies into a directed acyclic graph (DAG), ensuring the decidability of the migration order. Although chain breaking may cause temporary breaks in data dependencies, design flaws in the underlying data model can be fixed in subsequent version iterations through logging and manual review mechanisms, preventing similar problems from recurring. For example, in an ERP system, manual review revealed that the circular dependency between D101 and D102 stemmed from a business process design error (order headers should not depend on temporary data in details). During system upgrades, the data model can be modified to remove the dependency of D101 on D102, eliminating the circular dependency at its root.

[0132] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0133] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for incremental migration of a client database, characterized in that, Includes the following steps: S1. Obtain incremental data from the client database, generate a set of incremental data to be processed, extract the data blocks to be migrated using the incremental data capture method, obtain the set of incremental data after data segmentation, determine the version identifier of the set of incremental data after segmentation using the version control algorithm, locate and extract the migration data blocks, and obtain the set of migration data blocks. S1 includes the following steps: S11. Obtain incremental data from the client database, generate a set of incremental data to be processed, and use the incremental data capture method to extract the data blocks to be migrated, thus obtaining a set of data blocks to be migrated. S12. The set of data blocks to be migrated is divided by data block processing to obtain the incremental data set after block division. The version control algorithm includes: For each data block in the incremental data set after partitioning, calculate its modification time and data block hash value; By normalizing the data block hash value, the modification time is converted into a normalized weight of the data block. Based on the normalized weight of the data block, the version range is divided. The formula for calculating the weights is as follows: ； Among them, "maximum timestamp" is the maximum value of the modification timestamps of all data blocks in the incremental data set after block division, and "maximum checksum" is the maximum value of the checksum of the hash values ​​of all data blocks; The weight values ​​are sorted in chronological order, and the version intervals are divided by calendar day. That is, data blocks generated or modified within the same calendar day belong to the same version interval. Each version range generates a corresponding candidate version identifier. After generating the candidate version identifier set, the candidate version identifiers need to be processed by time interval calculation and merging. Calculate the time interval between any two adjacent candidate version identifiers. If the time interval is less than a preset threshold, the two version identifiers are considered to belong to the same logical version and are merged into a final version identifier. Extract migration data blocks using the final version identifier; S2. Perform data synchronization processing on the set of migration data blocks to obtain a synchronized set of migration data blocks, then generate a synchronized migration data block matrix, set the data block association relationship, mark the migration data blocks, and obtain a marked migration data block matrix. S3. Extract the migration feature parameters of the marked migration data block matrix, optimize the synchronization parameters in the feature parameters, calculate the migration priority, determine the main migration parameters according to the migration priority, train the migration decision model using the main migration parameters to obtain the migration decision classifier, output the migration execution results, and realize the incremental migration of the client database. S3 includes the following steps: S31. Use principal component analysis algorithm to extract migration feature parameters of the labeled migration data block matrix, and use genetic algorithm to optimize the synchronization parameters in the feature parameters to obtain a set of migration feature parameters; S32. Calculate the priority weights of the migration feature parameter set and determine the main migration parameters, which include data block size parameters, version span parameters, and dependency parameters. S33. Train the migration decision model to obtain the migration decision classifier. Input the data block size parameter, version span parameter, and dependency parameter into the migration decision classifier and output the migration execution result. The optimization of the synchronization parameters in the feature parameters using a genetic algorithm includes: The fitness function is set as a linear combination of synchronization parameters. The k-th individual in the genetic population moves along the parameter space. The mutation probability is set as p. When the individual encounters the parameter boundary during the movement, if the random number r∈[0,1] is greater than p, the mutation direction is positive; otherwise, it is negative. The fitness value is calculated after the individual's position is updated. When the current iteration number reaches the maximum iteration number, the optimization stops and the optimal synchronization parameters are output.

2. The incremental migration method for client databases according to claim 1, characterized in that, S2 includes the following steps: S21. Perform data block merging, conflict detection and redundancy cleanup on the migration data block set to complete the data synchronization process and obtain the synchronized migration data block set. S22. Based on the synchronized migration data block set, generate a synchronized migration data block matrix, and use the data block association relationship to perform migration marking on the synchronized migration data block matrix to obtain the marked migration data block matrix.

3. The incremental migration method for client databases according to claim 2, characterized in that, The migration marking of the synchronized migration data block matrix using data block association relationships includes: Mark the associated data block of the first data block in the upper left corner of the synchronized migration data block matrix, generate a migration sequence number, traverse the data block association relationship to the right, update the migration sequence number, until the upper right corner of the synchronized migration data block matrix is ​​reached, and then traverse the entire migration data block matrix in sequence to complete the migration marking.

4. The incremental migration method for client databases according to claim 1, characterized in that, S33 includes the following steps: S331. Obtain new incremental data from the client database, extract new data block size parameters, version span parameters, and dependency parameters to form a new migration sample set, divide the new migration sample set into a migration test set and a migration verification set, set the input node of the migration decision model to 3 and the output node to 1, input the migration test set into the migration decision model, iterate to the maximum number of times and then stop to obtain the trained migration decision model. S332. Input the transfer validation set into the trained transfer decision model. If the model error is less than the preset threshold, it is determined to be a transfer decision classifier; otherwise, adjust the model parameters until the error meets the requirements.

5. The incremental migration method for client databases according to claim 2, characterized in that, The collision detection process in S21 includes the following steps: S211. Traverse the synchronized migration data block set, identify data blocks with overlapping versions or dependency conflicts, and generate a list of conflicting data blocks. S212. Prioritize conflicting data blocks based on version span parameters, retain data blocks with smaller version spans first, and mark the migration data block matrix after conflict resolution.

6. The incremental migration method for client databases according to claim 3, characterized in that, The migration marking step further includes: A migration dependency graph is generated based on the data block relationships. If a circular dependency structure is detected, the dependency link is forcibly disconnected based on the version span parameter, and the location of the broken link is recorded in the migration log for subsequent manual review.

Images