Data migration methods, equipment, storage media, and software products

Abstract

This application discloses a data migration method, device, storage medium, and program product, relating to the field of data synchronization technology. In this application, after synchronizing the target data (after data changes) from the source database to the target database, the source and target databases are divided into blocks. The number of leaf nodes used to construct the corresponding block trees for each block is adjusted according to the access and change frequencies of each block. Based on the adjusted number of leaf nodes, a first block tree for the source database and a second block tree for the target database are constructed. Consistency verification of each block in the source and target databases is then performed using the first and second block trees. Therefore, by dividing the database into blocks, adjusting the number of leaf nodes, constructing block trees, and performing block consistency verification based on the block trees, the current technical problems of poor real-time performance and high resource consumption caused by relying on periodic full table comparisons are avoided, achieving real-time and efficient consistency verification.

Description

Technical Field

[0001] This application relates to the technical field of data synchronization, and in particular to data migration methods, data migration devices, storage media, and computer program products. Background Technology

[0002] With the development of information technology, database systems are playing an increasingly crucial role in enterprise informatization. As business scale expands, database systems often face demands such as restructuring, multi-site active-active architecture, database sharding, and cross-platform migration. Data migration, as a vital means of ensuring business continuity and data asset security, presents increasingly significant technical challenges. Existing data migration technologies, such as Alibaba DTS and Debezium, while supporting incremental synchronization, largely rely on periodic full table comparisons for consistency checks, resulting in poor real-time performance and high resource consumption.

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

[0004] The main purpose of this application is to provide a data migration method, data migration device, storage medium, and computer program product, which aims to solve the technical problem of difficulty in achieving real-time and efficient data migration consistency verification.

[0005] To achieve the above objectives, this application proposes a data migration method, which includes:

[0006] After synchronizing the target data with the modified data in the source database to the target database, the source database and the target database are divided into blocks to obtain the first block of the source database and the second block of the target database.

[0007] Based on the access frequency and change frequency of the first block, adjust the number of first leaf nodes used to construct the first block tree corresponding to the first block; based on the access frequency and change frequency of the second block, adjust the number of second leaf nodes used to construct the second block tree corresponding to the second block.

[0008] The first block tree is constructed based on the first number of leaf nodes, and the second block tree is constructed based on the second number of leaf nodes. The consistency of the first block and the second block is verified through the first block tree and the second block tree.

[0009] In one embodiment, the step of adjusting the number of first leaf nodes used to construct the first block tree corresponding to the first block based on the access frequency and change frequency of the first block includes:

[0010] The adaptive weight of the first block is determined based on the access frequency and change frequency of the first block.

[0011] When the adaptive weight is greater than a preset weight threshold, the number of first leaf nodes used to construct the first block tree corresponding to the first block is increased;

[0012] When the adaptive weight is less than or equal to a preset weight threshold, the number of first leaf nodes used to construct the first block tree corresponding to the first block is reduced.

[0013] In one embodiment, the step of determining the adaptive weight of the first block based on the access frequency and change frequency of the first block includes:

[0014] The block type of the first block is determined, wherein the block type includes hotspot access blocks and frequently changing blocks;

[0015] Based on the block type of the first block, a first weight for the access frequency of the first block and a second weight for the change frequency of the first block are determined.

[0016] The step of determining the adaptive weight of the first block based on its access frequency and change frequency includes:

[0017] The access frequency and change frequency of the first block are weighted according to the first weight and the second weight respectively to obtain the adaptive weight of the first block.

[0018] In one embodiment, the step of performing consistency verification on the first block and the second block using the first block tree and the second block tree includes:

[0019] When switching the stream to the target database in a grayscale manner, the grayscale switching metrics are monitored in real time; wherein, the grayscale switching metrics include synchronization latency rate, data difference rate, and error request rate;

[0020] The aggregation index is determined based on the grayscale tangent index within the most recent preset time window.

[0021] The risk score of grayscale tangential flow is determined based on the grayscale tangential flow index and the aggregation index.

[0022] When the risk score is greater than a preset score threshold, or when the grayscale slicing index and the aggregation index are greater than their respective preset index thresholds, grayscale slicing is stopped and a circuit breaker rollback is performed.

[0023] In one embodiment, the step of determining the risk score of grayscale shunting based on the grayscale shunting index and the aggregation index includes:

[0024] Based on the aggregation index and the first predictor of the previous grayscale sliding cycle, the second predictor of the current grayscale sliding cycle is obtained through exponential smoothing.

[0025] The risk score of grayscale flow is obtained by weighted calculation based on the grayscale flow index and the second predictive factor.

[0026] In one embodiment, the step of determining the risk score of grayscale shunting based on the grayscale shunting index and the aggregation index includes the following prior steps:

[0027] Determine the flow type of the grayscale flow and adjust the exponential smoothing coefficient used for exponential smoothing processing according to the flow type, and / or adjust the weighted calculation weights used for weighted calculation processing.

[0028] In one embodiment, the method further includes:

[0029] After a data change event occurs in the source database, a first multidimensional event sequence vector corresponding to the data change event and a second multidimensional event sequence vector corresponding to the historical data change event that has been synchronously written to the target database are recorded. The first multidimensional event sequence vector includes the event sequence number corresponding to the data change event, the storage partition sequence number of the target data corresponding to the data change event in the message queue, and the global time logical clock. The second multidimensional event sequence vector includes the event sequence number corresponding to the historical data change event, the storage partition sequence number of the target data corresponding to the historical data change event in the message queue, and the global time logical clock.

[0030] When the first multidimensional event sequence vector and the second multidimensional event sequence vector satisfy the preset event comparison rules, the target data after data changes in the source database is synchronized to the target database.

[0031] Furthermore, to achieve the above objectives, this application also proposes a data migration apparatus, the data migration apparatus comprising:

[0032] The first module is used to divide the source database and the target database into blocks after synchronizing the target data after the data changes in the source database to the target database, so as to obtain the first block of the source database and the second block of the target database.

[0033] The second module is used to adjust the number of first leaf nodes used to construct the first block tree corresponding to the first block based on the access frequency and change frequency of the first block; and to adjust the number of second leaf nodes used to construct the second block tree corresponding to the second block based on the access frequency and change frequency of the second block.

[0034] The third module is used to construct a first block tree based on the number of first leaf nodes, construct a second block tree based on the number of second leaf nodes, and perform consistency verification on the first block and the second block through the first block tree and the second block tree.

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

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

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

[0038] One or more technical solutions proposed in this application have at least the following technical effects:

[0039] In this application, after synchronizing the target data with modified data from the source database to the target database, the source and target databases are divided into blocks. The number of leaf nodes used to construct the corresponding block trees for each block is adjusted according to the access and change frequency of each block. Based on the adjusted number of leaf nodes, a first block tree for the source database and a second block tree for the target database are constructed. Consistency verification of each block in the source and target databases is then performed using the first and second block trees. Therefore, by dividing the database into blocks, adjusting the number of leaf nodes, constructing block trees, and performing block consistency verification based on the block trees, the current technical problems of poor real-time performance and high resource consumption caused by relying on periodic full table comparisons are avoided, achieving real-time and efficient consistency verification. Attached Figure Description

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

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

[0042] Figure 1 This is a flowchart illustrating the first embodiment of the data migration method of this application;

[0043] Figure 2 This is a flowchart illustrating the second embodiment of the data migration method of this application.

[0044] Figure 3 This is a flowchart illustrating the third embodiment of the data migration method of this application.

[0045] Figure 4 This is a flowchart illustrating the fourth embodiment of the data migration method of this application;

[0046] Figure 5 This is a schematic diagram of the module structure of the data migration device according to an embodiment of this application;

[0047] Figure 6 This is a schematic diagram of the device structure of the hardware operating environment involved in the data migration method in the embodiments of this application.

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

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

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

[0051] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or data migration device capable of performing the above functions. The following description uses a data migration device as an example to illustrate this embodiment and the subsequent embodiments.

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

[0053] In this embodiment, the data migration method includes steps S10 to S30:

[0054] Step S10: After synchronizing the target data with the changed data in the source database to the target database, the source database and the target database are divided into blocks to obtain the first block of the source database and the second block of the target database.

[0055] In one embodiment, after synchronizing the target data with modified data from the source database to the target database, and before partitioning the source and target databases into blocks, records with the same primary key from the source database are retrieved. The records in the source and target databases are then standardized (e.g., field sorting, data cleaning, etc.). The field concatenation rules are as follows: 1. Fields are sorted in ascending ASCII order by field name, using the format "field name=value", with different fields separated by "&" (e.g., "address_city=Beijing&created_at=2023-12-01T00:00:00Z").

[0056] 2. NULL values ​​are uniformly converted to an empty string "", Boolean values ​​are fixed as "true" / "false", and floating-point numbers are retained to 6 decimal places (e.g., 88.5 → 88.500000); 3. Nested fields are expanded into a flat structure (e.g., "address.city" is converted to "address_city"), and array types are serialized in element order (e.g., tags=[a,b] is converted to "tags=a&tags=b"). As an example: the record {name:"Alice",score:88.5,created_at:"2023-12-01T00:00:00Z",address:{city:"Beijing"}} has the following standardized concatenation string:

[0057] The string `address_city=Beijing&created_at=2023-12-01T00:00:00Z&name=Alice&score=88.500000` is used to calculate the SHA-256 hash values ​​of both ends of the string, ensuring data consistency. Furthermore, the hash values ​​of both ends are compared in real time: if the hash values ​​match, the verification is marked as successful; if they do not match, an anomaly is recorded and an alarm is sent.

[0058] In another embodiment, real-time block verification is triggered immediately after each data is written to the target database. That is, each piece of data synchronously written to the target database is hashed and compared with the record in the source database in real time, which greatly shortens the consistency detection window and ensures that the source data and the target database are synchronized accurately.

[0059] In another embodiment, batch blocks are periodically divided based on primary key range or hash prefix. The partitioning strategy can be dynamically selected based on the primary key type: for auto-incrementing primary keys (e.g., MySQL auto-incrementing IDs), primary key ID range partitioning is used, generating continuous ID intervals (e.g., every 10,000 records per block) at fixed steps (e.g., 10,000 records per block); for unordered primary keys (e.g., UUIDs), hash value prefix partitioning is used, performing SHA-256 hashing on the primary key and grouping by prefix length (e.g., the first 4 bytes); for business-dimensional isolation, business field partitioning is used (e.g., user ID geographic encoding, interface path tags, etc.). Records within each block are sorted by primary key to generate leaf node hashes, which are then aggregated layer by layer through a binary tree to generate the root hash, enabling fast block-level comparison and fine-grained difference location.

[0060] The steps for constructing a Merkle Tree are as follows: Pairwise combination of leaf node hashes generates the upper-level parent node hash: Parent_Hash = SHA256(Left_Child_Hash∥Right_Child_Hash), recursively moving upwards until the root node hash of the block is constructed. Using the Merkle Tree structure allows for the rapid location of discrepancies in block hashes in O(logN) time, rather than a full table scan; it also supports incremental verification and local repair, significantly reducing verification resource overhead during migration.

[0061] After constructing the Merkle Tree, the root hashes of blocks in the source and target databases can be compared periodically. If the root hashes match, the data within the block is consistent; if they do not match, the child nodes are recursively compared to pinpoint the individual abnormal record. To improve comparison efficiency and reliability, the following optimization strategies are introduced: 1. Root hash caching mechanism: The root hashes of verified blocks are cached (e.g., stored in Redis) to avoid redundant calculations and improve the efficiency of periodic verification; 2. Parallel construction and comparison: Supports multi-threaded parallel processing of Merkle Tree construction for different blocks, as well as root hash comparison between the source and target databases, accelerating batch verification; 3. Anomaly degradation verification: If real-time verification of a single record fails (inconsistent hash values), a fine-grained comparison at the primary key level is automatically triggered, the difference log is recorded, and the repair status is marked; 4. Configurable hash algorithm: SHA-256 is used by default to ensure security, but it can also be switched to a lightweight hash algorithm (such as MurmurHash) to adapt to high-performance scenarios, dynamically adjusted through configuration files. Through the above optimizations, the anomaly location time of the Merkle Tree mechanism in large-scale data scenarios is greatly reduced. Therefore, a Merkle Tree is constructed by periodically dividing the entire table data into blocks. The root hash value is used to quickly identify data drift blocks, and the comparison is recursively performed downwards to locate the location of abnormal data.

[0062] Step S20: Adjust the number of first leaf nodes used to construct the first block tree corresponding to the first block according to the access frequency and change frequency of the first block; adjust the number of second leaf nodes used to construct the second block tree corresponding to the second block according to the access frequency and change frequency of the second block.

[0063] Considering that the efficiency of Merkle Tree decreases when the amount of data increases dramatically or the distribution of access / changes is uneven in the above embodiments, this embodiment proposes an adaptive Merkle Tree based on block weight (referred to as A-MerkleTree).

[0064] It should be noted that the access frequency of a block refers to the number of times the block is accessed per unit of time, while the change frequency of a block refers to the frequency with which the data in the block changes during previous verification processes. Understandably, when adjusting the number of leaf nodes used to construct the corresponding block tree for each block based on its access and change frequencies, the higher the access and change frequencies of the blocks, the more leaf nodes are needed to construct the corresponding block tree. A block tree constructed with more leaf nodes can better address the shortcomings of the Merkle Tree in the above embodiments.

[0065] Step S30: Construct a first block tree based on the number of first leaf nodes, construct a second block tree based on the number of second leaf nodes, and perform consistency verification on the first block and the second block through the first block tree and the second block tree.

[0066] It is understood that the construction of the block tree and the block consistency verification based on the block tree in this embodiment can adopt the methods in the above embodiments, and will not be repeated here.

[0067] In this embodiment, the A-Merkle Tree achieves efficient consistency verification in large-scale data scenarios by dynamically adjusting block granularity and priority. Compared with a static Merkle Tree, it can shorten the anomaly location time of hotspot blocks under the same resources, while reducing the overall verification overhead.

[0068] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 Step S20 also includes steps S201 to S203:

[0069] Step S201: Determine the adaptive weight of the first block based on the access frequency and change frequency of the first block;

[0070] Step S202: When the adaptive weight is greater than the preset weight threshold, increase the number of first leaf nodes used to construct the first block tree corresponding to the first block;

[0071] Step S203: When the adaptive weight is less than or equal to the preset weight threshold, reduce the number of first leaf nodes used to construct the first block tree corresponding to the first block.

[0072] In this embodiment, the method of adjusting the number of first leaf nodes used to construct the first block tree corresponding to the first block based on the access frequency and change frequency of the first block is described as an example. The method of adjusting the number of second leaf nodes used to construct the second block tree corresponding to the second block based on the access frequency and change frequency of the second block is similar and will not be described in detail here.

[0073] Since a higher access frequency and change frequency of a block results in a greater number of leaf nodes for constructing the block tree corresponding to each block, the adaptive weight of the first block can first be determined based on its access frequency and change frequency. In one embodiment, a block weight function can be constructed: ,in, For the i-th block, For blocks The access frequency (unit: times / minute) is preferably 0–500. For blocks The historical hash difference rate (0-1), i.e., the frequency of change, represents how often the block shows a difference in previous checks. , Here, α + β = 1, with the default preferred values ​​being α = 0.6 and β = 0.4. It's understandable that α can be increased for real-time sensitive scenarios to emphasize hotspot processing, while β can be increased for scenarios with frequent changes to emphasize difference repair.

[0074] Secondly, the first block is divided into fine-grained or coarse-grained segments based on its adaptive weight: a high-weight first block can use finer leaf node division to improve positioning accuracy, while a low-weight first block can merge leaf nodes to reduce computational overhead. In one embodiment, when the adaptive weight is greater than a preset weight threshold, the number of first leaf nodes used to construct the first block tree corresponding to the first block is increased; when the adaptive weight is less than or equal to the preset weight threshold, the number of first leaf nodes used to construct the first block tree corresponding to the first block is decreased.

[0075] In another embodiment, parallel construction of A-Merkle Trees is supported, that is, A-Merkle Trees for different blocks can be constructed in parallel on multiple threads or multiple nodes to improve verification throughput; asynchronous delayed merging of A-Merkle Trees is supported, that is, A-Merkle Trees for non-critical blocks can be constructed asynchronously and merged when the system is idle, while A-Merkle Trees for core blocks are used for real-time comparison.

[0076] In one feasible implementation, steps A11-A12 may be included before step S201:

[0077] Step A11: Determine the block type of the first block, where the block type includes hotspot access blocks and frequently changing blocks;

[0078] Step A12: Determine the first weight of the access frequency of the first block and the second weight of the change frequency of the first block according to the block type of the first block.

[0079] Step S201 may include:

[0080] The access frequency and change frequency of the first block are weighted according to the first weight and the second weight respectively to obtain the adaptive weight of the first block.

[0081] Considering the weight coefficients of the aforementioned block weight function , This approach is not precise enough. In this embodiment, a first weight for the access frequency of the first block and a second weight for the change frequency of the first block are determined based on the block type of the first block. In one embodiment, for hot-spot access blocks, a parameter package A (real-time sensitive scenario) is given: when α=0.8 and β=0.2, hot-spot access blocks are divided with extremely fine granularity, suitable for services with high requirements for consistency of the latest data; for frequently changing blocks, a parameter package B (difference-priority repair scenario) is given: when α=0.4 and β=0.6, frequently changing blocks are subdivided with priority, suitable for frequent write-back / repair scenarios; for other blocks, a parameter package C (balanced scenario) is given: when α=0.6 and β=0.4, it is the default scheme, balancing real-time performance and difference detection capabilities.

[0082] Therefore, based on the first weight and the second weight corresponding to different first blocks and different scenarios, the access frequency and change frequency of the first block are weighted and calculated respectively to obtain a more accurate adaptive weight of the first block, thereby determining a more accurate number of leaf nodes of the first block tree corresponding to the first block, and finally improving the accuracy of consistency verification of the first block and the second block.

[0083] Based on the first embodiment of this application, in the third embodiment of this application, the content that is the same as or similar to that in the first embodiment can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 After step S30, the data migration method further includes steps S40 to S70:

[0084] Step S40: When switching the grayscale stream to the target database, monitor the grayscale switching metrics in real time; the grayscale switching metrics include synchronization latency rate, data difference rate, and error request rate.

[0085] Step S50: Determine the aggregation index based on the grayscale tangent index within the most recent preset time window;

[0086] Step S60: Determine the risk score of grayscale tangential flow based on the grayscale tangential flow index and the aggregation index;

[0087] Step S70: When the risk score is greater than the preset score threshold, or when the grayscale sliding index and the aggregation index are greater than their respective preset index thresholds, stop the grayscale sliding and perform a circuit breaker rollback.

[0088] During the gray-scale migration phase, dynamic monitoring and circuit breaker mechanisms are often lacking. If an anomaly occurs in the new database, the lack of an effective rollback mechanism can easily trigger large-scale business failures. To address this, this embodiment proposes a gray-scale migration mechanism that dynamically detects anomalies and supports automatic rollback.

[0089] In one embodiment, a canary rollout strategy is initiated, selecting traffic based on user ID or interface dimension. According to the canary rollout strategy, a small percentage of customer traffic is initially diverted: users are selected based on the modulo of UserID (UserID mod N), for example, users whose UserID%100<1 are considered the first 1% of canary rollout users. Alternatively, traffic can be divided according to interface functional modules; for example, newly launched services are prioritized for canary rollout, while core services are delayed. Alternatively, canary rollout may prioritize low-risk user groups such as internal test accounts and small groups of active users.

[0090] The core metrics for real-time monitoring of grayscale traffic switching include: synchronization delay rate (SyncDelay), data difference rate (DiffRate), i.e., verification inconsistency rate, and error request rate (ErrorRate), i.e., interface error rate. In one embodiment, aggregated metrics are determined based on the grayscale traffic switching metrics within the most recent preset time window. In this case, the synchronization delay rate (SyncDelay), data difference rate (DiffRate), and error request rate (ErrorRate) within the most recent preset time window t (e.g., 1 minute) can be weighted and combined to obtain an aggregated metric. .

[0091] In one embodiment, when determining the risk score of grayscale flow cutting based on grayscale flow cutting index and aggregation index, the risk score of grayscale flow cutting can be obtained by weighting each index according to the preset weight of each index.

[0092] When the risk score, gray-scale flow switching metric, or aggregation metric exceeds its corresponding preset threshold, the circuit breaker rollback is automatically triggered, i.e., gray-scale flow switching is stopped and a circuit breaker rollback is performed. In one embodiment, abnormal thresholds for each gray-scale flow switching metric are set, and each gray-scale flow switching metric is compared with the set threshold in real time. Typical thresholds are: DiffRate > 0.5%, SyncDelay > 5s, and ErrorRate > 0.2%. The set metric thresholds are as follows: a synchronization delay (SyncDelay) greater than 5 seconds indicates that the synchronization data is severely lagging; a data consistency difference (DiffRate) rate greater than 0.5% indicates that a large number of inconsistent records have appeared between the old and new databases; and a request error rate (ErrorRate) greater than 0.2% indicates that abnormal interface calls have begun to affect the user experience. Once any of the above metrics exceeds the set threshold, the circuit breaker condition is met. That is, the circuit breaker determination logic is: if any metric (such as synchronization delay, data difference rate, request error rate, etc.) exceeds its corresponding threshold, the system immediately triggers the circuit breaker mechanism. In other words, if the threshold is exceeded, the circuit breaker process will be triggered immediately without manual confirmation, pausing the grayscale and entering rollback.

[0093] During automatic rollback switching, user requests that have already been routed are redirected back to the old database route. In one embodiment, the API gateway or load balancer switches user requests back to the old database, suspending writes to the new database to prevent the spread of data pollution. Simultaneously, rollback operation logs and abnormal data snapshots are recorded for subsequent system recovery and audit tracing, forming a complete anomaly handling chain.

[0094] In one feasible implementation, step S60 may include steps S601 to S602:

[0095] Step S601: Based on the aggregation index and the first predictor of the previous grayscale sliding cycle, the second predictor of the current grayscale sliding cycle is obtained through exponential smoothing.

[0096] Step S602: Based on the weighted calculation of the gray-scale flow shunting index and the second predictive factor, the risk score of gray-scale flow shunting is obtained.

[0097] In this embodiment, another method is provided to determine the risk score of gray-scale flow cutting based on gray-scale flow cutting index and aggregation index. Specifically, in this method, the aggregation index is further converted into a predictor factor, and the risk score of gray-scale flow cutting is obtained by weighted calculation of gray-scale flow cutting index and predictor factor.

[0098] The aggregation index is determined based on the grayscale tangent index within the most recent preset time window. Then, based on the aggregation index The first predictor of the previous grayscale tangential flow cycle The second predictor for the current grayscale tangent cycle is obtained through exponential smoothing. : ,in, The exponential smoothing coefficient is recommended to be between 0.7 and 0.9, with a value closer to 0.9 for highly sensitive scenarios and 0.7 for stable scenarios. Next, based on the grayscale tangent index and the second predictor factor... The weighted calculation process yields the RiskScore for grayscale tangent flow:

[0099]

[0100] Where w1, w2, w3, and w4 are the weighting coefficients corresponding to each grayscale flow index, and w1 + w2 + w3 + w4 = 1. The default preferred values ​​are w1 = 0.2, w2 = 0.5, w3 = 0.2, and w4 = 0.1. , , The preset threshold values ​​for each grayscale flow metric are: Synchronization delay threshold (unit: seconds), default preferred. =5s; Data difference rate threshold (unit: %), default preferred. =0.5%; Error request rate threshold (unit: %), default preferred =0.2%.

[0101] In another feasible implementation, step S60 may include the following:

[0102] Determine the flow type of the grayscale flow and adjust the exponential smoothing coefficient used for exponential smoothing processing according to the flow type, and / or adjust the weighted calculation weights used for weighted calculation processing.

[0103] Before determining the risk score of grayscale flow cutting based on grayscale flow cutting index and aggregation index, the flow cutting type can be determined first, such as conservative (early warning priority), stable (avoid false triggering), or balanced (default). Different flow cutting types correspond to different coefficients, namely the exponential smoothing coefficient used for exponential smoothing processing. , and / or, the weighted calculation weights used for weighted calculation processing, such as w1, w2, w3, w4.

[0104] In one embodiment, for conservative grayscale flow cutting: increasing w4 (e.g., w4=0.2) and λ=0.9 makes it extremely sensitive to short-term anomalies, triggering pre-circuit breakage earlier and reducing the risk of fault propagation; for stable grayscale flow cutting: decreasing w4 (e.g., w4=0.05) and λ=0.7 makes it less sensitive to short-term fluctuations and reduces the probability of misjudgment rollback; for balanced grayscale flow cutting: w1=0.2, w2=0.5, w3=0.2, w4=0.1, λ=0.8 achieves a trade-off between accuracy and stability.

[0105] Therefore, by introducing predictive factors It can take protective measures (such as freezing traffic growth or limiting writes) before abnormal trends fully emerge, thereby reducing the frequency of rollbacks and business fluctuations, and improving the proactive protection capabilities and business continuity assurance level of gray-scale traffic switching.

[0106] Based on the first embodiment of this application, in the fourth embodiment of this application, the content that is the same as or similar to that in the first embodiment can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 4 The data migration method further includes steps T10 to T20:

[0107] Step T10: After a data change event occurs in the source database, record the first multi-dimensional event sequence vector corresponding to the data change event and the second multi-dimensional event sequence vector corresponding to the historical data change event that has been synchronously written to the target database. The first multi-dimensional event sequence vector includes the event sequence number corresponding to the data change event, the storage partition sequence number of the target data corresponding to the data change event in the message queue, and the global time logical clock. The second multi-dimensional event sequence vector includes the event sequence number corresponding to the historical data change event, the storage partition sequence number of the target data corresponding to the historical data change event in the message queue, and the global time logical clock.

[0108] Step T20: When the first multidimensional event sequence vector and the second multidimensional event sequence vector satisfy the preset event comparison rules, the target data after data changes in the source database is synchronized to the target database.

[0109] In one embodiment, after a data change event occurs in the source database and during the incremental log collection phase, a unified standard operation event structure is defined. The event includes core fields such as primary key, operation type, version number, timestamp, sequence number, and hash signature. First, when a data change operation (such as Insert, Update, or Delete) occurs in the source database, it is recorded and a Binlog log is generated. For example, the binlog_row_image parameter is configured to FULL in the database to fully record the change content. Second, the incremental log collection module subscribes to and captures the Binlog log in real time. For example, Debezium (an open-source distributed change data capture platform) + Kafka Connect (a distributed data integration platform) is configured to ensure low-latency event push. Next, the data change event is parsed to extract basic information such as table name, primary key, changed fields, and operation type. Simultaneously, the change event field format (including time format specifications, unified decimal point representation of values, NULL handling, etc.) and order are standardized. Then, a standard operation event object is encapsulated, and a hash is calculated as a digital signature. SHA-256 is preferably used for hash calculation, and the field concatenation order is kept stable to prevent hash deviation. Finally, the encapsulated event is pushed to the Kafka message queue, waiting for downstream synchronous consumption.

[0110] In another embodiment, the data synchronization processing module pulls operation events from the Kafka message queue in batches. First, it pulls events sequentially in batches, using the primary key as the partition key, with a maximum number of events per batch to reduce memory pressure. The batch size can be dynamically adjusted based on business concurrency, with 1000-5000 records per batch recommended. Second, it compares the version number of the current event in the source database with the current record in the target database: it queries the current record's Version number in the target database and compares it with the existing database version number Current.Version. If the event version number Event.Version < the existing database version number Current.Version, it indicates an outdated event and is discarded; if the current event Event.Version > DB.Version, it is considered a valid new event and can be written directly. If the version numbers match (Event.Version = DB.Version), the sequence number is further compared. The sequence number (SequenceID) is generated independently and incrementally by the incremental log collection module according to the primary key. For example, a memory counter is maintained for each primary key, automatically incremented by 1 each time a change event is generated. It is independent of the database transaction ID, ensuring that the event stream for the same primary key is strictly ordered. If Event.SequenceID <= Current.SequenceID, it indicates a duplicate or out-of-order replay event, which should be discarded to avoid dirty writes. If Event.SequenceID > Current.SequenceID, writing continues. If writing fails (e.g., due to network anomalies), the system will retry based on the event ID and primary key. However, based on idempotent verification rules, the write operation itself does not cause data corruption, ensuring consistency. Therefore, compared to incremental log collection methods that only compare timestamps or version numbers, which are prone to errors in network jitter scenarios, this embodiment prevents data overwriting or data loss due to latency or out-of-order delivery by simultaneously verifying the version number (Version) and the sequence number (SequenceID). Then, for legitimate events, they are entered into a sequential buffer queue and processed in order of sequence ID using a PriorityQueue (a min-heap sorted by SequenceID) to ensure strict sequential processing even for batch consumption. Finally, the event is synchronously written to a new database, performing insert or update operations, and updating the local idempotent control cache (such as Redis or an in-memory Map) after the write to record the latest Version and SequenceID. This approach introduces event sequence numbers and employs an independent incrementing mechanism based on the primary key dimension (such as an internal counter or Kafka offset derivation), combined with version numbers to control the synchronization order: under the same primary key, a write operation is only performed when the event sequence number is greater than the current sequence number of the target database record, and the version number is not lower than the target database version, ensuring that even in high-concurrency scenarios, data will not be out of order or lost.Moreover, through a strict idempotency determination mechanism, the data anomaly problems caused by event out-of-ordering and replay in traditional solutions are avoided.

[0111] In this embodiment, to address the issue that traditional single sequence numbers or version numbers cannot accurately determine the global order of events in scenarios involving multiple partitions, high concurrency, and asynchronous consumption across nodes, the single sequence number is further extended to a multi-dimensional event sequence vector (SEV). SEV can be denoted as: ,in, The primary key dimension represents a locally incrementing sequence number, i.e., the event sequence number corresponding to a data change event. A local counter is maintained for each primary key, and thread safety is ensured using atomic operations (CAS) or lightweight distributed locks. This refers to the sequence number (offset aligned) within the corresponding message middleware (such as Kafka), which is the storage partition sequence number of the target data corresponding to the data change event in the message queue. Message sequence numbers within a partition can be used to ensure order preservation within the same partition. A global logical clock spanning multiple partitions is preferred, ideally using a Lamport clock or a logical clock generated by combining millisecond-level timestamps with local logical counters (e.g., Timestamp << 20 | ProcessID << 10 | Counter). When the first multidimensional event sequence vector SEV-B and the second multidimensional event sequence vector SEV-A satisfy a preset event comparison rule (used to determine the order of SEV-A and SEV-B), the target data after data changes in the source database is synchronized to the target database. The preset event comparison rule can be: firstly, checking if the primary key is the same; if so, using the event sequence number corresponding to the data change event. The first layer determines the order of writes, used for absolute order control within the same primary key to prevent overwriting, duplicate writes, and out-of-order writes. The second layer determines the order when writing across primary keys, including the global time logical clock. Negative cross-node overall causal order, the sequence number of the target data corresponding to the data change event in the message queue's storage partition. Responsible for partition-level local ordering, using a global logical clock. and storage partition serial number The order is determined by the sequence of events. Through SEV's three-dimensional sequence determination logic, a consistent and provable order of events can be provided in distributed, multi-partition, and high-concurrency scenarios, significantly reducing data overwriting, loss, or out-of-order writes caused by cross-partition out-of-order processing, network replay, or consumption latency. This is superior to solutions relying solely on a single version number, improving the system's robustness and correctness.

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

[0113] This application also provides a data migration apparatus, please refer to... Figure 5 The data migration device includes:

[0114] The first module 10 is used to divide the source database and the target database into blocks after synchronizing the target data after the data changes in the source database to the target database, so as to obtain the first block of the source database and the second block of the target database.

[0115] The second module 20 is used to adjust the number of first leaf nodes used to construct the first block tree corresponding to the first block according to the access frequency and change frequency of the first block; and to adjust the number of second leaf nodes used to construct the second block tree corresponding to the second block according to the access frequency and change frequency of the second block.

[0116] The third module 30 is used to construct a first block tree based on the number of first leaf nodes, construct a second block tree based on the number of second leaf nodes, and perform consistency verification on the first block and the second block through the first block tree and the second block tree.

[0117] In one embodiment, the second module 20 is further configured to:

[0118] The adaptive weight of the first block is determined based on the access frequency and change frequency of the first block.

[0119] When the adaptive weight is greater than the preset weight threshold, the number of first leaf nodes used to construct the first block tree corresponding to the first block is increased;

[0120] When the adaptive weight is less than or equal to the preset weight threshold, the number of first leaf nodes used to construct the first block tree corresponding to the first block is reduced.

[0121] In one embodiment, the second module 20 is further configured to:

[0122] Before the step of determining the adaptive weight of the first block based on its access frequency and change frequency:

[0123] Determine the block type of the first block, where the block types include hot access blocks and frequently changing blocks;

[0124] Based on the block type of the first block, determine the first weight of the access frequency of the first block and the second weight of the change frequency of the first block;

[0125] The second module 20 is also used for:

[0126] The access frequency and change frequency of the first block are weighted according to the first weight and the second weight respectively to obtain the adaptive weight of the first block.

[0127] In one embodiment, the data migration apparatus further includes a fourth module for:

[0128] After the step of performing consistency verification on the first block and the second block using the first block tree and the second block tree:

[0129] When switching the stream to the target database in a grayscale manner, the grayscale switching metrics are monitored in real time. These metrics include synchronization latency rate, data difference rate, and error request rate.

[0130] The aggregation index is determined based on the grayscale tangent index within the most recent preset time window.

[0131] The risk score for grayscale shearing is determined based on the grayscale shearing index and the aggregation index.

[0132] If the risk score is greater than the preset score threshold, or if the grayscale flow slicing index and the aggregation index are greater than their respective preset index thresholds, the grayscale flow slicing will be stopped and a circuit breaker rollback will be performed.

[0133] In one embodiment, the fourth module is further configured to:

[0134] Based on the aggregation index and the first predictor of the previous grayscale tangent cycle, the second predictor of the current grayscale tangent cycle is obtained through exponential smoothing.

[0135] The risk score of grayscale flow is obtained by weighting the grayscale flow index and the second predictor.

[0136] In one embodiment, the fourth module is further configured to:

[0137] Before the step of determining the risk score of grayscale shearing based on grayscale shearing index and aggregation index:

[0138] Determine the flow type of the grayscale flow and adjust the exponential smoothing coefficient used for exponential smoothing processing according to the flow type, and / or adjust the weighted calculation weights used for weighted calculation processing.

[0139] In one embodiment, the data migration apparatus further includes a fifth module for:

[0140] After a data change event occurs in the source database, a first multidimensional event sequence vector corresponding to the data change event and a second multidimensional event sequence vector corresponding to the historical data change event that has been synchronously written to the target database are recorded. The first multidimensional event sequence vector includes the event sequence number corresponding to the data change event, the storage partition sequence number of the target data corresponding to the data change event in the message queue, and the global time logical clock. The second multidimensional event sequence vector includes the event sequence number corresponding to the historical data change event, the storage partition sequence number of the target data corresponding to the historical data change event in the message queue, and the global time logical clock.

[0141] When the first multidimensional event sequence vector and the second multidimensional event sequence vector satisfy the preset event comparison rules, the target data after the data change in the source database will be synchronized to the target database.

[0142] The data migration apparatus provided in this application, employing the data migration method described in the above embodiments, can solve the technical problem of difficulty in achieving real-time and efficient data migration consistency verification. Compared with the prior art, the beneficial effects of the data migration apparatus provided in this application are the same as those of the data migration method provided in the above embodiments, and other technical features in the data migration apparatus are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

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

[0144] The following is for reference. Figure 6 The diagram illustrates a structural schematic of a data migration device suitable for implementing embodiments of this application. The data migration device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The data migration device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of this application.

[0145] like Figure 6As shown, the data migration device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the data migration device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the data migration device to communicate wirelessly or wiredly with other devices to exchange data. While the figures show data migration devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

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

[0147] The data migration device provided in this application, employing the data migration method described in the above embodiments, can solve the technical problem of difficulty in achieving real-time and efficient data migration consistency verification. Compared with the prior art, the beneficial effects of the data migration device provided in this application are the same as those of the data migration method provided in the above embodiments, and other technical features of the data migration device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

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

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

[0150] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the data migration method described in the above embodiments.

[0151] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0152] The aforementioned computer-readable storage medium may be included in the data migration device; or it may exist independently and not be assembled into the data migration device.

[0153] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by a data migration device, the data migration device: after synchronizing the target data (after data changes) from the source database to the target database, divides the source and target databases into blocks to obtain a first block of the source database and a second block of the target database; adjusts the number of first leaf nodes used to construct the first block tree corresponding to the first block based on the access frequency and change frequency of the first block; adjusts the number of second leaf nodes used to construct the second block tree corresponding to the second block based on the access frequency and change frequency of the second block; constructs a first block tree based on the number of first leaf nodes, constructs a second block tree based on the number of second leaf nodes, and performs consistency verification on the first and second blocks using the first and second block trees.

[0154] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0155] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0156] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0157] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described data migration method, thereby solving the technical problem of difficulty in achieving real-time and efficient data migration consistency verification. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the data migration method provided in the above embodiments, and will not be repeated here.

[0158] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the data migration method described above.

[0159] The computer program product provided in this application can solve the technical problem of difficulty in achieving real-time and efficient data migration consistency verification. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the data migration method provided in the above embodiments, and will not be repeated here.

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

Claims

1. A data migration method, characterized by, The data migration method comprises: After synchronizing the changed data in the source database to the target database, the source database and the target database are divided into blocks to obtain a first block of the source database and a second block of the target database; According to the access frequency and change frequency of the first block, the number of first leaf nodes used to build a first block tree corresponding to the first block is adjusted; according to the access frequency and change frequency of the second block, the number of second leaf nodes used to build a second block tree corresponding to the second block is adjusted; Based on the number of first leaf nodes, the first block tree is constructed, based on the number of second leaf nodes, the second block tree is constructed, and the consistency of the first block and the second block is checked through the first block tree and the second block tree; The step of adjusting the number of first leaf nodes used to build the first block tree corresponding to the first block according to the access frequency and change frequency of the first block comprises: Determine the block type of the first block, wherein the block type includes hot access block and change frequent block; According to the block type of the first block, the first weight of the access frequency of the first block and the second weight of the change frequency of the first block are determined; wherein the first weight is increased in the real-time sensitive scene corresponding to the hot access block of the block type; the second weight is increased in the change high frequency scene corresponding to the change frequent block of the block type; According to the first weight and the second weight, the access frequency and the change frequency of the first block are weighted and calculated respectively to obtain the adaptive weight of the first block; When the adaptive weight is greater than the preset weight threshold, the number of first leaf nodes used to build the first block tree corresponding to the first block is increased; When the adaptive weight is less than or equal to the preset weight threshold, the number of first leaf nodes used to build the first block tree corresponding to the first block is reduced.

2. The data migration method of claim 1, wherein, The step of checking the consistency of the first block and the second block through the first block tree and the second block tree comprises: When gray cut flows to the target database, real-time monitoring of gray cut flow indicators is performed; wherein the gray cut flow indicators include synchronization delay rate, data difference rate and error request rate; According to the gray cut flow indicators in the recent preset time window, the aggregate indicators are determined; According to the gray cut flow indicators and the aggregate indicators, the risk score of gray cut flow is determined; When the risk score is greater than the preset score threshold, or the gray cut flow indicators and the aggregate indicators are greater than the respective preset indicator thresholds, the gray cut flow is stopped and the fuse rollback is performed.

3. The data migration method of claim 2, wherein, The step of determining the risk score of gray cut flow according to the gray cut flow indicators and the aggregate indicators comprises: According to the aggregate indicators and the first prediction factor of the last gray cut flow period, the second prediction factor of the current gray cut flow period is obtained through exponential smoothing processing; According to the weighted calculation processing of the gray cut flow indicators and the second prediction factor, the risk score of gray cut flow is obtained.

4. The data migration method of claim 3, wherein, The step of determining the risk score of the gray cut flow according to the gray cut flow index and the aggregation index comprises: determining the cut flow type of the gray cut flow, and adjusting the exponential smoothing coefficient for the exponential smoothing processing according to the cut flow type, and / or adjusting the weighted calculation weight for the weighted calculation processing.

5. The data migration method of claim 1, wherein, The method further comprises: After a data change event occurs in the source database, recording a first multi-dimensional event sequence vector corresponding to the data change event and a second multi-dimensional event sequence vector corresponding to a historical data change event that has been synchronously written into the target database, wherein the first multi-dimensional event sequence vector comprises an event sequence number corresponding to the data change event, a storage partition sequence number of the target data corresponding to the data change event in the message queue, and a global time logical clock, and the second multi-dimensional event sequence vector comprises an event sequence number corresponding to the historical data change event, a storage partition sequence number of the target data corresponding to the historical data change event in the message queue, and a global time logical clock; When the first multi-dimensional event sequence vector and the second multi-dimensional event sequence vector satisfy a preset event comparison rule, synchronizing the target data after the data change in the source database to the target database.

6. A data migration device, characterized by The device comprises a memory, a processor, and a computer program stored on the memory and executable on the processor, and the computer program is configured to implement the steps of the data migration method according to any one of claims 1 to 5.

7. A storage medium, characterized by The storage medium is a computer readable storage medium, and the storage medium stores a computer program, and the computer program is executed by the processor to implement the steps of the data migration method according to any one of claims 1 to 5.

8. A computer program product, characterised in that, The computer program product comprises a computer program, and the computer program is executed by the processor to implement the steps of the data migration method according to any one of claims 1 to 5.

Images