Statement distribution management method and device, equipment, storage medium and program product

Abstract

The embodiment of the invention provides a statement distribution management method and device, equipment, a storage medium and a program product, and relates to the field of databases. The method comprises the following steps: acquiring node information of a main node in a target cluster; information of standby nodes connected with the main node is obtained according to the node information, information of subordinate nodes connected with the standby nodes is inquired in a recursive mode, flow replication information is obtained through traversal, and the flow replication information comprises the hierarchical relation and the connection state of the subordinate nodes and the standby nodes of the main node; constructing a topological structure comprising multiple stages of standby nodes based on the stream replication information; and distributing the target statement to nodes in the target cluster according to the topological structure. According to the method provided by the invention, through the principles of hierarchical analysis and rule matching, the distribution strategy can accurately identify the local and remote nodes, and the SQL request is prevented from being wrongly distributed to the remote nodes, so that the cross-region communication delay is remarkably reduced, and a data basis is provided for the dynamic distribution strategy.

Description

Technical Field

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

[0002] In industries such as finance, telecommunications, and the internet, where high availability and low latency of data are extremely critical, the geographically dispersed dual-center cluster architecture is widely used to ensure business continuity. This architecture achieves cross-regional disaster recovery and load balancing by deploying database clusters in two geographically separated centers. For example, a bank's core transaction system might be deployed with primary and backup clusters in regions A and B respectively. If one center fails due to a natural disaster or network outage, the other center can seamlessly take over the operations.

[0003] However, in such scenarios, traditional read-write separation strategies face significant challenges: when a client initiates a high-frequency read request in a certain region, if the SQL statement is incorrectly distributed to a remote backup node, it will lead to a significant increase in cross-regional network transmission latency (usually reaching millisecond levels), which in turn causes fluctuations in business response time or even timeouts.

[0004] Therefore, in cross-regional deployment scenarios, existing technologies may cause SQL requests to be distributed to remote nodes, leading to network transmission delays and affecting system performance. Summary of the Invention

[0005] This application provides a statement distribution management method, apparatus, device, storage medium, and program product to solve the technical problem in existing technologies where SQL requests may be distributed to remote nodes in cross-regional deployment scenarios, causing network transmission delays and affecting system performance.

[0006] Firstly, this application provides a statement dispatch management method, including:

[0007] Obtain node information of the master node in the target cluster;

[0008] Based on the node information, obtain the information of the backup nodes connected to the master node, recursively query the information of the subordinate nodes connected to the backup nodes, and traverse to obtain the stream replication information, which includes the hierarchical relationship and connection status of the subordinate backup nodes of the master node.

[0009] Based on streaming replication information, a topology containing multiple levels of backup nodes is constructed;

[0010] Based on the topology, the target statements are distributed to the nodes in the target cluster.

[0011] Secondly, this application provides a statement distribution management device, comprising:

[0012] The information acquisition module is used to acquire node information of the master node in the target cluster;

[0013] The streaming replication information acquisition module is used to obtain the information of the backup nodes connected to the master node based on the node information, recursively query the information of the lower-level nodes connected to the backup nodes, and traverse to obtain the streaming replication information, which includes the hierarchical relationship and connection status of the lower-level backup nodes of the master node.

[0014] The topology building module is used to build a topology structure containing multiple levels of backup nodes based on streaming replication information;

[0015] The statement distribution module is used to distribute target statements to nodes in the target cluster according to the topology.

[0016] Thirdly, this application provides an electronic device, including: a processor and a memory communicatively connected to the processor;

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

[0018] The processor executes computer-executable instructions stored in memory to implement any of the methods of the first aspect.

[0019] 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 of any one of the first aspects.

[0020] 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.

[0021] The statement distribution management method, apparatus, device, storage medium, and program products provided in this application solve the problem that existing technologies cannot identify multi-level standby node hierarchies through recursive parsing of streaming replication information and construction of topology structures. The streaming replication information acquisition step ensures that the topology structure includes the hierarchical relationship of second-level standby nodes by querying the metadata of the master node's subordinate nodes. The topology structure construction step employs a breadth-first search strategy, expanding the connection relationships of standby nodes layer by layer to fully describe the multi-level architecture of the cluster. The statement distribution step prioritizes local nodes for distribution based on the node hierarchy and regional attributes in the topology structure. Through the principles of hierarchical parsing and rule matching, the distribution strategy can accurately identify local and remote nodes, preventing SQL requests from being incorrectly distributed to remote nodes, thereby significantly reducing cross-regional communication latency and providing a data foundation for dynamic distribution strategies. Attached Figure Description

[0022] 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.

[0023] Figure 1 This is a schematic diagram of a remote dual-center cluster architecture;

[0024] Figure 2 A flowchart illustrating a statement distribution management method provided in an embodiment of this application;

[0025] Figure 3 A schematic diagram of a geographically distributed dual-center cluster deployment architecture provided in an embodiment of this application;

[0026] Figure 4 This application provides a schematic diagram of a read / write separation statement distribution process for a geographically distributed dual-center cluster.

[0027] Figure 5 This is a schematic diagram of the structure of a statement distribution management device provided in an embodiment of this application;

[0028] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0029] The accompanying drawings have illustrated 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 specific embodiments. Detailed Implementation

[0030] 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.

[0031] 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 countries and regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation access points for users to choose to authorize or refuse.

[0032] Furthermore, the technical solution involved in this application, which involves big data analysis of user information (including but not limited to personal biometrics, identity data, consumption data, asset data, electronic terminal operation data, etc.) and the use of artificial intelligence technology for automated decision-making, and makes decisions that have a significant impact on personal rights based on the results of automated decision-making, provides users with corresponding operation entry points for users to choose to agree to or reject the results of automated decision-making; if the user chooses to reject, the process will proceed to the expert decision-making process.

[0033] It should be noted that the statement distribution management method, apparatus, device, storage medium, and program product provided in this application can be used in the database field, or in any field other than databases. The application field of the statement distribution management method, apparatus, device, storage medium, and program product in this application is not limited.

[0034] This application is specifically applied to cross-regional database cluster scenarios in industries such as finance, telecommunications, and government, where high availability and low latency requirements for data are stringent. In industries with extremely high requirements for data availability and low latency, such as finance, telecommunications, and the internet, a geographically dispersed dual-center cluster architecture is widely used to ensure business continuity. This architecture achieves cross-regional disaster recovery and load balancing by deploying database clusters in two geographically separated centers. For example, Figure 1 This is a schematic diagram of a geographically distributed dual-center cluster architecture, as shown below. Figure 1 As shown, a bank's core transaction system may deploy primary and backup clusters in regions A and B respectively. When one center fails due to natural disasters or network failures, the other center can seamlessly take over the business.

[0035] However, in such scenarios, traditional read / write separation strategies face significant challenges: when a client initiates a high-frequency read request in a certain region, if the SQL statement is incorrectly distributed to a remote backup node, it will lead to a significant increase in cross-regional network transmission latency (typically reaching milliseconds), which in turn causes fluctuations in business response time or even timeouts. Furthermore, as the cluster size increases (such as multi-level nested backup node deployments), existing technologies struggle to dynamically identify the hierarchical relationship between local and remote nodes, resulting in rigid distribution strategies that cannot adapt to the dynamic failover requirements in complex network environments.

[0036] The core of existing database read / write separation technology relies on the cluster status monitoring mechanism of the client's heartbeat thread. The specific process includes: (1) The client periodically checks the status of cluster nodes through the heartbeat thread and builds a list of available nodes; (2) The business thread distributes SQL statements to the backup nodes according to preset rules (such as round-robin, weight ratio). For example, when the master node is normal, the client only distributes read requests to the local backup node; when the local backup node fails, it automatically switches to the remote backup node.

[0037] However, existing solutions have several drawbacks, including: 1) Limitations in node identification: Existing solutions can only identify first-level backup nodes and cannot detect multi-level nested cluster structures (such as second-level backup nodes under the primary node), causing the distribution strategy to fail in complex topologies. 2) Cross-regional distribution latency: In dual-center deployment scenarios, if the client does not configure region-aware logic, SQL requests may be randomly distributed to remote nodes, causing significant network latency. 3) Insufficient dynamic adjustment capabilities: Existing distribution rules (such as fixed ratios or round-robin) cannot dynamically adjust priorities based on node location, load status, or failure status, resulting in low resource utilization. Furthermore, existing technologies do not provide a dedicated streaming replication information management mechanism for remote dual-center clusters, limiting the ability to deeply analyze the cluster hierarchy.

[0038] The statement distribution management method, apparatus, device, storage medium, and program product provided in this application obtain streaming replication information from the master node, which includes the hierarchical relationship and connection status of its subordinate backup nodes; based on the streaming replication information, a breadth-first search strategy is used to construct a topology structure, which covers the hierarchical relationship of the master node, first-level backup nodes, and second-level backup nodes, and marks the regional attributes of each node; according to the hierarchy and regional attributes of the nodes in the topology structure, SQL statements are distributed to nodes that conform to preset rules. Streaming replication information serves as the input for topology construction, and the topology structure serves as the basis for statement distribution. The three are logically linked through hierarchical resolution and rule matching, aiming to solve the above-mentioned technical problems of the prior art.

[0039] 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 be described below with reference to the accompanying drawings.

[0040] Figure 2 This is a flowchart illustrating a statement distribution management method provided in an embodiment of this application, as shown below. Figure 2 As shown, the method includes:

[0041] S201. Obtain node information of the master node in the target cluster.

[0042] In one example, the master node can include the node in a database cluster responsible for handling write operations, such as the master database instance deployed in region A in a financial system. Node information includes data describing the node's status and connection relationships, such as metadata containing the node's IP address, synchronization status, and hierarchy.

[0043] S202. Obtain the information of the backup nodes connected to the master node based on the node information, recursively query the information of the subordinate nodes connected to the backup nodes, and traverse to obtain the stream replication information.

[0044] In this embodiment of the application, the streaming replication information includes the hierarchical relationship and connection status of the primary node's subordinate backup nodes.

[0045] In one example, a backup node can include a node that synchronizes data with the primary node via streaming replication. For instance, the direct backup node of the primary node in region A is the database instance in region B. Streaming replication information includes metadata stored in the database node that describes the hierarchical relationship and connection status of its subordinate backup nodes. For example, the streaming replication information of the primary node might include identifiers of first-level backup nodes and a flag indicating whether second-level backup nodes exist.

[0046] S203. Based on streaming replication information, construct a topology structure containing multiple levels of backup nodes.

[0047] In one example, the topology includes a hierarchical network structure consisting of a master node, first-level standby nodes, and second-level standby nodes, used to represent the hierarchical relationship between nodes in the cluster. For example, the master node (node1) connects to the first-level standby node (node2), and node2 connects to the second-level standby node (node4). The hierarchical relationship of the standby nodes is recursively parsed using the flow replication information field, and a breadth-first search strategy is used to construct the multi-level topology. For example: 1. The connector first connects to the master node (node1), obtains its flow replication information, and discovers the standby nodes (node2 and node3). 2. The flow replication information of node2 is parsed, and its subordinate standby node (node4) is discovered. 3. The flow replication information of node3 is parsed, and its subordinate standby node (node5) is discovered. 4. Through breadth-first search, node4 and node5 are added to the topology list, finally constructing a complete multi-level standby node topology.

[0048] S204. Based on the topology, distribute the target statement to the nodes in the target cluster.

[0049] In one example, the target SQL statement is distributed to available nodes in the cluster according to preset rules. For instance, based on the hierarchy and geographic attributes of nodes in the topology, read requests are preferentially distributed to the local first-level standby node.

[0050] The system receives SQL statements from the business connection and configures node priorities (localreadlist) in the cluster topology. Based on the priority weights configured in the localreadlist parameters, and considering the node's geographic attributes, the distribution ratio is dynamically adjusted. For example: 1. If localreadlist is configured as "Region A node priority = 2, Region B node priority = 1", then the distribution ratio for Region A node is 2 / (2+1) = 66.7%. 2. When Region A node fails, the distribution ratio for Region B node is dynamically increased to 100%. 3. If Region A node recovers, the distribution ratio is redistributed according to the priority weights. Here, localreadlist is a pre-configured node priority parameter that defines the weights of nodes in different regions. For example, Region A node weight is set to 2, and Region B node weight is set to 1.

[0051] In one implementation scenario, Figure 3 This is a schematic diagram of a geographically distributed dual-center cluster deployment architecture provided in an embodiment of this application, as shown below. Figure 3 As shown, the database cluster is deployed in two regions. The primary node facing the outside world is node1, and the rest are backup nodes. Backup nodes include node4, and there are second-level backup nodes node5 and node6. A second-level node is a node whose primary node is a backup of its parent node. This cluster can be deployed in multiple nested layers.

[0052] Figure 4 This application provides a schematic diagram of a read / write separation statement distribution process for a geographically distributed dual-center cluster, as illustrated in the embodiments of this application. Figure 4 As shown, when the database connector heartbeat thread connects to the database, it first identifies the primary node and then checks all the backup nodes it can access. For each backup node, streaming replication information is added. The connector uses this information to obtain information about any potential lower-level backup nodes. If a lower-level backup node exists, it is added to the connection detection list to further retrieve even lower-level backup nodes; the strategy here is breadth-first search. After all node checks are completed, all valid nodes in the cluster are determined, and they are all sent to the business connection. In the event of a failure or the absence of lower-level backup nodes, the heartbeat detection periodically jumps back to the initial state for processing.

[0053] For example, in the identification and verification of a geographically distributed dual-center cluster structure, nodes will add streaming replication information, and information about their accessible lower-level nodes can be obtained through queries. First, the cluster is connected to find the master node, and then the backup node is found based on the master node's streaming replication information. By querying the backup node information, it is determined whether a second-level backup node exists. For the master node (a node with lower-level backup nodes) found in the sub-cluster, it is added to the connection maintenance list, and its backup node status is checked periodically.

[0054] To address the scenario where business connections cannot distinguish the level of backup nodes or their location when distributing SQL queries, a new parameter `localreadlist` is added to control node priority, in conjunction with a loadrate-based distribution strategy. This prioritizes distribution to local backup nodes, ensuring that the distribution ratio is evenly distributed among them when a node fails. If all local backup nodes fail, the distribution ratio is reset to remote backup nodes.

[0055] An exemplary implementation of freely selectable backup node distribution rules includes: adding the concept of node priority, adding the parameter `localreadlist`, supporting the configuration of node priorities, with higher-priority nodes being distributed first. To achieve freely selectable backup node distribution, `localreadlist` and `loadrate` are combined to constrain the scope of distributeable nodes, for example, by configuring 0 / 1 to restrict the distribution of local nodes.

[0056] In another implementation scenario, a node health status assessment module is introduced based on topology identification to collect real-time data on CPU utilization, memory usage, and network latency of each node. A weighted scoring model (e.g., health score = 0.4 × CPU health + 0.3 × memory health + 0.3 × network latency index) dynamically adjusts the availability markers of nodes in the topology. For example, when a local node's health score falls below a threshold, its priority in the distribution strategy is automatically reduced, even if it is located in the local region. By deeply integrating node health status with topology identification, the problem of "local node failures still being misused" caused by traditional solutions relying solely on static priority parameters is solved. Dynamic health scoring ensures that the distribution strategy always prioritizes the best-performing local node, further reducing the proportion of cross-regional requests and avoiding service response fluctuations caused by local node performance degradation.

[0057] In another implementation scenario, a real-time load awareness module is added to the distribution strategy. This module dynamically adjusts the weight allocation of the `localreadlist` parameter by collecting the current connection count, SQL execution queue length, and I / O throughput of each node. For example, when the connection count of local node 1 approaches the threshold, some of the load is automatically distributed to node 2 in the same region, instead of directly switching to a remote node. By introducing a load awareness mechanism, the problem of traditional static priority parameters being unable to adapt to sudden business fluctuations is solved. The distribution strategy can dynamically balance local node resources based on real-time load, avoiding performance bottlenecks caused by single-point overload, while reducing network latency caused by misuse of remote nodes, significantly improving the overall throughput of the cluster.

[0058] In another implementation scenario, a fault prediction module is added to the topology identification process. This module predicts potentially failing nodes by analyzing historical fault patterns (such as the correlation between node failures and network fluctuations) and real-time monitoring data (such as the number of lost node heartbeats). When a high risk of failure is predicted for a local node, some read requests are pre-distributed to backup nodes in the same region, rather than passively switching over after a failure occurs. This proactive fault prediction solves the response delay problem caused by traditional solutions that only trigger distribution strategy adjustments after a node failure. The pre-loading strategy can transfer the load to available nodes in advance, shortening failover time, reducing the risk of business interruption, and avoiding cross-regional delays caused by temporary takeover by remote nodes.

[0059] In another implementation scenario, a business type identification module is introduced into the distribution strategy. This module categorizes businesses into "high priority" (e.g., real-time transaction queries) and "low priority" (e.g., batch report queries) by parsing the characteristics of SQL statements (such as query complexity and table join size). For different business types, the priority inheritance rules of the `localreadlist` parameter are dynamically adjusted. For example, high-priority businesses are forced to be distributed primarily to local nodes, while low-priority businesses can tolerate a certain proportion of distribution to remote nodes. This differentiated distribution strategy solves the resource waste problem caused by the traditional "one-size-fits-all" priority configuration. High-priority businesses always receive local node resources with the lowest latency, ensuring the performance of critical businesses; low-priority businesses can flexibly utilize remote node resources, improving the overall resource utilization of the cluster, while avoiding a decline in service quality for high-priority businesses due to low-priority businesses preempting local nodes.

[0060] In another implementation scenario, a multi-level topology path planning module is extended to topology identification. This module dynamically plans the optimal distribution path by constructing a communication path graph between nodes (such as network bandwidth and link stability between nodes) and combining the amount of data transmitted and execution dependencies of SQL statements. For example, for complex queries that require cross-table joins, nodes in the local node whose physical storage location matches that of the target table are prioritized, rather than simply distributing based on regional priority. By deeply integrating data storage location with distribution path planning, the "local node storage mismatch" problem caused by traditional solutions that only distribute based on regional priority is solved. Intelligent path planning ensures that SQL statements are distributed to the optimal data storage location in the local node, reducing cross-node data transmission overhead, further reducing execution latency, and improving the execution efficiency of complex queries.

[0061] The statement distribution management method provided in this embodiment solves the problem of existing technologies being unable to identify multi-level standby node hierarchies by recursively parsing streaming replication information and constructing the topology. The streaming replication information acquisition step ensures that the topology contains the hierarchical relationship of second-level standby nodes by querying the metadata of the master node's subordinate nodes. The topology construction step employs a breadth-first search strategy, expanding the connection relationships of standby nodes layer by layer to fully describe the multi-level architecture of the cluster. The statement distribution step prioritizes local nodes for distribution based on the node hierarchy and regional attributes in the topology. Through the principles of hierarchical parsing and rule matching, the distribution strategy can accurately identify local and remote nodes, preventing SQL requests from being incorrectly distributed to remote nodes, thereby significantly reducing cross-regional communication latency and providing a data foundation for dynamic distribution strategies.

[0062] Optionally, based on the streaming replication information, a topology containing multiple levels of backup nodes is constructed, including: parsing the streaming replication information to obtain the identifiers of the lower-level nodes in the streaming replication information; and expanding the topology based on the lower-level node identifiers using a breadth-first search strategy.

[0063] In one example, the hierarchical relationship of backup nodes is determined by parsing the lower-level node identifiers in the streaming replication information. For example, the streaming replication information of the master node node1 contains the identifiers of node2 and node3, which, after parsing, are used as first-level backup nodes. Subsequently, a breadth-first search strategy is used to expand the topology layer by layer: first, node2 and node3 are visited, then the streaming replication information of node2 is parsed to obtain its lower-level node node4, finally constructing a complete topology containing the master node, first-level backup nodes, and second-level backup nodes. The lower-level node identifiers include: unique identifiers of backup nodes recorded in the streaming replication information, used to determine their connection relationship with the upper-level nodes. For example, the streaming replication information of the master node node1 contains the identifier of the lower-level node node2. The breadth-first search strategy includes: a graph traversal algorithm that prioritizes visiting all nodes in the current level before moving to the next level. For example, starting from the master node node1, its first-level backup nodes node2 and node3 are visited sequentially, and then the second-level backup node node4 of node2 is visited.

[0064] By parsing the identifiers of lower-level nodes and employing a breadth-first search strategy, the integrity of the topology is ensured, preventing the statement distribution strategy from failing due to omissions in hierarchical relationships. When a secondary backup node exists under a backup node of the primary node, it can be accurately identified and incorporated into the topology, enabling the distribution strategy to prioritize local nodes based on the complete hierarchical relationship, further reducing cross-regional communication latency.

[0065] Optionally, the target statement is distributed to nodes in the target cluster according to the topology, including: configuring the node priority weight of each node according to the regional attributes of the nodes in the topology; and dynamically adjusting the distribution ratio of the target statement to each node based on the node priority weight.

[0066] In one example, node priority weights are configured based on the geographic attributes of nodes in the topology (such as "Region A" or "Region B"). For instance, local nodes have higher weights than remote nodes. The distribution ratio is dynamically calculated based on these weights; for example, the distribution ratio for local nodes is a weight percentage (e.g., 2 / (2+1)=66.7%). The geographic priority control of the statement distribution strategy is achieved through the mathematical principles of weight allocation and ratio calculation. The geographic attribute includes: the geographical location identifier of the node, used to distinguish local nodes from remote nodes. For example, the geographic attribute of a node in Region A is labeled "Region A," and the geographic attribute of a node in Region B is labeled "Region B." The node priority weight is a user-configured value used to define the distribution priority of nodes in different regions. For example, the weight of a local node is set to 2, and the weight of a remote node is set to 1.

[0067] In another example, the step of configuring node priority weights based on the geographical attributes of nodes in the topology includes at least one of the following: classifying business types based on the characteristics of SQL statements; and dynamically adjusting node priority weights according to the business type.

[0068] For example, business types (such as high priority or low priority) are categorized by parsing the characteristics of SQL statements (e.g., query complexity, table join size), and node priority weights are dynamically adjusted based on these business types. For instance, high-priority businesses are forced to be distributed to local nodes first, while low-priority businesses can tolerate distribution to remote nodes. The characteristics of the SQL statements can include attributes such as query complexity and table join size. For example, high-priority businesses (such as real-time transaction queries) typically involve SQL statements that frequently access core tables. By dynamically binding business types with priority weights, differentiated resource allocation is achieved. For example, high-priority businesses always receive local node resources to ensure the performance of critical business operations; low-priority businesses flexibly utilize remote node resources to improve the overall cluster utilization.

[0069] By combining regional attributes with node priority weights, the system ensures that statements are preferentially distributed to local nodes, avoiding cross-regional communication delays. The regional priority control of the statement distribution strategy is achieved through the mathematical principles of weight allocation and proportional calculation.

[0070] Optionally, after dynamically adjusting the distribution ratio corresponding to the target statement distribution, the method further includes: performing fault detection on the node; when a node fault is detected, transferring the distribution ratio of the node fault to a locally available node or a remote node.

[0071] In one example, after dynamically adjusting the distribution ratio, the node status is monitored in real time. When a node failure is detected (e.g., node2 fails), the distribution ratio originally allocated to node2 is immediately transferred to an available node in the same region (e.g., node4) or a remote node (e.g., node3). Through the dynamic control principle of state awareness and ratio reallocation, rapid load balancing is achieved. Node failure refers to the state where a node is unable to respond to requests normally due to network interruption, resource exhaustion, or other reasons. For example, local node2 may lose its heartbeat due to network fluctuations.

[0072] In another example, before obtaining the streaming replication information of the master node in the cluster, the method also includes: collecting the health status data of the master node; and adjusting the parsing priority of the streaming replication information based on the health status data.

[0073] For example, before acquiring streaming replication information, the system collects the health status data of the master node (such as CPU utilization and memory usage). If the master node's health is poor, the system adjusts the parsing priority of the streaming replication information, for example, prioritizing the parsing of streaming replication information from local backup nodes rather than remote backup nodes. This process optimizes the efficiency of topology construction through the binding logic between health status and parsing priority. The health status data includes real-time data on indicators such as the master node's CPU utilization, memory usage, and network latency. For example, if the CPU utilization of master node1 exceeds a threshold, it is marked as "unhealthy." By combining health status data with parsing priority, the system ensures that the parsing process of streaming replication information prioritizes the master node with the best performance, avoiding topology construction delays due to master node performance degradation, thereby improving overall distribution efficiency.

[0074] By dynamically adjusting the distribution ratio and monitoring node status in real time, the distribution ratio is transferred to available nodes when a node failure is detected. Through fault detection and ratio transfer mechanisms, and through the dynamic control principle of state awareness and ratio reallocation, rapid load transfer is achieved. This ensures that the load of failed nodes is reasonably distributed to available nodes, avoiding business interruption and thus improving the cluster's fault tolerance.

[0075] Optionally, after expanding the topology structure based on the lower-level node identifiers using a breadth-first search strategy, the method further includes associating the regional attributes of the nodes in the topology structure with the node priority weights to obtain the association results.

[0076] In one example, after the topology is built, the node's geographic attribute is associated with its priority weight. For instance, the weight of node A in region A is set to 2, and the weight of node B in region B is set to 1, forming a geographic-weight mapping table. This process provides the data foundation for subsequent distribution strategies through attribute binding logic. The association involves binding the node's geographic attribute with its priority weight to form a mapping relationship. For example, the geographic attribute "Region A" of a local node is bound to a weight of 2.

[0077] After the topology is constructed, the node's geographic attributes are associated with its priority weights. This attribute binding logic provides the data foundation for subsequent distribution strategies. By linking geographic attributes with weights, the distribution strategy is ensured to make decisions based on complete topology information and priority rules, avoiding distribution errors caused by fragmented information.

[0078] Optionally, after associating the geographic attributes of nodes in the topology with the node priority weights to obtain the association results, the method further includes: dynamically adjusting the distribution ratio of the target statement distribution corresponding to each node based on the association results; and transferring the distribution ratio of the node failure to a locally available node or a remote node when a node failure is detected.

[0079] In one example, the association results include the binding relationship between regional attributes and priority weights, which guides the calculation of the distribution ratio. For example, a weight of 2 for node A in region B is associated with a weight of 1 for node B in region B. After associating regional attributes and weights, the distribution ratio is dynamically adjusted based on the association results. For example, the distribution ratio for local nodes is calculated to be 66.7% based on the weights. Simultaneously, in the event of a node failure (such as node2 failing), the distribution ratio of the failed node is transferred to available nodes (such as node4 or node3). This process achieves real-time optimization of the distribution strategy through a dynamic adjustment and failover linkage mechanism.

[0080] By associating geographic attributes and weights, the distribution ratio is dynamically adjusted based on the association results. Real-time optimization of the distribution strategy is achieved through a linkage mechanism between dynamic adjustment and failover. Comprehensive optimization of the distribution strategy is achieved by combining dynamic adjustment of the distribution ratio with failover. In the event of node failure, the system can quickly transfer the load while ensuring the rationality of the distribution ratio based on the latest weight allocation, thereby maximizing cluster performance and availability.

[0081] Figure 5 This is a schematic diagram of the structure of a statement distribution management device provided in an embodiment of this application, as shown below. Figure 5 As shown, the statement distribution management device 50 provided in this embodiment includes:

[0082] The information acquisition module 501 is used to acquire node information of the master node in the target cluster;

[0083] The streaming replication information acquisition module 502 is used to obtain the information of the backup nodes connected to the master node based on the node information, recursively query the information of the lower-level nodes connected to the backup nodes, and traverse to obtain the streaming replication information, which includes the hierarchical relationship and connection status of the lower-level backup nodes of the master node.

[0084] Topology building module 503 is used to build a topology structure containing multiple levels of backup nodes based on streaming replication information;

[0085] The statement distribution module 504 is used to distribute target statements to nodes in the target cluster according to the topology.

[0086] In one possible implementation, the topology building module 503 is specifically used to: parse the stream replication information to obtain the identifiers of the lower-level nodes in the stream replication information; and expand the topology structure based on the identifiers of the lower-level nodes using a breadth-first search strategy.

[0087] In one possible implementation, the statement distribution module 504 is specifically used to: configure the node priority weight of each node according to the regional attributes of the nodes in the topology; and dynamically adjust the distribution ratio of the target statement corresponding to each node based on the node priority weight.

[0088] In one possible implementation, the statement distribution management device is also specifically used for: detecting node faults; and when a node fault is detected, transferring the distribution ratio of the node fault to a locally available node or a remote node.

[0089] In one possible implementation, the statement dispatch management device is also specifically used to: associate the regional attributes of nodes in the topology with the priority weights of nodes to obtain the association result.

[0090] In one possible implementation, the statement distribution management device is further configured to: dynamically adjust the distribution ratio of the target statement distribution corresponding to each node based on the association results; and transfer the distribution ratio of the node failure to a local available node or a remote node when a node failure is detected.

[0091] The statement distribution 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.

[0092] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 6As shown, the electronic device 60 may include a memory 601 and a processor 602. Optionally, the electronic device may also include a transceiver 603, wherein the memory 601 and the processor 602 communicate; for example, the memory 601, the processor 602 and the transceiver 603 may communicate via a communication bus 604, the memory 601 is used to store a computer program, and the processor 602 executes the computer program to implement the method of the above embodiments.

[0093] Optionally, the aforementioned 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 in the method embodiments disclosed in this application can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0094] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the methods in any of the above method embodiments.

[0095] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the methods in any of the above method embodiments.

[0096] All or part of the steps in the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a readable memory. When the program is executed, it performs the steps of the above method embodiments; and the aforementioned memory (storage medium) includes: read-only memory (ROM), RAM, flash memory, hard disk, solid-state drive, magnetic tape, floppy disk, optical disk, and any combination thereof.

[0097] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processing unit of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processing unit of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0098] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0099] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0100] Obviously, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the spirit and scope of this application. Therefore, if these modifications and variations to the embodiments of this application fall within the scope of the claims of this application and their equivalents, this application also intends to include these modifications and variations.

[0101] In this application, the term "comprising" and its variations can refer to non-limiting inclusion; the term "or" and its variations can refer to "and / or". The terms "first", "second", etc., in this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. In this application, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0102] 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.

[0103] 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.

[0104] 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.

[0105] 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.

[0106] 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.

[0107] If the integrated unit / module is implemented as a software program module and sold or used as an independent 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 product. This computer software 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.

[0108] 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.

[0109] 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.

[0110] 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 statement dispatch management method, characterized in that, The method includes: Obtain node information of the master node in the target cluster; Based on the node information, obtain the backup node information connected to the master node, recursively query the lower-level node information connected to the backup node, and traverse to obtain the stream replication information, which includes the hierarchical relationship and connection status of the lower-level backup nodes of the master node. Based on the streaming replication information, a topology containing multiple levels of backup nodes is constructed; Based on the topology, the target statement is distributed to the nodes in the target cluster.

2. The method according to claim 1, characterized in that, The construction of a topology containing multiple levels of backup nodes based on the streaming replication information includes: The stream replication information is parsed to obtain the lower-level node identifier in the stream replication information; Based on the lower-level node identifiers, the topology is expanded using a breadth-first search strategy.

3. The method according to claim 1, characterized in that, The step of distributing the target statement to nodes in the target cluster according to the topology includes: Based on the geographical attributes of the nodes in the topology, the node priority weights of each node are configured. Based on the node priority weights, the distribution ratio of the target statement corresponding to each node is dynamically adjusted.

4. The method according to claim 3, characterized in that, After dynamically adjusting the distribution ratio corresponding to the target statement distribution, the method further includes: Perform fault detection on the node; When a node failure is detected, the distribution ratio of the node failure is transferred to a locally available node or a remote node.

5. The method according to claim 2, characterized in that, After expanding the topology structure using a breadth-first search strategy based on the lower-level node identifiers, the method further includes: The geographic attributes of nodes in the topology are associated with their priority weights to obtain the association results.

6. The method according to claim 5, characterized in that, After associating the geographic attributes of nodes in the topology with the node priority weights to obtain the association result, the method further includes: Based on the association results, the distribution ratio of the target statement corresponding to each node is dynamically adjusted; When a node failure is detected, the distribution ratio of the node failure is transferred to a locally available node or a remote node.

7. A statement dispatch management device, characterized in that, The device includes: The information acquisition module is used to acquire node information of the master node in the target cluster; The streaming replication information acquisition module is used to acquire the backup node information connected to the master node based on the node information, recursively query the lower-level node information connected to the backup node, and traverse to obtain the streaming replication information, wherein the streaming replication information includes the hierarchical relationship and connection status of the lower-level backup nodes of the master node. The topology building module is used to construct a topology structure containing multiple levels of backup nodes based on the streaming replication information; The statement distribution module is used to distribute the target statement to the nodes in the target cluster according to the topology.

8. 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 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 to 6.

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

Images