Data migration method, device, apparatus, medium, and product

Abstract

The present disclosure relates to the technical field of big data, and in particular, relates to a data migration method and device, equipment, medium and product, comprising: obtaining Pod features of a plurality of to-be-migrated database instances and node features of each candidate node in a database cluster; the Pod features include instance specifications, storage types, resource usage types, and the node features include computing resources, memory resources, storage resources, network delays, and network bandwidths. Resource usage prediction values of each candidate node are predicted based on the Pod features and the node features. Each candidate node is scored and sorted according to the resource usage prediction values, so as to select an optimal scheduling node from each candidate node. According to the type of each to-be-migrated database instance in the database cluster, each to-be-migrated database instance is sequentially migrated to the optimal scheduling node in the order of read-only libraries, backup libraries, and master libraries. The present disclosure can automatically adapt to multiple scenarios such as migration between different storage types, and can improve the flexibility of migration.

Description

Technical Field

[0001] This disclosure relates to the technical field of big data, and more specifically, to a data migration method, apparatus, device, medium, and product. Background Technology

[0002] Cloud-native MySQL data migration is the process of transferring data from one database system to another. Based on container orchestration platforms such as Kubernetes, cloud database MySQL enables rapid resource scheduling, fault recovery, and elastic scaling.

[0003] In related technologies, different migration plans, scheduling nodes and synchronization relationships are usually required for different migration scenarios. This can easily lead to uneven node load or resource fragmentation, resulting in insufficient flexibility in the data migration process. Summary of the Invention

[0004] This disclosure is made in view of the above-mentioned problems. This disclosure provides a data migration method, apparatus, device, medium, and product.

[0005] In a first aspect, embodiments of this disclosure provide a data migration method, comprising: Obtain the Pod characteristics of multiple database instances to be migrated, as well as the node characteristics of each candidate node in the database cluster. The Pod characteristics include instance specifications, storage type, and resource usage type, while the node characteristics include computing resources, memory resources, storage resources, network latency, and network bandwidth.

[0006] The resource usage prediction values ​​for each candidate node are predicted based on Pod features and node features.

[0007] The candidate nodes are scored and ranked according to the predicted resource usage values ​​in order to select the optimal scheduling node.

[0008] Based on the type of each database instance to be migrated in the database cluster, and in the order of read-only database, standby database, and primary database, each database instance to be migrated is migrated to the optimal scheduling node in sequence.

[0009] In one embodiment of the first aspect, migrating each database instance to be migrated sequentially to the optimal scheduling node includes: For database instances to be migrated that are of type read-only, a temporary read-only database is used to handle the traffic and migrate the database instances to the optimal scheduling node.

[0010] For database instances to be migrated that are of type standby and primary, a primary / standby database switchover method is used to migrate the database instances to the optimal scheduling node.

[0011] In one embodiment of the first aspect, a temporary read-only library is used to handle traffic, migrating the database instance to be migrated to the optimal scheduling node, including: Create a temporary read-only database and synchronize data with the primary database through the temporary read-only database.

[0012] Switch the business traffic from the read-only database to a temporary read-only database.

[0013] Migrate the read-only library to the optimal scheduling node.

[0014] In one embodiment of the first aspect, after migrating the read-only library to the optimal scheduling node, the method further includes: Switch business traffic from the temporary read-only database to the read-only database, and then delete the temporary read-only database.

[0015] In one embodiment of the first aspect, a primary / standby database switchover is used to migrate the database instance to be migrated to the optimal scheduling node, including: Prioritize migrating the backup database to the optimal scheduling node.

[0016] After the standby database completes the migration, a primary-standby database switchover is performed to switch the migrated standby database to the new primary database. Migrate the primary database to the optimal scheduling node.

[0017] In one embodiment of the first aspect, the method further includes: In a database cluster operating in a master-slave mode, the process prioritizes migrating the standby database to the optimal scheduling node.

[0018] or; In a database cluster operating in standalone mode, create a temporary backup database.

[0019] Data is synchronized with the primary database through a temporary standby database, and the standby mode is switched to the primary-standby mode.

[0020] In one embodiment of the first aspect, predicting the resource usage forecast for each candidate node includes: The Pod features and node features are input into the random forest model, and the random forest model outputs the predicted resource usage values ​​for each candidate node.

[0021] In one embodiment of the first aspect, the random forest model is trained in the following manner: Obtain historical resource usage data for cloud database instances and candidate nodes.

[0022] Samples are extracted from historical resource usage data using a bootstrap sampling method to construct multiple subsets; each subset corresponds to a decision tree.

[0023] A model-based feature fusion method is used to input the prediction results of each decision tree into the random forest model for training.

[0024] In one embodiment of the first aspect, ranking candidate nodes based on resource usage prediction values ​​to select the optimal scheduling node from among the candidate nodes includes: Based on the predicted resource usage values ​​of each candidate node, the candidate nodes are scored to obtain the scoring results.

[0025] Based on the scoring results, each candidate node is prioritized and ranked, and the candidate node with the highest priority is determined as the optimal scheduling node.

[0026] In a second aspect, embodiments of this disclosure provide a data migration apparatus, comprising: The feature acquisition unit is used to acquire the Pod features of multiple database instances to be migrated and the node features of each candidate node in the database cluster. The Pod features include instance specifications, storage type, and resource usage type, while the node features include computing resources, memory resources, storage resources, network latency, and network bandwidth.

[0027] The prediction unit is used to predict the resource usage of each candidate node based on Pod features and node features.

[0028] The node filtering unit is used to score and sort each candidate node based on the resource usage prediction value in order to select the optimal scheduling node from the candidate nodes.

[0029] The data migration unit is used to migrate each database instance to the optimal scheduling node in sequence, according to the type of each database instance to be migrated in the database cluster, in the order of read-only database, standby database, and primary database.

[0030] In a third aspect, embodiments of this disclosure provide an electronic device, including: a processor, a memory, and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the memory via the bus, and when the machine-readable instructions are executed by the processor, the steps in the above-described data migration method are performed.

[0031] In a fourth aspect, embodiments of this disclosure provide a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of the data migration method described above.

[0032] In a fifth aspect, embodiments of this disclosure provide a computer program product stored in a storage medium, the program product being executed by at least one processor to implement the steps in the data migration method described above.

[0033] As will be described in detail below, a data migration method, apparatus, device, medium, and product according to embodiments of this disclosure are disclosed. In embodiments of this disclosure, firstly, Pod characteristics of multiple database instances to be migrated and node characteristics of each candidate node in the database cluster are obtained; wherein, Pod characteristics include instance specifications, storage type, and resource usage type, and node characteristics include computing resources, memory resources, storage resources, network latency, and network bandwidth. Then, based on the Pod characteristics and node characteristics, the predicted resource usage values ​​of each candidate node are predicted. Each candidate node is scored and ranked according to its predicted resource usage values ​​to select the optimal scheduling node. Finally, according to the type of each database instance to be migrated in the database cluster, and in the order of read-only database, standby database, and primary database, each database instance to be migrated is sequentially migrated to the optimal scheduling node. By using the above processing method, the resource requirements of the database instance to be migrated can be accurately described by obtaining the Pod characteristics of the instance. By obtaining the multi-dimensional node characteristics of each candidate node, the resource supply capacity of each node can be comprehensively evaluated. Based on the resource usage prediction values ​​determined by these two types of data, the optimal node with the most abundant resources and most suitable for running the database instance to be migrated can be automatically selected from multiple candidate nodes. Then, through a unified migration control logic, that is, to migrate in the order of read-only database, standby database, and primary database, it can automatically adapt to various complex scenarios such as node failure migration and migration between different storage types. There is no need to develop a separate migration plan for each scenario, which can greatly improve the flexibility of the migration process.

[0034] It should be understood that both the foregoing general description and the following detailed description are exemplary and intended to provide further illustration of the claimed technology. Attached Figure Description

[0035] The above and other objects, features, and advantages of this disclosure will become more apparent from the more detailed description of the embodiments thereof in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this disclosure and form part of the specification. They are used together with the embodiments of this disclosure to explain the disclosure and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0036] Figure 1 This is a flowchart of a data migration method according to an embodiment of the present disclosure.

[0037] Figure 2 This is a flowchart illustrating a read-only library migration process according to an embodiment of this disclosure.

[0038] Figure 3 This is a flowchart of a master database migration process according to an embodiment of the present disclosure.

[0039] Figure 4This is a flowchart illustrating a data migration process according to an embodiment of the present disclosure.

[0040] Figure 5 This is a schematic diagram of a data migration apparatus according to an embodiment of the present disclosure.

[0041] Figure 6 This is a schematic diagram of an electronic device according to an embodiment of the present disclosure.

[0042] Figure 7 This is a schematic diagram of a computer program product according to an embodiment of the present disclosure. Detailed Implementation

[0043] To make the objectives, technical solutions, and advantages of this disclosure more apparent, exemplary embodiments according to this disclosure will now be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this disclosure, and not all embodiments of this disclosure. It should be understood that this disclosure is not limited to the exemplary embodiments described herein.

[0044] To facilitate understanding of this embodiment, a data migration method disclosed in this disclosure will first be described in detail. This data migration method can be applied to a data management platform. See [link to relevant documentation]. Figure 1 The diagram shows a flowchart of a data migration method provided in an embodiment of this disclosure. The method includes steps S101 to S104, wherein: Step S101: Obtain the Pod characteristics of multiple database instances to be migrated and the node characteristics of each candidate node in the database cluster; wherein, the Pod characteristics include instance specifications, storage type, and resource usage type, and the node characteristics include computing resources, memory resources, storage resources, network latency, and network bandwidth.

[0045] In this embodiment, the main components include a migration-operator node migration control module and a migration-scheduler node migration scheduling module, which control the node migration and node scheduling of the database container, respectively.

[0046] Specifically, the node migration control module supports cloud database migration in various complex scenarios, such as node failure, insufficient node resources, different storage clusters, cross availability zones, cross Kubernetes clusters, and different storage types (e.g., CEPH cloud disks, ESSD cloud disks, or local disks). It is compatible with various database deployment architectures (e.g., master-slave, single-machine, and read-only), ensuring high availability of database connections during cloud database migration.

[0047] The node migration scheduling module is used to calculate the migration container specifications, match node resource usage and predict node resource usage, and determine the container scheduling node according to the node pre-selection and node optimization steps to ensure the optimization of container scheduling nodes and reduce the node migration failure rate.

[0048] In this embodiment of the disclosure, the Pod characteristics of multiple database instances to be migrated can be obtained first. The Pod characteristics are a set of parameters that describe the resource requirements of the database instances to be migrated and are used to characterize the resource requirements of the database instance on the target node during scheduling.

[0049] Pod characteristics include instance specifications, storage type, and resource usage type. Instance specifications refer to the resource requests defined for the database instance to be migrated within the Kubernetes cluster, which may include the number of CPU cores and memory size. Instance specifications reflect the minimum resource guarantees required for the normal operation of the database instance and are one of the core filtering conditions in the node pre-selection phase.

[0050] Storage type refers to the type of persistent storage used by the database instance to be migrated. In containerized deployment scenarios, database instances typically declare storage requirements through Persistent Volume Claims (PVCs) and specify the storage backend type through StorageClass. Common storage types include CEPH cloud disks, ESSD cloud disks, and local disks. Different storage types have significant performance differences in terms of I / O operations per second, throughput, and latency. Furthermore, when migrating between nodes of different storage types, storage volume reconstruction and data synchronization need to be completed under the coordination of the migration controller.

[0051] Resource usage type refers to the resource configuration mode of the database instance to be migrated, including but not limited to dedicated and general-purpose. Dedicated instances mean that the instance exclusively uses all or most of the resources of the scheduled node, which is suitable for production environments with high requirements for performance isolation; general-purpose instances allow multiple instances to share the resources of the same node, which is suitable for cost-sensitive scenarios.

[0052] After that, you can also obtain the node characteristics of each candidate node in the database cluster. The node characteristics are a set of parameters that describe the resource supply capacity of each candidate node in the Kubernetes cluster, and are used to characterize the resource status of the node that can currently be used to host the newly scheduled database instance.

[0053] Node characteristics include computing resources, memory resources, storage resources, network latency, and network bandwidth. Computing resources refer to the total CPU resources of the node and their current availability. Specifically, the total number of CPU cores and the number of allocable cores can be obtained from the `Capacity` and `Allocatable` fields in the node's `NodeStatus` information via the Kubernetes API.

[0054] Memory resources: refers to the total amount of memory resources of a node and the current available amount. The total memory capacity and allocable capacity of a node can also be obtained through the Kubernetes API.

[0055] Storage resources refer to the total local storage capacity of a node and its current remaining capacity. Storage resources are used to assess whether a node has sufficient local storage space to store database instance log files, temporary files, etc.

[0056] Network latency refers to the round-trip time for network communication between a node and other nodes in the cluster. Network latency directly affects the efficiency and stability of database master-slave replication, especially in migration scenarios across availability zones, where network latency differences between different nodes can be significant. Network latency can be collected by sending ICMP probe packets between nodes or by monitoring data provided by Kubernetes network plugins (such as Cilium and Calico).

[0057] Network bandwidth: This refers to the available network bandwidth of a node. Network bandwidth reflects the maximum data transfer rate a node can support and has a significant impact on data synchronization and log transmission during database migration. Network bandwidth can be obtained through monitoring data from the node's network interface, such as the ratio of the node's current network throughput to its maximum bandwidth.

[0058] In this embodiment of the disclosure, the API Server can be used to query the Pod resource object corresponding to the database instance to be migrated, and the instance specification, storage type and resource usage type can be extracted from its Spec field. The API Server can also be used to query the Node resource objects of all candidate nodes in the cluster, and the computing resource and memory resource information can be extracted from their Status field. Storage resource, network latency and network bandwidth information can be collected through the node monitoring component. Finally, the Pod features and node features are stored in a structured form as feature vectors as input data for subsequent resource usage prediction steps.

[0059] In the above implementation, by acquiring multi-dimensional Pod and node characteristics, the scheduling requirements of the database instance and the resource supply capacity of each node can be comprehensively described, providing a sufficient data foundation for subsequent resource usage prediction and optimal node selection, effectively avoiding scheduling deviations caused by incomplete information, thereby improving the operational stability and resource utilization efficiency of the migrated database instance.

[0060] Step S102: Predict the resource usage of each candidate node based on Pod features and node features.

[0061] In this embodiment of the disclosure, based on the Pod characteristics of the database instance to be migrated and the node characteristics of the candidate nodes, the resource usage prediction value of each candidate node is predicted. Thus, the resource usage status of the node after scheduling can be evaluated in advance based on the resource usage prediction value before the database instance is actually scheduled to a certain node, thereby avoiding scheduling the instance to a node with high resource pressure or instability.

[0062] Step S103: Score and sort each candidate node according to the resource usage prediction value, so as to select the optimal scheduling node from each candidate node.

[0063] In this embodiment of the disclosure, for candidate nodes with high predicted resource usage values, it indicates that scheduling the database instance to be migrated to the node will put a lot of pressure on the node's resource usage, which will affect the operational stability of the database instance. Therefore, a deduction strategy is implemented for the node. For candidate nodes with low predicted resource usage values, it indicates that the node has sufficient resources and is suitable for hosting the database instance to be migrated. Therefore, a bonus strategy is implemented for the node or the original score is maintained.

[0064] Furthermore, after scoring each candidate node, this disclosure prioritizes all candidate nodes based on the scoring results, so as to determine the candidate node with the highest score as the optimal scheduling node.

[0065] In the above embodiments, through the above scoring and sorting mechanism, this disclosure can automatically select the optimal scheduling node with the most abundant resources and the most suitable for running the database instance to be migrated from multiple candidate nodes, thereby avoiding the problem of uneven load and resource fragmentation caused by improper node selection to a certain extent, and thus improving the accuracy of the data migration process.

[0066] Step S104: Based on the type of each database instance to be migrated in the database cluster, migrate each database instance to the optimal scheduling node in the order of read-only database, standby database, and primary database.

[0067] In this embodiment of the disclosure, each database instance to be migrated can be migrated to the optimal scheduling node in sequence according to the type of each database instance in the database cluster, namely read-only database, standby database, and primary database.

[0068] This disclosure adopts a migration mechanism that prioritizes the migration of read-only databases, followed by backup databases, and finally the primary database.

[0069] Specifically, read-only databases should be migrated first: Read-only databases typically handle read requests from the business side and do not participate in data writing to the primary database. Migrating read-only databases first allows for the gradual migration of read databases without affecting business read requests, reducing migration complexity. Simultaneously, migrating read-only databases verifies the availability of the optimal scheduling node and the correctness of the migration process.

[0070] The standby database is migrated secondarily: The standby database maintains data synchronization with the primary database but does not directly handle business write requests. After the read-only database migration is complete, the standby database is migrated. Leveraging the standby database's mirroring feature as the primary database, it maintains data synchronization with the primary database during the migration process, ensuring no data loss. Once migrated, the standby database can serve as the target node for subsequent primary database switching.

[0071] The primary database is migrated last: The primary database handles business write requests and is the most critical node in the entire database cluster. By performing the primary database migration only after the preceding read-only and standby database migrations are completed, it can be ensured that a fully migrated and synchronized standby database is available to handle business traffic at the moment of switchover, thus achieving a seamless primary database migration for the business.

[0072] In the above implementation, by obtaining the Pod characteristics of the database instance to be migrated, the resource requirements of the instance for the scheduling node can be accurately described. By obtaining the multi-dimensional node characteristics of each candidate node, the resource supply capacity of each node can be comprehensively evaluated. Based on the resource usage prediction values ​​determined by these two types of data, the optimal node with the most abundant resources and most suitable for running the database instance to be migrated can be automatically selected from multiple candidate nodes. Then, through a unified migration control logic, that is, migration is carried out in the order of read-only database, standby database, and primary database, which can automatically adapt to various complex scenarios such as node failure migration and migration between different storage types. There is no need to develop a separate migration plan for each scenario, which can greatly improve the flexibility of the migration process.

[0073] In an optional implementation, the above steps sequentially migrate each database instance to the optimal scheduling node, specifically including the following steps: For database instances to be migrated that are of type read-only, a temporary read-only database is used to handle the traffic and migrate the database instances to the optimal scheduling node.

[0074] For database instances to be migrated that are of type standby and primary, a primary / standby database switchover method is used to migrate the database instances to the optimal scheduling node.

[0075] This disclosure implements high-availability automatic migration and optimal scheduling of database containers through a cloud MySQL migration controller.

[0076] For different types of database migration (e.g., storage cluster migration, availability zone migration, cross-cluster migration, and storage type migration), control the migration order and execution steps of pods in the database cluster. Specify a dedicated scheduler schedulerName: migration-scheduler to control the database migration nodes and ensure optimal scheduling of database containers.

[0077] For different database architectures (e.g., master-slave, single-machine, and read-only), the migration controller is divided into a read-only database migration controller and a master-slave migration controller, which control the migration of read-only databases and master-slave databases respectively, thus enabling migration capabilities for different database architectures.

[0078] To ensure high availability of read-only database connections during migration and to ensure that user read-only direct connections or read-only proxy connections are not affected, this disclosure designs a temporary read-only database to carry the original read-only database request traffic. During the read-only database migration process, each read-only database connection is forwarded to the temporary read-only database in turn. After the migration is completed, the connection requests are switched back to the original read-only database, and the resources of the read-only database are cleaned up.

[0079] This disclosure performs the migration operation of the primary and standby databases after verifying that all read-only databases have been migrated. Since the standby database does not involve client connections, assuming the database cluster is in normal condition, the migration can be achieved simply by redoing the standby database using the database to be migrated (sc). There are two scenarios for primary database migration: if it is in single-machine mode, a new standby database needs to be created, and the database temporarily converted to primary-standby mode for migration; if it is in primary-standby mode, the migration is completed by switching over from primary to standby and redoing the original primary database.

[0080] In this embodiment, differentiated migration strategies are designed for three types of database instances: read-only databases, standby databases, and primary databases. Specifically, for read-only databases, a temporary read-only database is created to handle business traffic, and the traffic is seamlessly switched back to the original read-only database after the migration is complete, ensuring that read requests are not interrupted during the migration process. For standby and primary databases, the process involves prioritizing the migration of the standby database, performing a primary-standby switchover to transfer business to the migrated standby database, and then migrating the original primary database, ensuring that write requests are not interrupted during the migration process.

[0081] In the above embodiments, the differentiated migration strategy proposed in this disclosure jointly achieves business-unawareness and high availability assurance throughout the entire database migration process, thereby adaptively executing the corresponding migration process without requiring operation and maintenance personnel to manually adjust the migration plan according to different architectures, thus effectively improving the flexibility and automation of the data migration process.

[0082] In an optional implementation, the above steps employ a temporary read-only database to handle traffic, migrating the database instance to be migrated to the optimal scheduling node. Specifically, the steps include the following: Create a temporary read-only database and synchronize data with the primary database through the temporary read-only database.

[0083] Switch the business traffic from the read-only database to a temporary read-only database.

[0084] Migrate the read-only library to the optimal scheduling node.

[0085] In an optional implementation, after migrating the read-only library to the optimal scheduling node, the method further includes the following steps: Switch business traffic from the temporary read-only database to the read-only database, and then delete the temporary read-only database.

[0086] See Figure 2 The diagram shown is a flowchart of a read-only library migration process provided in an embodiment of this disclosure.

[0087] S201: Construct a temporary read-only database template based on the read-only database template and the list of read-only databases in the database cluster.

[0088] S202: Create a temporary read-only database based on the temporary read-only database template, and synchronize data with the primary database through the temporary read-only database.

[0089] S203: Switch the business traffic of the read-only database to a temporary read-only database.

[0090] S204: Migrate the read-only library to the optimal scheduling node.

[0091] S205: Switch business traffic from temporary read-only database to read-only database.

[0092] S206: Delete the temporary read-only database.

[0093] This disclosure first checks whether the database cluster status is ready. If not, it waits for the next enqueue processing. Then, it traverses the list of read-only databases in the database cluster. If no read-only database exists, the read-only database migration process is skipped. If a read-only database exists, it checks whether there is an ongoing migration task. If there is an ongoing migration task, it waits for the current migration task to complete before continuing processing. If there is no ongoing migration task, the read-only database migration process is performed.

[0094] Furthermore, this disclosure begins migrating the current read-only database when no other migration tasks are found. It checks whether a temporary read-only database has been created; if not, it constructs a temporary read-only database template using read-only database template information (including CPU, memory, storage type, storage size, availability zone, tags, and affinity, etc.) to ensure the temporary read-only database is compatible with traffic switching across different read-only databases.

[0095] Then, a temporary read-only database container is created. This involves creating a temporary read-only database on the optimal scheduling node, starting the MySQL database service, copying the source database (master database) ibd file (e.g., table data and indexes) to the target directory of the read-only database container ( / var / lib / mysql), and importing the ibd file to complete the migration of existing data. Finally, the GTID protocol is used to establish a synchronization relationship with the master database, completing the data synchronization between the temporary read-only database and the master database.

[0096] Based on this, the status and synchronization latency of the temporary read-only database are checked. Once the status is ready, the svcselector of the read-only database is modified to redirect access traffic to the temporary read-only database. Next, the read-only database is rebuilt using the storage cluster to be migrated (storageClass). The rebuild process involves deleting the statefulet or deployment resources and PVC resources bound to the original read-only database pod, then creating the relevant read-only database resources according to the storage cluster to be migrated (storageClass), and resynchronizing the data with the primary database.

[0097] Finally, check the status of the read-only database. Once the status is ready, modify the corresponding SVC selector for the temporary read-only database and then switch traffic back to the read-only database. Repeat the above steps to complete the migration of the other read-only databases. After verifying that all SVC selectors for each read-only database have been restored, clean up the temporary read-only database resources. At this point, the migration of all read-only databases is complete.

[0098] In the above implementation, by creating a temporary read-only database to handle business traffic and seamlessly switching the traffic back to the original read-only database after the migration is complete, uninterrupted business read requests are achieved throughout the entire read-only database migration process. Moreover, the instantaneous switching of traffic is completely transparent to the business side, and the application does not need to modify any configuration or restart, thus eliminating the risk of business downtime caused by read-only database migration.

[0099] In an optional implementation, the above steps employ a primary / standby database switchover method to migrate the database instance to be migrated to the optimal scheduling node, specifically including the following steps: Prioritize migrating the backup database to the optimal scheduling node.

[0100] After the standby database completes the migration, a primary-standby database switchover is performed to switch the migrated standby database to the new primary database. Migrate the primary database to the optimal scheduling node.

[0101] In an optional implementation, the above steps and methods further include the following steps: In a database cluster operating in a master-slave mode, the process prioritizes migrating the standby database to the optimal scheduling node.

[0102] or; In a database cluster operating in standalone mode, create a temporary backup database.

[0103] Data is synchronized with the primary database through a temporary standby database, and the standby mode is switched to the primary-standby mode.

[0104] See Figure 3 The diagram shown is a flowchart of a master database migration process provided in an embodiment of this disclosure.

[0105] S301: After the database cluster is ready, check the database cluster mode.

[0106] S302: In the case of a database cluster in master-slave mode, perform master-slave database switchover.

[0107] S303: Switch the migrated standby database to the new primary database.

[0108] S304: Create a temporary standby database when the database cluster is in stand-alone mode.

[0109] S305: Synchronizes data with the primary database through a temporary standby database and switches the standby mode to the primary-standby mode.

[0110] S306: Migrate the master database to the optimal scheduling node.

[0111] As mentioned earlier, there are two scenarios in the primary database migration process in this disclosure. If it is a standalone mode, a standby database needs to be created and temporarily converted into a primary-standby mode for migration. If it is a primary-standby mode, the migration is completed by switching from primary to standby and rebuilding the original primary database.

[0112] Specifically, first check if the database cluster status is ready, and after confirming that the database cluster status is ready, check the database cluster mode.

[0113] If the cluster mode is a standalone mode, create a temporary standby database using the storage cluster's storageClass to be migrated, and establish a connection between the temporary standby database and the standalone primary database to synchronize data. Once the newly created temporary standby database is ready, perform a primary-standby switchover operation, switching the temporary standby database of the migrated storage cluster to the new primary database, and the original primary database to the new standby database. After the primary-standby switchover is completed, delete the original primary database, release the corresponding resources, and restore the cluster mode to standalone mode.

[0114] If the cluster mode is master-slave mode, since the slave database has already been migrated in the previous step, you only need to perform a master-slave switchover operation to switch the slave database to the new master database.

[0115] Next, follow the backup database migration process to complete the migration of the original primary database.

[0116] The standby database migration process also needs to check whether the database cluster status is ready. After confirming that the database cluster status is ready, the standby database information of the database cluster is queried based on the role.

[0117] If no standby database information is available, skip the standby database migration process. If standby database information is available, redo the standby database using the migration storage cluster's storageClass. The redo steps include deleting the statefulets or deployment resources and PVC resource pools bound to the original standby database pod. Then, create a new standby database according to the storageClass to be migrated, copy the source database (primary database) ibd file (table data and indexes) to the target directory ( / var / lib / mysql) of the standby database container, import the ibd file, and then use the GTID protocol to establish a synchronization relationship with the primary database to complete data synchronization. Once the standby database is ready, the migration is complete.

[0118] Finally, after the original primary database migration is complete, the migration controller checks whether the cluster status is normal and deletes the migration flag. At this point, the automatic migration operation of the primary database is complete.

[0119] The above implementation achieves uninterrupted write requests during the primary database migration process through a three-step process: prioritizing the migration of the standby database, performing a primary-standby switchover to transfer services to the migrated standby database, and then migrating the original primary database. At the MySQL level, the primary-standby switchover process ensures strong data consistency through the GTID protocol, while at the business level, seamless traffic transfer is achieved through Service selector switching, ensuring complete data consistency before and after the migration and uninterrupted business writes.

[0120] In this embodiment, a combination of two mechanisms—temporary read-only database handling of traffic and primary / standby failover—achieves seamless business operation throughout the database migration process: the former ensures the continuity of read requests, while the latter ensures the continuity of write requests. These two mechanisms are deployed for database instances with different roles. This role-differentiated migration strategy makes the migration process completely transparent to the business side, significantly improving the flexibility and availability of cloud database migration.

[0121] In an optional implementation, the above steps predict the resource usage forecast for each candidate node, specifically including the following steps: The Pod features and node features are input into the random forest model, and the random forest model outputs the predicted resource usage values ​​for each candidate node.

[0122] In an optional implementation, the random forest model described above is trained in the following manner: Obtain historical resource usage data for cloud database instances and candidate nodes.

[0123] Samples are extracted from historical resource usage data using a bootstrap sampling method to construct multiple subsets; each subset corresponds to a decision tree.

[0124] A model-based feature fusion method is used to input the prediction results of each decision tree into the random forest model for training.

[0125] The kube-scheduler is one of the core components of Kubernetes, primarily responsible for scheduling the resources of the entire cluster. Based on specific scheduling algorithms and strategies, it schedules pods to the optimal worker nodes.

[0126] However, the kube-scheduler scheduler is not yet perfect for scheduling needs in different scenarios. Therefore, a dedicated migration scheduler, migration-scheduler, was designed and developed specifically for cloud database migration scenarios. Combining Kubernetes scheduling strategies and a random forest model, it predicts node resource usage in advance and makes decisions on container node scheduling. It registers with the scheduler via a plugin, without relying on external plugins or HTTP calls, accurately selecting the optimal node for migrating database pods. To use it, a custom dedicated scheduler is explicitly specified in the cloud database pod using the following method: spec.schedulerName: migration-scheduler.

[0127] Specifically, this includes container creation, event listening, queue processing, node pre-selection, random forest model node resource feature prediction, and node selection.

[0128] First, create a container: explicitly specify the schedulerName parameter in the container template as the migration-scheduler dedicated scheduler.

[0129] Then, event listening is performed: based on the Informer mechanism, watch apiserver listens for pod events in the cluster and puts pods with schedulerName set to migration-scheduler and spec.nodeName empty into the migration-scheduler scheduler queue.

[0130] Queue processing: Pop a migration pod from the scheduling queue, obtain the pod's pre-selection parameters, and prepare to start the node pre-selection process.

[0131] Node pre-selection: Selecting suitable node nodes for pod allocation. Based on pre-selection parameters retrieved from pod attributes, including CPU, memory, nodeSelector, and nodeAffinity, a candidate list of nodes that meet the requirements is filtered out.

[0132] Random forest model node resource feature prediction: First, collect the instance resource features of the database instance scheduling pod and the resource features of the pre-selected nodes to construct a dataset, that is, obtain the historical resource usage data of the cloud database instance and candidate nodes. This historical resource usage data includes resource usage data corresponding to CPU, memory, disk I / O, container specifications, node type, request throughput, and network latency, etc.

[0133] The constructed dataset is then split into training and testing sets, with 80% used for training and 20% for testing. Samples are extracted from the historical resource usage data in the split training set using bootstrap sampling to form multiple subsets.

[0134] Each subset is constructed by randomly sampling a portion of the training set with replacement, and each subset is the same size as the training set.

[0135] For each subset of data, this disclosure constructs a decision tree. At each node, a subset of features is randomly selected for splitting; the number of randomly selected features is equal to the square root or logarithm of the total number of features. By introducing randomness, the diversity of each decision tree is ensured. The above steps are repeated until a specified number of decision trees are generated.

[0136] Furthermore, this disclosure uses a model-based feature fusion method to fuse resource features, which can effectively capture the nonlinear relationships between feature subsets.

[0137] Specifically, first train the base model: using each feature subset Train the base models separately The prediction results are then output. The prediction results from the base model are then used as new features. It is the prediction result of the i-th decision tree, and the prediction results of each decision tree are concatenated and input into the random forest model.

[0138] Among them, the base model predicts: Where C is the number of categories, Let be the probability that sample i belongs to category c.

[0139] The result of splicing the predictions from each decision tree: .

[0140] Random Forest Model Training: .

[0141] In this embodiment of the disclosure, the independent prediction results of each decision tree are obtained through training, and the average value of the prediction results of all trees is calculated as the final output. Finally, the average value of the prediction results of all trees is calculated according to the prediction model to serve as the resource usage prediction value of each pre-selected node, that is, the resource usage prediction value of each candidate node is output by the random forest model.

[0142] In the above implementation, a random forest model is used to predict resource usage, and multiple decision trees are trained by constructing multiple subset datasets through bootstrapping. The prediction results of each decision tree are combined to output the predicted value of resource usage. This can more accurately predict the actual resource status of nodes after scheduling new instances, thereby improving the accuracy of selecting the optimal scheduling node while improving the prediction accuracy.

[0143] In an optional implementation, the above steps involve scoring and ranking each candidate node based on resource usage prediction values ​​to select the optimal scheduling node from among the candidate nodes, specifically including the following steps: Based on the predicted resource usage values ​​of each candidate node, the candidate nodes are scored to obtain the scoring results.

[0144] Based on the scoring results, each candidate node is prioritized and ranked, and the candidate node with the highest priority is determined as the optimal scheduling node.

[0145] In this embodiment of the disclosure, the initial score of each candidate node can be obtained based on the scoring strategy of the Kubernetes default scheduler. The default scheduling strategy includes, but is not limited to, resource balancing strategy, resource adaptation strategy, and node affinity strategy.

[0146] The resource balancing strategy evaluates the balance of resource allocation after scheduling a new Pod, with nodes scoring higher for more balanced CPU and memory usage. The resource adaptation strategy assesses whether a node meets the resource request and limit requirements of a Pod. The node affinity strategy assesses whether a node meets the affinity or anti-affinity rules for Pods. Using these default scheduling strategies, each candidate node receives an initial score.

[0147] Based on the default scheduling strategy score, the initial score is adjusted according to the resource usage prediction values ​​of each candidate node output by the random forest model to obtain the final score of each candidate node.

[0148] The adjustment rules proposed in this disclosure can be set as follows: nodes whose resource usage prediction values ​​exceed a preset threshold will have points deducted, nodes whose resource usage prediction values ​​are lower than the preset threshold will have points added, and nodes whose resource usage prediction values ​​are in the middle range will retain their original scores.

[0149] After completing the comprehensive scoring of each candidate node, all candidate nodes are prioritized according to the final scoring results: the higher the score, the higher the priority.

[0150] After sorting, the candidate node with the highest priority is determined as the optimal scheduling node. Specifically, the migration scheduler calls the Kubernetes API Server to perform a node binding operation, setting the spec.nodeName property of the Pod corresponding to the database instance to be migrated to the name of the optimal scheduling node, thus completing the node binding.

[0151] If multiple candidate nodes have the same score and are all the highest score, then further selection is performed according to the following secondary selection strategy: Prioritize nodes whose node labels match the Pod affinity rules more closely; prioritize nodes whose availability zones are closer to the current availability zone of the database instance to be migrated; if the above strategies still cannot distinguish them, randomly select one of the nodes as the optimal scheduling node.

[0152] In the above embodiments, by comprehensively scoring each candidate node based on the predicted resource usage value of each candidate node, and prioritizing the nodes according to the scoring results to determine the optimal scheduling node, the scheduling decision is automated and intelligent. The scoring and ranking mechanism of this disclosure can more comprehensively and proactively evaluate the scheduling suitability of each node, effectively avoiding the problems of uneven load and resource fragmentation caused by improper node selection, thereby improving the flexibility of the data migration process and the operational stability of the database instance after migration.

[0153] The following is combined Figure 4 The above data migration process is described in detail below: S401: Obtain the Pod characteristics of multiple database instances to be migrated and the node characteristics of each candidate node in the database cluster.

[0154] Here, Pod characteristics include instance specifications, storage type, and resource usage type, while node characteristics include computing resources, memory resources, storage resources, network latency, and network bandwidth.

[0155] S402: Predict resource usage for each candidate node based on Pod and node characteristics.

[0156] S403: Score and rank each candidate node based on the predicted resource usage values ​​to select the optimal scheduling node from among the candidate nodes.

[0157] S404: Determine the type of each database instance to be migrated in the database cluster.

[0158] S405: For database instances of type read-only that are to be migrated, a temporary read-only database is used to handle the traffic and migrate the database instances to the optimal scheduling node.

[0159] S406: For database instances of type standby and primary, the primary / standby database switching method is used to migrate the database instances to the optimal scheduling node.

[0160] In this embodiment, before migrating the cloud database, the database cluster status, schedulable node resources, and backup database are checked to assess whether the instance meets the migration conditions. Container traffic for the database to be migrated is promptly forwarded to the backup database to ensure that read and write operations on the migrated database are unaffected during the migration process. During migration, the migration-scheduler, based on its design, selects the optimal node for resource matching to schedule the migrated database. After migration, the status of the migrated database is checked; if the status is normal, traffic is switched back to the original migrated database, and unused backup databases are cleaned up. This disclosure achieves efficient containerized migration of cloud databases while ensuring optimal scheduling of container migration nodes.

[0161] In the above implementation, a dedicated node scheduler accurately selects and schedules nodes, solving the difficulties of cloud database migration in various scenarios and overcoming the bottleneck of the default scheduler's scheduling decision, effectively improving the success rate and accuracy of node migration. The node migration controller automatically controls the migration order and process of various types and scenarios of cloud database MySQL, providing methods for handling various abnormal situations during the migration process, and supporting various migration requirements (e.g., availability zones, storage types, cross-k8s clusters and storage clusters, etc.), thereby providing a complete high-availability cloud database migration solution, ensuring optimal performance of migration nodes, and effectively reducing the migration failure rate.

[0162] Based on the same inventive concept, this disclosure also provides a data migration device corresponding to the data migration method. Since the principle of the device in this disclosure for solving the problem is similar to the data migration method described above in this disclosure, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0163] Reference Figure 5 The diagram shown is a schematic representation of a data migration device provided in an embodiment of this disclosure. The device includes: a feature acquisition unit 50, a prediction unit 51, a node filtering unit 52, and a data migration unit 53; wherein: The feature acquisition unit is used to acquire the Pod features of multiple database instances to be migrated and the node features of each candidate node in the database cluster. The Pod features include instance specifications, storage type, and resource usage type, while the node features include computing resources, memory resources, storage resources, network latency, and network bandwidth.

[0164] The prediction unit is used to predict the resource usage of each candidate node based on Pod features and node features.

[0165] The node filtering unit is used to score and sort each candidate node based on the resource usage prediction value in order to select the optimal scheduling node from the candidate nodes.

[0166] The data migration unit is used to migrate each database instance to the optimal scheduling node in sequence, according to the type of each database instance to be migrated in the database cluster, in the order of read-only database, standby database, and primary database.

[0167] In one possible implementation, the device is also used for: For database instances to be migrated that are of type read-only, a temporary read-only database is used to handle the traffic and migrate the database instances to the optimal scheduling node.

[0168] For database instances to be migrated that are of type standby and primary, a primary / standby database switchover method is used to migrate the database instances to the optimal scheduling node.

[0169] In one possible implementation, the device is also used for: Create a temporary read-only database and synchronize data with the primary database through the temporary read-only database.

[0170] Switch the business traffic from the read-only database to a temporary read-only database.

[0171] Migrate the read-only library to the optimal scheduling node.

[0172] In one possible implementation, the device is also used for: Switch business traffic from the temporary read-only database to the read-only database, and then delete the temporary read-only database.

[0173] In one possible implementation, the device is also used for: Prioritize migrating the backup database to the optimal scheduling node.

[0174] After the standby database completes the migration, a primary-standby database switchover is performed to switch the migrated standby database to the new primary database. Migrate the primary database to the optimal scheduling node.

[0175] In one possible implementation, the device is also used for: In a database cluster operating in a master-slave mode, the process prioritizes migrating the standby database to the optimal scheduling node.

[0176] or; In a database cluster operating in standalone mode, create a temporary backup database.

[0177] Data is synchronized with the primary database through a temporary standby database, and the standby mode is switched to the primary-standby mode.

[0178] In one possible implementation, the device is also used for: The Pod features and node features are input into the random forest model, and the random forest model outputs the predicted resource usage values ​​for each candidate node.

[0179] In one possible implementation, the device is also used for: Obtain historical resource usage data for cloud database instances and candidate nodes.

[0180] Samples are extracted from historical resource usage data using a bootstrap sampling method to construct multiple subsets; each subset corresponds to a decision tree.

[0181] A model-based feature fusion method is used to input the prediction results of each decision tree into the random forest model for training.

[0182] In one possible implementation, the device is also used for: Based on the predicted resource usage values ​​of each candidate node, the candidate nodes are scored to obtain the scoring results.

[0183] Based on the scoring results, each candidate node is prioritized and ranked, and the candidate node with the highest priority is determined as the optimal scheduling node.

[0184] The processing flow of each module in the device and the interaction flow between each module can be referred to the relevant descriptions in the above method embodiments, and will not be detailed here.

[0185] Corresponding to Figure 1 In addition to the data migration method described in this disclosure, an electronic device 60 is also provided, such as... Figure 6 The diagram shown is a structural schematic of an electronic device 60 provided in an embodiment of this disclosure, including: The system includes a processor 61, a memory 62, and a bus 63. The memory 62 stores execution instructions and includes main memory 621 and external memory 622. The main memory 621, also called internal memory, temporarily stores the computational data in the processor 61, as well as data exchanged with external memory such as a hard disk. The processor 61 exchanges data with the external memory 622 through the main memory 621. When the electronic device 60 is running, the processor 61 communicates with the memory 62 through the bus 63, causing the processor 61 to execute the following instructions: Obtain the Pod characteristics of multiple database instances to be migrated, as well as the node characteristics of each candidate node in the database cluster. The Pod characteristics include instance specifications, storage type, and resource usage type, while the node characteristics include computing resources, memory resources, storage resources, network latency, and network bandwidth.

[0186] The resource usage prediction values ​​for each candidate node are predicted based on Pod features and node features.

[0187] The candidate nodes are scored and ranked according to the predicted resource usage values ​​in order to select the optimal scheduling node.

[0188] Based on the type of each database instance to be migrated in the database cluster, and in the order of read-only database, standby database, and primary database, each database instance to be migrated is migrated to the optimal scheduling node in sequence.

[0189] This disclosure also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the data migration method described in the above-described method embodiments. The storage medium may be a volatile or non-volatile computer-readable storage medium.

[0190] This disclosure also provides a computer program product 70, such as... Figure 7 The diagram shown is a schematic diagram of the structure of a computer program product 70 provided in an embodiment of this disclosure. The computer program product 70 carries a computer program 71. The program included in the computer program 71 can be used to execute the steps of the data migration method described in the above method embodiments. For details, please refer to the above method embodiments, which will not be repeated here.

[0191] The data migration method, apparatus, device, medium, and product according to embodiments of this disclosure have been described above with reference to the accompanying drawings. In these embodiments, the Pod characteristics of multiple database instances to be migrated and the node characteristics of each candidate node in the database cluster are first obtained. The Pod characteristics include instance specifications, storage type, and resource usage type, while the node characteristics include computing resources, memory resources, storage resources, network latency, and network bandwidth. Then, the predicted resource usage values ​​of each candidate node are predicted based on the Pod and node characteristics. The candidate nodes are scored and ranked according to their predicted resource usage values ​​to select the optimal scheduling node. Finally, based on the type of each database instance to be migrated in the database cluster, and in the order of read-only database, standby database, and primary database, each database instance to be migrated is sequentially migrated to the optimal scheduling node. By using the above processing method, the resource requirements of the database instance to be migrated can be accurately described by obtaining the Pod characteristics of the instance. By obtaining the multi-dimensional node characteristics of each candidate node, the resource supply capacity of each node can be comprehensively evaluated. Based on the resource usage prediction values ​​determined by these two types of data, the optimal node with the most abundant resources and most suitable for running the database instance to be migrated can be automatically selected from multiple candidate nodes. Then, through a unified migration control logic, that is, to migrate in the order of read-only database, standby database, and primary database, it can automatically adapt to various complex scenarios such as node failure migration and migration between different storage types. There is no need to develop a separate migration plan for each scenario, which can greatly improve the flexibility of the migration process.

[0192] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0193] The block diagrams of devices, apparatuses, devices, and systems disclosed herein are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as “comprising,” “including,” “having,” etc., are open-ended terms meaning “including but not limited to,” and are used interchangeably with them. The terms “or” and “and” as used herein refer to the terms “and / or,” and are used interchangeably with them unless the context clearly indicates otherwise. The term “such as” as used herein refers to the phrase “such as but not limited to,” and is used interchangeably with it.

[0194] Additionally, as used herein, the "or" used in a list of items beginning with "at least one" indicates a separate list, such that a list of, for example, "at least one of A, B, or C" means A or B or C, or AB or AC or BC, or ABC (i.e., A and B and C). Furthermore, the word "exemplary" does not imply that the described example is preferred or better than other examples.

[0195] It should also be noted that in the systems and methods of this disclosure, the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered as equivalent solutions to this disclosure.

[0196] Various changes, substitutions, and modifications can be made to the technology described herein without departing from the teachings defined by the appended claims. Furthermore, the scope of the claims of this disclosure is not limited to the specific aspects of the processes, machines, manufactures, events, means, methods, and actions described above. Currently existing or later-developed processes, machines, manufactures, events, means, methods, or actions that perform substantially the same function or achieve substantially the same result as the corresponding aspects described herein can be utilized. Therefore, the appended claims include such processes, machines, manufactures, events, means, methods, or actions within their scope.

[0197] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features disclosed herein.

[0198] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations therein.

Claims

1. A data migration method, characterized in that, include: Obtain the Pod characteristics of multiple database instances to be migrated and the node characteristics of each candidate node in the database cluster; wherein, the Pod characteristics include instance specifications, storage type, and resource usage type, and the node characteristics include computing resources, memory resources, storage resources, network latency, and network bandwidth; Based on the Pod features and the node features, predict the resource usage of each candidate node. The candidate nodes are scored and ranked according to the predicted resource usage values, so as to select the optimal scheduling node from the candidate nodes. Based on the type of each database instance to be migrated in the database cluster, and in the order of read-only database, standby database, and primary database, each database instance to be migrated is sequentially migrated to the optimal scheduling node.

2. The method according to claim 1, characterized in that, The step of sequentially migrating each of the database instances to be migrated to the optimal scheduling node includes: For database instances of type read-only that are to be migrated, a temporary read-only database is used to handle the traffic and migrate the database instances to the optimal scheduling node. For database instances of type "standby database" and "primary database" to be migrated, a primary / standby database switching method is used to migrate the database instances to the optimal scheduling node.

3. The method according to claim 2, characterized in that, The method of migrating the database instance to be migrated to the optimal scheduling node by using a temporary read-only library to handle traffic includes: Create the temporary read-only database and synchronize data with the main database through the temporary read-only database; Switch the business traffic of the read-only database to the temporary read-only database; The read-only library is migrated to the optimal scheduling node.

4. The method according to claim 3, characterized in that, After migrating the read-only library to the optimal scheduling node, the method further includes: The service traffic is switched from the temporary read-only database to the read-only database, and the temporary read-only database is deleted.

5. The method according to claim 2, characterized in that, The method of migrating the database instance to be migrated to the optimal scheduling node using a primary / standby database switchover includes: The backup database should be migrated to the optimal scheduling node first. After the backup database completes the migration, a primary / backup database switch is performed to switch the migrated backup database to the new primary database. The master database is migrated to the optimal scheduling node.

6. The method according to claim 5, characterized in that, The method further includes: In the case of the database cluster in master-slave mode, the process of prioritizing the migration of the standby database to the optimal scheduling node is executed. or; If the database cluster is in standalone mode, create a temporary backup database; Data is synchronized between the temporary backup database and the primary database, and the standby mode is switched to the primary-backup mode.

7. The method according to claim 1, characterized in that, The predicted resource usage values ​​for each candidate node include: The Pod features and node features are input into a random forest model, and the random forest model outputs the predicted resource usage values ​​for each candidate node.

8. The method according to claim 7, characterized in that, The random forest model was trained in the following way: Obtain historical resource usage data for the cloud database instance and the candidate nodes; Samples are extracted from the historical resource usage data using a bootstrap sampling method to construct multiple subsets; each subset corresponds to a decision tree. A model-based feature fusion method is used to input the prediction results of each decision tree into the random forest model for training.

9. The method according to claim 1, characterized in that, The step of scoring and ranking each candidate node based on the predicted resource usage value to select the optimal scheduling node from among the candidate nodes includes: The candidate nodes are scored based on their predicted resource usage values ​​to obtain a scoring result. Based on the scoring results, the candidate nodes are prioritized and sorted, and the candidate node with the highest priority is determined as the optimal scheduling node.

10. A data migration device, characterized in that, include: The feature acquisition unit is used to acquire the Pod features of multiple database instances to be migrated and the node features of each candidate node in the database cluster; wherein, the Pod features include instance specifications, storage type, and resource usage type, and the node features include computing resources, memory resources, storage resources, network latency, and network bandwidth; A prediction unit is used to predict the resource usage of each candidate node based on the Pod features and the node features. A node filtering unit is used to score and sort each candidate node according to the resource usage prediction value, so as to select the optimal scheduling node from each candidate node. The data migration unit is used to migrate each database instance to be migrated to the optimal scheduling node in sequence, according to the type of each database instance to be migrated in the database cluster, and in the order of read-only database, standby database, and primary database.

11. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, the steps of the data migration method as described in any one of claims 1 to 9 are performed.

12. A computer program product, characterized in that, The computer program product is stored in a storage medium, and the program product is executed by at least one processor to implement the data migration method as described in any one of claims 1 to 9.

Images