CN114640586A - Cluster version upgrading method and device, storage medium and equipment - Google Patents

Cluster version upgrading method and device, storage medium and equipment Download PDF

Info

Publication number
CN114640586A
CN114640586A CN202210541582.9A CN202210541582A CN114640586A CN 114640586 A CN114640586 A CN 114640586A CN 202210541582 A CN202210541582 A CN 202210541582A CN 114640586 A CN114640586 A CN 114640586A
Authority
CN
China
Prior art keywords
node
version
cluster
new
slave
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202210541582.9A
Other languages
Chinese (zh)
Other versions
CN114640586B (en
Inventor
陈实
赵增义
张益军
王金明
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Feihu Information Technology Tianjin Co Ltd
Original Assignee
Feihu Information Technology Tianjin Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Feihu Information Technology Tianjin Co Ltd filed Critical Feihu Information Technology Tianjin Co Ltd
Priority to CN202210541582.9A priority Critical patent/CN114640586B/en
Publication of CN114640586A publication Critical patent/CN114640586A/en
Application granted granted Critical
Publication of CN114640586B publication Critical patent/CN114640586B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0803Configuration setting
    • H04L41/0813Configuration setting characterised by the conditions triggering a change of settings
    • H04L41/082Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/65Updates
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network

Abstract

The application discloses a method, a device, a storage medium and equipment for upgrading cluster versions, wherein after a target version number input by a user is received, a slave node of a node group of a cluster is triggered to generate a new configuration file by using installation information; triggering the slave node to finish running the instance, loading the new configuration file to run the new instance to obtain the running state of the new instance; identifying the slave node with the successful operation state of the new instance as a candidate slave node, and selecting one candidate slave node from one or more candidate slave nodes as a target node; calling a preset failover command, and replacing the target node with the master node of the node group so as to change the target node into a new master node of the node group and change the replaced master node into a new slave node of the node group; after the new slave node executes the preset step, the user is prompted that the cluster version is upgraded successfully, and compared with the prior art, the upgrading method can ensure that the upgrading process can still provide service to the outside under the condition of realizing the version upgrading of the cluster.

Description

Cluster version upgrading method and device, storage medium and equipment
Technical Field
The present application relates to the field of version upgrading technologies, and in particular, to a method, an apparatus, a storage medium, and a device for upgrading a cluster version.
Background
With the wide application of remote dictionary services (redis), enterprises pay more and more attention to the operation and maintenance safety of a redis cluster (the redis cluster is referred to as a cluster in the present application), and in view of the fact that the redis is an open source service, the redis cluster can be continuously maintained and updated, new characteristics can be added to improve the capability when a version is updated, but the cluster inevitably has some bugs and bugs, and at the moment, version upgrading is needed to repair the bugs and the bugs.
At present, a manual processing scheme is adopted to upgrade the version, and an old version cluster is replaced after data is synchronized (a third-party synchronization tool can be adopted) by newly building a new version cluster. However, with the existing version upgrading method, the upgrading process cannot provide service to the outside.
Therefore, how to ensure that the upgrading process can still provide services to the outside under the condition of realizing the version upgrading of the cluster becomes a problem to be solved urgently in the field.
Disclosure of Invention
The application provides a cluster version upgrading method, a cluster version upgrading device, a storage medium and equipment, which are used for ensuring that the upgrading process can still provide services to the outside under the condition of realizing cluster version upgrading.
In order to achieve the above object, the present application provides the following technical solutions:
a cluster version upgrading method comprises the following steps:
after receiving a target version number input by a user, triggering the slave nodes of the node group of the cluster to generate a new configuration file by using the installation information; the installation information is obtained by loading an installation package of the cluster version to which the target version number belongs;
triggering the slave nodes of the node group to finish running the instances, and simultaneously loading the new configuration file to run the new instances to obtain the running state of the new instances; wherein the instance is grouped by accessing the node;
identifying the slave node with the successful operation state of the new instance as a candidate slave node, and selecting one candidate slave node from one or more candidate slave nodes as a target node;
calling a preset failover command, and replacing the target node with the master node of the node group so as to change the target node into a new master node of the node group and change the replaced master node into a new slave node of the node group;
and prompting the user cluster version to be upgraded successfully.
Optionally, the prompting that the user cluster version is successfully upgraded includes:
after triggering the new slave node to execute a preset step, prompting that the user cluster version is upgraded successfully; wherein the presetting step comprises: generating the new configuration file by using the installation information; and ending the running of the instance, and simultaneously loading the new configuration file to run the new instance to obtain the running state of the new instance.
Optionally, the method further includes:
and revisiting the node group to obtain new instance information of the node group, and displaying the new instance information to the user through a preset interface.
Optionally, before receiving the target version number input by the user, the method further includes:
receiving a version upgrading command sent by the user; wherein the version upgrade command comprises a current version number; the current version number is the version number of the cluster version currently used by the cluster;
under the condition that the version library contains a cluster version meeting preset conditions, acquiring configuration information of the cluster version from a configuration information library, and displaying the configuration information to the user through the preset interface; wherein the preset conditions are as follows: and the version number of the cluster version is arranged behind the current version number, and the version number and the current version number belong to the same level.
Optionally, the method further includes:
and prompting that the upgrading of the user cluster version fails under the condition that the version library does not contain the cluster version meeting the preset condition.
Optionally, before the triggering the slave node of the node group of the cluster to generate a new configuration file by using the installation information, the method further includes:
and triggering the slave node of the node group to copy the configuration file of the slave node to obtain a backup configuration file, and deleting the configuration file after the backup configuration file is stored to the local.
Optionally, after the triggering the slave node of the node group to end running the instance and simultaneously start running the new instance to obtain the running state of the new instance, the method further includes:
and identifying the slave node with the failure running state of the new instance as an invalid slave node, controlling the invalid slave node to stop running the new instance, and restarting to run the instance.
A version upgrade apparatus for a cluster, comprising:
the generating unit is used for triggering the slave nodes of the node group of the cluster to generate a new configuration file by using the installation information after receiving a target version number input by a user; the installation information is obtained by loading an installation package of the cluster version to which the target version number belongs;
the starting unit is used for triggering the slave nodes of the node group to finish running the instances, and simultaneously loading the new configuration file to run the new instance to obtain the running state of the new instance; wherein the instance is grouped by accessing the node;
the selecting unit is used for identifying the slave node with the successful running state of the new instance as a candidate slave node, and selecting one candidate slave node from one or more candidate slave nodes as a target node;
a replacing unit, configured to invoke a preset failover command, replace the master node of the node group with the target node, so that the target node is changed to a new master node of the node group, and the replaced master node is changed to a new slave node of the node group;
and the prompting unit is used for prompting that the user cluster version is upgraded successfully.
A computer-readable storage medium comprising a stored program, wherein the program performs the method for version-up of a cluster.
A clustered version-up device, comprising: a processor, a memory, and a bus; the processor and the memory are connected through the bus;
the memory is used for storing a program, and the processor is used for executing the program, wherein the program executes the version upgrading method of the cluster during running.
According to the technical scheme, after a target version number input by a user is received, the slave nodes of the node group of the cluster are triggered to generate a new configuration file by using the installation information, and the new configuration file is loaded to obtain a new instance; triggering the slave node to finish running the instance and running the new instance to obtain the running state of the new instance; identifying the slave node with the successful operation state of the new instance as a candidate slave node, and selecting one candidate slave node from one or more candidate slave nodes as a target node; calling a preset failover command, and replacing the target node with the master node of the node group so that the target node is changed into a new master node of the node group and the replaced master node is changed into a new slave node of the node group; compared with the prior art, the method can ensure that the upgrading process can still provide service to the outside under the condition of realizing upgrading of the cluster version.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.
Fig. 1 is a flowchart of a version upgrade method for a cluster according to an embodiment of the present application;
fig. 2 is a flowchart of another version upgrading method for a cluster according to the embodiment of the present application;
fig. 3 is a schematic architecture diagram of a version upgrading apparatus of a cluster according to an embodiment of the present disclosure.
Detailed Description
The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
As shown in fig. 1, a flowchart of a cluster version upgrading method provided in this embodiment of the present application may be applied to a server, and includes the following steps:
s101: after receiving a version upgrading command sent by a user, judging whether cluster versions meeting preset conditions are contained in all cluster versions prestored in a version library.
If the cluster versions pre-stored in the version library include the cluster versions meeting the preset conditions, executing S102, otherwise executing S103.
Wherein the preset conditions are as follows: the version number of the cluster version is arranged behind the current version number shown by the version upgrade command, and the version number and the current version number both belong to the same level (in practical application, if a large difference exists between the versions, the levels are different, for example, if a large difference exists between the 6.0 version and the 5.0 version, the 6.0 version and the 5.0 version do not belong to the same level); correspondingly, both the 6.0.1 version and the 6.0.2 version belong to the function maintenance of the 6.0 version, and no large function difference exists between the 6.0.1 version and the 6.0.2 version, so that the 6.0.1 version and the 6.0.2 version can be considered to belong to the same level; 6.2. the version also belongs to the function maintenance of the 6.0 version, and no large function difference exists between the two versions, so that the 6.2.4 version and the 6.0.1 version can be considered to belong to the same level. The cluster version information comprises the version configuration of the cluster and the download address of the installation package.
It should be noted that the current version number may be a version number of a cluster version currently used by a cluster.
Specifically, assume that each cluster version pre-stored in the version library is: 5.0.9 version, 6.0.4 version, 6.0.8 version, 6.2.2 version, 6.2.6 version and 6.3.0 version, where the current version number is 6.2.4 version, and after receiving a version upgrade command sent by a user, it is determined whether each cluster version pre-stored in the version library includes a cluster version meeting a preset condition (the version number of the cluster version, which is arranged behind the current version number shown in the version upgrade command, and the version number and the current version number all belong to the same level), and obviously, the cluster version meeting the preset condition is: version 6.2.6 and version 6.3.0, and for this reason execution continues with S102.
S102: and acquiring the configuration information of the cluster version meeting the preset conditions from the configuration information base, and displaying the configuration information to a user through a preset interface.
The configuration information base comprises configuration information of each cluster version, and in addition, a user can change the configuration information displayed on a preset interface according to actual conditions. The configuration information includes a plurality of configuration items, each of which includes but is not limited to: whether to daemon, TCP connection completion queue, log level, redis work log.
Specifically, assume that the cluster version satisfying the preset condition is: versions 6.2.6 and 6.3.0 are obtained from the configuration information base, and the configuration information of versions 6.2.6 and 6.3.0 is displayed to a user through a preset interface, wherein the configuration information of versions 6.2.6 and 6.3.0 (such as whether to daemon process, TCP connection completion queue, log level, redis work log and the like) is displayed to the user.
S103: and prompting the user that the cluster version fails to be upgraded.
Because each cluster version pre-stored in the version library does not contain a cluster version meeting the preset conditions, the cluster version to which the current version number shown by the version upgrading command belongs can be determined, and no scalable cluster version is used for version upgrading.
S104: and after receiving the target version number input by the user, accessing each node group in the cluster to obtain the example information of each node group.
Wherein, the instance information comprises an IP address of the instance, a version number of a cluster version to which the instance belongs, a port number of the master node, and a port number of the slave node. So-called instances, i.e. processes providing redis services, are well known to the skilled person, and in practice a cluster will provide a plurality of instances, each instance being responsible for a corresponding node group.
In order to ensure high availability, the nodes are divided into a plurality of node groups in advance, and each node group usually comprises a master node and a plurality of slave nodes. Generally, the master node is used for providing a redis service externally, and the slave nodes are used for synchronizing the operation data of the instances and ensuring the consistency with the data of the master node. When the master node is down or hung up, a mechanism exists in the cluster to select the slave node as the master node, so that the normal operation of the service is ensured. That is, the version of the cluster is upgraded, which is essentially to upgrade each node group of the cluster.
It should be noted that, a user may determine, by means of an input target version number, a cluster version that needs to be subjected to version upgrade, in this embodiment of the present application, the cluster version that needs to be subjected to version upgrade may be understood as a cluster version to which the target version number belongs.
Specifically, after receiving a target version number (for example, 6.2.6 version) input by a user, accessing each node group in the cluster, and obtaining example information of each node group as follows: packet A (10.10. XXX.1:6480master version:6.2.4, 10.10.XXX.2:7482slave version: 6.2.4), packet B (10.10. XXX.2:6481master version:6.2.4, 10.10.XXX.3:7480slave version: 6.2.4), packet C (10.10. XXX.3:6482master version:6.2.4, 10.10.XXX.1:7481slave version: 6.2.4).
It should be noted that the above specific implementation process is only used for illustration, and the value of XXX of the address shown in each instance information may be set by a technician according to an actual situation, generally, the value of XXX is usually in the range of 0 to 255.
S105: and judging whether each node group contains slave nodes meeting preset requirements.
If each node group contains slave nodes meeting the preset requirements, S106 is executed, otherwise, S107 is executed.
Wherein the preset requirements are as follows: the slave node is in a normal working state.
S106: and judging whether the installation package of the cluster version to which the target version number belongs does not exist locally.
And if the installation package of the cluster version to which the target version number belongs does not exist locally, executing S108, otherwise, executing S109.
S107: and prompting the user that the cluster version fails to be upgraded.
The individual node group does not contain slave nodes meeting the preset requirements, that is, all the slave nodes in the individual node group cannot work normally is determined, so that the individual node cannot perform master-slave node switching shown in the subsequent steps, and the individual node group cannot perform version upgrading, so that a user is prompted that the cluster version upgrading fails.
S108: and downloading the installation package of the cluster version to which the target version number belongs.
S109: and triggering each node in the node group to load the installation package to obtain the installation information of the cluster version to which the target version number belongs.
After execution of S109, execution continues with S110.
Wherein the installation information comprises a default configuration file.
It should be noted that the installation package of the cluster version to which the target version number belongs may be downloaded based on the installation package download address shown in the cluster version information of the cluster version to which the target version number belongs.
S110: for each node group, the slave node of the node group is triggered to copy the configuration file of the slave node to obtain a backup configuration file, and the configuration file is deleted after the backup configuration file is stored to the local (specifically, the server in the application).
The configuration file comprises configuration items and configuration values.
It should be noted that the slave node that triggers the node group copies its own configuration file to obtain a backup configuration file, and stores the backup configuration file to the local, which can ensure that data of the redis service borne by the node group is not lost, thereby improving reliability of upgrading a cluster version.
S111: and the slave node triggering the node grouping generates a new configuration file by using the default configuration file in the installation information, the configuration items in the backup configuration file and the configuration values.
S112: and triggering the slave nodes of the node group to finish running the instances, and simultaneously loading the new configuration file to run the new instances to obtain the running state of the new instances.
When the version of the cluster is upgraded, in order to ensure that all instances in the node grouping are upgraded, when the slave node of the control node grouping finishes running the instances, the new instances are started to run, so that one slave node in the node grouping can be used for switching to a master node (providing service) at any time, and the switched slave node (indicating the original master node) is upgraded.
S113: and judging whether the running state of the new instance is successful or not.
If the operation status of the new instance is successful, S114 is executed, otherwise S116 is executed.
S114: and identifying the slave nodes as candidate slave nodes, and selecting one candidate slave node from one or more candidate slave nodes as a target node.
S115: and calling a preset failover (failover) command to replace the master node of the node group by the target node so that the target node is changed into a new master node of the node group and the replaced master node is changed into a new slave node of the node group.
After execution of S115, execution continues with S117.
The step shown in S115 can be simply understood as: the failover between the master node and the slave node is realized by using the failover command, which is a technical means familiar to those skilled in the art and will not be described herein again.
Specifically, taking the above-mentioned node groups (i.e., group a, group B, and group C) as an example, assume that the target node of group a is 10.10.xxx.2:7482slave version:6.2.6, the target node of group B is 10.10.xxx.3:7480slave version:6.2.6, the target node of group C is 10.10.xxx.1:7481slave version:6.2.6, and further that the master node of group a is 10.10.xxx.1:6480master version:6.2.4, the master node of group B is 10.10.xxx.2:6481master version:6.2.4, the master node of group C is 10.10.xxx.3:6482master version:6.2.4, and for each node group, the target node invokes a transfer of a failure (i.e., a substitute command for the master node of group C with the target node of the new master node to be changed to 10. the target node of group a, and the target node of group B is changed to 10.2.2.2.6.4, and the target node of the new master node is changed to be 10. the group a new master node of group a The new master node after the change of the packet B is 10.10.XXX.3:7480master version 6.2.6, the new master node after the change of the packet C is 10.10.XXX.1:7481master version 6.2.6, the new slave node after the change of the packet A is 10.10.XXX.1:6480slave version 6.2.4, the new slave node after the change of the packet B is 10.10.XXX.2:6481slave version 6.2.4, and the new slave node after the change of the packet C is 10.10.XXX.3:6482slave version 6.2.4.
S116: and identifying the slave node as an invalid slave node, and controlling the invalid slave node to stop running the new instance and restart the running instance.
The backup configuration file is stored locally, so that the invalid slave node can directly acquire the backup configuration file from the local and load the backup configuration file running example to end the cluster version upgrading process and prompt a user that the cluster version upgrading fails.
S117: and after triggering the new slave node to execute the preset step, prompting the user that the cluster version is upgraded successfully.
After execution of S117, execution of S118 is continued.
Wherein, predetermine the step and include: generating a new configuration file by using the installation information, and loading the new configuration file to obtain a new instance; and finishing the running of the instance, and simultaneously starting to run the new instance to obtain the running state of the new instance.
S118: and revisiting each node group to obtain new instance information of each node group, and displaying each new instance information to a user through a preset interface.
The new instance information includes an IP address of the new instance, a version number (i.e., a target version number) of a cluster version to which the new instance belongs, a port number of the new master node, and a port number of the new slave node.
Specifically, taking the above-mentioned node groups (i.e., group a, group B, and group C) as an example, revisiting each node group to obtain new instance information of each node group includes:
the new example information for packet A is 10.10.XXX.2:7482master version:6.2.6, 10.10.XXX.1:6480slave version: 6.2.6;
new example information for packet B is 10.10.XXX.3:7480master version:6.2.6, 10.10.XXX.2:6481slave version: 6.2.6;
new example information for packet C is 10.10.XXX.1:7481master version:6.2.6, 10.10.XXX.3:6482slave version: 6.2.6.
It should be noted that the above specific implementation process is only for illustration.
In summary, by triggering the slave node of the node group to operate the new instance, and selecting one slave node from the one or more successfully operated slave nodes as the target node, and using the target node to replace the master node of the node group, compared with the prior art, it is ensured that the upgrade process can still provide service to the outside under the condition of implementing the version upgrade of the cluster.
As shown in fig. 2, a flowchart of another version upgrade method for a cluster provided in this embodiment of the present application may be applied to a server, and includes the following steps:
s201: and after receiving the target version number input by the user, triggering the slave nodes of the node group of the cluster to generate a new configuration file by using the installation information.
And the installation information is obtained by loading an installation package of the cluster version to which the target version number belongs.
S202: and triggering the slave nodes of the node group to finish running the instances, and simultaneously loading the new configuration file to run the new instances to obtain the running state of the new instances.
Wherein the instances are grouped by the access node.
S203: and identifying the slave node with the successful operation state of the new instance as a candidate slave node, and selecting one candidate slave node from one or more candidate slave nodes as a target node.
S204: and calling a preset failover command, and replacing the master node of the node group with the target node so that the target node is changed into a new master node of the node group and the replaced master node is changed into a new slave node of the node group.
S205: and prompting the user that the cluster version is upgraded successfully.
In summary, by triggering the slave node of the node group to operate the new instance, and selecting one slave node from the one or more successfully operated slave nodes as the target node, and using the target node to replace the master node of the node group, compared with the prior art, it is ensured that the upgrade process can still provide service to the outside under the condition of implementing the version upgrade of the cluster.
As shown in fig. 3, an architecture schematic diagram of a version upgrade apparatus for a cluster provided in an embodiment of the present application includes:
a generating unit 100, configured to trigger a slave node of a node group of a cluster to generate a new configuration file by using the installation information after receiving a target version number input by a user; and the installation information is obtained by loading an installation package of the cluster version to which the target version number belongs.
The generating unit 100 is further configured to receive a version upgrade command sent by a user; the version upgrading command comprises a current version number; the current version number is the version number of the cluster version currently used by the cluster; under the condition that the version library contains the cluster version meeting the preset condition, acquiring the configuration information of the cluster version from the configuration information library, and displaying the configuration information to a user through a preset interface; wherein the preset conditions are as follows: and the version number of the cluster version is arranged behind the current version number, and the version number and the current version number belong to the same level.
The generating unit 100 is further configured to prompt the user that the cluster version fails to be upgraded when the version library does not include the cluster version meeting the preset condition.
The generating unit 100 is further configured to trigger the slave node of the node group to copy its own configuration file, obtain a backup configuration file, and delete the configuration file after storing the backup configuration file locally.
The starting unit 200 is configured to trigger a slave node of the node group to end running the instance, and start running the new instance at the same time to obtain a running state of the new instance; wherein the instances are grouped by the access node.
The starting unit 200 is further configured to identify the slave node whose operation status of the new instance is failure as an invalid slave node, and control the invalid slave node to stop running the new instance and restart the running instance.
The selecting unit 300 is configured to identify a slave node whose operation state of the new instance is successful as a candidate slave node, and select one candidate slave node from one or more candidate slave nodes as a target node.
The replacing unit 400 is configured to invoke a preset failover command, and replace the master node of the node group with the target node, so that the target node is changed to a new master node of the node group, and the replaced master node is changed to a new slave node of the node group.
And a prompting unit 500, configured to prompt the user that the cluster version is upgraded successfully.
The prompt unit 500 is specifically configured to: after triggering the new slave node to execute the preset step, prompting the user that the version is upgraded successfully; wherein, predetermine the step and include: generating a new configuration file by using the installation information, and loading the new configuration file to obtain a new instance; and finishing the running of the instance, and simultaneously starting to run the new instance to obtain the running state of the new instance.
The prompting unit 500 is further configured to revisit the node group, obtain new instance information of the node group, and show the new instance information to the user through a preset interface.
In summary, by triggering the slave node of the node group to operate the new instance, and selecting one slave node from the one or more successfully operated slave nodes as the target node, and using the target node to replace the master node of the node group, compared with the prior art, it is ensured that the upgrade process can still provide service to the outside under the condition of implementing the version upgrade of the cluster.
The present application also provides a computer-readable storage medium including a stored program, wherein the program executes the version upgrade method for a cluster provided in the present application.
The present application further provides a version upgrading device of a cluster, including: a processor, a memory, and a bus. The processor is connected with the memory through a bus, the memory is used for storing programs, and the processor is used for running the programs, wherein when the programs are run, the method for upgrading the version of the cluster comprises the following steps:
after receiving a target version number input by a user, triggering the slave nodes of the node group of the cluster to generate a new configuration file by using the installation information; the installation information is obtained by loading an installation package of the cluster version to which the target version number belongs;
triggering the slave nodes of the node group to finish running the instance, and simultaneously loading the new configuration file to run the new instance to obtain the running state of the new instance; wherein the instance is grouped by accessing the node;
identifying the slave node with the successful operation state of the new instance as a candidate slave node, and selecting one candidate slave node from one or more candidate slave nodes as a target node;
calling a preset failover command, and replacing the target node with the master node of the node group so as to change the target node into a new master node of the node group and change the replaced master node into a new slave node of the node group;
and prompting the user cluster version to be upgraded successfully.
Optionally, the prompting that the user cluster version is successfully upgraded includes:
after triggering the new slave node to execute a preset step, prompting that the user cluster version is upgraded successfully; wherein the presetting step comprises: generating the new configuration file by utilizing the installation information; and ending the running of the instance, and simultaneously loading the new configuration file to run the new instance to obtain the running state of the new instance.
Optionally, the method further includes:
and revisiting the node group to obtain new instance information of the node group, and displaying the new instance information to the user through a preset interface.
Optionally, before receiving the target version number input by the user, the method further includes:
receiving a version upgrading command sent by the user; wherein the version upgrade command comprises a current version number; the current version number is the version number of the cluster version currently used by the cluster;
under the condition that the version library contains a cluster version meeting preset conditions, acquiring configuration information of the cluster version from a configuration information library, and displaying the configuration information to the user through the preset interface; wherein the preset conditions are as follows: and the version number of the cluster version is arranged behind the current version number, and the version number and the current version number belong to the same level.
Optionally, the method further includes:
and prompting that the upgrading of the user cluster version fails under the condition that the version library does not contain the cluster version meeting the preset condition.
Optionally, before the triggering the slave node of the node group of the cluster to generate a new configuration file by using the installation information, the method further includes:
and triggering the slave node of the node group to copy the configuration file of the slave node to obtain a backup configuration file, and deleting the configuration file after the backup configuration file is stored to the local.
Optionally, after the triggering the slave node of the node group to end running the instance and simultaneously start running the new instance to obtain the running state of the new instance, the method further includes:
and identifying the slave node with the failure running state of the new instance as an invalid slave node, controlling the invalid slave node to stop running the new instance, and restarting to run the instance.
The functions described in the method of the embodiment of the present application, if implemented in the form of software functional units and sold or used as independent products, may be stored in a storage medium readable by a computing device. Based on such understanding, part of the technical solutions or portions of the embodiments contributing to the prior art may be embodied in the form of a software product stored in a storage medium and including instructions for causing a computing device (which may be a personal computer, a server, a mobile computing device, a network device, or the like) to perform all or part of the steps of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: u disk, removable hard disk, read only memory, random access memory, magnetic or optical disk, etc. for storing program codes.
The embodiments are described in a progressive manner, each embodiment focuses on differences from other embodiments, and the same or similar parts among the embodiments are referred to each other.
The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the application. Thus, the present application is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims (10)

1. A method for upgrading cluster version is characterized by comprising the following steps:
after receiving a target version number input by a user, triggering the slave nodes of the node group of the cluster to generate a new configuration file by using the installation information; the installation information is obtained by loading an installation package of the cluster version to which the target version number belongs;
triggering the slave nodes of the node group to finish running the instances, and simultaneously loading the new configuration file to run the new instances to obtain the running state of the new instances; wherein the instance is grouped by accessing the node;
identifying the slave node with the successful operation state of the new instance as a candidate slave node, and selecting one candidate slave node from one or more candidate slave nodes as a target node;
calling a preset failover command, and replacing the target node with the master node of the node group, so that the target node is changed into a new master node of the node group, and the replaced master node is changed into a new slave node of the node group;
and prompting the user cluster version to be upgraded successfully.
2. The method of claim 1, wherein the prompting the user that the cluster version upgrade is successful comprises:
after triggering the new slave node to execute a preset step, prompting that the user cluster version is upgraded successfully; wherein the presetting step comprises: and generating the new configuration file by using the installation information, finishing running the instance, and simultaneously loading the new configuration file to run the new instance to obtain the running state of the new instance.
3. The method of claim 2, further comprising:
and revisiting the node group to obtain new instance information of the node group, and displaying the new instance information to the user through a preset interface.
4. The method of claim 1, wherein prior to receiving the user-entered target version number, further comprising:
receiving a version upgrading command sent by the user; wherein the version upgrade command comprises a current version number; the current version number is the version number of the cluster version currently used by the cluster;
under the condition that the version library contains a cluster version meeting preset conditions, acquiring configuration information of the cluster version from a configuration information library, and displaying the configuration information to the user through the preset interface; wherein the preset conditions are as follows: and the version number of the cluster version is arranged behind the current version number, and the version number and the current version number belong to the same level.
5. The method of claim 4, further comprising:
and prompting that the upgrading of the user cluster version fails under the condition that the version library does not contain the cluster version meeting the preset condition.
6. The method of claim 1, wherein before the triggering the slave node of the node group of the cluster to generate a new configuration file by using the installation information, the method further comprises:
and triggering the slave node of the node group to copy the configuration file of the slave node to obtain a backup configuration file, and deleting the configuration file after the backup configuration file is stored to the local.
7. The method of claim 1, wherein the triggering the slave node of the node group to end running the instance and simultaneously start running the new instance, and after obtaining the running state of the new instance, further comprises:
and identifying the slave node with the failure running state of the new instance as an invalid slave node, controlling the invalid slave node to stop running the new instance, and restarting to run the instance.
8. A version upgrade apparatus for a cluster, comprising:
the generating unit is used for triggering the slave nodes of the node group of the cluster to generate a new configuration file by using the installation information after receiving a target version number input by a user; the installation information is obtained by loading an installation package of the cluster version to which the target version number belongs;
the starting unit is used for triggering the slave nodes of the node group to finish running the instances, and simultaneously loading the new configuration file to run the new instance to obtain the running state of the new instance; wherein the instance is grouped by accessing the node;
the selecting unit is used for identifying the slave node with the successful running state of the new instance as a candidate slave node, and selecting one candidate slave node from one or more candidate slave nodes as a target node;
a replacing unit, configured to invoke a preset failover command, replace the master node of the node group with the target node, so that the target node is changed to a new master node of the node group, and the replaced master node is changed to a new slave node of the node group;
and the prompting unit is used for prompting that the user cluster version is upgraded successfully.
9. A computer-readable storage medium, characterized in that the computer-readable storage medium comprises a stored program, wherein the program performs the method of version upgrade of a cluster according to any one of claims 1 to 7.
10. A clustered version-up device, comprising: a processor, memory, and a bus; the processor and the memory are connected through the bus;
the memory is used for storing a program, and the processor is used for executing the program, wherein the program executes the version upgrading method of the cluster in any one of claims 1 to 7.
CN202210541582.9A 2022-05-19 2022-05-19 Cluster version upgrading method and device, storage medium and equipment Active CN114640586B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210541582.9A CN114640586B (en) 2022-05-19 2022-05-19 Cluster version upgrading method and device, storage medium and equipment

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210541582.9A CN114640586B (en) 2022-05-19 2022-05-19 Cluster version upgrading method and device, storage medium and equipment

Publications (2)

Publication Number Publication Date
CN114640586A true CN114640586A (en) 2022-06-17
CN114640586B CN114640586B (en) 2023-01-06

Family

ID=81953123

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210541582.9A Active CN114640586B (en) 2022-05-19 2022-05-19 Cluster version upgrading method and device, storage medium and equipment

Country Status (1)

Country Link
CN (1) CN114640586B (en)

Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102487391A (en) * 2010-12-01 2012-06-06 中兴通讯股份有限公司 Method and system for upgrading remote control edition
WO2016181462A1 (en) * 2015-05-11 2016-11-17 株式会社日立製作所 Information processing system and cluster management method
CN108063675A (en) * 2016-11-08 2018-05-22 北京京东尚科信息技术有限公司 Detection method, detection device and the cluster configuration detecting system of cluster configuration
CN108683516A (en) * 2018-03-14 2018-10-19 聚好看科技股份有限公司 A kind of upgrade method of application example, device and system
CN109582335A (en) * 2018-12-03 2019-04-05 郑州云海信息技术有限公司 It is a kind of without interrupt storage cluster node online upgrading method, device and equipment
CN109728886A (en) * 2017-10-27 2019-05-07 中兴通讯股份有限公司 A kind of method of data synchronization, device, equipment and storage medium suitable for cross-version upgrading
CN110311820A (en) * 2019-07-05 2019-10-08 山东云缦智能科技有限公司 A kind of micro services cluster upgrade method of continual service
CN110879718A (en) * 2019-11-15 2020-03-13 北京浪潮数据技术有限公司 maridb upgrading method and device, electronic equipment and storage medium
CN110912977A (en) * 2019-11-15 2020-03-24 北京浪潮数据技术有限公司 Configuration file updating method, device, equipment and storage medium
CN113805925A (en) * 2021-09-27 2021-12-17 济南浪潮数据技术有限公司 Online upgrading method, device, equipment and medium for distributed cluster management software
CN113961312A (en) * 2021-10-28 2022-01-21 北京金山云网络技术有限公司 Target service deployment method and device and electronic equipment
CN114047941A (en) * 2022-01-12 2022-02-15 飞狐信息技术(天津)有限公司 Configuration upgrading method and device for redis service nodes
CN114422329A (en) * 2022-02-28 2022-04-29 苏州浪潮智能科技有限公司 Node upgrading method, device, equipment and readable storage medium

Patent Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102487391A (en) * 2010-12-01 2012-06-06 中兴通讯股份有限公司 Method and system for upgrading remote control edition
WO2016181462A1 (en) * 2015-05-11 2016-11-17 株式会社日立製作所 Information processing system and cluster management method
CN108063675A (en) * 2016-11-08 2018-05-22 北京京东尚科信息技术有限公司 Detection method, detection device and the cluster configuration detecting system of cluster configuration
CN109728886A (en) * 2017-10-27 2019-05-07 中兴通讯股份有限公司 A kind of method of data synchronization, device, equipment and storage medium suitable for cross-version upgrading
CN108683516A (en) * 2018-03-14 2018-10-19 聚好看科技股份有限公司 A kind of upgrade method of application example, device and system
CN109582335A (en) * 2018-12-03 2019-04-05 郑州云海信息技术有限公司 It is a kind of without interrupt storage cluster node online upgrading method, device and equipment
CN110311820A (en) * 2019-07-05 2019-10-08 山东云缦智能科技有限公司 A kind of micro services cluster upgrade method of continual service
CN110879718A (en) * 2019-11-15 2020-03-13 北京浪潮数据技术有限公司 maridb upgrading method and device, electronic equipment and storage medium
CN110912977A (en) * 2019-11-15 2020-03-24 北京浪潮数据技术有限公司 Configuration file updating method, device, equipment and storage medium
CN113805925A (en) * 2021-09-27 2021-12-17 济南浪潮数据技术有限公司 Online upgrading method, device, equipment and medium for distributed cluster management software
CN113961312A (en) * 2021-10-28 2022-01-21 北京金山云网络技术有限公司 Target service deployment method and device and electronic equipment
CN114047941A (en) * 2022-01-12 2022-02-15 飞狐信息技术(天津)有限公司 Configuration upgrading method and device for redis service nodes
CN114422329A (en) * 2022-02-28 2022-04-29 苏州浪潮智能科技有限公司 Node upgrading method, device, equipment and readable storage medium

Also Published As

Publication number Publication date
CN114640586B (en) 2023-01-06

Similar Documents

Publication Publication Date Title
US7703091B1 (en) Methods and apparatus for installing agents in a managed network
JP4876438B2 (en) Component software operation method and operation platform
CN107844343B (en) Upgrading system and method for complex server application system
CN105468717B (en) Database operation method and device
US8990797B2 (en) Method for improving the performance of computers by releasing computer resources
CN112100005B (en) Redis copy set implementation method and device
US20080244589A1 (en) Task manager
CN110730090B (en) Batch updating method, device, medium and electronic equipment for agent terminals in cloud environment
CN104486108A (en) Node configuration method base on Zookeeper and node configuration system based on Zookeeper
CN102955714A (en) Device and method for implementing dynamic analog remote interface
CN112860282B (en) Cluster plug-in upgrading method, device and server
CN105260209A (en) Hot-update solution of program
CN112099825B (en) Method, device, equipment and storage medium for upgrading component
CN111273924A (en) Software updating method and device
CN111538585A (en) Js-based server process scheduling method, system and device
JP2006285443A (en) Object relief system and method
CN114640586B (en) Cluster version upgrading method and device, storage medium and equipment
CN111857975A (en) Service updating method, device, equipment and medium
CN109257235B (en) Network anomaly recovery method, device, equipment and computer readable storage medium
CN108595292B (en) System optimization method, mobile terminal and computer storage medium
CN115543429A (en) Project environment building method, electronic equipment and computer readable storage medium
CN115314361A (en) Server cluster management method and related components thereof
US6205581B1 (en) Method for replace-block loading in a multiprocessor system
CN111124737A (en) Cloud platform operation conflict judgment method and electronic equipment
CN111240589A (en) Partition isolation-based system management method, device, equipment and storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant