Thermal migration method, device and equipment for memory database service and storage medium

Abstract

The invention discloses a live migration method, device and equipment for a memory database service and a storage medium, and relates to the technical field of computers, and the method comprises the steps that configuration information of a takeover node is indicated in a live migration instruction, and when the live migration instruction is acquired, the configuration information of a service node running the memory database service can be directly acquired. The migration operation needs to comply with a certain sequence, so that the first service node can be determined according to the configuration information of each service node, and the target takeover node can be determined according to the configuration information of each takeover node. And then, the memory database service operated by the first service node can be migrated to the target takeover node. After the migration operation is completed, the node type of the target takeover node can be set as the main node type, so that the target takeover node can serve as a new main node to provide memory database service externally, and the problem of data loss of the memory database service is avoided.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method, apparatus, device, and storage medium for hot migration of an in-memory database service. Background Art

[0002] With the development of cloud computing and containerization, in-memory databases are increasingly being deployed in container service clusters. To achieve high availability, multiple in-memory database services are typically started simultaneously. Different in-memory database services can be deployed on different nodes in the container service cluster. One node can serve as the master node, providing in-memory database services, while the remaining nodes serve as slave nodes. In the event of a master node failure or instability, the slave nodes can be switched to provide in-memory database services.

[0003] If the performance of a node deploying the in-memory database service in a Container Service cluster degrades, you can add new nodes to the cluster and deploy the in-memory database service on the new nodes to replace the degraded nodes. Currently, manually creating a new in-memory database service on the new nodes can result in data loss in the original in-memory database service. Summary of the Invention

[0004] The present application provides a method, device, electronic device, storage medium, and program product for hot migration of an in-memory database service, to solve the problem of hot migration of an in-memory database service.

[0005] This application provides a method for hot migration of an in-memory database service, including:

[0006] When a hot migration instruction of the in-memory database service is obtained, configuration information of multiple service nodes running the in-memory database service is obtained, wherein the hot migration instruction includes configuration information of at least one takeover node;

[0007] Selecting a first service node from among the plurality of service nodes according to configuration information of each service node;

[0008] Selecting a target takeover node from at least one takeover node according to configuration information of each takeover node;

[0009] Migrating the in-memory database service running on the first service node to the target takeover node based on the configuration information of the first service node;

[0010] When the migration operation is detected to be complete, the node type of the target takeover node is set to the master node type, so that the target takeover node provides the in-memory database service as the master node.

[0011] This application also provides a hot migration device for an in-memory database service, including:

[0012] an acquisition module, configured to acquire configuration information of multiple service nodes running the in-memory database service when a hot migration instruction of the in-memory database service is obtained, wherein the hot migration instruction includes configuration information of at least one takeover node;

[0013] A selection module, configured to select a first service node from a plurality of service nodes based on the configuration information of each service node; and to select a target takeover node from at least one takeover node based on the configuration information of each takeover node;

[0014] A migration module, configured to migrate the memory database service running on the first service node to a target takeover node according to the configuration information of the first service node;

[0015] The setting module is used to set the node type of the target takeover node to the master node type when detecting that the migration operation is completed, so that the target takeover node provides the memory database service as the master node.

[0016] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any of the above-mentioned methods for hot migration of in-memory database services when executing the computer program.

[0017] The present application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned hot migration methods for in-memory database services are implemented.

[0018] The present application also provides a computer program product, including a computer program, which implements the steps of any of the above-mentioned hot migration methods for in-memory database services when executed by a processor.

[0019] By the present application, the configuration information of the takeover node is indicated in the hot migration instruction, and when the hot migration instruction is obtained, the configuration information of the plurality of service nodes running the in-memory database service can be directly obtained. Since the migration operation needs to comply with a certain order, the first service node that needs to be migrated first can be determined according to the configuration information of each service node, and the target takeover node corresponding to the first service node can be determined according to the configuration information of each takeover node. Then, the in-memory database service running on the first service node can be migrated to the target takeover node. After the migration operation is completed, the node type of the target takeover node can be set to the master node type, so that the target takeover node can provide the in-memory database service as a new master node. In the entire migration process, the migration process can be automatically executed, and before the migration operation is completed, the in-memory database service can be provided by the original master node, and after the migration operation is completed, the in-memory database service can be provided by the new master node (i.e., the target takeover node). The entire migration operation does not need to be manually executed, nor does it need to interrupt the in-memory database service. Moreover, by the migration operation, the original in-memory database service can be migrated to the new master node, avoiding the problem of data loss of the in-memory database service. BRIEF DESCRIPTION OF DRAWINGS

[0020] In order to more clearly illustrate the embodiments of the present application, the drawings needed in the embodiments will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0021] Figure 1 An architecture schematic diagram of a computer cluster is provided for the embodiments of the present application.

[0022] Figure 2 A flowchart of a hot migration method of an in-memory database service is provided for the embodiments of the present application.

[0023] Figure 3 A schematic diagram of deploying an in-memory database service on a node is provided for the embodiments of the present application.

[0024] Figure 4 A hot migration schematic diagram of an in-memory database service under an incomplete migration type is provided for the embodiments of the present application.

[0025] Figure 5 A hot migration schematic diagram of an in-memory database service under a complete migration type is provided for the embodiments of the present application.

[0026] Figure 6 A structure schematic diagram of a hot migration device of an in-memory database service is provided for the embodiments of the present application.

[0027] Figure 7 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0028] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0029] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0030] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0031] The hot migration method of the memory database service provided in this application can be implemented by a computer cluster, such as Figure 1 As shown, a computer cluster may include multiple nodes, and the nodes may be service nodes, management nodes, and takeover nodes. Each node may be a server. Service nodes may be used to provide in-memory database services to the outside world (to users), and management nodes may be used to perform hot migration operations of in-memory database services, as well as to manage each service node and takeover node. Takeover nodes may be used to take over in-memory database services. The computer cluster may be a container service cluster (for example, a K8S cluster). The functions of a management node may also be implemented by one of the multiple service nodes. The following is an example of setting up a dedicated management node in a computer cluster.

[0032] The embodiment of the present application provides a method for hot migration of an in-memory database service, which can be executed by a management node, such as Figure 2 As shown, the specific processing steps of the hot migration method of the in-memory database service may include:

[0033] Step S201: When a hot migration instruction of the memory database service is obtained, configuration information of multiple service nodes running the memory database service is obtained.

[0034] The configuration information of the service node can include node identification information and node type of the service node. For example, the node identification information of the service node can be "Node1", and the node type can be a master node type or a backup node type (also referred to as a slave node type). When the node type of the service node is the master node type, the service node provides the in-memory database service externally as a master node. When the node type of the service node is the backup node type, the service node can synchronize service data generated by the in-memory database service from the master node. In addition, when the service node is a backup node (also referred to as a slave node), it does not need to provide the in-memory database service externally, but when the master node fails and the service node is selected as a replacement master node, it provides the in-memory database service externally as a master node. The hot migration instruction can include configuration information of at least one takeover node, and the configuration information of the takeover node can include node identification information of the takeover node.

[0035] Specifically, when the management node detects that a new node is accessed in the computer cluster, the identification information of the new node (i.e., the identification information of the takeover node) can be obtained, and the hot migration instruction can be generated, or when the hot migration instruction sent by the target device is received, the configuration information of the plurality of service nodes can be extracted from the pre-built deployment file of the in-memory database service.

[0036] Step S202: selecting a first service node from the plurality of service nodes according to the configuration information of each service node.

[0037] Specifically, since the deployment order in the process of deploying the in-memory database service is predetermined, the migration operation must also be performed based on the deployment order during hot migration to avoid node failure caused by incorrect migration order, thereby avoiding the problem of interruption of the in-memory database service. Accordingly, the management node can select the first service node according to the first preset sorting rule and the node identification information of each service node, which can specifically include the following steps:

[0038] Step 1: sorting each service node according to the configuration information of each service node to obtain a migration order value corresponding to each service node.

[0039] Step 2: selecting a first service node from the plurality of service nodes according to the migration order value corresponding to each service node.

[0040] The management node can extract the node identification information of each service node from the configuration information of the service node, and then extract the node number from the node identification information, and sort each service node according to the extracted number to obtain a migration order value corresponding to each service node, and determine the first service node according to the migration order value of each service node.

[0041] Specifically, the management node can sort each service node by number from largest to smallest, and determine the service node with the highest migration order value as the first service node. For example, if the node identification information of multiple service nodes is "Node1," "Node2," and "Node3," the management node can determine the service node corresponding to "Node3" as the first service node. Using the node identification information of the service nodes, the service nodes can be accurately sorted, and the subsequent migration operation of the in-memory database service can be performed according to the accurate sorting, allowing the migration operation to be carried out safely, thereby improving the efficiency of the migration operation.

[0042] Step S203: Select a target takeover node from at least one takeover node according to the configuration information of each takeover node.

[0043] Specifically, similar to step S202, the management node must perform the migration operation based on the deployment order. That is, the management node may select the first service node according to the preset second sorting rule and the node identification information of each service node. Specifically, the following steps may be included:

[0044] Step 1: sort each takeover node according to the configuration information of each takeover node to obtain a migration sequence value corresponding to each takeover node.

[0045] Step 2: Select a target takeover node from multiple takeover nodes according to the migration sequence value corresponding to each takeover node.

[0046] The management node can extract the node identification information of each takeover node from the configuration information of the takeover node, and then extract the node number from the node identification information, and sort each takeover node according to the extracted number to obtain the migration sequence value corresponding to each takeover node, and determine the first takeover node based on the migration sequence value of each takeover node.

[0047] Specifically, the management node can sort each takeover node by number from smallest to largest and determine the takeover node with the highest migration order as the target takeover node. For example, if the node identification information of multiple takeover nodes is "Node4," "Node5," and "Node6," the management node can determine the takeover node corresponding to "Node4" as the target takeover node.

[0048] In some optional implementations, the management node may first determine the number of takeover nodes. If it determines that there is only one takeover node, the management node may directly determine the takeover node corresponding to the takeover node configuration information included in the live migration instruction as the target takeover node. Alternatively, if it determines that there are multiple takeover nodes, the management node may determine the target takeover node based on the aforementioned sorting method. This can conserve resources and improve the efficiency of the live migration operation.

[0049] Step S204: Migrate the memory database service running on the first service node to the target takeover node according to the configuration information of the first service node.

[0050] Specifically, in order to ensure that the computer cluster can still provide in-memory database services to the outside world during the migration process, for a service node that needs to perform the first migration operation during the migration process, the service node can be used as a standby node, and other service nodes that do not perform the migration operation can be used as master nodes. Accordingly, the management node can determine the node type of the first service node based on the configuration information of the first service node, and perform the in-memory database service migration operation corresponding to the node type of the first service node based on the node type of the first service node. Specifically, the following steps may be included:

[0051] Step 1: Determine whether the node type of the first service node is a master node type according to the configuration information of the first service node.

[0052] Step 2: When it is determined that the node type of the first service node is a master node type, a service node is selected from the plurality of service nodes other than the first service node as a second service node.

[0053] Step 3: Switch the node type of the first service node from a master node type to a standby node type, so that the first service node provides in-memory database services as a standby node. Also, switch the node type of the second service node from a standby node type to a master node type, so that the second service node provides in-memory database services as a master node.

[0054] Step 4: After completing the node type switching operations corresponding to the first service node and the second service node, the memory database service running on the first service node is migrated to the target takeover node.

[0055] or,

[0056] Step 5: When it is determined that the node type of the first service node is a standby node type, the memory database service running on the first service node is directly migrated to the target takeover node.

[0057] The management node can first extract the node type of the first service node from the configuration information of the first service node, and determine whether the node type of the first service node is a master node type. If the node type of the first service node is a standby node type, it means that there is currently another service node as the master node providing in-memory database services to the outside world. The management node can directly migrate the in-memory database service running on the first service node to the target takeover node. If the node type of the first service node is a master node type, the management node can first perform a master-slave node switching operation, that is, switch the node type of the first service node from a master node type to a standby node type, and switch the node type of the second service node from a standby node type to a master node type. After completing the master-slave switching operation, the management node can migrate the in-memory database service running on the first service node to the target takeover node. In this way, during the migration operation of the in-memory database service of the first service node, the second service node can still provide in-memory database services to the outside world without interrupting the in-memory database service. In other words, the above-mentioned migration operation is a hot migration operation.

[0058] The above-mentioned operation of migrating the in-memory database service on the management node may include multiple operations, one of which is to delete the in-memory database service running on the first service node, and the other is to create and start the in-memory database service on the target takeover node. Accordingly, migrating the in-memory database service running on the first service node to the target takeover node may include the following specific steps:

[0059] Step 1: Delete the in-memory database service on the first service node.

[0060] Step 2: Create and start the in-memory database service on the target takeover node.

[0061] Step 3: Set the target takeover node's node type to a standby node type. This allows the target takeover node to synchronize the service data generated by the in-memory database service running on the second service node with the second service node according to the pre-built master-slave data synchronization mechanism after starting the in-memory database service. This includes in-memory data and data written to disk.

[0062] Service data may include in-memory data and / or data written to disk. An in-memory database service may include a container group (Pod) running the in-memory database service and storage resource information. For example, the storage resource information may be a persistent volume claim (PVC). In InCloudOS, data written to disk may be stored using any storage method, such as object storage, file storage, or Network File System (NFS).

[0063] Accordingly, deleting the in-memory database service of the first service node can be accomplished by: determining, in the deployment file, a label for the in-memory database service corresponding to the first service node (this label indicates the service status of the in-memory database service, e.g., in service or out of service). The management node can set the label of the in-memory database service to "out of service," and then, based on the modified label, send a delete instruction to the first service node. Upon receiving the delete instruction, the first service node simultaneously deletes both the Pod and the PVC it ​​contains, to avoid the situation where, after deleting only the Pod or only the PVC, the other (the PVC if the former is a Pod, or the Pod if the former is a PVC) is automatically regenerated, causing the live migration operation to fail. After deleting the Pod, the service data related to the in-memory database service in memory is also deleted. After deleting the PVC, the first service node can automatically delete the service data persistently stored in the corresponding PV, thereby completing the complete deletion of the in-memory database service of the first service node on the first service node. This saves storage resources on the first service node.

[0064] In addition, the management node can create a label for the in-memory database service corresponding to the target takeover node in the deployment file and set the label to "In Service".

[0065] When the management node detects the completion of the deletion operation and the "In Service" label for the target takeover node's corresponding in-memory database service, it sends a service startup instruction to the target takeover node. Upon receiving the service startup instruction, the target takeover node creates a Pod and PVC according to the pre-set creation mechanism, and creates and starts the in-memory database service on this Pod. Furthermore, the management node creates a corresponding PV based on the PVC for subsequent persistent storage of service data.

[0066] The management node can set the node type of the target takeover node to the standby node type. In this way, the target takeover node can act as a standby node and synchronize the memory data generated by the memory database service on the master node (second service node) to its own memory and synchronize the disk data to its own PV according to the pre-built master-slave data synchronization mechanism.

[0067] Step S205: When it is detected that the migration operation is completed, the node type of the target takeover node is set to the master node type, so that the target takeover node provides the in-memory database service as the master node.

[0068] Specifically, the management node can periodically check whether the migration operation is complete. When the migration operation is complete, the management node performs a master-slave node switchover operation. After the switchover operation is complete, the target takeover node can serve as the master node to provide in-memory database services. Accordingly, the following steps can be used to check whether the migration operation is complete:

[0069] Step 1: Periodically obtain synchronization progress information of the target takeover node.

[0070] Step 2: When the synchronization progress information obtained in any period indicates that data synchronization is complete, the operation of obtaining the synchronization progress information is stopped, and the migration operation is determined to be complete.

[0071] The management node can periodically obtain data synchronization progress information. In each cycle, when the synchronization progress information obtained in that cycle indicates that data synchronization is complete, the management node stops periodically obtaining synchronization progress information and determines that the migration operation is complete. Alternatively, when the synchronization progress information obtained indicates that data synchronization is complete, the management node can further verify the data consistency between the second service node and the target takeover node (for example, Redis's DEBUG protocol can be used). When it is determined that the data on the second service node and the target takeover node are completely consistent, the migration operation is determined to be complete, which can avoid service instability caused by data loss.

[0072] In some optional implementations, when synchronization progress information indicating data synchronization completion is obtained for a predetermined number of consecutive cycles, a fault indication message can be sent to the target device so that technicians can promptly review and repair the fault. After the fault is repaired, the hot migration operation can be re-executed, thereby improving the safety and efficiency of the hot migration operation.

[0073] In some optional implementations, when there is only one takeover node, the migration operation can be determined to be complete after the above migration operation is completed. Alternatively, when there are multiple takeover nodes, the management node can also migrate the in-memory database services of other service nodes to other takeover nodes. Accordingly, the following steps can be performed:

[0074] Step 1: Delete the memory database services running on the other service nodes except the first service node among the multiple service nodes respectively.

[0075] Step 2: Create and start the in-memory database service on each of the takeover nodes except the target takeover node.

[0076] Step three: Set the node types of other takeover nodes to the standby node type, so that after starting the memory database service, the other takeover nodes can synchronize the service data generated by the memory database service running on the target takeover node from the target takeover node according to the pre-built master-slave data synchronization mechanism.

[0077] Specifically, the management node may perform deletion, creation, and restart operations of the in-memory database service according to the migration order value of each takeover node except the target takeover node determined in step S203, and the migration order value of each service node except the target takeover node determined in step S202, respectively. Specifically, the operations may include:

[0078] When it is determined that it is the turn to perform the migration operation on the memory database service running on the third service node based on the migration sequence value of the third service node, the first takeover node that is consistent with the migration sequence value of the third service node is determined. The management node can delete the memory database service running on the third service node (refer to the specific process of deleting the memory database service of the first service node in step S204, which will not be repeated here), and create and start the memory database service on the first takeover node (refer to the specific process of creating and starting the memory database service on the target takeover node in step S204, which will not be repeated here). Among them, the third service node is any service node among the multiple service nodes except the first service node, and the first takeover node is a takeover node among the multiple takeover nodes except the target takeover node that has the same migration sequence value as the third service node.

[0079] For example, multiple service nodes include node 1, node 2, and node 3, and multiple takeover nodes include node 4, node 5, and node 6. In steps S201 to S205, the memory database service of node 3 has been migrated to node 4. In the current step, the management node can first delete the memory database service on node 2, create and start the memory database service on node 5, and then delete the memory database service on node 1, and create and start the memory database service on node 6.

[0080] In each migration operation of the above migration process, the migrated nodes are all slave nodes, which can ensure that the master node always exists to provide in-memory database services to the outside world during the migration process.

[0081] In the hot migration method for an in-memory database service according to an embodiment of the present application, the configuration information of the takeover node is indicated in the hot migration instruction. Upon receiving the hot migration instruction, the configuration information of multiple service nodes running the in-memory database service can be directly obtained. Since the migration operation must follow a certain order, the first service node to be migrated first can be determined based on the configuration information of each service node, and the target takeover node corresponding to the first service node can be determined based on the configuration information of each takeover node. The in-memory database service running on the first service node can then be migrated to the target takeover node. After the migration operation is completed, the node type of the target takeover node can be set to the master node type, allowing the target takeover node to provide in-memory database services externally as the new master node. During the entire migration process, the migration process can be automatically executed, eliminating the need for manual migration, reducing the problems caused by manual migration, and thereby improving migration efficiency. Furthermore, before the migration operation is completed, the original master node can provide in-memory database services externally. After the migration operation is completed, the target takeover node is immediately switched to the new master node, allowing the target takeover node to immediately provide higher-performance in-memory database services externally, without interrupting the in-memory database service during the entire migration process. In addition, this solution can migrate the original in-memory database service to the new master node through the migration operation, avoiding the problem of data loss of the in-memory database service.

[0082] The following describes in detail the execution process of the hot migration method of the above-mentioned in-memory database service using a specific example.

[0083] The aforementioned in-memory database service is the Redis database service. The Redis database has the following characteristics: First, in-memory storage: the Redis database stores data in memory, offering fast access speeds. Second, key-value pair storage: the key is the unique identifier of the data, and the value is the specific content of the data, such as a string, hash, set, or list. Third, single-threaded command processing enables high performance and low latency for the Redis database service. Fourth, data persistence: data is stored on the hard disk to avoid memory data loss.

[0084] In a container service cluster, when deploying an in-memory database service, the management node can deploy the in-memory database service using a Helm template (the aforementioned deployment file). In the Helm template, Statefulset can be further used for orchestration.

[0085] In order to achieve data persistence for the Redis database service, that is, to store the data generated by the Redis database service on the hard disk, it is necessary to create a persistent storage volume claim (PVC) and a persistent storage volume (PV) on each service node.

[0086] like Figure 3 As shown in the following example, Redis-0 is deployed on Node 1, and PVC-0 and PV-0 are created. PVC-0 can be used to manage PV-0, allowing Redis-0 to use the storage resources of PV-Redis-0. Redis-1 is deployed on Node 2, and PVC-1 and PV-1 are created. PVC-1 can be used to manage PV-1, allowing Redis-1 to use the storage resources of PV-1. Redis-2 is deployed on Node 3, and PVC-2 and PV-Redis-2 are created. PVC-2 can be used to manage PV-2, allowing Redis-0 to use the storage resources of PV-2.

[0087] When one or more of Node 1, Node 2, and Node 3 experience storage performance or network performance degradation, the database services on the corresponding nodes can be migrated to the newly added takeover node.

[0088] The following describes the hot migration process using the incomplete migration type and the complete migration type as examples.

[0089] First, incomplete migration type (there is only one takeover node, which serves as the master node to provide in-memory database services).

[0090] like Figure 4 As shown in the figure, the Redis database service running on the master node is migrated to node 4. Nodes 1, 2, and 3 are all service nodes, and node 4 is the takeover node.

[0091] First, the management node determines whether node 3 is providing Redis database services as the primary node. If so, it switches node 3 to the standby node and switches either node 1 or node 2 (node ​​1 is used as an example below) to the primary node. The management node then sets the label for node 4 in the Statefulset's Labels section of the Helm template to "Redis:in" (also known as "in service") and the label for node 3 to "Redis:out" (also known as "out of service"). Upon detecting that the label for node 3 has changed to "Redis:out," the management node uses a pre-built script to delete Redis-2 (thus deleting the corresponding Pod), PVC2, and the data stored in PV3 on node 3. Furthermore, the management node creates Redis-2, PVC2, and PV2 on node 4 and starts Redis-2. Redis-2 can then synchronize data with node 1 using a master-slave replication mechanism. Once synchronization is complete, the management node switches node 4 to the primary node providing database services and switches node 1 to the standby node. It should be noted that after deleting the Pod, the data related to the Redis database service stored in memory will also be automatically deleted. After deleting the PVC, the data stored in the corresponding PV can be deleted automatically or by issuing a command from the management node.

[0092] In a container service cluster, when deploying Pods (i.e., the Redis database service in this solution) through a Statefulset using a Helm template, they must be created one by one according to the node identification information from small to large (for example, 0-1-2), and when deleting, they must be deleted according to the node identification information from large to small (for example, "2-1-0"). Therefore, after adding a high-performance node to the container service cluster, it is expected that this high-performance node will be used as the primary node to provide database services. Since the primary node provides Redis database services to the outside world, and the backup node is set to ensure that it can immediately take over the Redis database service when the primary node fails, the daily task of the backup node is to synchronize data from the primary node. In addition, in order to ensure that the container service cluster can still provide database services normally during the migration of the Redis database service, the management node can first determine whether the node with the largest node identification information (for example, the above-mentioned node 3) is used as the primary node to provide Redis database services. If not, it needs to be switched to the backup node to avoid interruption of the Redis database service. After the migration from node 3 to node 4 is completed and node 4 obtains the synchronized data on the standby node, the switch operation between the primary and standby nodes can be directly performed, so that node 4 can provide Redis database services to the outside world.

[0093] Second, the full migration type (the number of takeover nodes is multiple, and the in-memory databases running on all service nodes are migrated).

[0094] like Figure 5 As shown in the figure, Redis-2 standby node 3 is migrated to node 4, Redis-1 standby node 2 is migrated to node 5, and Redis-0 standby node 1 is migrated to node 6. Nodes 1, 2, and 3 are all service nodes, and nodes 4, 5, and 6 are takeover nodes.

[0095] Step 1: Migrate Redis-2 standby node 3 to node 4.

[0096] First, set the label "redis:in" on nodes 1 through 3 and "redis:out" on nodes 4 through 6. Furthermore, in the Helm template's Statefulset's Labels, set the label "redis:in" for nodes 1 through 3 and "redis:out" for nodes 4 through 6. Next, determine which node is serving the Redis database as the master. If node 3 is serving the Redis database as the master, either node 1 or node 2 (node ​​1 will be used as an example) can be switched to the master. Change the label on node 3 to "redis:out" and on node 4 to "redis:in" (you can also make the same changes to the Helm template's Statefulset's Labels). After modifying the labels, use the pre-built script or command to directly delete Redis-2 (that is, the Pod) and PVC2 on node 3. It's important to note that both the Pod and PVC must be deleted simultaneously. Deleting only one will automatically create the other resource, causing the migration to fail.

[0097] The management node can create Redis-2 and PVC2 on node 4. When both are successfully created and Redis-2 is started, node 4 can obtain the synchronized data from node 1 according to the master-slave data synchronization mechanism. When the management node detects that the synchronization operation is complete, it can switch node 4 to the master node and node 1 to the slave node. After the Redis database service is started, the sentinel process started in each Redis database service will switch the master and slave nodes according to the preset switching mechanism. In addition, directly copying the data of the PV volume often causes data jitter, that is, the copied data is inconsistent with the data actually to be copied. As a result, when the sentinel process detects that the service data of the Redis service is inconsistent, the Redis service cannot be started normally, which in turn affects the stability of the service. Therefore, setting the node type to fixed here can avoid jitter in the Redis database service.

[0098] Step 2: Migrate Redis-1 standby node 2 to node 5.

[0099] Modify the label on Node 2 to "Redis:out" and also on Node 5 to "Redis:in". After completing the label modification operation, use the pre-built script tool or command to directly delete Redis-1 (that is, delete the Pod) and PVC1 on Node 2. The management node can create Redis-1 and PVC1 on Node 5. Once both are successfully created and Redis-1 is started, Node 5 can synchronize data with the standby node 4 according to the master-slave data synchronization mechanism. Step 3: Migrate the Redis-0 standby node 1 to node 6.

[0100] Change the label on Node 1 to "Redis:out" and on Node 6 to "Redis:in." After modifying the labels, use pre-built scripts or commands to directly delete Redis-0 (that is, delete the pod) and PVC0 on Node 1. The management node can create Redis-0 and PVC0 on Node 6. Once both are successfully created and Redis-0 is started, Node 5 can synchronize data with Node 4 using the master-slave data synchronization mechanism.

[0101] After each Redis database service migration operation, the Sentinel process will restart. However, since the Sentinel process is a process within the Pod, the Sentinel process restart will not affect the operation of the Redis database service. After all migration operations are completed, the Sentinel process can switch between the primary and backup nodes according to its own master-slave switching mechanism to provide stable Redis database services.

[0102] After adding multiple high-performance nodes to the container service cluster, in order to ensure that the container service cluster can still provide database services normally during the migration of the Redis database service, the management node can first determine whether the node with the largest node identification information (for example, the above-mentioned node 3) provides the Redis database service as the primary node. If not, it needs to be switched to the backup node to avoid the interruption of the Redis database service. After completing the migration from node 3 to node 4 and node 4 obtains the synchronized data on the backup node, the switching operation of the primary and backup nodes can be directly executed, so that node 4 can provide the Redis database service to the outside world first. For the remaining migration operations, the migration operations can be performed in the specified order of the Helm template to complete the migration operation of the Redis database service of all nodes.

[0103] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0104] The embodiment of the present application also provides a hot migration device for an in-memory database service, such as Figure 6 Shown, including:

[0105] An acquisition module 610 is configured to acquire configuration information of multiple service nodes running the in-memory database service when a hot migration instruction of the in-memory database service is obtained, wherein the hot migration instruction includes configuration information of at least one takeover node;

[0106] A selection module 620 is configured to select a first service node from a plurality of service nodes based on the configuration information of each service node; and to select a target takeover node from at least one takeover node based on the configuration information of each takeover node;

[0107] A migration module 630 is configured to migrate the memory database service running on the first service node to a target takeover node based on the configuration information of the first service node;

[0108] The setting module 640 is used to set the node type of the target takeover node to the master node type when it is detected that the migration operation is completed, so that the target takeover node provides the in-memory database service as the master node.

[0109] In some optional implementations, the selection module 620 is specifically configured to:

[0110] Sort each service node according to its configuration information to obtain a migration order value corresponding to each service node;

[0111] A first service node is selected from the plurality of service nodes according to a migration sequence value corresponding to each service node.

[0112] In some optional implementations, the selection module 620 is specifically configured to:

[0113] Sort each takeover node according to its configuration information to obtain a migration order value corresponding to each takeover node;

[0114] A target takeover node is selected from multiple takeover nodes according to the migration sequence value corresponding to each takeover node.

[0115] In some optional implementations, the migration module 630 is specifically configured to:

[0116] Determining, according to the configuration information of the first service node, whether the node type of the first service node is a master node type;

[0117] When it is determined that the node type of the first service node is a primary node type, selecting a service node from among the plurality of service nodes other than the first service node as a second service node;

[0118] Switching the node type of the first service node from a master node type to a standby node type, so that the first service node provides an in-memory database service as a standby node;

[0119] and, switching the node type of the second service node from a standby node type to a master node type, so that the second service node provides an in-memory database service as a master node;

[0120] After completing the node type switching operations corresponding to the first service node and the second service node, the memory database service running on the first service node is migrated to the target takeover node;

[0121] or,

[0122] When it is determined that the node type of the first service node is a standby node type, the memory database service running on the first service node is directly migrated to the target takeover node.

[0123] In some optional implementations, the migration module 630 is specifically configured to:

[0124] Deleting the in-memory database service on the first service node;

[0125] Create and start the in-memory database service on the target takeover node;

[0126] Also, the node type of the target takeover node is set to a standby node type, so that after the target takeover node starts the memory database service, it synchronizes the service data generated by the memory database service running on the second service node from the second service node according to the pre-built master-slave data synchronization mechanism.

[0127] In some optional embodiments, a module 640 is provided, specifically configured to:

[0128] Periodically obtain synchronization progress information of the target takeover node;

[0129] When the synchronization progress information obtained in any period indicates that data synchronization is complete, the operation of obtaining the synchronization progress information is stopped, and the migration operation is determined to be complete.

[0130] In some optional implementations, when there are multiple takeover nodes, the migration module 630 is further configured to:

[0131] Deleting the memory database services running on the other service nodes except the first service node among the multiple service nodes respectively;

[0132] Create and start the in-memory database service on each takeover node except the target takeover node.

[0133] Set the node types of other takeover nodes to the standby node type, so that after starting the memory database service, the other takeover nodes can synchronize the service data generated by the memory database service running on the target takeover node from the target takeover node according to the pre-built master-slave data synchronization mechanism.

[0134] For the description of the features in the embodiment corresponding to the hot migration device of the in-memory database service, please refer to the relevant description of the embodiment corresponding to the hot migration method of the in-memory database service, which will not be repeated here.

[0135] The embodiment of the present application also provides an electronic device, such as Figure 7 As shown, it includes a memory 10 and a processor 20, the memory 10 stores a computer program, and the processor 20 is configured to run the computer program to execute the steps in any of the above-mentioned embodiments of the hot migration method of the in-memory database service.

[0136] An embodiment of the present application further provides a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps of any of the above-mentioned embodiments of the hot migration method for the in-memory database service when running.

[0137] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0138] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps of any of the above-mentioned hot migration method embodiments of the in-memory database service are implemented.

[0139] An embodiment of the present application also provides another computer program product, including a non-volatile computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the steps of any of the above-mentioned hot migration method embodiments of the in-memory database service.

[0140] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0141] The above is a detailed introduction to the hot migration method, device, electronic device, storage medium, and program product of an in-memory database service provided by the present application. This article uses specific examples to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the claims of the present application.

Claims

1. A hot migration method for an in-memory database service, characterized in that: include: When a hot migration instruction of the in-memory database service is obtained, obtaining configuration information of multiple service nodes running the in-memory database service, wherein the hot migration instruction includes configuration information of at least one takeover node; Selecting a first service node from the plurality of service nodes according to the configuration information of each of the service nodes; Selecting a target takeover node from at least one of the takeover nodes according to configuration information of each of the takeover nodes; Migrating the in-memory database service running on the first service node to the target takeover node according to the configuration information of the first service node; When it is detected that the migration operation is completed, the node type of the target takeover node is set to a master node type, so that the target takeover node provides the in-memory database service as a master node.

2. The hot migration method of the in-memory database service according to claim 1, characterized in that: The selecting a first service node from the plurality of service nodes according to the configuration information of each of the service nodes includes: Sort each of the service nodes according to the configuration information of each of the service nodes to obtain a migration sequence value corresponding to each of the service nodes; The first service node is selected from the plurality of service nodes according to the migration sequence value corresponding to each of the service nodes.

3. The hot migration method of the in-memory database service according to claim 1 or 2, characterized in that: The selecting a first service node from the plurality of service nodes according to the configuration information of each of the service nodes includes: Sort each of the takeover nodes according to the configuration information of each of the takeover nodes to obtain a migration sequence value corresponding to each of the takeover nodes; The target takeover node is selected from the plurality of takeover nodes according to the migration sequence value corresponding to each of the takeover nodes.

4. The hot migration method of the in-memory database service according to claim 1 or 2, characterized in that: The migrating the memory database service running on the first service node to the target takeover node according to the configuration information of the first service node includes: Determining, according to the configuration information of the first service node, whether the node type of the first service node is a master node type; When it is determined that the node type of the first service node is the master node type, selecting a service node from other service nodes among the plurality of service nodes excluding the first service node as a second service node; Switching the node type of the first service node from the master node type to the standby node type, so that the first service node provides the in-memory database service as a standby node; and, switching the node type of the second service node from the standby node type to the master node type, so that the second service node provides the in-memory database service as the master node; After completing the node type switching operations corresponding to the first service node and the second service node, respectively, migrating the memory database service running on the first service node to the target takeover node; or, When it is determined that the node type of the first service node is the standby node type, the memory database service running on the first service node is directly migrated to the target takeover node.

5. The hot migration method of the in-memory database service according to claim 4, characterized in that: Migrate the in-memory database service running on the first service node to the target takeover node: Deleting the memory database service on the first service node; Creating and starting the in-memory database service on the target takeover node; In addition, the node type of the target takeover node is set to the backup node type, so that after the target takeover node starts the in-memory database service, it synchronizes the service data generated by the in-memory database service running on the second service node from the second service node according to the pre-built master-slave data synchronization mechanism.

6. The hot migration method of the in-memory database service according to claim 5, characterized in that: Check whether the migration operation is complete, including: Periodically obtaining synchronization progress information of the target takeover node; When the synchronization progress information acquired in any period indicates that data synchronization is completed, the operation of acquiring the synchronization progress information is stopped, and it is determined that the migration operation is completed.

7. The hot migration method of the in-memory database service according to claim 4, characterized in that: When there are multiple takeover nodes, upon detecting that the migration operation is complete and the node type of the target takeover node is not a master node type, after setting the node type of the target takeover node to the master node type, the method further includes: Deleting the memory database services running on other service nodes among the plurality of service nodes except the first service node respectively; Creating and starting the in-memory database service on other takeover nodes except the target takeover node; The node types of the other takeover nodes are respectively set to the standby node type, so that after starting the in-memory database service, the other takeover nodes synchronize the service data generated by the in-memory database service running on the target takeover node from the target takeover node according to the pre-built master-slave data synchronization mechanism.

8. A hot migration device for an in-memory database service, characterized in that: include: an acquisition module, configured to acquire configuration information of multiple service nodes running the in-memory database service when a hot migration instruction of the in-memory database service is obtained, wherein the hot migration instruction includes configuration information of at least one takeover node; a selection module, configured to select a first service node from the plurality of service nodes according to the configuration information of each of the service nodes; and select a target takeover node from at least one of the takeover nodes according to the configuration information of each of the takeover nodes; a migration module, configured to migrate the memory database service running on the first service node to the target takeover node according to the configuration information of the first service node; The setting module is used to set the node type of the target takeover node to the master node type when detecting that the migration operation is completed, so that the target takeover node provides the in-memory database service as the master node.

9. An electronic device, characterized in that: include: Memory for storing computer programs; A processor, configured to implement the steps of the hot migration method for the in-memory database service according to any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, the steps of the hot migration method of the in-memory database service according to any one of claims 1 to 7 are implemented.

Images