Database management method, apparatus, device, medium, and program product

Abstract

Embodiments of the present application provide a database management method, device, equipment, medium and program product. The method comprises: deploying a database management system instance and a corresponding database node in a one-to-one manner on the same machine, and efficiently obtaining role state information of the on-the-same-machine node by using a local loopback address, to accurately determine a master-backup switching event, and then actively disconnect a connection with a current node when it is confirmed that a master node switches to a backup node. In this process, the local loopback communication reduces network delay and uncertainty, improves the instantaneity and accuracy of state perception, and the active disconnection mechanism cuts off the path of erroneous write operations, effectively solving the problem that the existing scheme is prone to causing business errors. The method achieves the effect of improving the high availability of the database management system itself, guaranteeing business continuity and data access correctness.

Description

Technical Field

[0001] This application relates to the field of database systems, and more particularly to a database management method, apparatus, device, medium, and program product. Background Technology

[0002] As enterprises deepen their digital transformation, the stability and continuity of database systems are crucial to business operations. Database clusters with a master-slave architecture (such as read-write separation clusters) have become the main solution to ensure high data availability.

[0003] To ensure that the upper-layer database management system can accurately and promptly detect changes in the role status of primary and backup nodes in the cluster, existing technologies typically deploy independent cluster management software (such as Pacemaker, Keepalived, etc.) as an external cluster manager. This software periodically sends network heartbeat packets to the database nodes or executes simple queries to detect node liveness. When a primary node failure is detected, the external cluster manager executes a pre-configured script to redirect the connection, thereby completing the failover.

[0004] However, existing technologies based on external managers and network layer heartbeats rely solely on sensing whether database nodes are alive to determine whether to reconnect. This makes it difficult to accurately and quickly detect the state switching of primary and backup roles within the database instance, which can easily further reduce the reliability and stability of business operations. Summary of the Invention

[0005] This application provides database management methods, apparatus, devices, media, and program products to improve the accuracy and speed of database node role status perception, thereby further enhancing the reliability and stability of business operations.

[0006] In a first aspect, embodiments of this application provide a database management method applied to a database management system instance, wherein the database management system instance and its corresponding database node are deployed on the same physical machine in a one-to-one manner, including:

[0007] By using the local loopback address, obtain the role status information of the database node deployed on the same machine, and determine whether the database node has undergone a primary / standby role switch based on the role status information.

[0008] When a switch from primary to backup node is detected, the connection with the currently deployed database node on the same machine is actively disconnected.

[0009] Optionally, a cross-physical-machine mutual monitoring link and heartbeat detection can be established between database management system instances deployed on different physical machines;

[0010] When a lack of response or abnormality is detected at the peer, a node fault alarm message is generated and output.

[0011] Optionally, the role status information of the database nodes deployed on the same machine can be obtained through the local loopback address, specifically including:

[0012] Using the local loopback address, periodically send at least one status query request to the database node deployed on the same machine;

[0013] Receive the role status information of each database node in each cycle.

[0014] Optionally, the status query request includes a system parameter query request, and also includes:

[0015] After obtaining the current system parameter values, compare the parameter values ​​with the parameter values ​​of the previous cycle;

[0016] If the current system parameter value changes from the first value representing read / write permissions in the previous cycle to the second value representing read-only permissions, a role downgrade switch from the primary node to the backup node is determined to have occurred.

[0017] Optionally, it can receive event messages actively sent by database nodes deployed on the same machine;

[0018] By parsing the event messages, the character's status information can be obtained.

[0019] Optionally, after actively disconnecting from the database node currently deployed on the same machine, a database reconnection process is triggered so that the database management system instance can connect to the database node in the database cluster that is currently in the new master node role and is deployed on another physical machine.

[0020] Secondly, embodiments of this application provide a database management device applied to a database management system instance, wherein the database management system instance and its corresponding database node are deployed on the same physical machine in a one-to-one manner, comprising:

[0021] The acquisition module is used to obtain the role status information of the database node deployed on the same machine through the local loopback address, and determine whether the database node has undergone a primary / standby role switch based on the role status information;

[0022] The processing module is used to proactively disconnect from the database node currently deployed on the same machine when it is determined that a role switch from primary node to backup node has occurred.

[0023] Optionally, the processing module is also used to establish cross-physical machine mutual monitoring links and perform heartbeat detection between database management system instances deployed on different physical machines;

[0024] When a lack of response or abnormality is detected at the peer, a node fault alarm message is generated and output.

[0025] Optionally, the acquisition module is also used to periodically send at least one status query request to the database node deployed on the same machine via the local loopback address;

[0026] Receive the role status information of each database node in each cycle.

[0027] Optionally, the status query request includes a system parameter query request, and the acquisition module is also used for...

[0028] After obtaining the current system parameter values, compare the parameter values ​​with the parameter values ​​of the previous cycle;

[0029] If the current system parameter value changes from the first value representing read / write permissions in the previous cycle to the second value representing read-only permissions, a role downgrade switch from the primary node to the backup node is determined to have occurred.

[0030] Optionally, the acquisition module is also used to receive event messages actively sent by database nodes deployed on the same machine;

[0031] By parsing the event messages, the character's status information can be obtained.

[0032] Optionally, the processing module is also used to trigger a database reconnection process after actively disconnecting from the database node currently deployed on the same machine, so that the database management system instance can connect to the database node in the database cluster that is currently in the new master node role and deployed on another physical machine.

[0033] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0034] The memory stores instructions that the computer executes;

[0035] The processor executes computer execution instructions stored in memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0036] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0037] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0038] The database management method, apparatus, device, medium, and program products provided in this application deploy the database management system instance and its corresponding database node on the same machine in a one-to-one manner. They utilize local loopback addresses to efficiently obtain the role status information of the nodes on the same machine, accurately determining master-slave switchover events. Upon confirming a switchover from master to slave node, the connection with the current node is proactively disconnected. In this process, local loopback communication reduces network latency and uncertainty, improves the immediacy and accuracy of status awareness, and the proactive disconnection mechanism cuts off the path of erroneous write operations, effectively solving the problem of business errors easily caused by existing solutions. This achieves the effect of improving the high availability of the database management system itself, ensuring business continuity, and guaranteeing the correctness of data access. Attached Figure Description

[0039] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0040] Figure 1 Flowchart of the database management method provided in this application Figure 1 ;

[0041] Figure 2 Flowchart of the database management method provided in this application Figure 2 ;

[0042] Figure 3 Flowchart of the database management method provided in this application Figure 3 ;

[0043] Figure 4 A schematic diagram of the database management device provided in this application;

[0044] Figure 5 A schematic diagram of the structure of the electronic device provided in this application.

[0045] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0046] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0047] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation portals for users to choose to authorize or refuse.

[0048] This application applies to high availability management scenarios for enterprise-level database clusters. In modern enterprise business systems, high availability (HA) of database services is a core requirement for ensuring business continuity. Especially in scenarios with extremely high requirements for data reliability and service continuity, such as finance, telecommunications, and healthcare, the master-slave failover mechanism of the database cluster directly impacts system stability and user experience. Taking a read-write separation architecture database cluster as an example, the master node handles write operations and some read operations, while the standby node maintains data synchronization with the master node through log replication and primarily handles read operations. When the master node becomes unavailable due to hardware failure, network interruption, or software anomalies (e.g., process crashes), the standby node must quickly take over the role of the master node to ensure seamless business interruption.

[0049] Existing technologies use independent cluster management software (such as Pacemaker or Keepalived) as the control center, periodically sending heartbeats to database nodes to check their liveness. When a master node failure is detected, the management software triggers virtual IP migration or notifies the application layer to reconnect via a script. Additionally, automatic reconnection is achieved through high availability parameters (such as failover and retries) in the database connection driver (such as JDBC). Specifically, after configuring all cluster node addresses at the application layer, the database connection driver attempts to connect and determines the target node based on the information returned by the node (such as the master node identifier).

[0050] However, existing technologies rely on external cluster managers for primary / standby failover detection and response mechanisms, requiring the deployment of independent third-party components. This complicates the system architecture and introduces single points of failure. Furthermore, high-availability mechanisms built into database drivers rely solely on network connectivity to determine node status, making accurate identification of primary / standby role switching difficult. This can lead to application layers mistakenly sending write requests to the standby node, causing errors. Additionally, existing technologies suffer from high latency in fault detection and fail to meet users' business requirements for fault response.

[0051] The database management method provided in this application is applied to a database management system instance, where the database management system instance and its corresponding database nodes are deployed on the same physical machine in a one-to-one manner. By using a local loopback address, the method obtains the role status information of the database nodes deployed on the same machine, and determines whether a primary / standby role switch has occurred based on this information. When a primary-to-standby role switch is determined, the method proactively disconnects from the currently deployed database nodes on the same machine. In this process, local loopback communication reduces network latency and uncertainty, improves the immediacy and accuracy of status awareness, and the proactive disconnection mechanism cuts off the path of erroneous write operations, effectively solving the problem that existing solutions easily lead to business errors. This achieves the effect of improving the high availability of the database management system itself, ensuring business continuity, and guaranteeing the correctness of data access.

[0052] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0053] Figure 1 Flowchart of the database management method provided in this application Figure 1 ,like Figure 1 As shown, the method includes:

[0054] S101. Deploy the database management system instance and the corresponding database node on the same physical machine in a one-to-one manner.

[0055] More specifically, a database node and a corresponding database management system instance are deployed on each physical machine in the database cluster environment.

[0056] In one possible embodiment, Figure 2 Flowchart of the database management method provided in this application Figure 2 ,like Figure 2 As shown, to achieve high availability for the database management system (e.g., KMCC), a cluster environment consisting of three independent physical machines (e.g., servers) was constructed. On server 1, the master database node of the database cluster and a dedicated database management system instance for managing that master database node are deployed. Figure 2 The primary KEMCC instance (KEMCC is used in this application to instruct the database management system) forms a one-to-one binding relationship with the primary instance. Similarly, backup database nodes (i.e., ...) of the database cluster are deployed on server 2 and server 3 respectively. Figure 2 The backup database node 1 and backup database node 2) and their respective management instances (i.e. Figure 2(KEMCC standby instance 1 and KEMCC standby instance 2). This embodiment achieves a lightweight, accurate state awareness, and fast response physical architecture foundation through a one-to-one deployment mode of one physical machine, one node, and one instance.

[0057] S102. For each database management system instance, obtain the role status information of the database nodes deployed on the same machine through the local loopback address, and determine whether the database node has undergone a primary / standby role switch based on the role status information.

[0058] More specifically, the role status information of the database nodes deployed on the same machine is obtained through the local loopback address, which includes: periodically sending at least one status query request to the database nodes deployed on the same machine through the local loopback address; and receiving the role status information of the database nodes in each period.

[0059] Optionally, the aforementioned status query request aims to obtain information reflecting the internal service role of the database node. For example, in one implementation, the status query request can be a query of system parameters (such as the `transaction_read_only` parameter) in the database kernel that characterize the read / write permissions of the current session. Here, `transaction_read_only` is a database system parameter used to set whether the current session or transaction is in read-only mode; when this parameter is set to "on", it indicates that the database instance is in the standby node role. In another implementation, it can also be determined by calling a specific system function (such as `pg_is_in_recovery()`) or querying a specific system view to determine whether the database node is in the role of a primary node (i.e., read / write) or a standby node (i.e., read-only).

[0060] In one possible embodiment, such as Figure 2 As shown, taking the KEMCC master instance deployed on server 1 as an example, this master instance periodically sends a request to the master database corresponding to the master database node deployed on the same machine via its local loopback address (127.0.0.1: port) to query the value of the `transaction_read_only` parameter. After processing the request, the master database returns the processing result (e.g., the first value: "off") to the master instance. The master instance then continuously obtains the real-time role status information of its corresponding node by receiving and parsing this periodically returned result. The local loopback address 127.0.0.1 is used for inter-process network communication on the same computer; data does not pass through physical network devices, thus resulting in high communication efficiency and stability.

[0061] This embodiment establishes a highly efficient state awareness channel from the database management system to the database itself, independent of the business network, by utilizing the local loopback address for periodic internal queries. This avoids interference from external network jitter or firewall policies, enabling stable and rapid acquisition of state information with low resource overhead, providing a reliable data source for subsequent accurate judgments.

[0062] Optionally, the status query request includes a system parameter query request. After obtaining the parameter value of the current system parameter, the parameter value is compared with the parameter value of the previous period. If the parameter value of the current system parameter changes from the first value representing read / write permission in the previous period to the second value representing read-only permission, it is determined that a role downgrade switch from the primary node to the backup node has occurred.

[0063] In one possible embodiment, such as Figure 2 As shown, taking the KEMCC master instance deployed on server 1 as an example, the transaction_read_only parameter value obtained by the KEMCC master instance in the previous query cycle (T1) was "off" (the first value, indicating read-write capability, i.e., master node status). In the current query cycle (T2), the parameter value is queried and obtained as "on" (the second value, indicating read-only capability, i.e., standby node status). By comparing the parameter value in query cycle T2 with that in query cycle T1, it is determined that the database node deployed on the same machine has been downgraded from a master node to a standby node, i.e., a master-standby role switch has occurred.

[0064] This embodiment achieves rapid and accurate perception of node role changes by directly querying and comparing system parameters maintained by the database kernel itself. Compared to existing technologies that only detect whether a node is alive, this embodiment can accurately identify whether a node is still in the core state of a master node, avoiding misjudgments caused by a node process still running but having lost its main service capabilities, thus improving the accuracy of fault identification.

[0065] Optionally, the method for obtaining the role status information of database nodes deployed on the same machine further includes: receiving event messages actively sent by database nodes deployed on the same machine; and obtaining role status information by parsing the event messages.

[0066] In one possible implementation, if the database cluster (e.g., Kims database) itself provides event publishing functionality for role state changes, then when Figure 2 When the primary database node in the system needs to relinquish its primary role due to a failure (e.g., manual operation by an administrator), it proactively sends a structured event notification message to the primary instance deployed on the same machine via its local loopback address. When the primary instance receives this event notification message, it parses the message to determine that the corresponding primary database node has become a standby node, at which point there is no need to perform periodic queries.

[0067] This embodiment employs an event-driven mechanism, enabling the receipt of event notifications the instant the role of a database node changes. This improves the real-time nature of state awareness, reduces response latency, and further reduces the potential overhead of state queries on the database.

[0068] Optionally, a cross-physical-machine mutual monitoring link is established and heartbeat detection is performed between database management system instances deployed on different physical machines; when no response or abnormality is detected at the other end, node fault alarm information is generated and output.

[0069] In one possible embodiment, such as Figure 2 The deployment relationship shown indicates that the KEMCC primary instance, KEMCC backup instance 1, and KEMCC backup instance 2 establish mutual monitoring links through the business network between servers. For example, the KEMCC primary instance and KEMCC backup instance 1, as well as the KEMCC primary instance and KEMCC backup instance 2, periodically send heartbeat data packets to each other.

[0070] For example, if a power outage on server 1 causes both the KEMCC primary instance and the primary database node to become unresponsive, KEMCC backup instance 1 and KEMCC backup instance 2 will immediately detect the link interruption with the KEMCC primary instance in their respective heartbeat checks. At this time, the KEMCC primary instance triggers the alarm module, generating alarm information (e.g., server 1 node failure and loss of connection) and sending it to the operations and maintenance platform. Simultaneously, the new primary node (e.g., backup instance 1 detects that the transaction_read_only parameter value of the original backup database node 1 has changed from on to off) and the corresponding management system instance deployed on the same machine begin to receive write requests.

[0071] Optionally, when the primary instance queries the local transaction_read_only parameter value and finds it has changed from off to on, it determines that a primary / standby failover has occurred on the local node.

[0072] This embodiment effectively compensates for potential failure scenarios that might be missed by relying solely on local parameter queries (such as physical machine downtime, split-brain due to cross-node network partitioning, etc.). It can promptly issue alarms to operations and maintenance personnel when a systemic failure occurs on any node (primary node and / or backup node). This ensures that even if the local detection mechanism successfully completes the service switchover, the alarm information can still notify users to promptly repair the failed database node, thereby restoring the system's original high availability and preventing further failures of remaining nodes from reducing the continuity and stability of business operations.

[0073] S103. When it is determined that a switch from primary node to backup node has occurred, actively disconnect the connection with the database node currently deployed on the same machine.

[0074] More specifically, when a database management system instance determines that its corresponding database node has been downgraded to a standby node, it proactively closes all database connection sessions with that node to immediately stop sending subsequent write operation requests to the node that has become read-only, thereby proactively avoiding potential batch business errors at the application layer.

[0075] Optionally, after actively disconnecting from the database node currently deployed on the same machine, a database reconnection process is triggered so that the database management system instance can connect to the database node in the database cluster that is currently in the new master node role and is deployed on another physical machine.

[0076] In one possible implementation, after the KEMCC primary instance actively disconnects from the database node deployed on the same machine (which is now the backup node), its connection pool or driver immediately attempts to initiate a new database reconnection request. Since the cluster is typically configured with virtual IPs or intelligent routing mechanisms, this database reconnection request will be automatically redirected to the new primary node in the database cluster, thereby quickly restoring normal database services.

[0077] This embodiment combines an active disconnection mechanism with a database reconnection mechanism. By disconnecting old connections to avoid business errors, and by utilizing the service discovery and routing capabilities of the database cluster for reconnection, it improves service recovery speed.

[0078] Figure 3 Flowchart of the database management method provided in this application Figure 3 ,like Figure 3 As shown, in this embodiment... Figure 1 Based on the embodiments, the database management method is described in detail. This method includes: after the start of a query cycle, a database management system instance initiates a status query to the database node deployed on the same machine via its local loopback address to obtain the `transaction_read_only` system parameter value of that database node. The obtained parameter value is then judged to determine whether it is the first value (i.e., "off"). If it is the first value, the current database node is determined to be the primary node, and the instance enters the primary node execution process: monitoring the health status (i.e., heartbeat response) of each backup node in the database cluster. If it is not the first value, the current node is determined to be a backup node, and the instance enters the backup node execution process: monitoring the health status of the primary node in the database cluster. During the monitoring process, each database management system instance periodically sends heartbeat messages to the monitored peer instance through this monitoring link and monitors the heartbeat response returned by the peer.

[0079] Optionally, if no heartbeat response is received from the peer within a preset time, the peer instance and its co-located database nodes are deemed to be in an abnormal state. An alarm module is then triggered to generate an alarm message, which is sent to the operations and maintenance platform. Simultaneously with the above steps, it is determined whether the value of the `transaction_read_only` system parameter has changed from `off` to `on`. If this change does not occur, the database connection with the current node is maintained, and the system waits for the next monitoring cycle. If the parameter value changes from `off` to `on`, it is determined that the current co-located database node has been downgraded from a primary node to a backup node, and the primary / backup role has switched. At this point, the database connection with the current database node (the original primary node) is actively disconnected, and a high-availability connection redirection mechanism is triggered.

[0080] The database management method provided in this application deploys the database management system instance and database nodes on the same physical machine in a one-to-one manner, and obtains the role status information inside the node through a physically isolated and efficient local loopback communication channel. This eliminates network jitter and external interference, improves the efficiency and accuracy of status awareness, and avoids the risk of single point of failure of third-party components. By actively disconnecting the connection of degraded nodes, it achieves the prevention of batch errors caused by accidental write operations to read-only backup nodes at the business layer, thereby improving the availability of the system.

[0081] Figure 4 This is a schematic diagram of the database management device provided in this application, applied to a database management system instance. The database management system instance and its corresponding database node are deployed on the same physical machine in a one-to-one manner, such as... Figure 4 As shown, the database management device 40 provided in this embodiment includes:

[0082] The acquisition module 401 is used to obtain the role status information of the database node deployed on the same machine through the local loopback address, and determine whether the database node has undergone a primary / standby role switch based on the role status information.

[0083] The processing module 402 is used to actively disconnect the connection with the database node currently deployed on the same machine when it is determined that a role switch from primary node to backup node has occurred.

[0084] Optionally, the processing module 402 is also used to establish a cross-physical machine mutual monitoring link and perform heartbeat detection between database management system instances deployed on different physical machines;

[0085] When a lack of response or abnormality is detected at the peer, a node fault alarm message is generated and output.

[0086] Optionally, the acquisition module 401 is also used to periodically send at least one status query request to the database node deployed on the same machine via the local loopback address;

[0087] Receive the role status information of each database node in each cycle.

[0088] Optionally, the status query request includes a system parameter query request. The acquisition module 401 is also used to compare the parameter value with the parameter value of the previous period after obtaining the parameter value of the current system parameter.

[0089] If the current system parameter value changes from the first value representing read / write permissions in the previous cycle to the second value representing read-only permissions, a role downgrade switch from the primary node to the backup node is determined to have occurred.

[0090] Optionally, the acquisition module 401 is also used to receive event messages actively sent by database nodes deployed on the same machine;

[0091] By parsing the event messages, the character's status information can be obtained.

[0092] Optionally, the processing module 402 is also used to trigger a database reconnection process after actively disconnecting from the database node currently deployed on the same machine, so that the database management system instance can connect to the database node in the database cluster that is currently in the new master node role and is deployed on another physical machine.

[0093] The database management device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0094] Figure 5 A schematic diagram of the structure of the electronic device provided in this application. Figure 5 As shown, the electronic device 50 provided in this embodiment includes at least one processor 501 and a memory 502. Optionally, the device 50 further includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus 504.

[0095] In a specific implementation, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to perform the above-described method.

[0096] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0097] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0098] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0099] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0100] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0101] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0102] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0103] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0104] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0105] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0106] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0107] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0108] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0109] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A database management method, characterized in that, The method is applied to a database management system instance, wherein the database management system instance and its corresponding database node are deployed on the same physical machine in a one-to-one manner; the method includes: By using the local loopback address, obtain the role status information of the database node deployed on the same machine, and determine whether the database node has undergone a primary / standby role switch based on the role status information. When a switch from primary to backup node is detected, the connection with the currently deployed database node on the same machine is actively disconnected.

2. The method according to claim 1, characterized in that, Also includes: Establish cross-physical-machine mutual monitoring links and perform heartbeat detection between database management system instances deployed on different physical machines; When a lack of response or abnormality is detected at the peer, a node fault alarm message is generated and output.

3. The method according to claim 1, characterized in that, The role status information of the database node deployed on the same machine is obtained through the local loopback address, specifically including: At least one status query request is periodically sent to the database node deployed on the same machine via the local loopback address; Receive the role status information of the database node for each cycle.

4. The method according to claim 3, characterized in that, The status query request includes a system parameter query request; it also includes: After obtaining the current system parameter values, compare the parameter values ​​with the parameter values ​​of the previous cycle; If the current system parameter value changes from the first value representing read / write permissions in the previous cycle to the second value representing read-only permissions, a role downgrade switch from the primary node to the backup node is determined to have occurred.

5. The method according to claim 3, characterized in that, Also includes: Receive event messages actively sent by database nodes deployed on the same machine; The role status information is obtained by parsing the event message.

6. The method according to claim 1, characterized in that, Also includes: After actively disconnecting from the database node currently deployed on the same machine, a database reconnection process is triggered so that the database management system instance can connect to the database node in the database cluster that is currently in the new master node role and deployed on another physical machine.

7. A database management device, characterized in that, This applies to database management system instances, where the database management system instance and its corresponding database node are deployed on the same physical machine in a one-to-one manner, including: The acquisition module is used to obtain the role status information of the database node deployed on the same machine through the local loopback address, and determine whether the database node has undergone a primary / standby role switch based on the role status information; The processing module is used to proactively disconnect from the database node currently deployed on the same machine when it is determined that a role switch from primary node to backup node has occurred.

8. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-6.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-6.

Images