A VIP binding method, device and electronic equipment based on a database backup

Abstract

This application discloses a VIP binding method and apparatus based on a database backup database, applied to read / write separation scenarios in an openGauss database cluster. The method includes: upon cluster startup, a collection and preemption phase is initiated, where the cluster management server distributes backup database VIP pool information, the proxy detects and reports any existing virtual IPs, and the server arbitrates allocation; after entering the balancing phase, only normal backup databases are allowed to hold virtual IPs, and the server evenly distributes the virtual IPs in the VIP pool to each normal backup database, prioritizing those with fewer virtual IPs; virtual IPs are released when the status is abnormal or the role is switched to the primary database; and all virtual IPs are released when the cluster shuts down. This invention, through dynamic binding of virtual IPs to backup database roles, ensures that the business side always connects to the backup database via a fixed IP, achieving IP-level load balancing and role adaptation, reducing the coupling between the business layer and the database high availability mechanism, and improving system read performance and fault tolerance.

Description

Technical Field

[0001] This application relates to the field of database master-slave switching technology, and in particular to a VIP binding method, apparatus, computer-readable storage medium, and electronic device based on a database backup database. Background Technology

[0002] As database applications continue to expand and business data volumes continue to grow, the access pressure on the primary database is increasing. To effectively alleviate the read operation pressure on the primary database, read-write separation architecture has become an important database deployment model. Under this architecture, routing read-only business operations to the standby database is a key means to improve the overall throughput of the system.

[0003] However, in the practical deployment of read / write separation in the openGauss database, existing technical solutions have the following technical shortcomings:

[0004] First, the static IP binding mechanism lacks role awareness. Current deployment methods often use fixed static IP addresses for nodes. When a database failover occurs, the original standby database may be promoted to the primary database, and the original primary database may be demoted to the standby database. Because the static IP is bound to the physical node rather than to the database role, the application layer cannot ensure a constant connection to the standby database through a fixed IP. As a result, the read / write splitting strategy fails, and the load balancing design goal cannot be achieved.

[0005] Second, the application-layer role detection mechanism increases the burden on business operations. If the application layer mandates a connection to the backup database, role detection must be performed during the initial connection establishment to confirm whether the target node is currently a backup database. After the connection is established, the role status of the connected node must be continuously monitored to prepare for potential primary / backup failover. This approach of pushing high availability judgment logic down to the application layer not only increases the development complexity and maintenance costs of the business system but also introduces additional network overhead and latency, reducing system operating efficiency.

[0006] Third, it lacks a native VIP (Virtual IP) dynamic binding mechanism. The existing openGauss architecture fails to provide virtual IP management capabilities that are linked to the database role status, and cannot achieve automatic migration of the "standby IP" at the network layer. As a result, the connection routing problem in read-write separation scenarios is difficult to fundamentally solve at the database infrastructure level.

[0007] In summary, there is an urgent need for a technical solution that can dynamically bind virtual IPs to database standby roles, enabling the application layer to transparently access the standby database through a fixed virtual IP without being aware of changes in the underlying primary-standby topology. This simplifies the application architecture while ensuring the continued effectiveness of the read-write separation strategy. Summary of the Invention

[0008] Terminology Explanation:

[0009] Backup VIP pool: There are currently no VIPs held by any node.

[0010] Preemption: Obtain a VIP from the standby VIP pool, configure this VIP to the network interface card, refresh the ARP cache, and the database listens on this configured VIP.

[0011] Release: Remove all VIPs currently held by the database instance from the network interface card and release them to the standby database VIP pool.

[0012] To address the issue that static IPs cannot guarantee continuous service connectivity to the standby database during master-slave failover scenarios in openGauss database clusters, this application proposes a novel VIP binding method based on the database standby database. This method aims to enable openGauss to achieve IP-level load balancing and role-adaptive capabilities in a read-write separation architecture, thereby meeting the deterministic requirements of services for accessing the standby database in high-availability scenarios.

[0013] This invention aims to achieve the following technical objectives:

[0014] First, ensure role consistency. Establish a virtual IP pool mechanism that is linked to the database role status to ensure that when the business side initiates a connection through any IP in the VIP pool, the accessed database node is always in the standby role, fundamentally eliminating the role mismatch problem caused by primary-standby switchover.

[0015] Second, load balancing capability. Virtual IPs in the VIP pool are evenly distributed to all available standby database nodes, so that read requests are evenly distributed to each standby database instance, avoiding excessive pressure on a single point and improving the overall read performance of the system.

[0016] Third, transparent access. The business layer only needs to configure the VIP pool address to access the backup database, without needing to be aware of the underlying node physical topology or changes in the master / slave status, thus reducing the coupling between the business system and the database high availability mechanism.

[0017] To achieve the above objectives, this application provides the following technical solution:

[0018] The first aspect of this application provides a VIP binding method based on a database backup database, applied to an openGauss database cluster, such as... Figure 1 As shown, the method includes:

[0019] S1. Maintain a standby database VIP pool, which contains a set of virtual IP addresses that are not currently held by any database instance;

[0020] S2. When the cluster starts up, it enters the collection and preemption phase. The cluster management server sends the standby database VIP pool information to the cluster management agent, allowing standby databases in normal status to detect and preempt the virtual IP address in the standby database VIP pool, and configure the preempted virtual IP address to the local network card.

[0021] S3. The cluster management agent detects the virtual IPs it currently holds and reports them to the cluster management server. The cluster management server arbitrates the ownership of the virtual IPs based on the reported information. Virtual IPs that have been preempted are released to the backup VIP pool by the subsequent reporting node.

[0022] S4. Entering the balancing phase, only standby databases in normal status are allowed to hold virtual IPs. The cluster management server will evenly distribute the virtual IPs in the standby database VIP pool to each normal standby database, with standby databases holding fewer virtual IPs receiving priority allocation.

[0023] S5. When the standby database is in an abnormal state or its role is switched to the primary database, the cluster management server arbitrates the node to release all the virtual IPs it holds to the standby database VIP pool.

[0024] S6. When the cluster is shut down, each node releases all the virtual IPs it holds and reclaims them to the backup VIP pool.

[0025] Furthermore, in the method of this application, during the collection and preemption phase and the balancing phase, the primary database is always arbitrated as not holding any backup database VIP. If it is detected that the primary database holds a backup database VIP, the backup database VIP held by it must be released immediately and reclaimed.

[0026] Furthermore, in the method of this application, step S2 also includes:

[0027] Within a preset time after the cluster starts, each database instance is allowed to report the virtual IP addresses it holds, and the normal standby databases are given priority to seize the free virtual IP addresses; for conflicting virtual IP address holdings, arbitration is carried out based on the reporting order, and the instance that reports later must release the virtual IP address.

[0028] Furthermore, in the method of this application, the collection and preemption phase in step S2 is set with a timeout period, and after the timeout, it automatically enters the balancing phase.

[0029] Furthermore, in the method of this application, before the cluster management agent reports in step S3, it first preempts the virtual IP in the backup database VIP pool and configures it to the local network card, refreshes the ARP cache, and then starts database listening.

[0030] Furthermore, in the method of this application, when the standby database status becomes abnormal due to streaming replication jitter in step S5, the virtual IP is recycled after a preset time delay to enhance system stability.

[0031] Furthermore, in the method of this application, the release action of the virtual IP in step S5 continues to be executed until it is successful or the action is canceled.

[0032] Furthermore, in the method of this application, the cluster management server continuously sends virtual IP configuration instructions, revocation instructions and detection instructions to the cluster management agent, and the cluster management agent performs the corresponding actions and reports the execution results.

[0033] A second aspect of this application provides a VIP binding device based on a database backup database, applied to an openGauss database cluster, the device comprising:

[0034] The VIP pool management module is used to maintain a standby VIP pool, which contains a set of virtual IP addresses that are not currently held by any database instance.

[0035] The collection and preemption module is used to enter the collection and preemption phase when the cluster starts up. The cluster management server sends the standby database VIP pool information to the cluster management agent, allowing standby databases in normal status to detect and preempt the virtual IP addresses in the standby database VIP pool, and configure the preempted virtual IP addresses to the local network card.

[0036] The attribution arbitration module is used by the cluster management agent to detect the currently held virtual IPs and report them to the cluster management server. The cluster management server arbitrates the attribution of the virtual IPs based on the reported information. Virtual IPs that have been preempted are released to the backup VIP pool by the subsequent reporting node.

[0037] The balancing allocation module is used to enter the balancing phase. Only standby databases in normal status are allowed to hold virtual IPs. The cluster management server will evenly distribute the virtual IPs in the standby database VIP pool to each normal standby database. Standby databases with fewer virtual IPs will be given priority in allocation.

[0038] The switching processing module is used to arbitrate when the standby database is in an abnormal state or its role is switched to the primary database, and the cluster management server arbitrates the node to release all the virtual IPs it holds to the standby database VIP pool.

[0039] The release control module is used to ensure that each node releases all virtual IPs it holds and reclaims them to the backup VIP pool when the cluster is shut down.

[0040] When the device is running, it implements the steps of the aforementioned VIP binding method based on the database backup.

[0041] A third aspect of this application provides an electronic device, including: a memory and a processor;

[0042] Memory: Used to store computer programs;

[0043] Processor: Used to execute the computer program to implement the steps of the aforementioned VIP binding method based on the database backup.

[0044] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the aforementioned VIP binding method based on a database backup.

[0045] In summary, compared with the prior art, the method of the present invention has the following advantages:

[0046] (1) Guarantee of role certainty

[0047] By using a dynamic binding mechanism between the standby VIP pool and database roles, virtual IPs automatically drift with the standby database status, ensuring that business access via a fixed virtual IP will always connect to the standby database. This fundamentally solves the role mismatch problem caused by primary / standby switching and eliminates the burden of application layer role detection.

[0048] (2) Load balancing optimization

[0049] A two-stage strategy of collection and preemption and balancing is adopted to evenly distribute virtual IPs to each normal backup database node, so that read requests are evenly distributed and avoid single-point pressure overload; at the same time, a priority preemption mechanism is supported to ensure that VIP resources are tilted to low-load nodes, thereby improving the overall read performance and resource utilization of the system.

[0050] (3) Enhanced availability and fault tolerance

[0051] The arbitration mechanism based on the cluster management tool enables continuous retry of virtual IP configuration and delayed recovery of abnormal status, effectively dealing with transient failures such as stream replication jitter; the full release and reallocation strategy during cluster start-up and shutdown ensures the integrity and consistency of VIP resources and improves system robustness.

[0052] (4) Improved business transparency

[0053] The business layer only needs to configure the VIP pool address to access the backup database, without needing to be aware of changes in the underlying node topology or master-slave switching events. This significantly reduces the coupling between the business system and the database high availability mechanism, and simplifies the application architecture design and operation and maintenance complexity.

[0054] Other features and advantages of this application will be set forth in detail in the following description, or will become apparent through the implementation of the relevant technical solutions of this application. The objectives and other advantages of this application can be achieved through the technical features and means explicitly pointed out in the description, claims, and drawings, and will be obtained through the implementation of these technical contents. Attached Figure Description

[0055] To more clearly illustrate the technical solution of this application, the accompanying drawings involved in the description of this invention will be briefly introduced below. It should be noted that the drawings only show some embodiments of the invention. For those skilled in the art, other related drawings can be derived from these drawings without creative effort.

[0056] Figure 1 This is a flowchart illustrating the overall implementation of the VIP binding method based on a database backup in this invention.

[0057] Figure 2 This is a schematic diagram illustrating the relationship between the backup VIP pool and the primary / backup database cluster in this invention.

[0058] Figure 3 This is a structural diagram of the VIP binding device based on a database backup according to the present invention.

[0059] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0060] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be noted that the described embodiments are only some embodiments of this application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the protection scope of this application.

[0061] In this document, the term "comprising" and any variations thereof (such as "including," "including," etc.) are open-ended expressions and should be understood as "including but not limited to," meaning that the listed content is not exhaustive and may include other content not explicitly mentioned. The term "based on" should be understood as "at least partially based on," meaning that the basis or condition referred to may not be the only factor and may involve other relevant factors. The term "one embodiment" should be understood as "at least one embodiment," meaning that the described embodiment is not the only possible implementation, and other similar embodiments may exist.

[0062] In this application, the terms "a" and "a plurality of" are used to modify related elements or features, and their expression is illustrative rather than restrictive. Unless otherwise expressly stated in the context, "a" should be understood as "at least one," and "a plurality of" should be understood as "at least two." Those skilled in the art should reasonably interpret these terms based on the semantic and logical relationships of the context to ensure that they cover the possibility of "one or more."

[0063] Example: A VIP binding method based on a database backup

[0064] This invention addresses the master-slave failover process in the openGauss database, where the roles of the master and slave databases change on a single database instance.

[0065] This invention addresses existing problems using a standby database VIP pool method, primarily divided into a collection and preemption phase and a balancing phase. Upon cluster startup, it enters the collection and preemption phase, allowing a period (e.g., 20 seconds) for all database instances to become normal. If a normal standby database instance does not have a VIP, it preempts one from the standby VIP pool. During this time, it also checks if it already holds a VIP; if a held VIP has not been preempted by another node, it preempts it. VIPs preempted by other standby database instances are actively released back into the standby VIP pool. In the balancing phase, only normal standby databases can hold VIPs. VIPs held by abnormal standby databases are reclaimed from the standby VIP pool. Nodes can only reacquire VIPs from the pool after normalization, with nodes holding fewer VIPs having priority. VIPs are allocated from the standby VIP pool one at a time until all VIPs are allocated. The primary database actively releases all VIPs from the standby VIP pool. Furthermore, all configured VIPs are deleted when the cluster stops.

[0066] This implementation is based on the CM cluster management tool; CMS is responsible for receiving the reported messages from CMA and issuing the arbitration results: which CMA needs to delete a VIP, add a VIP, or check the currently owned VIPs; while CMA is responsible for executing the actions and reporting the detection results.

[0067] The CMS will continuously execute actions such as configuring and reclaiming VIPs until they are successfully executed or the actions are canceled.

[0068] If a user holds a VIP, due to node malfunctions caused by streaming replication jitter, there will be a certain delay (e.g., 10 seconds) before the VIP is actually reclaimed.

[0069] Example: When the cluster stopped, some nodes did not release all standby database VIPs. Now the cluster starts.

[0070] 1. CMS sends all VIPs in the current VIP address pool to all CMAs. CMAs check the VIPs they already hold and report them. CMS records the VIPs that are currently held (whoever reports first holds the VIP, and those who report later are directly arbitrated to release the VIP). Once all nodes have reported, or after a timeout, the system enters the balancing phase.

[0071] 2. During the balancing phase, if a node fails, the node will be arbitrated to release all VIPs. This process continues until all held VIPs are successfully released, and the recovered VIPs are used for allocation.

[0072] If there are idle VIPs in the VIP address pool, and the backup database reports them normally, a VIP can be immediately assigned if the number of VIPs held by the backup is smaller than that held by other normal nodes, or if the number of VIPs held by all normal nodes is the same.

[0073] 3. When the system is shut down, CMA will proactively clear all VIPs it holds.

[0074] To more clearly illustrate the technical solution of this application, the following will provide further explanation through specific scenario embodiments.

[0075] Figure 2 This is a schematic diagram illustrating the relationship between the backup VIP pool and the primary / backup database cluster in this invention. Figure 2 As shown (this illustration uses only one primary and one backup configuration; the process is similar in cases of one primary and multiple backup configurations), the present invention includes the following process:

[0076] I. The collection and acquisition phase, with the following specific steps:

[0077] 1. Detect and preempt the VIP held on the database node;

[0078] 2. If the database node has recovered to normal and is a standby database, then VIP preemption will be performed.

[0079] II. The balancing phase, the specific steps are as follows:

[0080] 1. Only normal standby databases can continuously hold VIPs and preempt VIPs, and normal standby databases with fewer VIPs are given priority for preemption;

[0081] 2. All database instances other than the normal standby database should release their VIPs, releasing all VIPs they hold;

[0082] 3. Specify which database instance's VIP to release. This VIP can then be preempted by other nodes. After a period of time, this VIP can be preempted by all nodes.

[0083] 4. When the cluster is shut down, all nodes release all held VIPs.

[0084] Figure 3 The image shows a VIP binding device based on a database backup database proposed in this application, applied to an openGauss database cluster. The device includes:

[0085] The VIP pool management module is used to maintain a standby VIP pool, which contains a set of virtual IP addresses that are not currently held by any database instance.

[0086] The collection and preemption module is used to enter the collection and preemption phase when the cluster starts up. The cluster management server sends the standby database VIP pool information to the cluster management agent, allowing standby databases in normal status to detect and preempt the virtual IP addresses in the standby database VIP pool, and configure the preempted virtual IP addresses to the local network card.

[0087] The attribution arbitration module is used by the cluster management agent to detect the currently held virtual IPs and report them to the cluster management server. The cluster management server arbitrates the attribution of the virtual IPs based on the reported information. Virtual IPs that have been preempted are released to the backup VIP pool by the subsequent reporting node.

[0088] The balancing allocation module is used to enter the balancing phase. Only standby databases in normal status are allowed to hold virtual IPs. The cluster management server will evenly distribute the virtual IPs in the standby database VIP pool to each normal standby database. Standby databases with fewer virtual IPs will be given priority in allocation.

[0089] The switching processing module is used to arbitrate when the standby database is in an abnormal state or its role is switched to the primary database, and the cluster management server arbitrates the node to release all the virtual IPs it holds to the standby database VIP pool.

[0090] The release control module is used to ensure that each node releases all virtual IPs it holds and reclaims them to the backup VIP pool when the cluster is shut down.

[0091] When the above-mentioned device is in operation, it implements the steps of the VIP binding method based on the database backup disclosed in this application.

[0092] The flowcharts and block diagrams in the accompanying drawings illustrate possible implementations of apparatus, methods, and computer program products according to various embodiments of this application, including architecture, functionality, and operation. In these figures, each block may represent a module, program segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should be noted that each block in the block diagrams and / or flowcharts, and combinations thereof, can be implemented using either a dedicated hardware-based system or a combination of dedicated hardware and computer instructions to achieve the specified function or operation.

[0093] like Figure 4As shown, embodiments of this application also disclose an electronic device, including: a processor 310, a communication interface 320, a memory 330 for storing a processor-executable computer program, and a communication bus 340. The processor 310, communication interface 320, and memory 330 communicate with each other via the communication bus 340. The processor 310 executes the executable computer program to implement the steps of the aforementioned VIP binding method based on a database backup.

[0094] It is understood that, in addition to memory and a processor, this electronic device may also include input devices (such as a keyboard), output devices (such as a display), and other communication modules. These input devices, output devices, and other communication modules all communicate with the processor through I / O interfaces (i.e., input / output interfaces).

[0095] The operations described in this application can be implemented by writing computer program code using one or more programming languages ​​or a combination thereof. The programming languages ​​include, but are not limited to, the following types:

[0096] Object-oriented programming languages, such as Java, Smalltalk, C++, etc.

[0097] Conventional procedural programming languages, such as "C" or similar programming languages.

[0098] The execution methods of program code include, but are not limited to:

[0099] It runs entirely on the user's computer;

[0100] Part of it executes on the user's computer, and part of it executes on a remote computer;

[0101] Execute as a standalone software package;

[0102] It is executed entirely on a remote computer or server.

[0103] In scenarios involving remote computers, the remote computer can connect to the user's computer via any type of network, including but not limited to local area networks (LANs) or wide area networks (WANs). Furthermore, the remote computer can also connect to external computers through an internet service provider, for example, by utilizing the internet for connection.

[0104] Furthermore, this application also discloses a computer-readable storage medium, wherein when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is able to perform the various steps of the VIP binding method based on a database backup disclosed in this application.

[0105] In the context of this application, a computer-readable storage medium refers to a tangible medium capable of storing computer program code and related data. Specific examples include, but are not limited to, the following:

[0106] (1) Portable computer disk: such as floppy disks and other removable magnetic storage media.

[0107] (2) Hard disk: including mechanical hard disks and solid-state hard disks and other fixed storage devices.

[0108] (3) Random Access Memory (RAM): A volatile storage medium used for temporary storage of data and program code.

[0109] (4) Read-only memory (ROM): a non-volatile storage medium used to store fixed programs and data.

[0110] (5) Erasable programmable read-only memory (EPROM) or flash memory: non-volatile storage media that supports multiple erasures and reprogrammings.

[0111] (6) Fiber optic storage devices: storage media based on fiber optic technology.

[0112] (7) Portable compact disc read-only memory (CD-ROM): a read-only medium that stores data in the form of an optical disc.

[0113] (8) Optical storage devices: such as DVDs, Blu-ray discs and other storage media based on optical principles.

[0114] (9) Magnetic storage devices: such as magnetic tapes, disks and other storage media based on magnetic principles.

[0115] (10) Any suitable combination of the above: for example, combining multiple storage media to meet different storage needs.

[0116] These computer-readable storage media can be used to store the program code and related data described in this application to support program execution and persistent data storage.

[0117] Specifically, according to embodiments of this application, the processes described in the flowcharts can be implemented as computer software programs. For example, embodiments of this application relate to a computer program product comprising a computer program carried on a non-transitory computer-readable medium. This computer program includes program code for executing the VIP binding method based on a database backup disclosed in this application. When the computer program is executed by a processing device, it can achieve the functions defined in the embodiments of this application.

[0118] While the foregoing discussion contains several specific implementation details, these details should not be construed as limiting the scope of this application. The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this application is not limited to technical solutions formed by specific combinations of the above-described technical features. Furthermore, this application should also cover other technical solutions formed by any combination of the above-described technical features or their equivalents without departing from the foregoing disclosed concept.

[0119] Those skilled in the art should also understand that modifications can be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features, without departing from the spirit and scope of the technical solutions of the embodiments of this application. These modifications or substitutions will not cause the essence of the corresponding technical solutions to deviate from the core spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A database backup-based VIP binding method applied to an openGauss database cluster, characterized in that, The method includes: S1. Maintain a standby database VIP pool, which contains a set of virtual IP addresses that are not currently held by any database instance; S2. When the cluster starts up, it enters the collection and preemption phase. The cluster management server sends the standby database VIP pool information to the cluster management agent, allowing standby databases in normal status to detect and preempt the virtual IP address in the standby database VIP pool, and configure the preempted virtual IP address to the local network card. S3. The cluster management agent detects the virtual IPs it currently holds and reports them to the cluster management server. The cluster management server arbitrates the ownership of the virtual IPs based on the reported information. Virtual IPs that have been preempted are released to the backup VIP pool by the subsequent reporting node. S4. Entering the balancing phase, only standby databases in normal status are allowed to hold virtual IPs. The cluster management server will evenly distribute the virtual IPs in the standby database VIP pool to each normal standby database, with standby databases holding fewer virtual IPs receiving priority allocation. S5. When the standby database is in an abnormal state or its role is switched to the primary database, the cluster management server arbitrates the node to release all the virtual IPs it holds to the standby database VIP pool. S6. When the cluster is shut down, each node releases all the virtual IPs it holds and reclaims them to the backup VIP pool.

2. The method of claim 1, wherein, During the collection and preemption phases and the balancing phase, the primary database is always arbitrated as not holding any standby database VIPs. If it is detected that the primary database holds standby database VIPs, the standby database VIPs it holds must be released immediately and reclaimed.

3. The method of claim 1, wherein, Step S2 also includes: Within a preset time after the cluster starts, each database instance is allowed to report the virtual IP addresses it holds, and the normal standby databases are given priority to seize the free virtual IP addresses; for conflicting virtual IP address holdings, arbitration is carried out based on the reporting order, and the instance that reports later must release the virtual IP address.

4. The method of claim 1, wherein, The collection and preemption phase in step S2 is set with a timeout period, after which the system automatically enters the balancing phase.

5. The method of claim 1, wherein, Before the cluster management agent reports in step S3, it first seizes the virtual IP in the backup database VIP pool and configures it to the local network card, refreshes the ARP cache, and then starts database listening.

6. The method of claim 1, wherein, In step S5, if the standby database status becomes abnormal due to streaming replication jitter, the virtual IP is recycled after a preset time delay to enhance system stability. The virtual IP release process continues until it succeeds or is canceled.

7. The method of claim 1, wherein, The cluster management server continuously sends virtual IP configuration commands, revocation commands, and detection commands to the cluster management agent. The cluster management agent executes the corresponding actions and reports the execution results.

8. A database standby-based VIP binding device applied to an openGauss database cluster, characterized in that, The device, when operating, implements the VIP binding method based on a database backup as described in any one of claims 1-7, and the device comprises: The VIP pool management module is used to maintain a standby VIP pool, which contains a set of virtual IP addresses that are not currently held by any database instance. The collection and preemption module is used to enter the collection and preemption phase when the cluster starts up. The cluster management server sends the standby database VIP pool information to the cluster management agent, allowing standby databases in normal status to detect and preempt the virtual IP addresses in the standby database VIP pool, and configure the preempted virtual IP addresses to the local network card. The attribution arbitration module is used by the cluster management agent to detect the currently held virtual IPs and report them to the cluster management server. The cluster management server arbitrates the attribution of the virtual IPs based on the reported information. Virtual IPs that have been preempted are released to the backup VIP pool by the subsequent reporting node. The balancing allocation module is used to enter the balancing phase. Only standby databases in normal status are allowed to hold virtual IPs. The cluster management server will evenly distribute the virtual IPs in the standby database VIP pool to each normal standby database. Standby databases with fewer virtual IPs will be given priority in allocation. The switching processing module is used to arbitrate when the standby database is in an abnormal state or its role is switched to the primary database, and the cluster management server arbitrates the node to release all the virtual IPs it holds to the standby database VIP pool. The release control module is used to ensure that each node releases all virtual IPs it holds and reclaims them to the backup VIP pool when the cluster is shut down.

9. A computer readable storage medium having stored thereon a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the VIP binding method based on the database backup as described in any one of claims 1-7.

10. An electronic device, comprising: include: Memory and processor; Memory: Used to store computer programs; Processor: for executing the computer program to implement the steps of the VIP binding method based on a database backup as described in any one of claims 1-7.

Images