An upgrading method, device, apparatus and storage medium

Abstract

The application discloses an upgrading method, device and equipment and a storage medium. The method comprises the following steps: acquiring a copy number and a current copy number in a configuration file; determining a copy number state according to the copy number and the current copy number in the configuration file; and upgrading a POD in a database cluster according to the copy number state. According to the technical scheme, the database cluster can be upgraded with zero downtime without affecting service availability, and the safety and availability of the upgrade are ensured.

Description

An upgrade method, apparatus, device, and storage medium Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to an upgrade method, apparatus, device and storage medium. Background Technology

[0002] Databases occupy a fundamental position in a business system, providing reliable data assurance and support. However, database expansion and upgrades are inevitable during database operation and maintenance.

[0003] In traditional database operations and maintenance, upgrades and expansions inevitably require downtime, leading to business unavailability. The resulting additional costs and business interruptions often result in substantial, even unbearable, losses. Therefore, to ensure service availability, a rolling upgrade solution has been proposed.

[0004] Existing database cluster rolling upgrade solutions are prone to situations where the primary POD of the database cluster is deleted during the rolling upgrade process, leading to fatal failures such as business data interruption and data inconsistency. Summary of the Invention

[0005] This invention provides an upgrade method, apparatus, device, and storage medium that enables zero-downtime upgrades of database clusters without affecting service availability, ensuring the security and availability of the upgrade.

[0006] According to one aspect of the present invention, an upgrade method is provided, comprising:

[0007] Get the number of replicas from the configuration file and the current number of replicas;

[0008] The replica count status is determined based on the replica count in the configuration file and the current replica count.

[0009] Upgrade the PODs in the database cluster based on the replica count status.

[0010] According to another aspect of the present invention, an upgrading device is provided, the upgrading device comprising:

[0011] The replica count acquisition module is used to obtain the replica count in the configuration file and the current replica count;

[0012] The replica count status determination module is used to determine the replica count status based on the replica count in the configuration file and the current replica count.

[0013] The upgrade module is used to upgrade the PODs in the database cluster based on the replica count status.

[0014] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0015] At least one processor; and

[0016] A memory communicatively connected to the at least one processor; wherein,

[0017] The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the upgrade method described in any embodiment of the present invention.

[0018] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the upgrade method described in any embodiment of the present invention.

[0019] This invention achieves zero-downtime upgrades of containerized databases without affecting service availability by obtaining the number of replicas in the configuration file and the current number of replicas; determining the replica status based on the number of replicas in the configuration file and the current number of replicas; and upgrading the PODs in the database cluster based on the replica status. This ensures the security and availability of the upgrade.

[0020] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0021] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 is a flowchart of an upgrade method according to an embodiment of the present invention;

[0023] Figure 2 is a topology diagram of the K8s high-availability database cluster in an embodiment of the present invention;

[0024] Figure 3 is a flowchart of another upgrade method in an embodiment of the present invention;

[0025] Figure 4 is a schematic diagram of an upgrade device according to an embodiment of the present invention;

[0026] Figure 5 is a schematic diagram of the structure of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0027] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0028] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0029] It is understood that before using the technical solutions disclosed in the various embodiments of this disclosure, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0030] Example 1

[0031] Figure 1 is a flowchart of an upgrade method provided by an embodiment of the present invention. This embodiment is applicable to upgrading PODs in a database cluster. The method can be executed by the upgrade device in this embodiment of the present invention. The device can be implemented in software and / or hardware. As shown in Figure 1, the method specifically includes the following steps:

[0032] S110 retrieves the number of replicas from the configuration file and the current number of replicas.

[0033] The configuration file can be a YAML file, and it is a configuration file for the database cluster. The configuration file can include: the total number of PODs, and the attribute information of each POD, etc.

[0034] Specifically, the current replica count can be obtained by: obtaining the number of PODs prefixed with the target prefix; and determining the number of PODs prefixed with the target prefix as the current replica count. The target prefix can be sample-mysql.

[0035] Specifically, the number of replicas in the configuration file can be obtained by: obtaining the total number of PODs in the configuration file and determining the total number of PODs in the configuration file as the number of replicas in the configuration file.

[0036] S120 determines the replica count status based on the replica count in the configuration file and the current replica count.

[0037] The replica count state can include any one of the following: replica count increases, replica count remains unchanged, and replica count decreases; the replica count state can also include any one of the following: replica count increases, replica count remains unchanged, replica count decreases and is not 2, and replica count decreases to 2.

[0038] Specifically, the replication status can be determined based on the replication number in the configuration file and the current replication number as follows: If the replication number in the configuration file is greater than the current replication number, the replication status is determined to be increasing; if the replication number in the configuration file is equal to the current replication number, the replication status is determined to be unchanged; if the replication number in the configuration file is less than the current replication number, the replication status is determined to be decreasing. Alternatively, the replication status can be determined as follows: If the replication number in the configuration file is greater than the current replication number, the replication status is determined to be increasing; if the replication number in the configuration file is equal to the current replication number, the replication status is determined to be unchanged; if the replication number in the configuration file is less than the current replication number, and the replication number in the configuration file is greater than 2, the replication status is determined to be decreasing and not 2; if the replication number in the configuration file is less than the current replication number, and the replication number in the configuration file is equal to 2, the replication status is determined to be decreasing to 2.

[0039] S130, upgrade the POD in the database cluster according to the replica count status.

[0040] Specifically, the method for upgrading PODs in the database cluster based on the replica count status can be as follows: if the replica count status indicates an increase in replicas, the existing PODs remain unchanged, and the newly added PODs are directly cloned from the slave PODs; if the replica count status indicates no change in replicas, each slave POD is upgraded sequentially, and the master POD is upgraded after all slave PODs have been successfully upgraded; if the replica count status indicates a decrease in replicas, the number of slave PODs to be deleted is determined based on the difference between the current replica count and the replica count in the configuration file, and the slave PODs are deleted based on the number of slave PODs to be deleted. Specifically, the method for upgrading PODs in the database cluster based on the replica count status can also be as follows: If the replica count status indicates an increase in replicas, the original POD remains unchanged, and a new slave POD is created based on the difference between the replica count in the configuration file and the current replica count, and the slave POD; if the replica count status indicates no change in replicas, each slave POD is upgraded sequentially. After all slave PODs are successfully upgraded, the master POD is upgraded. If the high availability component detects that the original master POD is unavailable, a POD is selected from the successfully upgraded slave PODs as the new master POD, and the original master POD is added as a slave POD. In a database cluster; if the high availability component detects that the original master POD is available, there is no need to re-select a master POD, and the original master POD's identity remains unchanged; if the replica count status is decreasing, the number of slave PODs to be deleted is determined based on the difference between the current replica count and the replica count in the configuration file, and slave PODs are deleted based on the number of slave PODs to be deleted; if the high availability component detects that the original master POD is unavailable, a new master POD is selected from all PODs through the high availability component, and the remaining PODs are designated as slave PODs; if the high availability component detects that the original master POD is available, there is no need to re-select a master POD, and the original master POD's identity remains unchanged.

[0041] Optionally, the replica count status can be determined based on the replica count in the configuration file and the current replica count, including:

[0042] If the number of replicas in the configuration file is greater than the current number of replicas, then the replica count status is determined to be "replica count increase";

[0043] If the number of replicas in the configuration file is equal to the current number of replicas, then the replica count status is determined to be unchanged.

[0044] If the number of replicas in the configuration file is less than the current number of replicas, then the replica count status is determined to be a decrease in the number of replicas.

[0045] It should be noted that if the number of replicas in the configuration file is less than the current number of replicas, then determining the replica count status as a reduction in replicas can include: if the number of replicas in the configuration file is less than the current number of replicas, and the number of replicas in the configuration file is greater than 2, then the replica count status is determined to be a reduction in replicas and not 2; if the number of replicas in the configuration file is less than the current number of replicas, and the number of replicas in the configuration file is equal to 2, then the replica count status is determined to be a reduction in replicas to 2.

[0046] Optionally, upgrading the PODs in the database cluster based on the replica count status includes:

[0047] If the replica count status is "replica count increased", then keep the original POD unchanged, and create a new slave POD based on the difference between the replica count in the configuration file and the current replica count, and from the original POD.

[0048] If the number of replicas remains unchanged, then each slave POD is upgraded sequentially. After all slave PODs have been successfully upgraded, the master POD is upgraded.

[0049] If the replica count status is "replica count decreases", then the number of slave PODs to be deleted is determined based on the difference between the current replica count and the replica count in the configuration file, and the slave PODs are deleted based on the number of slave PODs to be deleted.

[0050] Specifically, the way to keep the original POD unchanged is to keep the original master POD and the original slave POD unchanged in the database cluster.

[0051] Specifically, based on the difference between the number of replicas in the configuration file and the current number of replicas, and the method of creating a new slave POD from the original POD, the following can be used: add a new slave POD based on the original slave POD, and the new slave POD is the same as the original slave POD.

[0052] Upgrading a slave POD involves deleting the original slave POD from the database cluster and creating a new slave POD based on the configuration file. Upgrading a master POD involves deleting the original master POD from the database cluster and creating a new master POD based on the configuration file.

[0053] Specifically, each slave POD is upgraded sequentially. After all slave PODs have been successfully upgraded, the master POD can be upgraded in the following way: each slave POD in the database cluster is upgraded sequentially in a randomly selected order. After all slave PODs have been successfully upgraded, the master POD is upgraded. For example, the database cluster includes: sample-mysql-0 (original master POD), sample-mysql-1 (original slave POD1), and sample-mysql-2 (original slave POD2). If the number of replicas in the configuration file is 3, and the current number of replicas is 3, then the number of replicas is set to remain unchanged. First, sample-mysql-1 is upgraded. After sample-mysql-1 is successfully upgraded, sample-mysql-2 is upgraded. After sample-mysql-2 is successfully upgraded, sample-mysql-0 is upgraded.

[0054] Specifically, if the replica count status is decreasing, the number of slave PODs to be deleted is determined based on the difference between the current replica count and the replica count in the configuration file. The method for deleting slave PODs based on this number is as follows: If the replica count status is decreasing and the replica count in the configuration file is greater than 2, the number of slave PODs to be deleted is determined based on the difference between the current replica count and the replica count in the configuration file; slave PODs are then deleted based on this number. If the replica count status is decreasing and the replica count in the configuration file is equal to 2, the primary POD is set to read-only mode; once the data in the slave POD is consistent with the data in the primary POD, the number of slave PODs to be deleted is determined based on the difference between the current replica count and the replica count in the configuration file; slave PODs are then deleted based on this number. Specifically, if the replica count status is decreasing, the number of slave PODs to be deleted is determined based on the difference between the current replica count and the replica count in the configuration file. Alternatively, slave PODs can be deleted based on this number: if the replica count status is decreasing and not 2, the number of slave PODs to be deleted is determined based on the difference between the current replica count and the replica count in the configuration file; slave PODs are then deleted based on this number. If the replica count status is decreasing and is 2, the primary POD is set to read-only mode; once the data in the slave POD matches the data in the primary POD, the number of slave PODs to be deleted is determined based on the difference between the current replica count and the replica count in the configuration file; slave PODs are then deleted based on this number.

[0055] Optionally, if the replica count remains unchanged, each slave POD is upgraded sequentially. After all slave PODs are successfully upgraded, and the master POD is upgraded, the following steps are also included:

[0056] If the high availability component detects that the original primary POD is unavailable, it selects a new primary POD from the successfully upgraded secondary PODs and adds the original primary POD to the database cluster as a secondary POD.

[0057] The phrase "original owner POD unavailable" means that the original owner POD is inaccessible or the access timeout occurs.

[0058] The high-availability component can be Xenon.

[0059] It should be noted that if the original master POD is unavailable, a new master POD needs to be selected. If the original master POD is available, there is no need to select a new master POD; the original master POD's identity can remain unchanged.

[0060] In a specific example, if xenon detects that the original primary POD is unavailable, xenon selects a POD from the successfully upgraded secondary PODs as the new primary POD, and adds the original primary POD to the database cluster as a secondary POD.

[0061] Optionally, if the replica count status is "replica count decreases", then the number of slave PODs to be deleted is determined based on the difference between the current replica count and the replica count in the configuration file. After deleting slave PODs based on the number of slave PODs to be deleted, the process also includes:

[0062] If the high availability component detects that the original primary POD is unavailable, a new primary POD is selected from all PODs through the high availability component, and the remaining PODs are designated as secondary PODs.

[0063] Here, "all PODs" refers to all PODs in the database cluster. For example, if the current replica count is 5 and the replica count in the configuration file is 3, then the difference between the current replica count and the replica count in the configuration file is determined to be 2. Two slave PODs are deleted from the database cluster, leaving one master POD (A) and two slave PODs (B and C). If the master POD becomes unavailable, a new master POD (B) is selected from A, B, and C using a high-availability component, while A and C are designated as slave PODs.

[0064] The remaining PODs are those other than the new primary POD in the database cluster.

[0065] It should be noted that if the original master POD is unavailable, a new master POD needs to be selected. If the original master POD is available, there is no need to select a new master POD; the original master POD's identity can remain unchanged.

[0066] In a specific example, if xenon detects that the original primary POD is unavailable, xenon selects a new primary POD from all PODs and designates the remaining PODs as secondary PODs.

[0067] Optionally, if the replica count status is "replica count decreasing," then the number of slave PODs to be deleted is determined based on the difference between the current replica count and the replica count in the configuration file. Slave PODs are then deleted based on this number, including:

[0068] If the replica count status is decreasing and the replica count in the configuration file is greater than 2, then the number of PODs to be deleted is determined based on the difference between the current replica count and the replica count in the configuration file.

[0069] Delete PODs based on the number of PODs to be deleted.

[0070] Optionally, if the replica count status is "replica count decreasing", then the number of slave PODs to be deleted is determined based on the difference between the current replica count and the replica count in the configuration file. Deleting slave PODs based on the number of slave PODs to be deleted includes:

[0071] If the replica count status is "replica count decreased" and the replica count in the configuration file is equal to 2, then the primary POD will be set to read-only mode.

[0072] Once the data in the slave POD is consistent with the data in the master POD, the number of slave PODs to be deleted is determined based on the difference between the current number of replicas and the number of replicas in the configuration file.

[0073] Delete PODs based on the number of PODs to be deleted.

[0074] It's important to note that to ensure data consistency between the slave POD and the master POD, the master POD must first be set to read-only mode. Deleting a slave POD requires that the data in all slave PODs within the database cluster is identical to the data in the master POD. In other words, deleting a slave POD only after all the data in all slave PODs in the database cluster is consistent with the data in the master POD ensures data security.

[0075] Optionally, retrieve the current number of replicas, including:

[0076] Get the number of PODs whose prefix is ​​the target prefix;

[0077] The number of PODs prefixed with the target prefix is ​​determined as the current number of replicas.

[0078] If the cluster name is sample, then the target prefix can be sample-mysql.

[0079] In a specific example, Figure 2 shows the topology of a Kubernetes high-availability database cluster. As shown in Figure 2, the database cluster includes: a master POD (sample-mysql-0), slave POD1 (sample-mysql-1), and slave POD2 (sample-mysql-2). Here, sample-mysql-0 to sample-mysql-2 are the names of the Pods allocated by the Kubernetes StatefulSet. The master POD's container components include: a MySQL database container, a Xenon high-availability component container, and other containers serving various functions. As shown in Figure 2, the current number of replicas is 3. If the number of replicas in the configuration file is 3, then the replica count status is determined to be unchanged. The upgrade process is as follows: Step 1, upgrade sample-mysql-1; Step 2, after sample-mysql-1 is successfully upgraded, upgrade another slave POD, namely sample-mysql-2; Step 3, after sample-mysql-2 is successfully upgraded, upgrade the master POD, namely sample-mysql-0; Step 4, after sample-mysql-0 is successfully upgraded, Xenon selects sample-mysql-1 as the new master POD and changes the identity of sample-mysql-0 to slave POD.

[0080] The database cluster provided in this embodiment of the invention can be the open-source project radondb-mysql-kubernetes, and Xenon is a MySQL high availability and replication management middleware based on the Raft protocol.

[0081] In another specific example, as shown in Figure 3, this embodiment of the invention aims to achieve secure rolling upgrades of the database. Unlike the original rolling upgrade method in Kubernetes, this embodiment customizes the upgrade rules to ensure data security and availability, and handles the following situations respectively:

[0082] Scenario 1: The number of replicas increases, requiring expansion. In this case, the method of adding replicas is used to keep the original Pod unchanged and directly clone data from the POD node to create a new slave POD.

[0083] Scenario 2: Upgrade without changing the number of replicas. In this case, some system modifications are required. The Operator first processes the slave PODs: it deletes the slave POD and waits for its successful upgrade before processing the next slave POD. After all slave PODs have been processed, the master POD is deleted and its upgrade is completed. At this point, the high availability component container (the open-source high availability component Xenon) will select a new master POD from the slave PODs, and the existing master POD will be added to the database cluster as a slave POD.

[0084] Scenario 3: The number of replicas is reduced, but the number of replicas is not 2. In this case, the slave POD is deleted, and a new master POD is selected. The original master POD is then added to the database cluster as a slave POD.

[0085] Scenario 4: The number of replicas is reduced to 2. In this case, the Raft cluster will transform into a simple master-slave cluster. First, the master POD needs to be set to read-only mode. After the data in the slave POD is consistent with the data in the master POD, the slave POD is deleted. Then, the high-availability component Xenon elects a new master POD, and the remaining PODs are designated as slave PODs.

[0086] By employing the above methods, secure rolling upgrades of the database were achieved, ensuring data security and availability.

[0087] The technical solution of this embodiment obtains the number of replicas and the current number of replicas in the configuration file; determines the replica status based on the number of replicas in the configuration file and the current number of replicas; and upgrades the PODs in the database cluster based on the replica status. This enables zero-downtime upgrades of containerized databases without affecting service availability, ensuring the security and availability of the upgrade.

[0088] Example 2

[0089] Figure 4 is a schematic diagram of an upgrade device provided in an embodiment of the present invention. This embodiment is applicable to upgrading PODs in a database cluster. The device can be implemented in software and / or hardware and can be integrated into any device that provides upgrade functionality. As shown in Figure 4, the upgrade device specifically includes: a replica count acquisition module 210, a replica count status determination module 220, and an upgrade module 230.

[0090] The replica count acquisition module is used to obtain the replica count in the configuration file and the current replica count.

[0091] The replica count status determination module is used to determine the replica count status based on the replica count in the configuration file and the current replica count.

[0092] The upgrade module is used to upgrade the PODs in the database cluster based on the replica count status.

[0093] The above-described products can perform the methods provided in any embodiment of the present invention, and have the corresponding functional modules and beneficial effects for performing the methods.

[0094] The technical solution of this embodiment obtains the number of replicas and the current number of replicas in the configuration file; determines the replica status based on the number of replicas in the configuration file and the current number of replicas; and upgrades the PODs in the database cluster based on the replica status. This enables zero-downtime upgrades of containerized databases without affecting service availability, ensuring the security and availability of the upgrade.

[0095] Example 3

[0096] Figure 5 illustrates a schematic diagram of an electronic device 10 that can be used to implement embodiments of the present invention. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0097] As shown in Figure 5, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer programs stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0098] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0099] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as upgrade methods.

[0100] In some embodiments, the upgrade method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the upgrade method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the upgrade method by any other suitable means (e.g., by means of firmware).

[0101] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0102] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0103] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0104] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0105] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0106] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0107] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0108] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. An upgrade method, characterized in that, include: Get the number of replicas from the configuration file and the current number of replicas; The replica count status is determined based on the replica count in the configuration file and the current replica count. Upgrade the PODs in the database cluster based on the replica count status; Upgrading PODs in the database cluster based on the replica count status includes: if the replica count status indicates an increase in replicas, keeping the existing PODs unchanged and creating new slave PODs based on the difference between the replica count in the configuration file and the current replica count; if the replica count status indicates no change in replicas, upgrading each slave POD sequentially, and upgrading the master POD after all slave PODs have been successfully upgraded; if the replica count status indicates a decrease in replicas, determining the number of slave PODs to be deleted based on the difference between the current replica count and the replica count in the configuration file, and deleting slave PODs based on the number of slave PODs to be deleted. OD; Maintaining existing PODs unchanged involves keeping the original master POD and slave PODs unchanged in the database cluster; Creating new slave PODs based on the difference between the number of replicas in the configuration file and the current number of replicas, and using the slave PODs themselves, includes: adding new slave PODs based on the original slave PODs, with the new slave PODs being identical to the original slave PODs; Upgrading slave PODs includes: deleting the original slave PODs in the database cluster and creating new slave PODs based on the configuration file; Upgrading master PODs includes: deleting the original master PODs in the database cluster and creating new master PODs based on the configuration file.

2. The method according to claim 1, characterized in that, The replica count status is determined based on the replica count in the configuration file and the current replica count, including: if the replica count in the configuration file is greater than the current replica count, the replica count status is determined to be increasing; if the replica count in the configuration file is equal to the current replica count, the replica count status is determined to be unchanged; if the replica count in the configuration file is less than the current replica count, the replica count status is determined to be decreasing.

3. The method according to claim 2, characterized in that, Upgrading PODs in the database cluster based on the replica count status includes: if the replica count status indicates an increase in replicas, keeping the existing PODs unchanged and creating new slave PODs based on the difference between the replica count in the configuration file and the current replica count; if the replica count status indicates no change in replicas, upgrading each slave POD sequentially, and upgrading the master POD after all slave PODs have been successfully upgraded; if the replica count status indicates a decrease in replicas, determining the number of slave PODs to be deleted based on the difference between the current replica count and the replica count in the configuration file, and deleting slave PODs based on the number of slave PODs to be deleted.

4. The method according to claim 3, characterized in that, If the number of replicas remains unchanged, each slave POD is upgraded sequentially. After all slave PODs are successfully upgraded, and after the master POD is upgraded, the process continues as follows: if the original master POD is detected to be unavailable by the high availability component, a POD is selected from the successfully upgraded slave PODs by the high availability component to be the new master POD, and the original master POD is added to the database cluster as a slave POD.

5. The method according to claim 3, characterized in that, If the replica count status is "replica count decreases", then the number of slave PODs to be deleted is determined based on the difference between the current replica count and the replica count in the configuration file. After deleting slave PODs based on the number of slave PODs to be deleted, the process also includes: if the original master POD is detected to be unavailable through the high availability component, then a new master POD is selected from all PODs through the high availability component, and the remaining PODs are determined as slave PODs.

6. The method according to claim 3, characterized in that, If the replica count status is "replica count decreases", then the number of slave PODs to be deleted is determined based on the difference between the current replica count and the replica count in the configuration file. Slave PODs are then deleted based on the number of slave PODs to be deleted. This includes: if the replica count status is "replica count decreases" and the replica count in the configuration file is greater than 2, then the number of slave PODs to be deleted is determined based on the difference between the current replica count and the replica count in the configuration file. Slave PODs are then deleted based on the number of slave PODs to be deleted.

7. The method according to claim 3, characterized in that, If the replica count status is "replica count decreases", then the number of slave PODs to be deleted is determined based on the difference between the current replica count and the replica count in the configuration file. Deleting slave PODs based on the number of slave PODs to be deleted includes: if the replica count status is "replica count decreases" and the replica count in the configuration file is equal to 2, then the primary POD is set to read-only mode; when the data in the slave POD is consistent with the data in the primary POD, the number of slave PODs to be deleted is determined based on the difference between the current replica count and the replica count in the configuration file; and slave PODs are deleted based on the number of slave PODs to be deleted.

8. The method according to claim 1, characterized in that, Get the current replica count, including: getting the number of PODs with the target prefix; and determining the number of PODs with the target prefix as the current replica count.

9. An upgrading device, characterized in that, include: The replica count acquisition module is used to obtain the replica count in the configuration file and the current replica count; The replica count status determination module is used to determine the replica count status based on the replica count in the configuration file and the current replica count. The upgrade module is used to upgrade PODs in the database cluster based on the replica count status. Specifically, the upgrade module is used as follows: if the replica count status is "replica count increases", then the original PODs remain unchanged, and new slave PODs are created based on the difference between the replica count in the configuration file and the current replica count, and the slave PODs; if the replica count status is "replica count remains unchanged", then each slave POD is upgraded sequentially, and the master POD is upgraded after all slave PODs have been successfully upgraded; if the replica count status is "replica count decreases", then the number of slave PODs to be deleted is determined based on the difference between the current replica count and the replica count in the configuration file, and slave PODs are deleted based on the number of slave PODs to be deleted; the way to keep the original PODs unchanged is: keep the original master POD and the original slave PODs in the database cluster unchanged. Based on the difference between the number of replicas in the configuration file and the current number of replicas, and by creating a new slave POD from the original POD, the process includes: adding a new slave POD based on the original slave POD, with the new slave POD being identical to the original slave POD; upgrading a slave POD includes: deleting the original slave POD from the database cluster and creating a new slave POD based on the configuration file; upgrading a master POD includes: deleting the original master POD from the database cluster and creating a new master POD based on the configuration file.

10. An electronic device, characterized in that, The electronic device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the upgrade method according to any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the upgrade method according to any one of claims 1-8.

Images