HBase upgrading method and device, storage medium and electronic equipment

Abstract

The invention provides an HBase upgrading method and device, a storage medium and electronic equipment, and the method comprises the steps: creating a new version instance based on a Kubernetes environment at the beginning of rolling upgrading, and executing a starting hook of the new version instance; checking whether an upgrade lock exists in a preset directory of the old version instance or not; if the upgrade lock exists, executing a stop hook before the old version instance is offline and stops service; and after the Region migration of the old version instance is completed, deleting the Zode node, and stopping the old version instance offline so as to create a next new version instance, recreate the Zode node and upgrade and migrate the next old version instance. According to the method, the instance needing to be upgraded is determined based on the start hook and the stop hook, the service of the old version instance can be directly migrated to the new version instance, the situation of repeated migration of the old version instance is avoided, the upgrading efficiency is improved, and waste of broadband resources and computing resources is avoided.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of servers, in particular to an HBase upgrading method and device, a storage medium and an electronic equipment. BACKGROUND

[0002] For distributed services, there are often multiple nodes providing services externally. When upgrading service nodes (such as configuration changes, capacity expansion, etc.), a rolling restart operation needs to be performed on all nodes of the entire cluster. Deploying the HBase cluster of the distributed service in a containerized manner and using Kubernetes for management is a current trend in the industry for deploying HBase clusters. Cloud-native deployment can improve cluster deployment efficiency, improve host hardware resource utilization, quickly expand or shrink capacity according to business size, and rely on various service orchestration capabilities of Kubernetes to easily perform various upgrades on the cluster. In this context, the commonly used rolling upgrade method for upgrading the RegionServer of the HBase cluster deployed on Kubernetes can ensure that the read-write services of the cluster are not affected during the upgrade process, but the efficiency of Region migration is very low. The Regions on the RegionServer to be offline will be migrated to other RegionServers to be offline next, and this cycle will cause the same batch of Regions to be repeatedly migrated, reducing the upgrade efficiency and seriously wasting bandwidth and computing resources. SUMMARY

[0003] In view of the above problems, the present application provides an HBase upgrading method, device, storage medium and electronic equipment which can overcome the above problems or at least partially solve the above problems.

[0004] In a first aspect, an HBase upgrading method is provided, comprising:

[0005] When the rolling upgrade starts, a new version instance is created based on the Kubernetes environment, and a startup hook of the new version instance is executed, wherein the execution logic of the startup hook is to register a Znode node in Zookeeper and write the address of the new version instance into the Znode node;

[0006] Check whether there is an upgrade lock in a preset directory of an old version instance, wherein the old version instance is the current instance to be upgraded;

[0007] If the upgrade lock exists in the preset directory of the old version instance, a preset stop hook is executed before the old version instance is offline and stops serving, and the execution logic of the stop hook is that a corresponding address is read from the Znode node, and the Region of the old version instance is migrated to the address.

[0008] After the Region migration of the old version instance is completed, the Znode node is deleted, and the old version instance is offline and stopped, so that a next new version instance is created to re-create a Znode node, a next old version instance is migrated and upgraded, and the cycle is repeated until the migration and upgrade of all nodes of the HBase cluster are completed.

[0009] Optionally, in some optional embodiments, when the rolling upgrade starts, a new version instance is created based on a Kubernetes environment, and a start hook of the new version instance is executed, including:

[0010] When the rolling upgrade starts, a new version instance is created based on a Kubernetes environment, and a start hook of the new version instance is set;

[0011] The start hook of the new version instance is executed, and a Znode node is registered in Zookeeper, wherein the address of the Znode node is: / hbase / region-moving-target.

[0012] The address and RPC service port number information of the new version instance are written into the Znode node.

[0013] Optionally, in some optional embodiments, the method further includes:

[0014] It is determined whether the upgrade lock exists in the preset directory of the old version instance by checking whether a specified file exists in a preset directory.

[0015] If the specified file exists in the preset directory, it is determined that the upgrade lock exists.

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

[0017] Optionally, in some optional embodiments, after it is determined whether the upgrade lock exists in the preset directory of the old version instance, the method further includes:

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

[0019] Optionally, in some optional embodiments, if the upgrade lock exists in the preset directory of the old version instance, a preset stop hook is executed before the old version instance is offline and stops serving, including:

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

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

[0022] Optionally, in some optional embodiments, after the Region migration of the old version instance is completed, the Znode node is deleted, and the old version instance is offline and stopped, so as to create a new Znode node for the next new version instance, and migrate the next old version instance, and so on until all nodes of the HBase cluster are migrated and upgraded, including:

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

[0024] The Region service of the old version instance is offline and stopped;

[0025] The next instance is rolled up, a next new version instance is created based on the Kubernetes environment, and a Znode node is registered in the Zookeeper for migrating the next old version instance, and so on until all nodes of the HBase cluster are migrated and upgraded.

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

[0027] The execution device of the old version instance is controlled to sleep for a preset time length.

[0028] In a second aspect, an HBase upgrading apparatus includes a new instance creating unit, an upgrade lock checking unit, a service migrating unit and an old instance offline unit.

[0029] The new instance creation unit is configured to, when the rolling upgrade starts, create a new version instance based on a Kubernetes environment, and execute a start hook of the new version instance, wherein the execution logic of the start hook is: registering a Znode node in Zookeeper, and writing an address of the new version instance into the Znode node.

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

[0031] The service migration unit is configured to, 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 offline and service is stopped, wherein the execution logic of the stop hook is: reading a corresponding address from the Znode node, and migrating a Region of the old version instance to the address.

[0032] The old instance offline unit is configured to, after the migration of the Region of the old version instance is completed, deleting the Znode node, and offline and stopping the old version instance, so as to create a next new version instance to re-create a Znode node, and to upgrade and migrate a next old version instance, and so on, until all nodes of the HBase cluster are migrated and upgraded.

[0033] In a third aspect, a computer readable storage medium has a program stored thereon, and the program is executed by a processor to implement the HBase upgrade method of any of the preceding aspects.

[0034] In a fourth aspect, an electronic device includes at least one processor, and at least one memory connected to the processor; wherein the processor and the memory complete mutual communication through a bus; the processor is configured to call program instructions in the memory to execute the HBase upgrade method of any of the preceding aspects.

[0035] By the technical scheme, the HBase upgrading method, device, storage medium and electronic equipment provided by the application can create a new version instance based on a Kubernetes environment at the beginning of rolling upgrade, and execute a start hook of the new version instance, wherein the execution logic of the start hook is: registering a Znode node in Zookeeper, and writing the address of the new version instance into the Znode node; checking whether an upgrade lock exists in a preset directory of an old version instance, wherein the old version instance is a current instance to be upgraded; if the upgrade lock exists in the preset directory of the old version instance, executing a preset stop hook before the old version instance is offline and service is stopped, wherein the execution logic of the stop hook is: reading the corresponding address from the Znode node, and migrating the Region of the old version instance to the address; after the Region of the old version instance is migrated, deleting the Znode node, and offline and stopping the old version instance, so as to create a next new version instance to re-create a Znode node, upgrade and migrate a next old version instance, and repeat the cycle until each node of the HBase cluster is migrated and upgraded. As can be seen, the application can accurately determine the upgrading state of the instance based on the start hook and the stop hook, accurately upgrade the instance to be upgraded, and directly migrate the service of the old version instance to the new version instance by establishing the new version instance, thereby avoiding repeated migration of the old version instance, improving the upgrading efficiency, and avoiding waste of bandwidth resources and computing resources.

[0036] The above description is only a summary of the technical scheme of the application. In order to more clearly understand the technical means of the application, the application can be implemented according to the content of the specification, and in order to make the above and other purposes, characteristics and advantages of the application more obvious and easy to understand, the following specific embodiments of the application are described. BRIEF DESCRIPTION OF DRAWINGS

[0037] Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments. The accompanying drawings are included to provide a description of the preferred embodiments and are not meant to limit the present application. Furthermore, the same reference numerals are used throughout the several drawings to designate the same or similar parts. In the drawings:

[0038] Figure 1 A flowchart of a first HBase upgrading method provided by the application is shown;

[0039] Figure 2 A flowchart of a second HBase upgrading method provided by the application is shown;

[0040] Figure 3A flow chart of a third HBase upgrading method provided by the application is shown;

[0041] Figure 4 A flow chart of a fourth HBase upgrading method provided by the application is shown;

[0042] Figure 5 A flow chart of a fifth HBase upgrading method provided by the application is shown;

[0043] Figure 6 A general flow chart of a HBase upgrading method provided by the application is shown;

[0044] Figure 7 A structure schematic diagram of a HBase upgrading device provided by the application is shown;

[0045] Figure 8 A structure schematic diagram of an electronic device provided by the application is shown. DETAILED DESCRIPTION

[0046] Exemplary embodiments of the present application will be described herein below with reference to the accompanying drawings. Although exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application can be implemented in various forms and should not be limited by the embodiments set forth herein. Rather, these embodiments are provided so that the present application can be more thoroughly understood and so that the scope of the present application can be completely conveyed to those skilled in the art.

[0047] As shown in Figure 1 The present application provides a HBase upgrading method, comprising: S100, S200, S300 and S400.

[0048] S100, when the rolling upgrade starts, a new version instance is created based on the Kubernetes environment, and a start hook of the new version instance is executed, wherein the execution logic of the start hook is to 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 the present application refers to a process that one RegionServer node is upgraded at a time during the Kubernetes upgrading process, and the next RegionServer node is upgraded after the upgrading of the current RegionServer node is successful. However, since each RegionServer node is stateless (there is no particularity in the position of any RegionServer node in the cluster), the present application establishes a start hook and a stop hook to facilitate the subsequent upgrading process to migrate the Region directionally, so as to realize the stateful control, and the present application does not limit this.

[0050] Optionally, for distributed services, there are often multiple nodes providing services externally. When upgrading service nodes (such as configuration changes, scaling, etc.), it is necessary to perform a rolling restart operation on all nodes in the entire cluster. The embodiment of the present application can smoothly migrate the data and services borne by the nodes to other nodes to continue providing services during the entire upgrade process, and migrate these data and services to the node again after the upgrade is completed, and the entire migration process does not affect the external service provision.

[0051] Optionally, the Kubernetes environment (K8s for short) mentioned in the present application is an open source container orchestration engine. Kubernetes aims to simplify the deployment, expansion and management process of containerized applications. Kubernetes provides rich functions such as automatic deployment, automatic expansion, rolling update, self-repair, etc., making the operation and maintenance of containerized applications more simple and efficient, and the present application does not limit this.

[0052] Optionally, an instance (for example, a new version instance of the present application) generally refers to a virtual server or container created in a cloud environment, which is a core component of cloud computing technology. Through virtualization technology, the resources (such as CPU, memory, storage, etc.) of a physical server are divided into multiple independent parts, each of which can independently run an operating system and an application program to form an independent server environment. This virtualization technology enables more flexible allocation and management of resources, improving resource utilization and system scalability, and the present application does not limit this.

[0053] Optionally, during the rolling upgrade process, one instance is upgraded at a time, a new version instance can be recreated each time, and a corresponding startup hook can be set, and then the startup hook is executed to facilitate subsequent migration of the Region service, and the present application does not limit this.

[0054] For example, as shown in Figure 2 In some optional embodiments, the S100 includes S110, S120 and S130.

[0055] S110, when the rolling upgrade starts, 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 the present application refers to a command executed immediately after the creation of a container (instance). The startup hook refers to a command executed before starting a container instance in a Pod started by Kubernetes. The present application can place the defined logic in the script of the execution command in advance to complete the environment initialization before instance startup or some cleaning and preparation work before instance stop, and the present application does not limit this.

[0057] S120, executing a start hook of the new version instance, and registering a Znode node in Zookeeper, wherein an address of the Znode node is / hbase / region-moving-target;

[0058] Optionally, Zookeeper is a distributed, open source distributed application coordination service, which is an open source implementation and an important component of Hadoop and Hbase. It is a software that provides consistency service for distributed applications, and provides functions including configuration maintenance, domain name service, distributed synchronization, group service, etc.

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

[0060] Optionally, the address of the container refers to a unique identifier of the container on the host machine. Each container has a unique ID, and the container can be identified by the name or ID of the container. Through the physical address, the container can be found and managed on the host machine, and the present application does not make any limitation.

[0061] Optionally, RPC (Remote Procedure Call) is a technology for requesting services from remote computer programs through a network without understanding the details of the underlying network technology. RPC adopts a client or server mode, and the client sends call information to the service process, and the server processes the request and returns the result. The RPC service usually uses port 135 for communication, and the present application does not make any limitation.

[0062] Optionally, the present application writes the address and RPC service port number information of the instance into the Znode node, so that the stop hook of the old version instance can read the corresponding address and RPC service port number information from the Znode node for Region service migration, and the present application does not make any limitation.

[0063] S200, checking whether an upgrade lock exists in a preset directory of an old version instance, wherein the old version instance is a current instance to be upgraded;

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

[0065] For example, as shown in Figure 3 S200, S210, S220 and S230 are included in some optional embodiments.

[0066] S210, checking whether the specified file exists in the preset directory to determine whether the upgrade lock exists;

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

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

[0069] Optionally, the upgrade lock functions if the Znode node has not been deleted in time due to some unexpected reasons, and the Znode node is always retained, which may affect the Region migration of the subsequent normal instance. Therefore, the application can write a file in the fixed directory of each node to be offline before the start of the rolling upgrade, as the "upgrade lock" of the Region migration. In the subsequent stop hook, it is checked whether the current node exists the "upgrade lock" to determine whether it belongs to the upgrade scenario.

[0070] Optionally, for the preset directory of the "upgrade lock", the application can be randomly selected, and once the preset directory is selected, it must be consistent before and after (that is, the written directory and the subsequent read directory are consistent).

[0071] For example, an independent service generates a file under the " / etc / ready_to_upgrade" file of the Znode node to be offline, and the content is "1". The purpose is to identify that the Znode node enters the rolling upgrade process, as a check bit of the subsequent process, to prevent some unexpected situations from affecting the normal execution of the subsequent logic.

[0072] When the subsequent stop hook is executed, it can be checked whether the content under the " / etc / ready_to_upgrade" file is "1". If it is "1", it indicates a normal upgrade process; if it is not "1", or the file does not exist, the node does not perform the upgrade process.

[0073] The application avoids errors caused by some abnormal scenarios during the upgrade process by adding the logic of the "upgrade lock". For example, if a RegionServer cannot clean up the znode: / regio-moving-target in the Znode node registered by itself in time, the uncleaned / regio-moving-target can affect the default migration strategy of the aforementioned RegionServer. (In some scenarios, the default Region migration strategy needs to be used when the RegionServer needs to be restarted or offline. In this scenario, the rolling upgrade of the RegionServer is not involved. In this scenario, the Regions can be evenly distributed to other RegionServers, and the application does not limit this.

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

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

[0076] Optionally, the preset default node offline process refers to the strategy that will be performed when the RegionServer of HBase itself is offline, that is, the Regions on the RegionServer to be offline are evenly migrated to other RegionServers in the cluster (this is not expected to happen in the application because the aforementioned repeated migration can occur), and the application does not limit this.

[0077] S300, if the upgrade lock exists in the preset directory of the old version instance, a preset stop hook is executed before the old version instance is offline and stops serving, and the execution logic of the stop hook is to read the corresponding address from the Znode node and migrate the Regions 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 and not affect the corresponding Region service to continue providing services during the migration, the application can execute the corresponding stop hook before the old version instance is offline and stops serving, and then offline the old version instance after the execution is completed, and the application does not limit this.

[0079] For example, as shown in Figure 4 S300, in some optional embodiments, S300 includes S310 and S320.

[0080] S310, if the preset directory of the old version instance exists the upgrade lock, before the old version instance is offline and stops service, executing the stop hook of the old version instance, reading the corresponding address from the Znode node;

[0081] S320, migrating 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.

[0082] Optionally, as described above, the address in the Znode node is written when the new version instance is established, and the address matches the corresponding new version instance. That is, the Region service of the new version instance will be obtained from the address, therefore, the stop hook can first migrate the Region service to the address, so that the new version instance obtains the Region service of the old version instance from the address, and the application does not limit this.

[0083] S400, after the Region of the old version instance is migrated, the Znode node is deleted, and the old version instance is offline and stopped, so as to create the next new version instance to re-create the Znode node, upgrade and migrate the next old version instance, and repeat the cycle until the nodes of the HBase cluster are all migrated and upgraded.

[0084] Optionally, as described above, the Znode node matches the new version instance, in order to avoid confusion and cause instance update error, the application can delete the corresponding Znode node after the Region of each old version instance is migrated, re-create a Znode node when the next old version instance is rolled over and upgraded, and write the corresponding address and RPC service port number information in the Znode node, and repeat the cycle, and the application does not limit this.

[0085] Optionally, the HBase cluster is composed of a plurality of RegionServer nodes and one or more HMaster nodes. The HMaster node is responsible for managing metadata (for example, the location and partition of a table), and coordinating the nodes in the cluster. The RegionServer node is responsible for storing and processing data, and communicating with the HMaster node to obtain metadata information, and the application does not limit this.

[0086] Optionally, as mentioned before, Kubernetes is a management tool for instance deployment. For such distributed software as HBase, it can be deployed directly on a physical machine (referred to as bare cloth) or deployed through Kubernetes. For Kubernetes, there are several deployment modes such as Deployments, ReplicaSet, StatefulSet, DaemonSet, etc. The present application can run in these deployment modes and achieve the goal of directional migration of Region. However, in actual combat, considering the convenience of management of the entire HBase cluster deployment, the present application generally recommends using the Deployments deployment mode.

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

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

[0089] Optionally, in some optional embodiments, after the S410, the method further comprises:

[0090] controlling the execution device of the old version instance to sleep for a preset time length.

[0091] S420, offline the Region service of the old version instance;

[0092] S430, roll upgrade to the next instance, create the next new version instance based on the Kubernetes environment, and register a Znode node in Zookeeper for upgrading and migrating the next old version instance, and repeat the cycle until the migration and upgrade of each node of the HBase cluster are completed.

[0093] Optionally, in order to further clearly illustrate the scheme of the present application, the present application provides a general flow framework diagram as shown in Figure 6 the contents in the figure are described above, and the present application will not be repeated.

[0094] The present application realizes the sequence of online of the new version instance and offline of the old version instance in the upgrade process through designing a reasonable Kubernetes upgrade strategy, and realizes the directional migration of Region.

[0095] The present application realizes the directional migration of Region before the old version instance is stopped by writing the logic of the Kubernetes instance start hook and stop hook, and avoids the repeated migration of the same Region in the subsequent upgrade process.

[0096] The application uses a Region migration tool to support external read and write services during the Region-oriented migration process, so that the entire migration process is transparent and imperceptible to users.

[0097] To sum up, the application designs a complete HBase RegionServer upgrade process, and through the service upgrade logic written in advance, the Region-oriented migration is realized without destroying the stateless deployment mode of RegionServer, the efficiency of the upgrade is improved, the resource waste caused by repeated migration of Region during the upgrade process is avoided, and the external service of the cluster during the upgrade process is guaranteed.

[0098] Although the operations are depicted in a particular order, this should not be understood as requiring the operations to be performed in the particular order shown or in sequential order. Under certain circumstances, multitasking and parallel processing can be advantageous.

[0099] It should be understood that each step described in the method embodiments of the application can be performed in a different order and / or in parallel. In addition, the method embodiments can include additional steps and / or omit the execution of the steps shown. The scope of the application is not limited in this respect.

[0100] As shown in Figure 7 The application provides an HBase upgrade device, which comprises a new instance creation unit 100, an upgrade lock checking unit 200, a service migration unit 300 and an old instance offline unit 400.

[0101] The new instance creation unit 100 is used to create a new version instance based on a Kubernetes environment when a rolling upgrade starts, and execute a startup hook of the new version instance, wherein the execution logic of the startup hook is to 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 an upgrade lock exists in a preset directory of an old version instance, wherein the old version instance is the current instance to be upgraded.

[0103] The service migration unit 300 is used to execute a preset stop hook before the old version instance stops the service if the upgrade lock exists in the preset directory of the old version instance, wherein the execution logic of the stop hook is to 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 configured to delete the Znode node and offline and stop the old version instance after the Region migration of the old version instance is completed, so as to create a next new version instance to re-create a Znode node, migrate and upgrade a next old version instance, and repeat the cycle until the migration and upgrade of all nodes of the HBase cluster are completed.

[0105] Optionally, in some optional embodiments, the new instance creation unit 100 comprises an instance creation subunit, a node registration subunit and an information writing subunit.

[0106] The instance creation subunit is configured to create a new version instance based on a Kubernetes environment and set a start hook for the new version instance when the rolling upgrade starts.

[0107] The node registration subunit is configured to execute the start 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 subunit is configured to write the address and RPC service port number information of the new version instance into the Znode node.

[0109] Optionally, in some optional embodiments, the upgrade lock checking unit 200 comprises a file checking subunit, an upgrade lock existing subunit and an upgrade lock non-existing subunit.

[0110] The file checking subunit is configured to check whether a specified file exists in a preset directory, so as to determine whether an upgrade lock exists.

[0111] The upgrade lock existing subunit is configured to determine that the upgrade lock exists if the specified file exists in the preset directory.

[0112] The upgrade lock non-existing subunit is configured to determine that the upgrade lock does not exist if the specified file does not exist in the preset directory.

[0113] Optionally, in some optional embodiments, the apparatus further comprises a default process execution unit.

[0114] The default process execution unit is configured to execute a preset default node offline process if the upgrade lock does not exist in the preset directory of the old version instance after the preset directory of the old version instance is checked.

[0115] Optionally, in some optional embodiments, the service migration unit 300 comprises: an address reading subunit and a Region migration subunit.

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

[0117] The Region migration subunit is configured 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 embodiments, the old instance offline unit 400 comprises: a node deletion subunit, a service stop subunit and a re-registration subunit.

[0119] The node deletion subunit is configured 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 configured to offline and stop the Region service of the old version instance.

[0121] The re-registration subunit is configured to roll up to the next instance, create a next new version instance based on the Kubernetes environment, and re-register a Znode node in the Zookeeper, which is used to upgrade and migrate the next old version instance, and the cycle is repeated until the migration and upgrade of each node of the HBase cluster are completed.

[0122] Optionally, in some optional embodiments, the device further comprises: a device hibernation unit.

[0123] The device hibernation unit is configured to, after the Znode node is deleted and the old version instance is offline and stopped after the Region migration of the old version instance is completed, control the execution device of the old version instance to hibernate for a preset time length.

[0124] As to the device in the above embodiments, the specific manners in which various modules perform operations have been described in detail in the embodiments of the method, and will not be described here in detail.

[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 preset stop hook is executed before the old version instance is offline and stops serving, and the execution logic of the stop hook is that a corresponding address is read from the Znode node, and the Region of the old version instance is migrated to the address.

[0135] After the Region migration of the old version instance is completed, the Znode node is deleted, and the old version instance is offline and stopped, so that a next new version instance is created to re-create a Znode node, a next old version instance is migrated and upgraded, and the cycle is repeated until the migration and upgrade of all nodes of the HBase cluster are completed.

[0136] Optionally, in some optional embodiments, when the rolling upgrade starts, a new version instance is created based on a Kubernetes environment, and a start hook of the new version instance is executed, including:

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

[0138] The start hook of the new version instance is executed, and a Znode node is registered in Zookeeper, wherein the address of the Znode node is / hbase / region-moving-target.

[0139] The address and RPC service port number information of the new version instance are written into the Znode node.

[0140] Optionally, in some optional embodiments, the method further includes:

[0141] It is determined whether an upgrade lock exists in a preset directory of an old version instance.

[0142] If the specified file exists in the preset directory, it is determined that the upgrade lock exists.

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

[0144] Optionally, in some optional embodiments, after it is determined whether the upgrade lock exists in the preset directory of the old version instance, the method further includes:

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

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

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

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

[0149] Optionally, in some optional embodiments, after the Region of the old version instance is migrated, the Znode node is deleted, and the old version instance is offline and stopped, so as to create a new Znode node for the next new version instance, migrate the next old version instance, and repeat the cycle until all nodes of the HBase cluster are migrated and upgraded, including:

[0150] After the Region of the old version instance is migrated, the Znode node created by the new version instance is deleted;

[0151] The Region service of the old version instance is offline and stopped;

[0152] The next instance is rolled up, a next new version instance is created based on the Kubernetes environment, and a Znode node is registered in the Zookeeper for migrating the next old version instance, and the cycle is repeated until all nodes of the HBase cluster are migrated and upgraded.

[0153] Optionally, in some optional embodiments, after the Region of the old version instance is migrated, the Znode node is deleted, and the old version instance is offline and stopped, the method further includes:

[0154] The execution device of the old version instance is controlled to sleep for a preset time length.

[0155] The computer program instructions can also be loaded onto a computer, other programmable device, or other device to cause a series of operations to be performed on the computer, other programmable device, or other device to produce a computer implemented process such that the instructions which execute on the computer or other programmable device implement the functions specified in the flowchart block or blocks. Figure 1 The flowchart and / or block diagram in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments. In this regard, each flowchart block and / or combination of flowchart blocks 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, or other programmable device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable device, implement the functions specified in the flowchart block or blocks. Figure 1 The flowchart and / or block diagram in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments. In this regard, each flowchart block and / or combination of flowchart blocks 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, or other programmable device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable device, implement the functions specified in the flowchart block or blocks.

[0156] In one typical configuration, the electronic device includes one or more processors (CPU), memory, and a bus. The electronic device can also include an input / output interface, a network interface, and the like.

[0157] The memory can include non-persistent memory and / or volatile memory, e.g., random access memory (RAM) having a common memory space functioning as primary storage for the computer; and / or non-volatile memory, e.g., read only memory (ROM), electrically programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), flash memory, or other solid state memory technology, compact disc read only memory (CD-ROM), digital versatile disc (DVD), or other optical storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other non-transitory medium that can be used to store the desired information. According to the definitions in this document, computer readable medium does not include transitory computer readable medium, such as modulated data signals and carrier waves.

[0158] The computer readable medium includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology for storing information. The information can be computer readable instructions, data structures, program modules 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 programmable read only memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette, magnetic tape disk storage or other magnetic storage device, or any other non-transitory medium that can be used to store information that can be accessed by a computing device. According to the definition in this document, computer readable medium does not include transitory computer readable medium, such as modulated data signals and carrier waves.

[0159] In the description of the present application, it should be understood that the orientation or positional relationship indicated by terms such as "upper", "lower", "front", "back", "left" and "right" are based on the orientation or positional relationship shown in the drawings, and are only for the convenience of describing the present application and simplifying the description, and do not indicate or imply that the indicated position or element must have a particular orientation, be constructed and operated in a particular orientation, and therefore cannot be understood as a limitation of the present application.

[0160] It should be noted that the relational terms herein such as first and second and the like are used solely to distinguish one from another entity or action, without necessarily requiring or implying any actual relationship or order between such entities or actions. It should also be noted that the terms "comprises", "comprising", or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element preceded by "comprises... a" does not, without more constraints, foreclose the existence of additional identical elements in the process, method, article, or apparatus that comprises the element.

[0161] Those skilled in the art will appreciate that embodiments of the present application can be devised for a method, a system, or a computer program product. Accordingly, the present application can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROMs, optical storage devices, etc.) embodying computer-readable program code.

[0162] The above merely provides an embodiment of the present application and is not intended to limit the present application. The present application can have various modifications and changes for those skilled in the art. Any modification, equivalent replacement, improvement, etc. within the spirit and principle of the present application shall be included in the scope of the present application.

Claims

1. A method for HBase upgrade, characterized in that, The method comprises the steps of: When the rolling upgrade starts, a new version instance is created based on a Kubernetes environment, and a start hook of the new version instance is executed, wherein the execution logic of the start hook is to register a Znode node in Zookeeper and write the address of the new version instance into the Znode node; Checking whether there is an upgrade lock in a preset directory of an old version instance, wherein the old version instance is a current instance to be upgraded; If there is the upgrade lock in the preset directory of the old version instance, executing a preset stop hook before the old version instance is offline and stops serving, wherein the execution logic of the stop hook is to read a corresponding address from the Znode node and migrate the Region of the old version instance to the address; After the migration of the Region of the old version instance is completed, the Znode node is deleted, and the old version instance is offline and stopped, so that a Znode node is re-created for a next new version instance, a next old version instance is migrated and upgraded, and the cycle is repeated until all nodes of an HBase cluster are migrated and upgraded.

2. The method of claim 1, wherein, When the rolling upgrade starts, a new version instance is created based on a Kubernetes environment, and a start hook of the new version instance is executed, comprising: When the rolling upgrade starts, a new version instance is created based on a Kubernetes environment, and a start hook of the new version instance is executed, comprising: When the rolling upgrade starts, a new version instance is created based on a Kubernetes environment, and a start hook of the new version instance is executed, comprising: When the rolling upgrade starts, a new version instance is created based on a Kubernetes environment, and a start hook of the new version instance is executed, comprising:

3. The method of claim 1, wherein, The method further comprises the steps of: If there is no upgrade lock in the preset directory of the old version instance, executing a preset default node offline process. If there is the upgrade lock in the preset directory of the old version instance, executing a preset stop hook before the old version instance is offline and stops serving, comprising: If there is the upgrade lock in the preset directory of the old version instance, executing a preset stop hook before the old version instance is offline and stops serving, comprising:

4. The method of claim 1, wherein, If there is the upgrade lock in the preset directory of the old version instance, executing a preset stop hook before the old version instance is offline and stops serving, comprising: Migrating the Region of the old version instance to the address read from the Znode node, so as to migrate the Region of the old version instance to the new version instance.

5. The method of claim 1, wherein, ​ ​ ​ 6. The method of claim 1, wherein, The Znode node is deleted after the Region migration of the old version instance is completed, and the old version instance is stopped to facilitate the creation of the next new version instance to recreate the Znode node, the upgrade migration of the next old version instance, and the repeated cycle until the migration and upgrade of each node of the HBase cluster are completed, including: The Znode node created by the new version instance is deleted after the Region migration of the old version instance is completed; The Region service of the old version instance is stopped; The next instance is rolled over, a new version instance is created based on the Kubernetes environment, and a Znode node is registered in Zookeeper for the upgrade migration of the next old version instance, and the repeated cycle is repeated until the migration and upgrade of each node of the HBase cluster are completed.

7. The method of claim 1, wherein, After the Znode node is deleted and the old version instance is stopped after the Region migration of the old version instance is completed, the method further includes: The execution device of the old version instance is put to sleep for a preset time length.

8. An HBase upgrading apparatus, characterized by comprising: It includes: A new instance creation unit, an upgrade lock checking unit, a service migration unit, and an old instance offline unit; The new instance creation unit is configured to create a new version instance based on the Kubernetes environment at the beginning of the rolling upgrade, and execute a startup hook of the new version instance, wherein the execution logic of the startup hook is to 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 configured to check whether an upgrade lock exists in a preset directory of an old version instance, wherein the old version instance is the current instance to be upgraded; The service migration unit is configured to execute a pre-set stop hook before the old version instance is stopped if the upgrade lock exists in the preset directory of the old version instance, wherein the execution logic of the stop hook is to 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 configured to delete the Znode node after the Region migration of the old version instance is completed, and stop the old version instance to facilitate the creation of the next new version instance to recreate the Znode node, the upgrade migration of the next old version instance, and the repeated cycle until the migration and upgrade of each node of the HBase cluster are completed.

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

10. An electronic device, comprising: The electronic device includes at least one processor, at least one memory connected to the processor, and a bus; wherein the processor, the memory complete mutual communication through the bus; the processor is used to call the program instruction in the memory, to execute the HBase upgrade method of any one of claims 1 to 7.

Images