HBase upgrade method and device, storage medium and electronic equipment

Abstract

The application provides an HBase upgrading method and device, a storage medium and an electronic device, which can create a new version instance based on a Kubernetes environment when a rolling upgrade starts, and execute a start hook of the new version instance; check whether an upgrade lock exists in a preset directory of an old version instance; if the upgrade lock exists, execute a stop hook before the old version instance is offline and service is stopped; after Region migration of the old version instance is completed, delete a Znode node, and offline and stop the old version instance, so that a next new version instance is created to re-create the Znode node, and the next old version instance is migrated. Based on the start hook and the stop hook, the application determines the instance that needs to be upgraded, can directly migrate the service of the old version instance to the new version instance, avoids repeated migration of the old version instance, improves the upgrading efficiency, and avoids waste of bandwidth resources and computing resources.

Description

Technical Field

[0001] This invention relates to the field of servers, and in particular to an HBase upgrade method, apparatus, storage medium, and electronic device. Background Technology

[0002] For distributed services, multiple nodes often provide services externally. When upgrading service nodes (such as configuration changes, scaling up or down), a rolling restart operation needs to be performed on all nodes in the entire cluster. Deploying HBase clusters for distributed services in a containerized manner and managing them using Kubernetes is a current industry trend. Cloud-native deployment methods can improve cluster deployment efficiency, increase host hardware resource utilization, and quickly scale up or down according to business scale. Relying on Kubernetes' various service orchestration capabilities, it also facilitates various cluster upgrades. In this context, when upgrading HBase cluster RegionServers deployed on Kubernetes, the commonly used rolling upgrade method can ensure that the cluster's read and write services are not affected during the upgrade process, but the efficiency of Region migration is very low. Regions on RegionServers that are currently going offline will be migrated to other RegionServers that are going offline next. This cycle leads to the same batch of Regions being migrated repeatedly, reducing upgrade efficiency and seriously wasting bandwidth and computing resources. Summary of the Invention

[0003] In view of the above problems, the present invention provides an HBase upgrade method, apparatus, storage medium and electronic device that overcomes or at least partially solves the above problems.

[0004] Firstly, an HBase upgrade method includes:

[0005] When the rolling upgrade begins, a new version instance is created based on the Kubernetes environment, and the startup hook of the new version instance is executed. The execution logic of the startup hook is as follows: register a Znode node in Zookeeper and write the address of the new version instance into the Znode node.

[0006] Check if an upgrade lock exists in the preset directory of the old version instance, where the old version instance is the instance currently to be upgraded;

[0007] If the upgrade lock exists in the preset directory of the old version instance, a pre-set stop hook is executed before the old version instance is taken offline and service is stopped. The execution logic of the stop hook is as follows: read the corresponding address from the Znode node and migrate the Region of the old version instance to the address.

[0008] After the migration of the old version instance's Region is completed, the Znode node is deleted and the old version instance is taken offline to allow the creation of the next new version instance to recreate the Znode node, upgrade and migrate the next old version instance, and so on, until all nodes of the HBase cluster have been migrated and upgraded.

[0009] Optionally, in some alternative implementations, when the rolling upgrade begins, a new version instance is created based on the Kubernetes environment, and the startup hook of the new version instance is executed, including:

[0010] When a rolling upgrade begins, a new version instance is created based on the Kubernetes environment, and a startup hook is set for the new version instance;

[0011] Execute the startup hook of the new version instance to register a Znode node in ZooKeeper, wherein the address of the Znode node is: / hbase / region-moving-target;

[0012] Write the address and RPC service port number of the new version instance into the Znode node.

[0013] Optionally, in some optional implementations, checking whether an upgrade lock exists in a preset directory of the old version instance includes:

[0014] Check if the specified file exists in the preset directory to determine if an upgrade lock exists;

[0015] If the specified file exists in the preset directory, then the upgrade lock is confirmed to exist.

[0016] If the specified file does not exist in the preset directory, then the upgrade lock does not exist.

[0017] Optionally, in some alternative implementations, after checking whether an upgrade lock exists in a preset directory of the older version instance, the method further includes:

[0018] If the upgrade lock does not exist in the preset directory of the old version instance, the preset default node offline process is executed.

[0019] Optionally, in some optional implementations, if the upgrade lock exists in the preset directory of the old version instance, a pre-set stop hook is executed before the old version instance is taken offline and service is stopped, including:

[0020] If the upgrade lock exists in the preset directory of the old version instance, the stop hook of the old version instance is executed before the old version instance is taken offline and service is stopped, and the corresponding address is read from the Znode node;

[0021] The Region of the old version instance is migrated to the address obtained from the read, so as to migrate the Region of the old version instance to the new version instance.

[0022] Optionally, in some implementations, after the migration of the old version instance's Region is complete, the Znode node is deleted and the old version instance is taken offline to facilitate the creation of the next new version instance, recreating the Znode node, upgrading and migrating the next old version instance, and so on, until all nodes in the HBase cluster have been migrated and upgraded, including:

[0023] After the Region migration of the old version instance is completed, delete the Znode nodes created by the new version instance;

[0024] The Region service for the old version instance will be taken offline and stopped.

[0025] Rolling upgrades are performed to the next instance. A new version instance is created based on the Kubernetes environment, and a new Znode node is registered in ZooKeeper for upgrading and migrating the next old version instance. This process is repeated until all nodes in the HBase cluster have been migrated and upgraded.

[0026] Optionally, in some optional implementations, after the old version instance's Region migration is completed, the Znode node is deleted, and the old version instance is taken offline and stopped, the method further includes:

[0027] Control the preset sleep duration of the execution device of the old version instance.

[0028] Secondly, an HBase upgrade device includes: a new instance creation unit, an upgrade lock checking unit, a service migration unit, and an old instance decommissioning unit;

[0029] The new instance creation unit is used to create a new version instance based on the Kubernetes environment when the rolling upgrade starts, and execute the startup hook of the new version instance. The execution logic of the startup hook is as follows: register a Znode node in Zookeeper and write the address of the new version instance into the Znode node.

[0030] The upgrade lock checking unit is used to check whether there is an upgrade lock in the preset directory of the old version instance, wherein the old version instance is the instance to be upgraded.

[0031] The service migration unit is configured to execute a pre-set stop hook before the old version instance stops service if the upgrade lock exists in the preset directory of the old version instance. The execution logic of the stop hook is as follows: read the corresponding address from the Znode node and migrate the Region of the old version instance to the address.

[0032] The old instance offline unit is used to delete the Znode node and take the old version instance offline after the Region migration of the old version instance is completed, so as to create the next new version instance, recreate the Znode node, upgrade and migrate the next old version instance, and repeat this cycle until all nodes of the HBase cluster have been migrated and upgraded.

[0033] Thirdly, a computer-readable storage medium having a program stored thereon, which, when executed by a processor, implements the HBase upgrade method described in any of the preceding claims.

[0034] Fourthly, an electronic device includes at least one processor, at least one memory connected to the processor, and a bus; wherein the processor and the memory communicate with each other via the bus; the processor is used to call program instructions in the memory to execute the HBase upgrade method described above.

[0035] By employing the above technical solution, the present invention provides an HBase upgrade method, apparatus, storage medium, and electronic device that can create a new version instance based on a Kubernetes environment and execute a startup hook for the new version instance at the start of a rolling upgrade. The execution logic of the startup hook is as follows: register a Znode node in ZooKeeper and write the address of the new version instance into the Znode node; check if an upgrade lock exists in a preset directory of the old version instance, where the old version instance is the instance currently to be upgraded; if the upgrade lock exists in the preset directory of the old version instance, execute a pre-set stop hook before the old version instance is taken offline and stopped from service. The execution logic of the stop hook is as follows: read the corresponding address from the Znode node and migrate the Region of the old version instance to the address; after the Region migration of the old version instance is completed, delete the Znode node and take the old version instance offline to facilitate the creation of the next new version instance, recreate the Znode node, upgrade and migrate the next old version instance, and so on, repeating this cycle until all nodes in the HBase cluster have been migrated and upgraded. As can be seen, this invention can accurately determine the upgrade status of an instance based on start hooks and stop hooks, thereby accurately upgrading the instance to be upgraded. Furthermore, it can directly migrate the services of the old version instance to the new version instance by creating a new version instance, avoiding repeated migration of the old version instance, improving upgrade efficiency, and avoiding waste of bandwidth and computing resources.

[0036] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0037] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0038] Figure 1 A flowchart of the first HBase upgrade method provided by this invention is shown;

[0039] Figure 2 A flowchart of the second HBase upgrade method provided by this invention is shown;

[0040] Figure 3A flowchart of the third HBase upgrade method provided by this invention is shown;

[0041] Figure 4 A flowchart of the fourth HBase upgrade method provided by this invention is shown;

[0042] Figure 5 A flowchart of the fifth HBase upgrade method provided by this invention is shown;

[0043] Figure 6 The diagram illustrates the overall process framework of an HBase upgrade method provided by this invention.

[0044] Figure 7 This invention provides a schematic diagram of the structure of an HBase upgrade device.

[0045] Figure 8 A schematic diagram of the structure of an electronic device provided by the present invention is shown. Detailed Implementation

[0046] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this invention will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

[0047] like Figure 1 As shown, this invention provides an HBase upgrade method, including: S100, S200, S300 and S400;

[0048] S100. When the rolling upgrade begins, a new version instance is created based on the Kubernetes environment, and the startup hook of the new version instance is executed. The execution logic of the startup hook is as follows: register a Znode node in Zookeeper and write the address of the new version instance into the Znode node.

[0049] Optionally, the rolling upgrade mentioned in this invention refers to the process of upgrading one RegionServer node at a time during the Kubernetes upgrade process, and then upgrading the next RegionServer node after the previous one is successfully upgraded. However, since each RegionServer node is stateless (the position of any RegionServer node in the cluster is not special), this invention establishes start hooks and stop hooks to facilitate the targeted migration of Regions during subsequent upgrades, thereby achieving stateful control. This invention does not impose any limitations on this.

[0050] Optionally, for distributed services, multiple nodes often provide services to the outside world. When upgrading service nodes (such as configuration changes, scaling up or down, etc.), a rolling restart operation needs to be performed on all nodes in the entire cluster. In this embodiment of the invention, the data and services carried by the node can be smoothly migrated to other nodes to continue providing services during the entire upgrade process, and after the upgrade is completed, the data and services are migrated back to the original node, and the entire migration process does not affect the provision of services to the outside world.

[0051] Optionally, the Kubernetes environment (K8s) mentioned in this invention is an open-source container orchestration engine. Kubernetes aims to simplify the deployment, scaling, and management of containerized applications. Kubernetes provides rich features, such as automatic deployment, automatic scaling, rolling updates, and self-healing, making the operation and maintenance of containerized applications simpler and more efficient, and this invention does not limit these features.

[0052] Optionally, an instance (e.g., a new version of the instance of this invention) typically refers to a virtual server or container created in a cloud environment, which is a core component of cloud computing technology. Virtualization technology divides the resources of a physical server (such as CPU, memory, storage, etc.) into multiple independent parts, each of which can independently run operating systems and applications, forming independent server environments. This virtualization technology enables more flexible allocation and management of resources, improving resource utilization and system scalability; however, this invention does not limit this.

[0053] Optionally, in the rolling upgrade process, this invention upgrades one instance at a time. Each time an upgrade is performed, a new version instance can be created and a corresponding startup hook can be set and executed to facilitate the subsequent migration of Region services. This invention does not impose any restrictions on this.

[0054] For example, such as Figure 2 As shown, in some optional embodiments, S100 includes: S110, S120 and S130;

[0055] S110. When the rolling upgrade begins, a new version instance is created based on the Kubernetes environment, and a startup hook is set for the new version instance.

[0056] Optionally, the startup hook mentioned in this invention refers to a command executed immediately after the container (instance) is created. A startup hook is a command executed before a container instance in a Pod is started in Kubernetes. This invention can pre-define the logic and place it in the script that executes the command to complete environment initialization before instance startup or some cleanup and preparation work before instance shutdown. This invention does not impose any limitations on this.

[0057] S120. Execute the startup hook of the new version instance and register a Znode node in Zookeeper, wherein the address of the Znode node is: / hbase / region-moving-target;

[0058] Optionally, ZooKeeper is a distributed, open-source distributed application coordination service. It's an open-source implementation and a crucial component of Hadoop and HBase. It's software that provides consistency services for distributed applications, offering features such as configuration maintenance, domain name service, distributed synchronization, and group services.

[0059] S130. Write the address and RPC service port number of the new version instance into the Znode node.

[0060] Optionally, the container's address refers to the container's unique identifier on the host machine. Each container has a unique ID, which can be identified by the container's name or ID. This physical address allows the container to be found and managed on the host machine; this invention does not impose any limitations on this.

[0061] Optionally, RPC (Remote Procedure Call) is a technology that requests services from a remote computer program over a network without needing to understand the underlying network technology details. RPC employs a client or server model, where the client sends a call message to the service process, and the server processes the request and returns the result. RPC services typically use port 135 for communication, and this invention does not impose any restrictions on this.

[0062] Optionally, this invention writes the instance's address and RPC service port number information into a Znode node, so that the stop hook of subsequent older version instances can read the corresponding address and RPC service port number information from the Znode node to perform Region service migration. This invention does not limit this aspect.

[0063] S200. Check if there is an upgrade lock in the preset directory of the old version instance, wherein the old version instance is the instance to be upgraded.

[0064] Optionally, for each instance, the present invention may establish a corresponding preset directory and store corresponding files in the preset directory to indicate that an upgrade lock exists in the preset directory.

[0065] For example, such as Figure 3 As shown, in some optional embodiments, S200 includes: S210, S220 and S230;

[0066] S210. Check if the specified file exists in the preset directory to determine if an upgrade lock exists;

[0067] S220. If the specified file exists in the preset directory, then it is determined that the upgrade lock exists;

[0068] S230. If the specified file does not exist in the preset directory, then it is determined that the upgrade lock does not exist.

[0069] Optionally, the upgrade lock serves to address the issue that if a Znode node, due to some unforeseen event, fails to delete an offline instance in a timely manner and remains retained, it may affect the subsequent Region migration of normal instances. Therefore, this invention can write a file in a fixed directory of each node to be offline before the rolling upgrade begins, acting as an "upgrade lock" for Region migration. The existence of this "upgrade lock" on the current node is checked in the subsequent stop hook to determine whether an upgrade scenario is applicable.

[0070] Optionally, the present invention can randomly select the preset directory for writing the "upgrade lock". Once the preset directory is selected, it must be consistent before and after (that is, the directory written and the directory read in the subsequent process are consistent).

[0071] For example, a separate service might create a file with the value "1" in the " / etc / ready_to_upgrade" directory of the Znode node to be taken offline. This is to indicate that the Znode node has entered the rolling upgrade process, serving as a checksum for subsequent processes to prevent unforeseen circumstances from affecting the normal execution of subsequent logic.

[0072] When stopping hook execution later, you can check if the content of the " / etc / ready_to_upgrade" file is "1". If it is "1", it means that the upgrade process is normal; if it is not 1, or the file does not exist, the node will not perform the upgrade process.

[0073] This invention avoids errors caused by abnormal scenarios during the upgrade process by adding an "upgrade lock" logic. For example, if a RegionServer fails to promptly clean up the znode ` / regio-moving-target` in its registered Znode nodes, this uncleaned ` / regio-moving-target` might affect the aforementioned default migration strategy of the RegionServer. (In some scenarios where a RegionServer needs to be restarted / taken offline, the default Region migration strategy should be followed. In this scenario, rolling upgrades of RegionServers are not involved. In this scenario, Regions can be evenly distributed across other RegionServers.) This invention does not impose any restrictions on this.

[0074] Optionally, in some alternative embodiments, after S200, the method further includes:

[0075] If the upgrade lock does not exist in the preset directory of the old version instance, the preset default node offline process is executed.

[0076] Optionally, the preset default node shutdown process refers to the strategy that HBase itself will execute when a RegionServer goes offline, which is to uniformly migrate the Regions on the RegionServer to be shut down to other RegionServers in the cluster (this is something that this invention does not want to happen, because the aforementioned duplicate migration will occur), and this invention does not impose any restrictions on this.

[0077] S300. If the upgrade lock exists in the preset directory of the old version instance, before the old version instance is taken offline and service is stopped, a pre-set stop hook is executed. The execution logic of the stop hook is: read the corresponding address from the Znode node and migrate the Region of the old version instance to the address.

[0078] Optionally, in order to accurately migrate the Region service of the old version instance to the new version instance without affecting the continued provision of the corresponding Region service, this invention can execute the corresponding stop hook before taking the old version instance offline and stopping the service. After the execution is completed, the old version instance is taken offline. This invention does not impose any restrictions on this.

[0079] For example, such as Figure 4 As shown, in some optional embodiments, S300 includes: S310 and S320;

[0080] S310. If the upgrade lock exists in the preset directory of the old version instance, then before the old version instance is taken offline and service is stopped, the stop hook of the old version instance is executed, and the corresponding address is read from the Znode node.

[0081] S320. The Region of the old version instance is migrated to the address obtained by reading, so as to migrate the Region of the old version instance to the new version instance.

[0082] Optionally, as mentioned above, the address in the Znode is written when a new version instance is created, and this address matches the corresponding new version instance. That is, the Region service of the new version instance will be obtained from this address. Therefore, the stop hook can first migrate the Region service to this address so that the new version instance can obtain the Region service of the old version instance from this address. This invention does not limit this.

[0083] S400. After the migration of the Region of the old version instance is completed, delete the Znode node and take the old version instance offline to facilitate the creation of the next new version instance, recreate the Znode node, upgrade and migrate the next old version instance, and repeat this cycle until all nodes of the HBase cluster have been migrated and upgraded.

[0084] Optionally, as mentioned above, the Znode node is matched with the new version instance. To avoid confusion and errors in instance updates, this invention can create a new Znode node after the Region migration of each old version instance is completed. When rolling upgrade to the next old version instance, a new Znode node is created, and the corresponding address and RPC service port number information are written to this Znode node. This process is repeated repeatedly, and this invention does not limit the scope of the invention.

[0085] Optionally, an HBase cluster consists of multiple RegionServer nodes and one or more HMaster nodes. The HMaster node is responsible for managing metadata (such as table locations and partitions) and coordinating the various nodes in the cluster. The RegionServer nodes are responsible for storing and processing data and communicating with the HMaster node to obtain metadata information; this invention does not limit this.

[0086] Optionally, as mentioned earlier, Kubernetes is a tool for managing instance deployments. For distributed software like HBase, it can be deployed directly on physical machines (referred to as bare metal) or via Kubernetes. Kubernetes offers several deployment modes, including Deployments, ReplicaSet, StatefulSet, and DaemonSet. This invention can run in all of these deployment modes and achieve the goal of targeted Region migration. However, in practice, considering the convenience of managing the entire HBase cluster deployment, this invention generally recommends using the Deployments deployment mode.

[0087] For example, such as Figure 5 As shown, in some optional embodiments, S400 includes: S410, S420 and S430;

[0088] S410. After the Region migration of the old version instance is completed, delete the Znode node created by the new version instance;

[0089] Optionally, in some alternative embodiments, after S410, the method further includes:

[0090] Control the preset sleep duration of the execution device of the old version instance.

[0091] S420. Stop the Region service of the old version instance;

[0092] S430: Rolling upgrade to the next instance. Create the next new version instance based on the Kubernetes environment and register a new Znode node in Zookeeper for upgrading and migrating the next old version instance. Repeat this cycle until all nodes in the HBase cluster have been migrated and upgraded.

[0093] Optionally, to further clarify the solution of the present invention, the present invention provides, as follows: Figure 6 The overall process framework diagram shown is provided above. Please refer to the foregoing explanation for the contents of the diagram. This invention will not repeat them here.

[0094] This invention designs a reasonable Kubernetes upgrade strategy to achieve the correct order of bringing new version instances online and taking old version instances offline during the upgrade process, enabling targeted migration of regions.

[0095] This invention implements targeted migration of Regions before the old version instance is stopped by writing logic for Kubernetes instance start hooks and stop hooks, thus avoiding repeated migration of the same Region in subsequent upgrade processes.

[0096] This invention uses a Region migration tool to support the continued provision of read and write services during Region-directed migration, making the entire migration process transparent and seamless for users.

[0097] In summary, this invention designs a complete HBase RegionServer upgrade process. Through pre-written service upgrade logic, it achieves stateful targeted migration of Regions without disrupting the stateless deployment mode of RegionServers, thereby improving upgrade efficiency, avoiding resource waste caused by repeated Region migrations during the upgrade process, and ensuring that the cluster's external services are not affected during the upgrade process.

[0098] Although the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous.

[0099] It should be understood that the various steps described in the method embodiments of the present invention may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present invention is not limited in this respect.

[0100] like Figure 7 As shown, the present invention provides an HBase upgrade device, including: a new instance creation unit 100, an upgrade lock checking unit 200, a service migration unit 300, and an old instance decommissioning unit 400;

[0101] The new instance creation unit 100 is used to create a new version instance based on the Kubernetes environment when the rolling upgrade starts, and execute the startup hook of the new version instance. The execution logic of the startup hook is as follows: register a Znode node in Zookeeper and write the address of the new version instance into the Znode node.

[0102] The upgrade lock checking unit 200 is used to check whether there is an upgrade lock in the preset directory of the old version instance, wherein the old version instance is the instance to be upgraded.

[0103] The service migration unit 300 is used to execute a pre-set stop hook before the old version instance stops service if the upgrade lock exists in the preset directory of the old version instance. The execution logic of the stop hook is as follows: read the corresponding address from the Znode node and migrate the Region of the old version instance to the address.

[0104] The old instance offline unit 400 is used to delete the Znode node and take the old version instance offline after the Region migration of the old version instance is completed, so as to create the next new version instance, recreate the Znode node, upgrade and migrate the next old version instance, and repeat this cycle until all nodes of the HBase cluster have been migrated and upgraded.

[0105] Optionally, in some optional implementations, the new instance creation unit 100 includes: an instance creation subunit, a node registration subunit, and an information writing subunit;

[0106] The instance creation subunit is used to create a new version instance based on the Kubernetes environment when the rolling upgrade begins, and to set a startup hook for the new version instance;

[0107] The node registration subunit is used to execute the startup hook of the new version instance and register a Znode node in Zookeeper, wherein the address of the Znode node is: / hbase / region-moving-target;

[0108] The information writing sub-unit is used to write the address and RPC service port number of the new version instance into the Znode node.

[0109] Optionally, in some optional embodiments, the upgrade lock checking unit 200 includes: a file viewing subunit, an upgrade lock existence subunit, and an upgrade lock non-existence subunit;

[0110] The file viewing subunit is used to check whether a specified file exists in a preset directory, thereby determining whether an upgrade lock exists;

[0111] The upgrade lock has a subunit, which is used to determine the existence of the upgrade lock if the specified file exists in the preset directory;

[0112] The upgrade lock has no sub-unit, which is used to determine that the upgrade lock does not exist if the specified file does not exist in the preset directory.

[0113] Optionally, in some alternative embodiments, the apparatus further includes: a default process execution unit;

[0114] The default process execution unit is used to execute a preset default node offline process after checking whether an upgrade lock exists in the preset directory of the old version instance. If the upgrade lock does not exist in the preset directory of the old version instance, the default process execution unit is used to execute the preset process.

[0115] Optionally, in some alternative implementations, the service migration unit 300 includes: an address reading subunit and a Region migration subunit;

[0116] The address reading subunit is used to execute the stop hook of the old version instance and read the corresponding address from the Znode node before the old version instance stops service, if the upgrade lock exists in the preset directory of the old version instance;

[0117] The Region migration subunit is used to migrate the Region of the old version instance to the read address, so as to migrate the Region of the old version instance to the new version instance.

[0118] Optionally, in some optional implementations, the old instance offline unit 400 includes: a node deletion subunit, a service stop subunit, and a re-registration subunit;

[0119] The node deletion subunit is used to delete the Znode node created by the new version instance after the Region migration of the old version instance is completed;

[0120] The service stop subunit is used to take the Region service of the old version instance offline and stop it.

[0121] The re-registered sub-unit is used for rolling upgrades to the next instance. It creates the next new version instance based on the Kubernetes environment and registers a new Znode node in Zookeeper for upgrading and migrating the next old version instance. This process is repeated until all nodes in the HBase cluster have been migrated and upgraded.

[0122] Optionally, in some alternative embodiments, the device further includes: a device sleep unit;

[0123] The device hibernation unit is used to control the execution device hibernation preset duration of the old version instance after the old version instance's Region migration is completed, the Znode node is deleted, and the old version instance is taken offline and stopped.

[0124] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0125] The HBase upgrade device includes a processor and a memory. The new instance creation unit 100, upgrade lock check unit 200, service migration unit 300, and old instance decommissioning unit 400 are all stored as program units in the memory. The processor executes the program units stored in the memory to achieve the corresponding functions.

[0126] The processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured, and by adjusting kernel parameters based on start and stop hooks, the upgrade status of an instance can be accurately determined. This allows for the accurate upgrading of instances that need upgrading. Furthermore, by creating a new version instance, services from the old version instance can be directly migrated to the new version instance, avoiding repeated migrations of the old version instance, improving upgrade efficiency, and preventing the waste of bandwidth and computing resources.

[0127] This invention provides a computer-readable storage medium storing a program that, when executed by a processor, implements the HBase upgrade method.

[0128] This invention provides a processor for running a program, wherein the program executes the HBase upgrade method during runtime.

[0129] like Figure 8 As shown, this embodiment of the invention provides an electronic device 70, which includes at least one processor 701, at least one memory 702 connected to the processor 701, and a bus 703. The processor 701 and the memory 702 communicate with each other via the bus 703. The processor 701 is used to call program instructions in the memory 702 to execute the aforementioned HBase upgrade method. The electronic device in this document can be a server, PC, PAD, mobile phone, etc.

[0130] The present invention also provides a computer program product, which, when executed on an electronic device, is suitable for executing an initialization program having the following method steps:

[0131] An HBase upgrade method includes:

[0132] When the rolling upgrade begins, a new version instance is created based on the Kubernetes environment, and the startup hook of the new version instance is executed. The execution logic of the startup hook is as follows: register a Znode node in Zookeeper and write the address of the new version instance into the Znode node.

[0133] Check if an upgrade lock exists in the preset directory of the old version instance, where the old version instance is the instance currently to be upgraded;

[0134] If the upgrade lock exists in the preset directory of the old version instance, a pre-set stop hook is executed before the old version instance is taken offline and service is stopped. The execution logic of the stop hook is as follows: read the corresponding address from the Znode node and migrate the Region of the old version instance to the address.

[0135] After the migration of the old version instance's Region is completed, the Znode node is deleted and the old version instance is taken offline to allow the creation of the next new version instance to recreate the Znode node, upgrade and migrate the next old version instance, and so on, until all nodes of the HBase cluster have been migrated and upgraded.

[0136] Optionally, in some alternative implementations, when the rolling upgrade begins, a new version instance is created based on the Kubernetes environment, and the startup hook of the new version instance is executed, including:

[0137] When a rolling upgrade begins, a new version instance is created based on the Kubernetes environment, and a startup hook is set for the new version instance;

[0138] Execute the startup hook of the new version instance to register a Znode node in ZooKeeper, wherein the address of the Znode node is: / hbase / region-moving-target;

[0139] Write the address and RPC service port number of the new version instance into the Znode node.

[0140] Optionally, in some optional implementations, checking whether an upgrade lock exists in a preset directory of the old version instance includes:

[0141] Check if the specified file exists in the preset directory to determine if an upgrade lock exists;

[0142] If the specified file exists in the preset directory, then the upgrade lock is confirmed to exist.

[0143] If the specified file does not exist in the preset directory, then the upgrade lock does not exist.

[0144] Optionally, in some alternative implementations, after checking whether an upgrade lock exists in a preset directory of the older version instance, the method further includes:

[0145] If the upgrade lock does not exist in the preset directory of the old version instance, the preset default node offline process is executed.

[0146] Optionally, in some optional implementations, if the upgrade lock exists in the preset directory of the old version instance, a pre-set stop hook is executed before the old version instance is taken offline and service is stopped, including:

[0147] If the upgrade lock exists in the preset directory of the old version instance, the stop hook of the old version instance is executed before the old version instance is taken offline and service is stopped, and the corresponding address is read from the Znode node;

[0148] The Region of the old version instance is migrated to the address obtained from the read, so as to migrate the Region of the old version instance to the new version instance.

[0149] Optionally, in some implementations, after the migration of the old version instance's Region is complete, the Znode node is deleted and the old version instance is taken offline to facilitate the creation of the next new version instance, recreating the Znode node, upgrading and migrating the next old version instance, and so on, until all nodes in the HBase cluster have been migrated and upgraded, including:

[0150] After the Region migration of the old version instance is completed, delete the Znode nodes created by the new version instance;

[0151] The Region service for the old version instance will be taken offline and stopped.

[0152] Rolling upgrades are performed to the next instance. A new version instance is created based on the Kubernetes environment, and a new Znode node is registered in ZooKeeper for upgrading and migrating the next old version instance. This process is repeated until all nodes in the HBase cluster have been migrated and upgraded.

[0153] Optionally, in some optional implementations, after the old version instance's Region migration is completed, the Znode node is deleted, and the old version instance is taken offline and stopped, the method further includes:

[0154] Control the preset sleep duration of the execution device of the old version instance.

[0155] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatuses, electronic devices (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0156] In a typical configuration, an electronic device includes one or more processors (CPUs), memory, and a bus. The electronic device may also include input / output interfaces, network interfaces, etc.

[0157] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, like read-only memory (ROM) or flash RAM, and memory includes at least one memory chip. Memory is an example of computer-readable media.

[0158] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0159] In the description of this invention, it should be understood that if the terms "upper", "lower", "front", "rear", "left" and "right" are used to indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, they are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the position or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this invention.

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

[0161] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0162] The above are merely embodiments of the present invention and are not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of the present invention should be included within the scope of the present invention.

Claims

1. An HBase upgrade method, characterized in that, include: When the rolling upgrade begins, a new version instance is created based on the Kubernetes environment, and the startup hook of the new version instance is executed. The execution logic of the startup hook is as follows: register a Znode node in Zookeeper and write the address of the new version instance into the Znode node. Check if an upgrade lock exists in the preset directory of the old version instance, where the old version instance is the instance currently to be upgraded; If the upgrade lock exists in the preset directory of the old version instance, a pre-set stop hook is executed before the old version instance is taken offline and service is stopped. The execution logic of the stop hook is as follows: read the corresponding address from the Znode node and migrate the Region of the old version instance to the address. After the migration of the old version instance's Region is completed, the Znode node is deleted and the old version instance is taken offline to allow the creation of the next new version instance to recreate the Znode node, upgrade and migrate the next old version instance, and so on, until all nodes of the HBase cluster have been migrated and upgraded.

2. The method according to claim 1, characterized in that, When the rolling upgrade begins, a new version instance is created based on the Kubernetes environment, and the startup hook of the new version instance is executed, including: When a rolling upgrade begins, a new version instance is created based on the Kubernetes environment, and a startup hook is set for the new version instance; Execute the startup hook of the new version instance to register a Znode node in ZooKeeper, wherein the address of the Znode node is: / hbase / region-moving-target; Write the address and RPC service port number of the new version instance into the Znode node.

3. The method according to claim 1, characterized in that, The step of checking whether an upgrade lock exists in the preset directory of the old version instance includes: Check if the specified file exists in the preset directory to determine if an upgrade lock exists; If the specified file exists in the preset directory, then the upgrade lock is confirmed to exist. If the specified file does not exist in the preset directory, then the upgrade lock does not exist.

4. The method according to claim 1, characterized in that, After checking whether an upgrade lock exists in the preset directory of the old version instance, the method further includes: If the upgrade lock does not exist in the preset directory of the old version instance, the preset default node offline process is executed.

5. The method according to claim 1, characterized in that, If the upgrade lock exists in the preset directory of the old version instance, then before the old version instance is taken offline and service is stopped, a pre-set stop hook is executed, including: If the upgrade lock exists in the preset directory of the old version instance, the stop hook of the old version instance is executed before the old version instance is taken offline and service is stopped, and the corresponding address is read from the Znode node; The Region of the old version instance is migrated to the address obtained from the read, so as to migrate the Region of the old version instance to the new version instance.

6. The method according to claim 1, characterized in that, After the migration of the Region of the old version instance is completed, the Znode node is deleted, and the old version instance is taken offline and stopped. This is to facilitate the creation of the next new version instance, recreating the Znode node, upgrading and migrating the next old version instance, and repeating this cycle until all nodes in the HBase cluster have been migrated and upgraded, including: After the Region migration of the old version instance is completed, delete the Znode nodes created by the new version instance; The Region service for the old version instance will be taken offline and stopped. Rolling upgrades are performed to the next instance. A new version instance is created based on the Kubernetes environment, and a new Znode node is registered in ZooKeeper for upgrading and migrating the next old version instance. This process is repeated until all nodes in the HBase cluster have been migrated and upgraded.

7. The method according to claim 1, characterized in that, After the migration of the old version instance's Region is completed, the Znode node is deleted, and the old version instance is taken offline and stopped, the method further includes: Control the preset sleep duration of the execution device of the old version instance.

8. An HBase upgrade device, characterized in that, include: New instance creation unit, upgrade lock check unit, service migration unit, and old instance decommissioning unit; The new instance creation unit is used to create a new version instance based on the Kubernetes environment when the rolling upgrade starts, and execute the startup hook of the new version instance. The execution logic of the startup hook is as follows: register a Znode node in Zookeeper and write the address of the new version instance into the Znode node. The upgrade lock checking unit is used to check whether there is an upgrade lock in the preset directory of the old version instance, wherein the old version instance is the instance to be upgraded. The service migration unit is configured to execute a pre-set stop hook before the old version instance stops service if the upgrade lock exists in the preset directory of the old version instance. The execution logic of the stop hook is as follows: read the corresponding address from the Znode node and migrate the Region of the old version instance to the address. The old instance offline unit is used to delete the Znode node and take the old version instance offline after the Region migration of the old version instance is completed, so as to create the next new version instance, recreate the Znode node, upgrade and migrate the next old version instance, and repeat this cycle until all nodes of the HBase cluster have been migrated and upgraded.

9. A computer-readable storage medium having a program stored thereon, characterized in that, When the program is executed by the processor, it implements the HBase upgrade method as described in any one of claims 1 to 7.

10. An electronic device, characterized in that, The electronic device includes at least one processor, at least one memory connected to the processor, and a bus; wherein the processor and the memory communicate with each other through the bus; the processor is used to call program instructions in the memory to execute the HBase upgrade method as described in any one of claims 1 to 7.

Images