Database cluster architecture processing method, apparatus, device, and storage medium
By decoupling the implementation logic of the database cluster architecture from the core framework and using dynamic libraries and standardized interfaces, high availability of the database cluster architecture is achieved, solving the problems of high maintenance costs and low flexibility caused by complex adaptation in existing technologies.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CETC JINCANG (BEIJING) TECH CO LTD
- Filing Date
- 2026-01-23
- Publication Date
- 2026-05-29
AI Technical Summary
Existing database cluster architectures require complex adaptations for different architectures during deployment and maintenance, resulting in high operation and maintenance costs and high technical barriers, which affects high availability.
By defining standardized architecture interfaces, implementations of different architectures are encapsulated as dynamic libraries, and relevant modules are loaded on demand at runtime using a dynamic loading mechanism, enabling unified deployment and dynamic switching of database cluster architectures, and supporting seamless switching between multiple high-availability architectures.
It reduces maintenance costs, improves the flexibility and availability of the database cluster architecture, and ensures high availability of the database cluster architecture, making it suitable for dynamic high availability requirements in enterprise-level database clusters.
Smart Images
Figure CN122111978A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of database technology, and in particular to a database cluster architecture processing method, apparatus, device and storage medium. Background Technology
[0002] High availability is a core requirement for ensuring business continuity in database clusters. Database clusters typically need to support dynamic scaling and flexible switching of database cluster architecture to adapt to changes in business load.
[0003] In related technologies, different database cluster architectures often require independent binary files and configuration files, which leads to complex adaptations for different database cluster architectures during deployment and maintenance, increasing operation and maintenance costs and technical barriers, and affecting the high availability of the database cluster architecture. Summary of the Invention
[0004] This application provides a database cluster architecture processing method, apparatus, device, and storage medium to achieve high availability of the database cluster architecture.
[0005] In a first aspect, this application provides a database cluster architecture processing method, comprising: loading a dynamic library corresponding to the first database cluster architecture according to a first processing request for the first database cluster architecture, wherein the first processing request includes creating or deleting the first database cluster architecture; if the first processing request is to create the first database cluster architecture, calling an interface for initialization and node registration in the architecture interface from the dynamic library to obtain the first database cluster architecture providing data read and write services; if the first processing request is to delete the first database cluster architecture, calling an interface for deinitialization and node deregistration in the architecture interface from the dynamic library to delete the first database cluster architecture and release the resources of the first database cluster architecture.
[0006] In one possible embodiment, before loading the dynamic library corresponding to the first database cluster architecture, the method further includes: according to a second processing request for the first database cluster architecture, if the second processing request indicates the addition of a new first database cluster architecture, adding an architecture interface corresponding to the first database cluster architecture and encapsulating the architecture interface of the first database cluster architecture into the newly added dynamic library corresponding to the first database cluster architecture.
[0007] In one possible embodiment, before adding the architecture interface corresponding to the first database cluster architecture and encapsulating the architecture interface of the first database cluster architecture into the newly added dynamic library corresponding to the first database cluster architecture, the method further includes: calling the architecture configuration interface according to the configuration request for the first database cluster architecture and configuring the architecture type and dynamic library path of the first database cluster architecture based on the architecture configuration interface.
[0008] In one possible embodiment, after adding an architecture interface corresponding to the first database cluster architecture and encapsulating the architecture interface of the first database cluster architecture into a newly added dynamic library corresponding to the first database cluster architecture, the method further includes: if a second processing request indicates modification of the first database cluster architecture, performing at least one of the following according to the second processing request: modifying the architecture interface of the first database cluster architecture and re-encapsulating the modified architecture interface into the corresponding dynamic library; modifying the architecture type and / or dynamic library path of the first database cluster architecture by calling the architecture configuration interface.
[0009] In one possible embodiment, the method is applied to a target node, and the architecture interface further includes: an interface for obtaining information about each node in the database cluster architecture where the target node resides; an interface for determining whether the target node is a majority in the database cluster architecture; and an interface for obtaining information about the master node in the database cluster architecture where the target node resides. The method further includes: according to a first processing request or a second processing request, performing at least one of the following through the architecture interface: obtaining information about each node in the database cluster architecture where the target node resides; determining whether the target node is a majority in the database cluster architecture; and obtaining information about the master node in the database cluster architecture where the target node resides.
[0010] In one possible embodiment, the method further includes: based on a third processing request for the first database cluster architecture, if the third processing request indicates a switch of the master node of the database cluster architecture where the target node is located, determining the master node after the switch by using the metadata of the database cluster architecture where the target node is located and by calling an interface for determining whether the target node is the majority in the database cluster architecture; triggering the master node switch through the node state machine; and updating the metadata after the master node switch is completed.
[0011] In one possible embodiment, the method further includes: when a third processing request indicates that the master node of the database cluster architecture where the target node is located be restored, determining the master node to be restored through the metadata of the database cluster architecture where the target node is located; triggering the master node restoration through the node state machine; and updating the metadata after the master node restoration is completed.
[0012] Secondly, this application provides a database cluster architecture processing apparatus, comprising: a loading module, configured to load a dynamic library corresponding to a first database cluster architecture according to a first processing request for a first database cluster architecture, the first processing request including creating or deleting the first database cluster architecture; a processing module, configured to, when the first processing request is to create the first database cluster architecture, call interfaces for initialization and node registration in the architecture interface from the dynamic library to obtain a first database cluster architecture providing data read and write services; the processing module is further configured to, when the first processing request is to delete the first database cluster architecture, call interfaces for deinitialization and node deregistration in the architecture interface from the dynamic library to delete the first database cluster architecture and release the resources of the first database cluster architecture.
[0013] Thirdly, this application provides an electronic device, including: a processor and a memory communicatively connected to the processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory to implement the method as described in any of the first aspects.
[0014] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any of the first aspects.
[0015] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the method of any one of the first aspects.
[0016] In this embodiment, each database cluster architecture corresponds to its own dynamic library. The dynamic library encapsulates an architecture interface, which includes various interfaces for implementing request processing functions. This allows each database cluster architecture to perform architecture logic processing through a unified architecture interface, thereby achieving high availability of the database cluster architecture. Furthermore, the architecture logic processing offers greater flexibility and scalability, as well as lower maintenance costs.
[0017] Each database cluster architecture's dynamic libraries can be developed and maintained independently, eliminating the need to develop and maintain the entire database cluster architecture. Therefore, the maintenance cost of each database cluster's dynamic libraries is lower, while offering greater flexibility and scalability. Furthermore, during the core processing of the database cluster, such as read and write operations performed by the core engine, there's no need to focus on the architectural logic, resulting in a lower technical barrier and a wider range of application scenarios. Additionally, each database cluster architecture corresponds to its own independent dynamic libraries, meaning that a failure in one database cluster architecture will not affect others. This achieves fault isolation and ensures the overall availability of multiple database cluster architectures.
[0018] In summary, the database cluster architecture processing method of this application embodiment can achieve high availability.
[0019] For example, for any database cluster architecture (e.g., the first database cluster architecture), the creation and deletion of the first database cluster architecture can be supported by loading the corresponding dynamic library and calling the relevant architecture interface. Attached Figure Description
[0020] 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.
[0021] Figure 1 This is a schematic diagram of the system architecture of the database cluster architecture processing method according to an embodiment of this application;
[0022] Figure 2 This is a flowchart of a database cluster architecture processing method according to an embodiment of this application;
[0023] Figure 3 This is a schematic diagram illustrating the process of creating a first database cluster architecture according to an embodiment of this application;
[0024] Figure 4 This is a schematic diagram illustrating the process of deleting the first database cluster architecture according to an embodiment of this application;
[0025] Figure 5 This is a schematic diagram of a database cluster architecture processing device according to an embodiment of this application;
[0026] Figure 6 This is a schematic diagram of an electronic device according to an embodiment of this application.
[0027] 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
[0028] 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.
[0029] The technical terms used in the embodiments of this application will be explained below.
[0030] Recovery Time Objective (RTO): The longest acceptable time to restore service after a database cluster failure.
[0031] Recovery Point Objective (RPO): The maximum acceptable amount of data loss within a given timeframe after a database cluster failure.
[0032] Network partitioning (split-brain): When the network between some nodes in a database cluster is interrupted, multiple independent small clusters are formed, each of which provides services to the outside world as an effective cluster.
[0033] Data consistency: The datasets of all nodes in the database cluster are kept synchronized, conflict-free, redundant, and without missing data.
[0034] High availability: A measure of a database cluster's ability to continuously provide services within a specified time period.
[0035] A dynamic library (DLL) is a collection of reusable binary code modules and data that have been compiled and assembled by a compiler. DLLs are stored as independent files and are not directly embedded in the application's executable file. Instead, they are dynamically loaded into memory and linked by the operating system at runtime, allowing the application to call their exposed interfaces.
[0036] In related technologies, one of several architectures is typically adopted, such as read-write separation architecture, multi-center architecture, or real-time application cluster architecture.
[0037] Read-Write Cluster (RWC) architecture consists of one master node and N slave nodes, where N is an integer greater than or equal to 1. The master node performs write services and synchronizes the transaction log, while the slave nodes synchronize data with the master node through physical / logical replication and perform read services. Virtual IP failover and split-brain detection are used to switch slave nodes to become the master node in case of master node failure. The RTO of a read-write cluster architecture is typically in the minutes range, and the RPO approaches zero. Network partitioning in a read-write cluster architecture relies on arbitration mechanisms such as shared locks / quorum voting to ensure the integrity of a single master node, while data consistency relies on ordered log synchronization and breakpoint resumption.
[0038] Multi-center architecture: This includes multiple central nodes located in different locations. Each central node achieves cross-regional data synchronization through asynchronous / semi-synchronous replication. The RTO of this multi-center architecture reaches the second level, and the RPO reaches the second level (semi-synchronous) or the minute level (asynchronous). In the event of a failure in any central node, a rapid switchover to a backup central node is possible. Network partitioning relies on a cross-center arbitration cluster and data verification. Data consistency supports eventual consistency or strong consistency synchronization protocols. Multi-center architectures include two-place three-center cluster (TPTC) architectures.
[0039] Real Application Clusters (RAC) architecture: Employs a shared storage and multi-node redundancy model, where all nodes share storage devices and heartbeat detection and resource synchronization are achieved through a private high-speed network. All nodes can perform read and write services with no data replication latency. The RAC architecture achieves an RTO of less than a second and an RPO of 0. Network partitioning relies on a node voting mechanism to avoid split-brain scenarios. Data consistency depends on atomic operations on shared storage and real-time heartbeat synchronization.
[0040] Taking the three database cluster architectures mentioned above as examples, each architecture has its own independent binary file and configuration file. The binary file is a machine language executable file generated after the source code is compiled, assembled, and linked.
[0041] The three cluster architectures are based on independent binary files. When business scenarios change, it is necessary to uninstall the old architecture's binary files, clean up the corresponding configuration files, recompile / install the new architecture's binary files, configure the new architecture's parameters, and complete data migration, which lacks flexibility. In addition, the above process causes long-term service interruptions, resulting in RTO exceeding the preset range and posing a risk to data consistency.
[0042] The three cluster architectures are based on independent configuration files, which leads to problems such as inconsistent naming of configuration items, significant differences in parameter meanings and value ranges, and inconsistent cluster management commands. Users need to maintain configuration files for each of the three architectures; otherwise, cluster failures are highly likely, making it difficult to achieve high availability and resulting in high maintenance costs.
[0043] Furthermore, adding a new database cluster architecture requires modifying the core framework code, resulting in a long development cycle and potential compatibility issues. Implementing multiple independent database cluster architectures leads to code redundancy, increasing resource consumption and maintenance workload.
[0044] Based on this, this application proposes a database cluster architecture processing method, apparatus, device, and storage medium. Through interface abstraction and dynamic loading technology, the implementation logic of a highly available database cluster architecture is decoupled from the core framework, thereby achieving unified deployment, dynamic switching, and flexible expansion of the database cluster architecture. Specifically, by defining standardized architecture interfaces, the implementations of different architectures are encapsulated as dynamic libraries, and a dynamic loading mechanism is used to load relevant modules on demand at runtime. This allows the same set of binary packages and configuration files to adapt to multiple high-availability architectures. Users can switch and expand the database cluster architecture without modifying the core framework code, significantly reducing maintenance costs and improving the flexibility of the database cluster architecture, thus ensuring high availability of the database cluster architecture.
[0045] This application's embodiments can be applied to scenarios with dynamic high availability requirements in enterprise-level database clusters. For example, in the core transaction systems of the financial industry, businesses may need to dynamically switch read-write separation architectures based on real-time load to optimize performance, or switch to a multi-center architecture to ensure disaster recovery capabilities in the event of a disaster. Furthermore, distributed database clusters in the telecommunications industry may need to dynamically adjust their architecture strategies based on network partitioning. This application's embodiments support seamless switching across architectures, are suitable for scenarios requiring flexible deployment and rapid response to business changes, and are compatible with various high-availability database cluster architectures.
[0046] Figure 1 This is a schematic diagram of the system architecture of the database cluster architecture processing method according to an embodiment of this application.
[0047] like Figure 1 As shown, the system architecture includes terminal device 1 and server cluster 2. Server cluster 2 consists of n servers, where n is an integer greater than or equal to 2. Each server can be understood as a node. A database cluster is deployed on server cluster 2 in a related architecture, consisting of m databases, where m is an integer greater than or equal to 2.
[0048] For example, a user initiates a processing request through a terminal device. This processing request includes at least one of the following: a first processing request, a second processing request, a third processing request, and a configuration request. After the processing request is sent to any node in the server cluster 2, the corresponding node executes the database cluster architecture processing method of this application embodiment.
[0049] The technical solution of this application and how it solves the above-mentioned technical problems will be 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 be described below with reference to the accompanying drawings.
[0050] Figure 2 This is a flowchart of a database cluster architecture processing method according to an embodiment of this application.
[0051] like Figure 2 As shown, the database cluster architecture processing method of this application embodiment includes steps S110 to S130.
[0052] S110. Based on the first processing request for the first database cluster architecture, load the dynamic library corresponding to the first database cluster architecture.
[0053] For example, loading a dynamic library is achieved through the Dynamic Linking Open (dlopen) function.
[0054] The first database cluster architecture can be understood as the database cluster architecture specified by the request to be processed. The following will use database cluster architectures including Read-Write Cluster (RWC), Two-Site Three-Center Cluster (TPTC), and Real-Time Application Cluster (RAC) as examples. The first database cluster architecture can be at least one of RWC, TPTC, and RAC.
[0055] The first processing request includes creating or deleting the first database cluster architecture.
[0056] Creating a primary database cluster architecture refers to implementing an existing primary database cluster architecture as a directly runnable instance or function to provide data read and write services.
[0057] Deleting the first database cluster architecture refers to removing an existing instance or function of the first database cluster architecture.
[0058] S120. If the first processing request is to create a first database cluster architecture, call the interface in the architecture interface used for initialization and node registration from the dynamic library to obtain the first database cluster architecture that provides data read and write services.
[0059] Initialization is used to request resources for the first database cluster architecture to run, parse configuration parameters related to the first database cluster architecture, and start the first database cluster architecture.
[0060] Node registration is used to register the information of each node in the first database cluster architecture to the master node or the metadata storage module of the first database cluster architecture.
[0061] S130. If the first processing request is to delete the first database cluster architecture, call the interface for deinitialization and node deregistration from the dynamic library to delete the first database cluster architecture and release the resources of the first database cluster architecture.
[0062] Deinitialization is used to stop the first database cluster architecture from providing read and write services to the outside world and to disconnect the first database cluster architecture.
[0063] Node deregistration is used to remove the cluster node status of each node in the first database cluster architecture.
[0064] In this embodiment, each database cluster architecture corresponds to its own dynamic library. The dynamic library encapsulates an architecture interface, which includes various interfaces for implementing request processing functions. This allows each database cluster architecture to perform architecture logic processing through a unified architecture interface, thereby achieving high availability of the database cluster architecture. Furthermore, the architecture logic processing offers greater flexibility and scalability, as well as lower maintenance costs.
[0065] Specifically, architectural logic processing can be understood as logic processing related to the architecture, such as architecture creation, architecture deletion, and, as mentioned below, architecture modification and architecture addition. In this embodiment, the functions required for architectural logic processing are encapsulated through the architecture interface of a dynamic library, which decouples architectural logic processing from core processing. The core processing is not affected by architectural logic processing, thus ensuring the continuous availability of core processing.
[0066] For example, core processing may include read and write operations, which can be implemented using binary files. That is, different database cluster architectures can reuse the same binary files to support their core processing. For different database cluster architectures, only the corresponding dynamic libraries need to be loaded.
[0067] Each database cluster architecture's dynamic libraries can be developed and maintained independently, eliminating the need to develop and maintain the entire database cluster architecture. Therefore, the maintenance cost of dynamic libraries for each database cluster architecture is lower, while offering greater flexibility and scalability. Furthermore, during the core processing of the database cluster, such as read and write operations performed by the core engine, there is no need to focus on the architectural logic, resulting in a lower technical barrier and a wider range of application scenarios.
[0068] In addition, each database cluster architecture corresponds to its own independent dynamic library, so the failure of any one database cluster architecture will not affect other database cluster architectures. This enables fault isolation and ensures the overall availability of multiple database cluster architectures.
[0069] In summary, the database cluster architecture processing method of this application embodiment can achieve high availability.
[0070] For example, for any database cluster architecture (e.g., the first database cluster architecture), the creation and deletion of the first database cluster architecture can be supported by loading the corresponding dynamic library and calling the relevant architecture interface.
[0071] Figure 3This is a schematic diagram illustrating the process of creating a first database cluster architecture according to an embodiment of this application.
[0072] like Figure 3 As shown, creating the first database cluster architecture includes steps S201 to S205.
[0073] S201. Determine the architecture type of the first database cluster architecture.
[0074] S202 includes steps S202-1 to S202-3.
[0075] S202-1. When the architecture type of the first database cluster is RAC, load the dynamic library corresponding to RAC.
[0076] S202-2. When the architecture type of the first database cluster is RWC, load the dynamic library corresponding to RWC.
[0077] S202-2. When the architecture type of the first database cluster is TPTC, load the dynamic library corresponding to TPTC.
[0078] S203, Call the interface used for initialization in the architecture interface.
[0079] S204. Call the interface used for node registration in the architecture interface.
[0080] S205, Start the service.
[0081] This service can be the data read and write service provided to the outside world by the first database cluster architecture.
[0082] Figure 4 This is a schematic diagram illustrating the process of deleting the first database cluster architecture according to an embodiment of this application.
[0083] like Figure 4 As shown, deleting the first database cluster architecture includes steps S301 to S305.
[0084] S301. Determine the architecture type of the first database cluster architecture.
[0085] S302 includes steps S302-1 to S302-3.
[0086] S302-1. When the architecture type of the first database cluster is RAC, load the dynamic library corresponding to RAC.
[0087] S302-2. When the architecture type of the first database cluster is RWC, load the dynamic library corresponding to RWC.
[0088] S302-2. When the architecture type of the first database cluster is TPTC, load the dynamic library corresponding to TPTC.
[0089] S303, Call the interface used for deinitialization in the architecture interface.
[0090] S304. Call the interface in the architecture interface used for node deregistration.
[0091] S305, Service terminated.
[0092] In addition to handling existing first database cluster architectures, such as creating or deleting them, there is also a need to add new, non-existent first database cluster architectures. This can be understood as the absence of a dynamically allocated library for a previously developed first database cluster architecture.
[0093] like Figure 2 As shown, for the newly added first database cluster architecture, in one possible embodiment, before step S110, the database cluster architecture processing method further includes step S140.
[0094] S140. Based on the second processing request for the first database cluster architecture, if the second processing request indicates the addition of a new first database cluster architecture, add an architecture interface corresponding to the first database cluster architecture and encapsulate the architecture interface of the first database cluster architecture into the newly added dynamic library corresponding to the first database cluster architecture.
[0095] For example, the architecture interface of the first database cluster architecture can be developed by the user, and the developed architecture interface of the first database cluster architecture can be obtained to implement the architecture interface corresponding to the newly added first database cluster architecture.
[0096] It should be noted that after the addition of the dynamic library of the first database cluster architecture in the embodiments of this application, it indicates that the first database cluster architecture already exists, and subsequent processing such as creation, deletion and modification of the first database cluster architecture can be performed.
[0097] In this embodiment of the application, the first database cluster architecture can be extended by adding an architecture interface corresponding to the first database cluster architecture and encapsulating the architecture interface of the first database cluster architecture into a newly added dynamic library corresponding to the first database cluster architecture. The architecture processing logic of the first database cluster architecture is encapsulated in the newly added dynamic library, which does not affect the normal operation of other database cluster architectures.
[0098] like Figure 2 As shown, in one possible embodiment, before step S140, the database cluster architecture processing method further includes step S150.
[0099] S150. Based on the configuration request for the first database cluster architecture, call the architecture configuration interface and configure the architecture type and dynamic library path of the first database cluster architecture based on the architecture configuration interface.
[0100] Taking RWC, TPTC, and RAC as examples again, the architecture type is used to indicate one of RWC, TPTC, and RAC.
[0101] The dynamic library path is used to locate dynamic libraries. The dynamic library path can be represented by a storage address or a storage identifier.
[0102] In this embodiment, before creating, deleting, adding, or subsequently modifying the first database cluster architecture, the architecture type and dynamic library path of the first database cluster architecture can be configured by calling the architecture configuration interface and configuring it. Specifically, this involves configuring the architecture type and dynamic library path. This ensures that the dynamic library of the first database cluster architecture can be successfully loaded when creating, deleting, adding, or subsequently modifying the first database cluster architecture.
[0103] Furthermore, by configuring the architecture type of the first database cluster architecture, the execution boundaries of its architecture processing logic can be constrained. For example, different architecture types have different processing logic for their corresponding architecture interfaces. Each database cluster architecture must adapt to the processing logic of its corresponding architecture interface in order to successfully execute the architecture processing logic.
[0104] like Figure 2 As shown, in one possible embodiment, after step S140, the database cluster architecture processing method further includes: if the second processing request indicates modification of the first database cluster architecture, performing at least one of the following according to the second processing request: modifying the architecture interface of the first database cluster architecture and re-encapsulating the modified architecture interface into the corresponding dynamic library; modifying the architecture type and / or dynamic library path corresponding to the first database cluster by calling the architecture configuration interface.
[0105] It should be noted that modifications to the first database cluster architecture include: modifying the architecture interface and modifying the configuration of the first database cluster architecture. If the second processing request indicates modification of the architecture interface of the first database cluster, the architecture interface is modified and the modified interface is re-encapsulated into the corresponding dynamic library. If the second processing request indicates modification of the configuration of the first database cluster, the architecture type and / or dynamic library path corresponding to the first database cluster is modified by calling the architecture configuration interface. Of course, the second processing request may also indicate modification of the architecture interface and configuration of the first database cluster, which will not be elaborated upon here.
[0106] In this embodiment, the above operations support modification of the architecture interface of the first database cluster architecture. This allows for adaptive modification of the first database cluster architecture without requiring reconstruction, to accommodate changes in business scenarios. Furthermore, the above operations support modification of the configuration of the first database cluster architecture, enabling maintenance of the first database cluster architecture to adapt to different deployment environments or resolve performance and fault issues.
[0107] In addition, modifying the configuration of the first database cluster architecture is less costly and faster than deleting the original first database cluster architecture and rebuilding a new one, thereby ensuring the high availability of the first database cluster architecture.
[0108] In one possible embodiment, the database cluster architecture processing method is applied to the target node. The target node can be understood as any server in the server cluster deployed in the database cluster architecture.
[0109] In this embodiment of the application, the architecture interface further includes: an interface for obtaining information about each node in the database cluster architecture where the target node is located, an interface for determining whether the target node is the majority in the database cluster architecture, and an interface for obtaining information about the master node in the database cluster architecture where the target node is located.
[0110] For example, node information indicates whether a node is online or offline, whether it is a master node or a slave node, etc. Through an interface used to obtain information about each node in the database cluster architecture where the target node resides, the detection and management of the database cluster architecture can be achieved.
[0111] The database cluster architecture processing method in this application embodiment further includes: according to the first processing request or the second processing request, performing at least one of the following through the architecture interface: obtaining information of each node in the database cluster architecture where the target node is located; determining whether the target node is the majority in the database cluster architecture where it is located; obtaining information of the master node in the database cluster architecture where the target node is located.
[0112] In this embodiment, based on the cluster characteristics of the database cluster architecture, the general cluster information processing for various database cluster architectures is adaptively implemented through the aforementioned architecture interface, ensuring high availability of the database cluster architecture and avoiding read / write service interruptions and data inconsistencies. For example, many database cluster architectures have master nodes and slave nodes. By determining whether the target node is in the majority of its database cluster architecture, the risk of split-brain can be prevented and master node switching can be facilitated. By obtaining the information of each node in the database cluster architecture where the target node is located, cluster visibility can be ensured. Figure 1 Consistency. By obtaining the master node information in the database cluster architecture where the target node resides, a unique master node can be identified.
[0113] It should be noted that the above-described general cluster information processing can adapt to various database cluster architectures. That is, various database cluster architectures can reuse the processing flow of this application's embodiments, differing only in the architecture interface of the dynamic library. This difference can be encapsulated in the corresponding dynamic library. Each dynamic library contains interfaces with the same functionality, but the same functional interface may be implemented differently in different architectures. For processing any database cluster architecture, the corresponding functional interface can be called without concern for its specific implementation. This makes the database cluster architecture processing method of this application's embodiments more flexible and scalable.
[0114] In addition to the examples of the architecture interfaces mentioned above, the architecture interfaces also support extensions to adapt to specific application scenarios.
[0115] Based on the characteristics of a database cluster architecture with master and slave nodes, and the master node having the function of managing the cluster, in the event of a failure of the master node, it is necessary to switch the master node to ensure the high availability of the database cluster architecture.
[0116] Specifically, regarding master node switching, in one possible embodiment, the database cluster architecture processing method further includes: based on a third processing request for the first database cluster architecture, if the third processing request indicates that the master node of the database cluster architecture where the target node is located be switched, determining the master node after switching by using the metadata of the database cluster architecture where the target node is located, and calling an interface used to determine whether the target node is the majority in the database cluster architecture; triggering the master node switch through the node state machine; and updating the metadata after the master node switch is completed.
[0117] Metadata includes the node role of each node in the database cluster architecture (such as whether a node is a master node or a slave node), the number of quorum votes used to determine the master node, the mindset of each node, and data consistency records, etc.
[0118] A node state machine is used to define valid node state change paths. For example, the state change of each master node must satisfy the following constraint: the changes should proceed sequentially as offline, initialization, slave node, candidate node, and master node.
[0119] Based on the above example, when the third processing request indicates a switch to the master node of the database cluster architecture where the target node is located, after using the metadata of the database cluster architecture where the target node is located and calling the interface used to determine whether the target node is the majority in the database cluster architecture, the candidate node whose number of nodes in the network partition is greater than or equal to the number of votes is determined as the master node after the switch, based on the quorum indicated by the metadata and the node role of each node.
[0120] In this embodiment, the above operations are used to ensure high availability of the database cluster architecture by compatibility with the metadata, node state machine, and interfaces in the architecture interface used to determine whether the target node is a majority in the database cluster architecture. This enables master node switching. After determining the new master node, the master node switch is triggered via the node state machine, and the metadata is updated after the switch is complete to record the master node switching process.
[0121] In addition to the aforementioned master node switching, there is also a need to restore the master node after the original master node fails and recovers. For master node restoration, in one possible embodiment, the database cluster architecture processing method further includes: when a third processing request indicates that the master node of the database cluster architecture containing the target node should be restored, determining the master node to be restored through the metadata of the database cluster architecture containing the target node; triggering master node restoration through the node state machine; and updating the metadata after the master node restoration is complete.
[0122] Similar to the previous embodiment, in this embodiment, the above operations ensure compatibility with the metadata of the database cluster architecture where the target node resides, thereby enabling master node recovery and ensuring high availability of the database cluster architecture. After determining the master node to be recovered, the master node recovery is triggered through the node state machine, and the metadata is updated after the master node recovery is completed, thus recording the master node recovery process.
[0123] In summary, the database cluster architecture processing method of this application embodiment can achieve high availability of the database cluster architecture, and by maintaining dynamic libraries, it can achieve pluggable database cluster architecture processing and facilitate the expansion to new architectures. Furthermore, users do not need to concern themselves with the specific implementation of the architecture logic processing for each database cluster architecture; they can achieve architecture logic processing simply by loading the corresponding dynamic libraries and sending requests. This reduces user usage and maintenance costs and improves ease of use.
[0124] Figure 5This is a schematic diagram of the database cluster architecture processing device according to an embodiment of this application. Figure 5 As shown, the database cluster architecture processing device provided in this application embodiment includes a loading module 410 and a processing module 420.
[0125] Loading module 410 is used to load the dynamic library corresponding to the first database cluster architecture according to the first processing request for the first database cluster architecture. The first processing request includes creating the first database cluster architecture or deleting the first database cluster architecture.
[0126] The processing module 420 is used to call the interface for initialization and node registration in the architecture interface from the dynamic library when the first processing request is to create a first database cluster architecture, so as to obtain the first database cluster architecture that provides data read and write services.
[0127] The processing module 420 is also used to call the interface for deinitialization and node deregistration in the architecture interface from the dynamic library when the first processing request is to delete the first database cluster architecture, so as to delete the first database cluster architecture and release the resources of the first database cluster architecture.
[0128] In one possible embodiment, the apparatus further includes: a new module, configured to, based on a second processing request for the first database cluster architecture, and if the second processing request indicates the addition of a new first database cluster architecture, add an architecture interface corresponding to the first database cluster architecture and encapsulate the architecture interface of the first database cluster architecture into a newly added dynamic library corresponding to the first database cluster architecture.
[0129] In one possible embodiment, the apparatus further includes a configuration module, configured to invoke an architecture configuration interface and configure the architecture type and dynamic library path of the first database cluster architecture based on a configuration request for the first database cluster architecture.
[0130] In one possible embodiment, the apparatus further includes: a modification module, configured to, upon a second processing request indicating modification of the first database cluster architecture, perform at least one of the following according to the second processing request: modify the architecture interface of the first database cluster architecture and repackage the modified architecture interface into the corresponding dynamic library; modify the architecture type and / or dynamic library path of the first database cluster architecture by calling the architecture configuration interface.
[0131] In one possible embodiment, the device is applied to a target node, and the architecture interface further includes: an interface for obtaining information about each node in the database cluster architecture where the target node resides; an interface for determining whether the target node is a majority in the database cluster architecture; and an interface for obtaining information about the master node in the database cluster architecture where the target node resides. The processing module is further configured to perform at least one of the following through the architecture interface according to a first processing request or a second processing request: obtaining information about each node in the database cluster architecture where the target node resides; determining whether the target node is a majority in the database cluster architecture; and obtaining information about the master node in the database cluster architecture where the target node resides.
[0132] In one possible embodiment, the apparatus further includes: a determining module, configured to determine the switched master node based on the metadata of the database cluster architecture where the target node is located, and by calling an interface for determining whether the target node is a majority in the database cluster architecture, in accordance with a third processing request for the first database cluster architecture, provided that the third processing request indicates a switch of the master node in the database cluster architecture where the target node is located; a switching module, configured to trigger the master node switch through a node state machine; and an updating module, configured to update the metadata after the master node switch is completed.
[0133] In one possible embodiment, the determining module is further configured to determine the master node to be restored by means of the metadata of the database cluster architecture where the target node is located, when the third processing request indicates that the master node of the database cluster architecture where the target node is located be restored; the device also includes a recovery module for triggering master node recovery through the node state machine; the updating module is further configured to update the metadata after the master node recovery is completed.
[0134] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 6 As shown, this application embodiment provides an electronic device including a processor 501 and a memory 502. Optionally, the device further includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus 504.
[0135] The electronic device can be a server.
[0136] In the specific implementation process, the memory 502 stores code, and the processor 501 runs the code stored in the memory 502 to execute the method of the above method embodiment.
[0137] 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.
[0138] In the above Figure 6In the illustrated embodiments, it should be understood that the processor 501 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.
[0139] The memory 502 may include high-speed RAM memory, and may also include non-volatile memory (NVM), such as at least one disk storage.
[0140] Bus 504 can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Bus 504 can be divided into address bus, data bus, control bus, etc. For ease of illustration, the bus 504 in the accompanying drawings of this application is not limited to only one bus or one type of bus.
[0141] This application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the methods described in the above-described method embodiments.
[0142] The aforementioned computer-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.
[0143] 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.
[0144] This application provides a computer program product, including a computer program that, when executed by a processor, implements the methods provided in any of the embodiments described above.
[0145] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.
[0146] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.
[0147] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.
[0148] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.
[0149] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.
[0150] If the integrated unit / module is implemented as a software program module and sold or used as an independent financial product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software financial product. This computer software financial product is stored in a memory 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 application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.
[0151] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.
[0152] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.
[0153] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.
Claims
1. A database cluster architecture processing method, characterized in that, include: Based on a first processing request for the first database cluster architecture, load the dynamic library corresponding to the first database cluster architecture. The first processing request includes creating the first database cluster architecture or deleting the first database cluster architecture. In the case where the first processing request is to create the first database cluster architecture, the interface for initialization and node registration in the architecture interface is called from the dynamic library to obtain the first database cluster architecture that provides data read and write services. If the first processing request is to delete the first database cluster architecture, the interface for deinitialization and node deregistration in the architecture interface is called from the dynamic library to delete the first database cluster architecture and release the resources of the first database cluster architecture.
2. The method according to claim 1, characterized in that, Before loading the dynamic library corresponding to the first database cluster architecture, the method further includes: According to the second processing request for the first database cluster architecture, if the second processing request indicates that the first database cluster architecture is added, an architecture interface corresponding to the first database cluster architecture is added and the architecture interface of the first database cluster architecture is encapsulated into the newly added dynamic library corresponding to the first database cluster architecture.
3. The method according to claim 2, characterized in that, Before adding the architecture interface corresponding to the first database cluster architecture and encapsulating the architecture interface of the first database cluster architecture into the newly added dynamic library corresponding to the first database cluster architecture, the method further includes: Based on the configuration request for the first database cluster architecture, the architecture configuration interface is invoked, and the architecture type and dynamic library path of the first database cluster architecture are configured based on the architecture configuration interface.
4. The method according to claim 3, characterized in that, After adding the architecture interface corresponding to the first database cluster architecture and encapsulating the architecture interface of the first database cluster architecture into the newly added dynamic library corresponding to the first database cluster architecture, the method further includes: if the second processing request indicates modification of the first database cluster architecture, performing at least one of the following according to the second processing request: Modify the architecture interface of the first database cluster architecture and repackage the modified architecture interface into the corresponding dynamic library; Modify the architecture type and / or dynamic library path of the first database cluster architecture by calling the architecture configuration interface.
5. The method according to any one of claims 1-4, characterized in that, The method is applied to the target node, and the architecture interface further includes: an interface for obtaining information about each node in the database cluster architecture where the target node resides; an interface for determining whether the target node is a majority node in the database cluster architecture; and an interface for obtaining information about the master node in the database cluster architecture where the target node resides. The method also includes: Based on the first processing request or the second processing request, at least one of the following is executed through the architecture interface: Obtain information about each node in the database cluster architecture where the target node is located; Determine whether the target node is a majority in the database cluster architecture; Obtain the master node information in the database cluster architecture where the target node is located.
6. The method according to claim 5, characterized in that, The method further includes: According to the third processing request for the first database cluster architecture, if the third processing request indicates to switch the master node of the database cluster architecture where the target node is located, the master node after the switch is determined by using the metadata of the database cluster architecture where the target node is located and by calling the interface used to determine whether the target node is the majority in the database cluster architecture. Master node switching is triggered via the node state machine; After the master node switch is completed, update the metadata.
7. The method according to claim 6, characterized in that, The method further includes: If the third processing request indicates that the master node of the database cluster architecture where the target node is located be restored, the master node to be restored shall be determined by the metadata of the database cluster architecture where the target node is located. The master node recovery is triggered by the node state machine. After the master node has recovered, update the metadata.
8. A database cluster architecture processing device, characterized in that, include: The loading module is used to load the dynamic library corresponding to the first database cluster architecture according to the first processing request for the first database cluster architecture. The first processing request includes creating the first database cluster architecture or deleting the first database cluster architecture. The processing module is used to call the interface for initialization and node registration in the architecture interface from the dynamic library when the first processing request is to create the first database cluster architecture, so as to obtain the first database cluster architecture that provides data read and write services. The processing module is further configured to, when the first processing request is to delete the first database cluster architecture, call the interface for deinitialization and node deregistration in the architecture interface from the dynamic library, so as to delete the first database cluster architecture and release the resources of the first database cluster architecture.
9. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 7.
10. 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 to 7.