Log regulation method, medium, product and equipment of database cluster

Abstract

The application provides a log regulation method, medium, product and equipment of a database cluster. The method comprises: in a plurality of backup databases of the database cluster, each backup database receives pre-written logs of a corresponding master database through leaf nodes of a self-paired heap; a backup database with the fastest playback progress is determined as a feedback backup database in the plurality of backup databases; in the case that all the pre-written logs received by the leaf nodes of the feedback backup database are special logs and the duration reaches a preset time threshold, idle control information is sent from the feedback backup database to the master database; the master database enters a business idle state in response to the idle control information and stops the generation and transmission of special logs. Through this method, a unified and coordinated idle feedback mechanism can be established in the multi-backup database cluster, the problems of signal redundancy, conflict and master misjudgment caused by independent feedback of multiple backup databases are solved from the root, the real-time response capability of the system is enhanced, and more efficient log transmission and application processes are realized.

Description

Technical Field

[0001] This invention relates to the field of database technology, and in particular to a method, medium, product, and device for log control of a database cluster. Background Technology

[0002] Currently, in database clusters, the primary and standby databases rely on write-ahead logs to maintain logical consistency. Even if data pages can be accessed indiscriminately through shared storage, each node in the cluster still needs to replicate and synchronize data through write-ahead logs to ensure cluster transaction consistency, data recovery capabilities, and failover capabilities. To ensure the stable operation of the log replay process in the standby database, the primary database node generates special write-ahead logs when there is no business activity. These logs do not contain any actual data page modifications; they are only used to drive the standby database replay version number progression, maintaining the log selection and replay progression logic of paired heaps within the standby database.

[0003] Currently, the industry commonly adopts a technical solution that generates special write-ahead logs at fixed intervals. Regardless of whether the primary database cluster is running actual business, each node of the primary database continuously generates special write-ahead logs at fixed time intervals. This ensures that the standby database heap has a continuous source of log input and that the minimum replay version number selection logic executes correctly. While the above-mentioned existing technical solution can ensure uninterrupted log replay, it has significant technical drawbacks in practical applications. First, even when the primary database cluster is idle, it continues to generate a large number of redundant special write-ahead logs, causing the log storage directory to expand rapidly, significantly increasing the pressure on log archiving and storage management, and resulting in ineffective waste of storage space. Second, redundant special write-ahead logs need to be transmitted through streaming replication channels, which generates additional network input / output overhead. At the same time, the standby database consumes processor resources to process such invalid logs, increasing the load on the log replay queue and reducing the overall performance of the cluster. Third, the existing solution cannot perceive the cluster's business load status in real time and cannot dynamically adjust the special write-ahead log generation strategy according to the cluster's idle and running status, resulting in low resource utilization and high cluster operating costs. Summary of the Invention

[0004] In view of the above problems, the present invention proposes a log control method, medium, product and device for database clusters that overcomes or at least partially solves the above problems.

[0005] One objective of this invention is to improve cluster resource utilization and operational performance while ensuring stable log playback.

[0006] A further objective of this invention is to ensure that, even in a multi-standby database environment, the most representative standby database can be selected to provide feedback to the primary database.

[0007] Specifically, this invention provides a log control method for a database cluster, comprising: In the multiple standby databases of the database cluster, each standby database receives the write-ahead logs of the corresponding master database through the leaf nodes of its own paired heap. The paired heap is used to receive the write-ahead logs sent from the master database to the standby database. The write-ahead logs include business logs and special logs. The business logs are used to record specific business data, and the special logs are used to advance the playback version number of the standby database. The leaf nodes correspond one-to-one with the master database. Among multiple backup databases, the backup database with the fastest playback progress is selected as the feedback backup database. If all the write-ahead logs received by the feedback standby database leaf nodes are special logs and the duration reaches a preset time threshold, the control feedback standby database sends idle control information to the primary database. In response to the idle control information, the master database enters the business idle state and stops the generation and transmission of special logs.

[0008] Optionally, after stopping the generation and transmission of special logs, the following steps may also be taken: If the primary database regenerates business logs, the primary database will be switched to business production state, and special logs will be regenerated according to preset inspection rules.

[0009] Optionally, the step of regenerating special logs according to preset inspection rules includes: If the master database does not generate business logs within the set time window and does not receive idle control information, control the master database to generate special logs at set time intervals.

[0010] Optionally, the step of determining the backup database with the fastest playback progress among multiple backup databases as the feedback backup database includes: Obtain the last log sequence number received by each standby database from each master database; The backup database with the largest log sequence number is selected as the feedback backup database based on the log sequence number.

[0011] Optionally, the step of selecting the standby database with the largest log sequence number as the feedback standby database based on the log sequence number includes: Sort the nodes of the master database to obtain a list of master database nodes; Based on the list of primary database nodes, collect the log sequence numbers of all standby databases corresponding to the same primary database node, and construct a set of sequence numbers corresponding to the primary database node; Determine if a unique, largest target log sequence number exists in the sequence number set; If there is a unique and largest target log sequence number in the sequence number set, the standby database corresponding to the target log sequence number is determined as the feedback standby database.

[0012] Optionally, after determining whether a unique, largest target log sequence number exists in the sequence number set, the step further includes: If there is no single largest target log sequence number in the sequence number set, but there are multiple standby databases with the same largest log sequence number, the standby databases corresponding to the log sequence number with the same largest log sequence number are constructed into a standby database set. Determine the next master node in the master node list as the master node to be compared; Obtain the log sequence numbers received by all standby databases in the standby database set in the primary database node to be compared, and then construct a new sequence number set corresponding to the primary database node to be compared. Based on the new sequence number set, the step of determining whether there is a unique and largest target log sequence number in the sequence number set is executed again until the backup database or the primary database node list is completely traversed.

[0013] Optionally, it also includes: If the backup database has not been determined after traversing the list of primary database nodes, check whether the backup database in the latest backup database set is unique. If so, then the backup database in the latest backup database set is determined as the feedback backup database; If not, then select the backup database with the smallest static number from the latest backup database set as the feedback backup database.

[0014] According to another aspect of the present invention, a computer-readable storage medium is also provided, on which a computer program is stored, wherein the computer program, when executed by a processor, implements the steps of the log control method for any of the above-described database clusters.

[0015] According to another aspect of the present invention, a computer program product is also provided, comprising a computer program that, when executed by a processor, implements the steps of the log control method for any of the above-described database clusters.

[0016] According to another aspect of the present invention, a computer device is also provided, including a memory, a processor, and a machine-executable program stored in the memory and running on the processor, wherein the processor executes the machine-executable program to implement the steps of the log control method for any of the above-described database clusters.

[0017] The log control method for a database cluster of the present invention involves multiple standby databases in the database cluster. Each standby database receives write-ahead logs from the corresponding master database through the leaf nodes of its paired heap. The paired heap is used to receive write-ahead logs sent from the master database to the standby database. The write-ahead logs include business logs and special logs. Business logs are used to record specific business data, and special logs are used to advance the replay version number of the standby database. The leaf nodes correspond one-to-one with the master database. First, the standby database with the fastest replay progress is determined as the feedback standby database. When all the write-ahead logs received by the leaf nodes of the feedback standby database are special logs, and the duration reaches a preset time threshold, the feedback standby database is controlled to send idle control information to the master database. The master database responds to the idle control information, enters a business idle state, and stops the generation and transmission of special logs. By limiting feedback to the standby database with the fastest replay progress, the method of the present invention can ensure that the master cluster can continuously generate necessary special logs, thereby avoiding the stuttering phenomenon caused by missing or delayed logs in the log application process for standby databases with lagging replay progress. Meanwhile, the primary database is spared from receiving false idle signals from multiple standby databases and entering unnecessary waiting states, further optimizing resource allocation and improving overall transaction throughput. It also promotes progress coordination among standby databases, reduces the processing overhead of the primary cluster for feedback messages, thereby enhancing the system's real-time response capability, achieving more efficient log transmission and application processes, significantly improving the user experience, and significantly reducing latency caused by replay.

[0018] Furthermore, the log control method for the database cluster of the present invention includes the step of determining the backup database with the fastest replay progress among multiple backup databases as the feedback backup database, which includes: obtaining the last log sequence number received by each backup database from each master database; filtering the backup database with the largest log sequence number as the feedback backup database based on the log sequence number; and the step of filtering the backup database with the largest log sequence number as the feedback backup database based on the log sequence number includes: sorting the nodes of the master database to obtain a master database node list; collecting the log sequence numbers of all backup databases corresponding to the same master database node based on the master database node list to construct a sequence number set corresponding to the master database node; determining whether there is a unique and largest target log sequence number in the sequence number set; and determining the backup database corresponding to the target log sequence number as the feedback backup database if there is a unique and largest target log sequence number in the sequence number set. If the sequence number set does not contain a unique and largest target log sequence number, but multiple standby databases have log sequence numbers that are tied for the largest, then the standby databases corresponding to the tied largest log sequence number are constructed into a standby database set. The next master database node in the master database node list is determined as the master database node to be compared. The log sequence numbers received by all standby databases in the standby database set from the master database node to be compared are obtained, thus constructing a new sequence number set corresponding to the master database node to be compared. Based on the new sequence number set, the step of determining whether a unique and largest target log sequence number exists in the sequence number set is executed again until a feedback standby database is determined or the master database node list has been traversed. If a feedback standby database is still not determined after traversing the master database node list, it is determined whether the standby databases in the latest standby database set are unique. If so, the standby database in the latest standby database set is determined as the feedback standby database; otherwise, the standby database with the smallest static number in the latest standby database set is selected as the feedback standby database. This method ensures that a unique feedback standby database can be determined in any scenario, avoiding misjudgment of the master database due to multiple standby databases simultaneously sending idle control information, and ensuring the stability and reliability of the log control process.

[0019] The above and other objects, advantages and features of the present invention will become more apparent to those skilled in the art from the following detailed description of specific embodiments of the invention in conjunction with the accompanying drawings. Attached Figure Description

[0020] The following sections will describe some specific embodiments of the invention in detail by way of example and not limitation, with reference to the accompanying drawings. The same reference numerals in the drawings denote the same or similar parts or portions. Those skilled in the art should understand that these drawings are not necessarily drawn to scale. In the drawings: Figure 1 This is a flowchart illustrating a log control method for a database cluster according to an embodiment of the present invention. Figure 2 This is a flowchart illustrating a log control method for a database cluster according to another embodiment of the present invention; Figure 3This is a schematic diagram of the process for determining the feedback backup database in a log control method for a database cluster according to an embodiment of the present invention; Figure 4 This is a schematic diagram of a computer program product according to an embodiment of the present invention; Figure 5 This is a schematic diagram of a computer-readable storage medium according to an embodiment of the present invention; and Figure 6 This is a schematic diagram of a computer device according to an embodiment of the present invention. Detailed Implementation

[0021] Those skilled in the art should understand that the embodiments described below are merely a part of the embodiments of the present invention, and not all of the embodiments of the present invention. These partial embodiments are intended to explain the technical principles of the present invention and are not intended to limit the scope of protection of the present invention. Based on the embodiments provided by the present invention, all other embodiments obtained by those skilled in the art without creative effort should still fall within the scope of protection of the present invention.

[0022] It should be noted that the logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be specifically implemented in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0023] Currently, in database clusters with shared storage architecture, the primary and standby databases rely on write-ahead logging (WAL) to maintain logical consistency. Even if data pages are accessed seamlessly through shared storage, each node still needs to ensure logical sequence consistency through streaming replication to maintain transaction consistency, database recovery capabilities, and failover capabilities.

[0024] To support the replay logic of the standby database, the primary database node proactively generates special types of WAL logs when there is no business pressure. These logs are used to maintain the selection logic and replay progress within the standby database pairing heap. These logs typically do not involve the actual data page content but are used to drive the standby database replay SCN forward. In a shared storage architecture database scenario, they are generally referred to as Special_WAL, or simply special logs.

[0025] In existing technologies, regardless of whether the primary database has any business activity, each primary database node actively generates Special_WAL at fixed intervals. This ensures that the standby database continuously has usable logs for replay during streaming replication, maintaining a complete source of leaf nodes in the standby database pairing heap. This guarantees the sustainable execution of the minimum LSN selection logic in the heap. While this design ensures an unbroken replay link, it also introduces some drawbacks: (1) Even when the primary database is idle, it continues to generate a large number of meaningless Special_WAL records. Even when there is no business traffic, all primary database nodes still write Special_WAL records at fixed time intervals, resulting in a disproportionate log volume to business volume. In addition, the continuous accumulation of Special_WAL records will cause the WAL directory to expand rapidly, increasing the pressure on log archiving and storage management, and wasting a certain amount of storage space.

[0026] (2) The full Special_WAL still needs to be transmitted to the standby database through the streaming replication channel, causing unnecessary I / O consumption and bringing additional burden to the network and I / O. When the standby database continues to process these Special_WALs that have no actual business significance, it will waste a lot of CPU time and put additional pressure on the replay queue, affecting the overall performance.

[0027] (3) In addition, the system lacks the ability to perceive the real-time status of cluster services and cannot automatically stop the generation of Special_WAL when the cluster is idle, which makes it impossible to dynamically adjust the log policy according to the actual load.

[0028] It is evident that while the design logic of existing technologies is simple and reliable, it is crude and inefficient, generating a large number of redundant logs in idle scenarios of shared storage clusters, resulting in increased system resource consumption and maintenance costs.

[0029] To address the shortcomings of existing technologies, this invention proposes a method capable of sensing the business status of primary and backup nodes and dynamically adjusting the Special_WAL generation strategy. Specifically, the primary database determines whether to stop generating Special_WAL logs by receiving idle control information from the backup database, thereby reducing unnecessary resource overhead. This mechanism performs well in a single backup database environment, effectively achieving primary / backup load awareness and log generation optimization. However, when the system expands to multiple backup databases, the existing independent feedback mechanism reveals significant flaws, making it difficult for the primary cluster to accurately determine the global idle status. Specifically, the main problems are as follows: First, the replay progress of multiple standby databases often differs. Standby databases with faster replay speeds may have already completed local log application and pairing heap filling operations, thus sending idle control information prematurely. Meanwhile, standby databases with slower replay speeds still heavily rely on subsequent Special_WAL logs to complete their operations. If the primary database immediately stops generating Special_WAL logs based solely on feedback from some standby databases, especially those with faster progress, the lagging standby databases will be unable to obtain the necessary logs in time during their catch-up process, causing replay blocking or significant delays.

[0030] Second, playback stuttering in the lagging standby database will further affect the primary database cluster through the feedback channel. The primary database cluster may enter an unnecessary waiting state due to receiving inconsistent or conflicting load signals, or even trigger resource waste or false "cluster idle" judgments, forming a vicious cycle between the primary and standby databases, ultimately reducing the throughput and availability of the entire cluster.

[0031] Third, under high concurrency and high load environments, the above problems are further amplified, becoming a key bottleneck restricting the performance improvement of RAC streaming replication, affecting the real-time performance and user experience of the database system.

[0032] Specifically, the root of the problem lies in the lack of a coordination mechanism for the replay progress of the standby database, leading to redundancy and conflicts in feedback messages. An optimization method is urgently needed to ensure that only the most representative standby database provides feedback, thereby avoiding unnecessary log generation interruptions. This invention provides a log control method for database clusters. Figure 1 This is a flowchart illustrating a log control method for a database cluster according to an embodiment of the present invention, as shown below. Figure 1 As shown, the log control method for this database cluster includes at least the following steps S101 to S105.

[0033] In step S101, among the multiple standby databases in the database cluster, each standby database receives the write-ahead logs from the corresponding primary database through the leaf nodes of its paired heap. The paired heap is used to receive write-ahead logs sent from the primary database to the standby database. Write-ahead logs generally include business logs and special logs. Business logs are generally used to record specific business data, while special logs are generally used to advance the replay version number of the standby database. Each leaf node corresponds one-to-one with a primary database and is used to independently receive the log stream output by the corresponding primary database node.

[0034] In this embodiment, each leaf node continuously receives the write-ahead log stream from the corresponding primary database, and the standby database selects target write-ahead logs from the write-ahead log stream to perform log replay. This method can ensure that the standby database stably receives continuous log data from multiple primary database nodes, providing underlying support for the cluster's high availability architecture and data logical consistency.

[0035] Optionally, the steps for controlling the standby database to select the target write-ahead log for log replay from the write-ahead log stream generally include: controlling the standby database to extract the replay version number from the write-ahead log stream; selecting the write-ahead log with the smallest version number from the replay version numbers as the target write-ahead log; and performing log replay based on the target write-ahead log. This minimum replay version number selection mechanism ensures the orderliness and accuracy of standby database log replay, avoids replay errors, and maintains cluster logical consistency.

[0036] Step S102: Select the backup database with the fastest playback progress from among multiple backup databases as the feedback backup database. Selecting only the backup database with the fastest playback progress as the sole feedback subject can shield against interference from the lagging progress of slower backup databases, ensuring the global representativeness of the idle feedback signal, thereby fundamentally avoiding signal conflicts and primary database misjudgments caused by concurrent feedback from multiple backup databases.

[0037] In some optional embodiments, the step of determining the backup database with the fastest replay progress among multiple backup databases as the feedback backup database generally includes: obtaining the last log sequence number received by each backup database from each primary database; and filtering based on the log sequence number to obtain the backup database with the largest log sequence number as the feedback backup database. The log sequence number is used to characterize the log receiving progress and replay capability of the backup database. The backup database with the largest log sequence number indicates that its replay progress is the fastest. Using it as the feedback backup database can accurately represent the latest global replay status of the cluster, thereby avoiding interference from the lagging progress of slow backup databases on idle time determination.

[0038] Optionally, the step of selecting the backup database with the largest log sequence number as the feedback backup database based on the log sequence number generally includes: sorting the nodes of the primary database to obtain a list of primary database nodes; based on the list of primary database nodes, collecting the log sequence numbers of all backup databases corresponding to the same primary database node to construct a sequence number set corresponding to the primary database node; determining whether there exists a unique and largest target log sequence number in the sequence number set; and if there is a unique and largest target log sequence number in the sequence number set, determining the backup database corresponding to the target log sequence number as the feedback backup database. Here, the log sequence number is used to characterize the log reception progress and replay capability of the backup database to the corresponding primary database node. A larger log sequence number under the same primary database node indicates that the backup database is synchronizing logs to that primary node faster and has a stronger replay capability. Comparing the log sequence numbers of all backup databases at the same primary database node level can horizontally distinguish the progress differences of each backup database under the same source log stream, achieving fast and accurate progress sorting.

[0039] The reason why a standby database can be directly identified as the feedback standby database when a unique and largest target log sequence number exists in the current master database node's sequence number set, without needing to continue traversing the remaining master database nodes, is that when a standby database presents a globally unique and largest log sequence number on any master database node, it indicates that the standby database has an absolute lead in log synchronization progress on that master node, and this lead is sufficient to characterize the standby database as the fastest in overall replay progress in the cluster. Furthermore, the election objective of this invention only needs to select a unique, definitive, and fastest representative standby database, rather than performing a full traversal and scoring of all master database nodes. Given that a unique leading standby database has already emerged, continuing to traverse other master database nodes will not change the election result, but will only increase unnecessary computational and communication overhead. Therefore, adopting a single-node unique maximum value direct convergence method can ensure the accuracy and effectiveness of the feedback standby database election results, simplify the selection logic, reduce system resource consumption, achieve efficient and lightweight standby database coordination election, and adapt to the low-latency operation requirements of high-availability database clusters.

[0040] Optionally, after determining whether a unique and largest target log sequence number exists in the sequence number set, the process can generally include: if there is no unique and largest target log sequence number in the sequence number set, but multiple standby databases have log sequence numbers that are tied for the largest, construct a standby database set corresponding to the standby databases with the tied largest log sequence number; determine the next master database node in the master database node list as the master database node to be compared; obtain the log sequence numbers received by all standby databases in the standby database set in the master database node to be compared, thereby constructing a new sequence number set corresponding to the master database node to be compared; and repeat the step of determining whether a unique and largest target log sequence number exists in the sequence number set based on the new sequence number set, until a feedback standby database is determined or the master database node list has been traversed. Since a tie for the largest log sequence number indicates that the current progress of each standby database node is the same, and it is impossible to distinguish between fast and slow, constructing a new standby database set can narrow the comparison range and improve the filtering efficiency; iterating to the next master node can use the progress differences of multiple nodes to refine the filtering step by step, thereby solving the problem of indecisiveness due to tied progress and ensuring the accuracy of the election; iterating until a result is determined or the traversal is completed can ensure that the process has an exit point, thereby ensuring the stable operation of the cluster.

[0041] Optionally, if the feedback backup database is not determined after traversing the main database node list, it is determined whether the backup database in the latest backup database set is unique. If so, the backup database in the latest backup database set is determined as the feedback backup database; otherwise, the backup database with the smallest static number in the latest backup database set is selected as the feedback backup database. If traversing all nodes still does not distinguish between fast and slow backup databases, it means that there are multiple backup databases with the same global progress. Random selection will not affect the validity of the feedback, thus ensuring that a unique feedback backup database can be output in all scenarios.

[0042] Step S103: Determine whether all write-ahead logs received by the leaf nodes of the backup database are special logs and whether the duration reaches a preset time threshold. By using the condition that all leaf nodes receive special logs and the duration meets the threshold, the idle state of the cluster without real business can be accurately identified, distinguishing it from short-term no-business scenarios. This avoids false idle determinations and improves the reliability of log control.

[0043] In some optional embodiments, the determination can generally be made by sampling the leaf nodes of the paired heap in the feedback standby database. Specifically, all leaf nodes of the paired heap in the feedback standby database are traversed at a fixed sampling period to determine the type of write-ahead log currently received by each leaf node. This periodic full-node traversal sampling can comprehensively cover the log status of all primary database nodes, avoid sampling omissions, and thus improve the accuracy of idle state determination.

[0044] This step involves the precise determination of the cluster's idle state. It uses the duration of special logs across all nodes as the criterion, differing from conventional heartbeat detection methods. This allows for accurate differentiation between genuine cluster idleness and short-term periods without business activity, effectively avoiding misjudgments. The preset time threshold is the continuous observation period during which the standby database determines all leaf nodes in the paired heap have special logs. A smaller preset time threshold allows the primary database to switch to an idle state earlier, resulting in a more agile response, but it increases communication overhead between the primary and standby databases and the frequency of state switching. A larger preset time threshold reduces the frequency of state switching and improves system stability, but it prolongs the invalid generation period of write-ahead logs, increasing potential waste. Therefore, those skilled in the art can determine the specific value of the preset time threshold according to actual needs.

[0045] In step S104, if the determination in step S103 is yes, the control feedback backup database sends idle control information to the primary database. By having the backup database actively report its idle status, collaborative management and control between the primary and backup nodes can be achieved, providing triggering conditions for dynamically shutting down special logs and breaking through the technical limitations of existing fixed-period log generation.

[0046] Optionally, the steps for controlling the standby database to send idle control information to the primary database generally include: generating idle control information in the standby database; and sending the idle control information to the primary database through the streaming replication channel between the primary and standby databases. This reuses the existing streaming replication channel to transmit control information, eliminating the need for new independent communication links and reducing system deployment complexity and network communication overhead.

[0047] In step S105, the primary database responds to the idle control information, enters the business idle state, and stops the generation and transmission of special logs. This step can eliminate redundant special logs in idle scenarios from the root, effectively reduce log storage volume, reduce log archiving and storage management pressure, and at the same time reduce network I / O and standby database CPU resource consumption caused by invalid log transmission, thereby improving the overall performance of the cluster.

[0048] In some alternative embodiments, after stopping the generation and transmission of special logs, the process may further include: if the primary database regenerates business logs, controlling the primary database to switch to business production state and regenerating special logs according to preset check rules. The primary database automatically switches states and restarts special log generation when business resumes, enabling adaptive switching of log policies, ensuring uninterrupted backup database replay process, and balancing resource conservation with high cluster availability.

[0049] Optionally, the step of regenerating special logs according to preset check rules generally includes: if the primary database does not generate business logs within a set time window and does not receive idle control information, controlling the primary database to generate special logs at set time intervals. For example, if a primary database node does not generate any business logs within a very short time window (e.g., 10ms), then the node actively generates a special log at the set time interval. The smaller the interval value for the primary database to automatically generate special logs by a single node in an idle state, that is, the smaller the set time interval, the faster the backup database pairing heap fills, thereby accelerating the replay process. However, this increases the frequency of special log generation, leading to increased resource waste. The larger the set time interval, the less resource waste, but it may slightly slow down the replay process. Therefore, those skilled in the art can determine the specific values ​​of the set time window and the set time interval according to actual needs. This time window-based on-demand generation mechanism can provide stable log input to the backup database pairing heap when there is no business activity, avoiding replay stagnation, while also avoiding excessive generation of invalid logs, balancing replay stability and resource utilization.

[0050] This method achieves dynamic adaptation between special log generation strategies and cluster business states. It not only precisely solves the technical problems of redundant log resource consumption and poor load adaptability in existing technologies, but also ensures stable log replay of the standby database and consistent cluster data throughout the process. It possesses technical advantages such as adaptive control, low resource consumption, and high operational stability, and can be widely adapted to shared storage database cluster scenarios with diverse loads. Furthermore, it selects the standby database with the fastest replay progress as the sole feedback standby database, ensuring that the idle feedback signal truly represents the latest global replay status of the cluster. This avoids the primary database prematurely stopping special logs, which could cause slow standby database replay blocking, stuttering, and data synchronization delays. Moreover, only the representative feedback standby database performs idle status determination and message reporting, while other standby databases silently suppress feedback. This significantly reduces primary-standby interaction overhead and cluster state switching jitter, improving system operational stability.

[0051] Figure 2 This is a flowchart illustrating a log control method for a database cluster according to another embodiment of the present invention, as shown below. Figure 2 As shown, the process includes at least the following steps S201 to S207.

[0052] Step S201: The primary database sends write-ahead logs to multiple standby databases. During the normal operation of the database cluster with a shared storage architecture, each node of the primary database continuously synchronizes the generated write-ahead logs to the standby databases through a streaming replication channel. This enables the standby databases to perform data replay based on the write-ahead logs, ensuring data consistency and transaction consistency between the primary and standby nodes, and providing a real-time data source for standby database status sampling and idle determination.

[0053] Step S202: Among multiple standby databases, the standby database with the fastest replay progress is selected as the feedback standby database. The log sequence number is used to characterize the log receiving progress and replay capability of the standby database. The standby database with the largest log sequence number indicates that its replay progress is the fastest. Using it as the feedback standby database can accurately represent the latest global replay status of the cluster, thereby avoiding interference from the lagging progress of slow standby databases on idle status determination and ensuring that the feedback signal has global representativeness.

[0054] Step S203 involves sampling the leaf nodes of the paired stack of the feedback standby database. During log replay, the feedback standby database continuously samples each leaf node of the paired stack to obtain the log input type corresponding to each primary database node in real time. This sampling process is based on the existing replay data of the feedback standby database, without adding additional probing overhead or system burden, providing an accurate basis for subsequent cluster business status judgment. Since each leaf node of the paired stack corresponds one-to-one with a primary database node, full sampling of all leaf nodes ensures complete coverage of the log status of all primary database nodes, avoiding judgment bias caused by single-point sampling omissions, thereby improving the comprehensiveness and accuracy of cluster idle state identification.

[0055] Step S204: Determine whether all write-ahead logs received by all leaf nodes are special logs and whether their duration reaches a preset time threshold. If the determination in step S204 is negative, continue with the sampling operation in step S203. Since special logs are generally used to advance the standby database replay version number, all nodes having special logs indicates that the cluster has no real business load. Combining this with the duration threshold can filter out short-term fluctuations in business activity, thereby accurately distinguishing between real idle and temporary idle. Furthermore, this step uses both the log type and duration of all nodes as dual judgment conditions, which can effectively avoid misjudgments caused by momentary lack of business activity and ensure the accuracy of idle state identification. When the judgment conditions are not met, feedback is sent to the standby database for continuous cyclic sampling to ensure uninterrupted monitoring of the cluster's business status and achieve real-time perception.

[0056] The specific value of the preset time threshold can be flexibly configured and adjusted by those skilled in the art according to the cluster size, business load characteristics, stability and other requirements, so as to adapt to the idle judgment sensitivity and system stability requirements under different deployment scenarios.

[0057] Step S205: If the determination in step S204 is yes, the backup control database sends idle control information to the primary database. Once the backup control database confirms that the entire primary database cluster has entered a truly idle state, it sends idle control information to the primary database through the existing streaming replication channel. This enables rapid synchronization of the backup control database's determination result with the primary database, providing triggering conditions for the primary database to dynamically adjust its log generation strategy, and achieving primary-backup collaborative control.

[0058] In step S206, the primary database responds to the idle control information, enters the business idle state, and stops the generation and transmission of special logs. Upon receiving the idle control information, the primary database uniformly switches its operating state, and all nodes synchronously stop the generation and transmission of special logs, retaining only the normal processing of business logs. This eliminates the generation of invalid special logs during idle periods from the source, effectively reducing log storage usage, network transmission overhead, and the pressure on the backup database for replay processing, significantly saving cluster system resources. Furthermore, by uniformly stopping special logs based on feedback from the fastest backup database, it ensures that all slow backup databases with sufficient locally cached special logs can complete replay catching up, preventing log loss. This saves resources while completely avoiding backup database replay blocking, ensuring the stability of cluster data synchronization.

[0059] Step S207: Determine if the primary database has regenerated business logs. If the determination in step S207 is no, continue to step S206 to maintain the primary database's idle state. While idle, the primary database continuously monitors the generation of business logs, maintains an idle state when no business is being restored, continuously disables special logs, extends the effective duration of resource optimization, and further improves cluster resource utilization.

[0060] In step S208, if the determination in step S207 is yes, the primary database is switched to the business production state and the write-ahead log is regenerated. When the primary database detects business recovery and generates business logs, it automatically and seamlessly switches back to the business production state, restores the normal write-ahead log generation mechanism, and provides stable log input to each standby database in a timely manner. This ensures that the standby database paired heap works normally and the log replay process is continuous and uninterrupted, avoiding the impact of replay stagnation on the high availability of the cluster.

[0061] The specific values ​​of the set time window and set time interval used for generating the primary database recovery log can be customized by those skilled in the art based on the playback progress speed and resource consumption control objectives, thereby achieving an optimal balance between backup database playback efficiency and cluster resource consumption.

[0062] The method of this invention uses the standby database with the fastest replay progress as the sole feedback node, effectively avoiding signal conflicts and misjudgments caused by parallel feedback from multiple standby databases. This ensures that the idle feedback signal has global representativeness and prevents replay blocking caused by missing logs in lagging standby databases. Furthermore, it employs a dual-determination mechanism combining paired heap full leaf node sampling with duration analysis, accurately distinguishing between true cluster idleness and momentary periods without business activity, significantly improving the accuracy and anti-interference capability of idle state identification. When the cluster is idle, the generation and transmission of special logs are uniformly stopped, directly reducing storage consumption, network transmission, and computing power consumption caused by invalid logs, achieving efficient utilization of cluster resources. When the primary database resumes business operations, it automatically switches its running state and restores log output, ensuring continuous and stable log replay for standby databases. This approach balances resource optimization and high cluster availability, comprehensively improving the operational stability, data synchronization efficiency, and service reliability of the database cluster.

[0063] Figure 3 This is a flowchart illustrating the process of determining the feedback backup database in a database cluster log control method according to an embodiment of the present invention. Addressing the issues of inconsistent replay progress and conflicting feedback signals in multi-backup database clusters, this process achieves deterministic election of a globally unique feedback backup database based on ordered comparison of primary database nodes, iterative filtering of log sequence numbers, and static numbering as a fallback arbitration. This provides a reliable feedback entity for cluster idle determination and log control, specifically including the following steps S301 to S310.

[0064] Step S301: Sort the nodes of the primary database to obtain a list of primary database nodes. Sort the primary database nodes to organize the scattered primary database nodes in the cluster into a fixed and ordered comparison sequence, unify the comparison benchmark and execution order of subsequent log sequence numbers, and ensure that the feedback backup database determination process is deterministic and repeatable.

[0065] Step S302: Based on the primary database node list, collect the log sequence numbers of all standby databases corresponding to the same primary database node, and construct a sequence number set corresponding to the primary database node. The log sequence numbers are generally used to accurately characterize the log reception progress and replay capability of the standby databases to the corresponding primary database node. Collecting log sequence numbers from all standby databases along the same primary database node dimension allows for horizontal comparison of synchronization differences among standby databases under the same log stream source, providing a unified and objective quantitative basis for determining the speed of standby database progress, and ensuring the fairness and accuracy of the initial screening.

[0066] Step S303: Determine if there exists a unique and largest target log sequence number in the current sequence number set. The unique and largest log sequence number represents that the corresponding standby database has an absolute lead in log synchronization progress on the current master node. This determination step can quickly identify the standby database with the fastest global progress, reduce redundant iterative calculations, and effectively improve the efficiency of determining the feedback standby database.

[0067] Step S304: If the determination in step S303 is yes, the standby database corresponding to the target log sequence number is determined as the feedback standby database. The unique maximum log sequence number under a single master node is sufficient to prove that the standby database is the node with the fastest replay progress in the cluster. There is no need to continue traversing the other master database nodes to complete the election. Under the premise of ensuring the accuracy of the election results, the filtering logic can be greatly simplified and the system's computing and communication overhead can be reduced.

[0068] Step S305: If the determination in step S303 is negative, construct a standby database set corresponding to the standby databases with the largest tied log sequence numbers. A tie for the largest log sequence number indicates that multiple standby databases have completely identical replay progress on the current master node, making it impossible to directly distinguish between them. Constructing a standby database set narrows the scope of subsequent comparisons, allowing further filtering only on candidate standby databases with the same progress, avoiding redundant calculations on all standby databases, and thus significantly improving the execution efficiency of iterative filtering.

[0069] Step S306: After step S305 is completed, determine the next master database node in the master database node list as the master database node to be compared. Switch the nodes to be compared according to the ordered order of the master database node list, following the iterative rule of gradually refining from the master node with the lowest index, and peel off the candidate backup databases step by step based on the progress difference of multiple master nodes to ensure that the screening process is progressive.

[0070] Step S307: Determine whether the primary database node list has been traversed. This step is a termination boundary determination for iterative filtering, clarifying the execution upper limit of the election process, ensuring that the feedback backup database determination process is completed within a finite number of steps, and guaranteeing the stable operation of the overall cluster control process.

[0071] Step S308: If the determination in step S307 is negative, obtain the log sequence numbers received by all standby databases in the standby database set in the primary database node to be compared, thereby constructing a new sequence number set corresponding to the primary database node to be compared. Then continue to execute step S303. Before all primary database nodes have been traversed, reconstruct the sequence number set based on the new primary database node to be compared and repeat the uniqueness check. The candidate range can be further refined by utilizing the differences in log progress of different primary nodes, gradually narrowing down the standby database set until a unique leading standby database is found, ensuring the accuracy of the election results.

[0072] Step S309: If the determination in step S307 is yes, determine whether the standby database in the latest standby database set is unique. If the determination in step S309 is yes, continue to execute step S304. After traversing all master database nodes, if there is only one standby database left in the standby database set, it means that the standby database is the only qualified candidate after iterative screening and can be directly determined as the feedback standby database.

[0073] In step S310, if the determination in step S309 is negative, select the backup database with the smallest static number from the latest backup database set as the feedback backup database. If multiple candidate backup databases still exist after traversing all master database nodes, it indicates that the playback progress of each backup database is completely consistent across all master nodes. In this case, selecting the backup database with the smallest static number can achieve deterministic fallback election based on the fixed attributes of the backup database, ensuring that a unique feedback backup database can be output in all scenarios, thus avoiding signal conflicts and master database misjudgments caused by concurrent feedback from multiple backup databases from the root cause.

[0074] The method of this invention, by limiting feedback to the standby database with the fastest replay progress, ensures that the primary cluster can continuously generate necessary special logs, thereby preventing standby databases lagging behind in replay progress from experiencing lag or delays in log application. Simultaneously, the primary cluster avoids receiving false idle signals from multiple standby databases, preventing unnecessary waiting states and further optimizing resource allocation and improving overall transaction throughput. Furthermore, this method can promote progress coordination among standby databases, reduce the processing overhead of feedback messages on the primary cluster, achieve more efficient log transmission and application processes, thereby enhancing the system's real-time responsiveness, significantly reducing latency caused by replay, and improving user experience.

[0075] To more clearly illustrate the method of the present invention, a specific example of a database cluster log control workflow is provided below: Log synchronization phase: Each host node of the primary database generates write-ahead logs in real time and synchronously transmits them to the corresponding leaf nodes in the paired heaps of each standby database. Even when the cluster is not running real business operations, each host node continuously generates and sends special logs.

[0076] In the standby database determination phase, a standby database grouping and log LSN-based comparison mechanism are introduced. Only the standby database with the fastest replay progress is allowed to provide idle control information to the primary cluster, thereby ensuring that the primary cluster does not prematurely stop generating special logs due to the potential needs of the lagging standby database.

[0077] State sampling and determination phase: The backup database periodically samples all leaf nodes of its paired heap to identify the log types received by each node; when all leaf nodes receive special logs and the duration of this state reaches a preset time threshold, the primary database cluster is determined to be in an idle state.

[0078] Idle control phase: The standby database sends idle control information to the master database through the master-standby streaming replication channel. The master database responds to this information and enters the business idle state, controlling all host nodes to uniformly stop the generation and network transmission of special logs, thus eliminating redundant logs at the source.

[0079] Business recovery phase: The primary database monitors the business operation status in real time. When any host node regenerates business logs, it automatically switches to the business production state and restores the normal generation mechanism of write-ahead logs. In the business production state, the primary database generates special logs as needed based on a set time window and a set time interval to ensure stable log input and continuous playback process for the backup database's paired heap.

[0080] The specific values ​​of the preset time threshold, set time window, and set time interval can be configured and adjusted by those skilled in the art according to the cluster size, business load characteristics, and system stability requirements to adapt to diverse deployment scenarios.

[0081] Based on the above design, the standby database and the primary database have different mechanisms, specifically: Standby database mechanism: The standby database with the fastest replay progress among multiple standby databases is selected as the feedback standby database. The feedback standby database maintains a pairing heap, used to select the smallest log sequence number from the WAL streams input from multiple master database nodes for replay. The leaf nodes of the pairing heap represent the WAL sources of each master database node. To determine whether the master database is idle, the standby database executes the following logic: (1) Sample the contents of the leaf nodes of the paired heap. If all leaf nodes are special logs in the continuous sampling window, it is assumed that there is no real business WAL input in the main database.

[0082] (2) Continuous observation time y seconds. If the above state duration reaches the preset threshold y, the entire main cluster is considered to have entered the "idle state".

[0083] (3) Send an idle notification to the primary database and the backup database sends a control message indicating that the cluster is idle through the streaming replication channel. For example, this message can be denoted as primary_cluster_idle.

[0084] Master database state machine mechanism: To respond to backup database notifications and dynamically control the generation of special logs based on the business WAL generation status, the master database is designed with the following two-state state machine: (1) State 1: Need_Special_WAL. This state indicates that the primary database has generated a business WAL or has not yet been confirmed to enter the idle state, and it is necessary to maintain the activity of the replay link. In this state: If a primary database node does not generate any business WAL within a very short time window (e.g., 10ms), the node will proactively generate a special log at a fixed time interval x to ensure that the feedback backup database pairing heap has sufficient input to maintain progress.

[0085] If the primary database receives the primary_cluster_idle message, it immediately stops all nodes from generating special logs and switches the status to Not_Need_Special_WAL.

[0086] (2) State Two: Not_Need_Special_WAL. This state indicates that the master database has confirmed it is in an idle state and does not require special logs to maintain the progress of the pairing heap. In this state: The master database completely stops the special log output of all nodes, eliminating waste in scenarios without business operations.

[0087] If any node in the primary database regenerates the business WAL, the state will be immediately switched back to Need_Special_WAL, and the dynamic generation strategy of special logs will be restored according to the time window check mechanism to maintain the replay activity of the standby database.

[0088] The example above introduces two key parameters for balancing system performance and resource utilization: (1) Parameter x: The interval at which a single node in the master database automatically generates special logs when it is idle. The smaller the value, the faster the backup database fills the matching heap, thus accelerating the replay process. However, this will increase the frequency of special log generation, leading to increased resource waste. The larger the value, the less resource waste, but it may slightly slow down the replay process.

[0089] (2) Parameter y: The duration of observation when all leaf nodes of the standby database are special logs. The smaller the value, the earlier the master database can switch to the idle state and the more agile the response, but it will increase the communication overhead between the master and standby databases and the frequency of state switching. The larger the value, the lower the frequency of state switching and the more stable the system, but it will prolong the invalid generation period of special logs and increase potential waste.

[0090] Based on the above design, the feedback standby database maintains a paired heap structure during replay, where each leaf node corresponds to a WAL input from a different primary database node. The method of this invention samples these nodes and statistically analyzes their WAL types within a fixed time window. When all leaf nodes continuously generate special logs for a duration exceeding a threshold y, the feedback standby database can infer that the entire primary cluster has not written any actual business WAL during this interval. This determination method relies entirely on existing messages on the replay side, requiring no additional probing capabilities, thus avoiding additional network probing overhead, protocol complexity, or new resource consumption. Compared to traditional heartbeat and load detection, this mechanism's advantage lies in reflecting actual WAL behavior, making the judgment more reliable. When the feedback standby database confirms that the primary cluster has entered an idle state, it sends a lightweight control message back to the primary database as confirmation of the entire cluster's idle state. This information is transmitted through the existing streaming replication channel, allowing the primary database to immediately learn the standby database's global determination result and thus pause the output of special logs.

[0091] The output behavior of the special logs of the primary database is controlled by a simple and stable state machine. The state machine switches between two states based on conditions such as "whether there is real business WAL input" and "whether an idle signal is received": In the Need_Special_WAL state, the primary database needs to generate special logs at specified time intervals to ensure that the backup database pairing heap has a continuous source of LSNs; In the Not_Need_Special_WAL state, the primary database completely stops generating special logs and only retains real business WALs.

[0092] In the Need_Special_WAL state, the master database determines the generation cycle of special logs based on parameter x. If no new business WALs are generated within the specified time, the master database replenishes the logs at intervals of x, ensuring that the pairing heap does not stagnate due to a prolonged lack of LSN input. Once any node in the master database generates a real business WAL, the system immediately switches from the Not_Need_Special_WAL state back to the Need_Special_WAL state to prevent the pairing heap from becoming blocked due to the continuous disabling of special logs.

[0093] Furthermore, an example of an optional implementation of the election feedback backup library in this invention is as follows: Assume the primary cluster contains N nodes (node ​​numbers i = 1, 2, ..., N), each node independently generates WAL logs and transmits them to M standby databases (standby database numbers s = 1, 2, ..., M) via streaming replication. Node i in each standby database s maintains a recently received WAL log LSN, denoted as last_receive_lsn_s_i. This LSN is typically a 64-bit sequence number representing the latest log position received but not yet fully replayed by the standby node, used to measure replay progress. LSN comparison follows standard log ordering rules: the larger the LSN value, the faster the node is progressing.

[0094] The execution process of the election feedback backup database typically includes: (1) Backup database initialization and LSN collection: Each backup database s collects the last_receive_lsn_s_i of all nodes i at startup or periodically. These LSN values ​​are synchronized through the communication protocol between backup databases.

[0095] (2) Standby database grouping and LSN comparison: To determine which standby database is eligible to respond to the primary_cluster_idle message, the standby databases are dynamically grouped and compared node by node. This process uses an iterative algorithm, gradually refining from the lowest node. The specific steps include: Step 1: Starting from node i = 1, collect the last_receive_lsn_s_i of all standby databases s for the same node i to form an LSN set Ri = {last_receive_lsn_1_i, last_receive_lsn_2_i,..., last_receive_lsn_M_i}. This set reflects the progress differences of different standby databases in receiving the primary node's log.

[0096] Step 2: Compare the LSN values in Ri: If there is a unique maximum LSN, that is, the last_receive_lsn_s_i of a certain primary database s is the maximum value in Ri and there is no tie, then this standby database s is selected as the feedbacker and sends a primary_cluster_idle message to the primary cluster. The comparison process ends and returns a success status.

[0097] If the LSNs of multiple standby databases are tied for the maximum, for example, the last_receive_lsn of standby database 1 and standby database 3 are equal and both are the maximum values, then perform the following steps: Increment the node index i (i++), and ensure that i does not exceed N; form a temporary set Wi with these tied standby databases; for the standby database s in Wi, extract their last_receive_lsn_s_i at the next node i to form a new Ri set; go to Step 3 for iterative checking, and set the maximum iteration limit to N.

[0098] Step 3: Check the current node index i: If i < N, return to Step 2 and continue to compare the LSN sets of the next node to further refine the Wi set until a unique fastest standby database is found or the end is reached.

[0099] If i == N, that is, all nodes have been compared and there are still multiple standby databases in Wi, then select the standby database with the smallest number in Wi as the feedbacker to ensure determinism based on the static numbering and avoid inconsistencies introduced by randomness.

[0100] (3) Feedback execution: The selected standby database only sends a primary_cluster_idle message when its own replay is not stuck, that is, the local log application is smooth and there is no waiting for Special_WAL. Other standby databases do not send this message to the primary database.

[0101] Through the above comparison logic, the standby database with the fastest replay represents the forefront speed of the system, ensuring that the lagging standby databases can smoothly follow the cluster progress without getting stuck due to log missing.

[0102] The above methods significantly improve the stability and efficiency of RAC streaming replication. On one hand, they significantly reduce special log output during periods of concentrated idle time: through idle detection mechanisms and master-slave collaboration strategies, the generation of special logs is fully correlated with actual business needs, and output can be completely stopped during large idle windows, reducing the amount of invalid logs. On the other hand, they reduce the pressure on the master and slave database WAL directories and archiving systems: the reduction in the number of special logs significantly slows the growth rate of the master database WAL directory, alleviating the pressure on the archiving system and making it easier to maintain a stable log cleanup strategy. Simultaneously, they directly reduce network traffic consumption and lower the WAL parsing pressure in the streaming replication protocol. Furthermore, the method of this invention can adapt to complex and diverse workload patterns: during peak business periods, the state machine automatically maintains necessary special log output to ensure uninterrupted playback; in intermittent and low-frequency scenarios, it can quickly enter a low-overhead mode. The entire system has a certain degree of automatic adjustment capability, maximizing system resource conservation while ensuring high availability, data consistency, and operational stability of the database cluster, adapting to all scenarios of business load, including peak, intermittent, and fully idle periods.

[0103] In addition, the method of this invention, by designating the standby database with the fastest replay progress as the feedback standby database, ensures that the primary cluster can continuously generate necessary special logs, thereby avoiding stuttering caused by missing or delayed logs during application by standby databases with lagging replay progress. Simultaneously, the primary cluster is spared from receiving false idle signals from multiple standby databases and entering unnecessary waiting states, further optimizing resource allocation and improving overall transaction throughput. Furthermore, since the method of this invention does not require feedback information from other standby databases, it further promotes progress coordination among standby databases, reduces the processing overhead of feedback messages for the primary cluster, and achieves a more efficient log transmission and application process.

[0104] The flowchart provided in this embodiment is not intended to indicate that the operations of the method will be performed in any particular order, or that all operations of the method are included in every case. Furthermore, the method may include additional operations. Within the scope of the technical concept provided by the method in this embodiment, additional variations can be made to the above method.

[0105] It should be understood that in some embodiments, the components may be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods may be implemented using software or firmware stored in memory and executed by a suitable instruction execution system.

[0106] This embodiment also provides a computer program product 10, a computer-readable storage medium 20, and a computer device 30. Figure 4 This is a schematic diagram of a computer program product 10 according to an embodiment of the present invention. Figure 5This is a schematic diagram of a computer-readable storage medium 20 according to an embodiment of the present invention. Figure 6 This is a schematic diagram of a computer device 30 according to an embodiment of the present invention. The computer program product 10 includes a computer program 11, which, when executed by the processor 32, implements the steps of the log control method for the database cluster described above. A computer-readable storage medium 20 stores the computer program 11 thereon, which, when executed by the processor 32, implements the steps of the log control method for the database cluster described above. The computer device 30 may include a memory 31, a processor 32, and the computer program 11 stored on the memory 31 and running on the processor 32.

[0107] The computer program 11 used to perform the operations of this invention may be assembly instructions, Instruction Set Architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages ​​and procedural programming languages. The computer program 11 may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a Local Area Network (LAN) or Wide Area Network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, to perform aspects of this invention, electronic circuits, including, for example, programmable logic circuits, Field-Programmable Gate Arrays (FPGAs), or Programmable Logic Arrays (PLAs), may execute computer-readable program instructions to personalize the electronic circuits by utilizing state information from computer-readable program instructions.

[0108] For the purposes of this embodiment, computer program product 10 is a related product containing computer program 11. For the purposes of this embodiment, computer-readable storage medium 20 is a tangible device capable of holding and storing computer program 11, and can be any device capable of containing, storing, communicating, propagating, or transmitting program 11 for use by or in conjunction with an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable storage medium 20 include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable optical disc read-only memory (CD-ROM), digital versatile disc (DVD), memory stick, floppy disk, mechanical encoding device, and any suitable combination thereof.

[0109] Computer device 30 can be, for example, a server, desktop computer, laptop computer, tablet computer, or smartphone. In some examples, computer device 30 can be a cloud computing node. Computer device 30 can be described in the general context of computer system executable instructions (such as program modules) executed by a computer system. Typically, program modules can include routines, programs, object programs, components, logic, data structures, etc., that perform specific tasks or implement specific abstract data types. Computer device 30 can be implemented in a distributed cloud computing environment where tasks are performed by remote processing devices linked through a communication network. In a distributed cloud computing environment, program modules can reside on local or remote computing system storage media, including storage devices.

[0110] Computer device 30 may include a processor 32 adapted to execute stored instructions and a memory 31 that provides temporary storage space for the operation of said instructions during operation. The processor 32 may be a single-core processor, a multi-core processor, a computing cluster, or any other configuration. The memory 31 may include random access memory (RAM), read-only memory, flash memory, or any other suitable storage system.

[0111] Computer device 30 may also include a network adapter / interface and an input / output (I / O) interface. The I / O interface allows external devices that can be connected to the computer device to input and output data. The network adapter / interface provides communication between the computer device and a network, typically represented as a communication network.

[0112] Therefore, those skilled in the art should recognize that although numerous exemplary embodiments of the present invention have been shown and described in detail herein, many other variations or modifications conforming to the principles of the present invention can be directly determined or derived from the disclosure of the present invention without departing from the spirit and scope of the invention. Thus, the scope of the present invention should be understood and construed as covering all such other variations or modifications.

Claims

1. A log control method for a database cluster, comprising: In the database cluster, each standby database receives the write-ahead logs from the corresponding master database through the leaf nodes of its own paired heap. The paired heap is used to receive the write-ahead logs sent from the master database to the standby database. The write-ahead logs include business logs and special logs. The business logs are used to record specific business data, and the special logs are used to advance the playback version number of the standby database. The leaf nodes correspond one-to-one with the master database. Among the multiple backup databases, the backup database with the fastest playback progress is selected as the feedback backup database; If all the write-ahead logs received by the leaf nodes of the feedback backup database are the special logs and the duration reaches a preset time threshold, the feedback backup database is controlled to send idle control information to the primary database. In response to the idle control information, the master database enters a business idle state and stops the generation and transmission of the special logs.

2. The log control method for a database cluster according to claim 1, wherein, The step of stopping the generation and transmission of the special log also includes: If the master database regenerates the business logs, then the master database is switched to the business production state, and the special logs are regenerated according to the preset inspection rules.

3. The log control method for a database cluster according to claim 2, wherein, The step of regenerating the special log according to the preset inspection rules includes: If the master database fails to generate the business log within a set time window and does not receive the idle control information, the master database is controlled to generate the special log at set time intervals.

4. The log control method for a database cluster according to claim 1, wherein, The step of determining the backup database with the fastest playback progress among the multiple backup databases as the feedback backup database includes: Obtain the last log sequence number received by each standby database in relation to each primary database; The backup database with the largest log sequence number is selected as the feedback backup database based on the log sequence number.

5. The log control method for a database cluster according to claim 4, wherein, The step of selecting the backup database with the largest log sequence number as the feedback backup database based on the log sequence number includes: Sort the nodes of the main database to obtain a list of main database nodes; Based on the list of master database nodes, collect the log sequence numbers of all the backup databases corresponding to the same master database node, and construct the sequence number set corresponding to the master database node; Determine whether there exists a unique and largest target log sequence number in the set of sequence numbers; If there is a unique and largest target log sequence number in the set of sequence numbers, the backup database corresponding to the target log sequence number is determined as the feedback backup database.

6. The log control method for a database cluster according to claim 5, wherein, Following the step of determining whether a unique and largest target log sequence number exists in the sequence number set, the following is also included: If there is no single largest target log sequence number in the sequence number set, but there are multiple backup databases with the same largest log sequence number, the backup databases corresponding to the log sequence number with the same largest log sequence number are constructed into a backup database set. The next master database node in the master database node list is determined as the master database node to be compared. Obtain the log sequence numbers received by all the backup databases in the backup database set in the primary database node to be compared, thereby constructing a new sequence number set corresponding to the primary database node to be compared; Based on the new sequence number set, the step of determining whether there is a unique and largest target log sequence number in the sequence number set is executed again until the list of feedback backup database or primary database node has been traversed.

7. The log control method for a database cluster according to claim 6, wherein, Also includes: If the backup database has not been determined after traversing the list of primary database nodes, determine whether the backup database in the latest backup database set is unique. If so, then the backup database in the latest backup database set is determined as the feedback backup database; If not, then select the backup database with the smallest static number from the latest backup database set as the feedback backup database.

8. A computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the log control method for a database cluster according to any one of claims 1 to 7.

9. A computer program product comprising a computer program that, when executed by a processor, implements the steps of the log control method for a database cluster as described in any one of claims 1 to 7.

10. A computer device comprising a memory, a processor, and a machine-executable program stored in the memory and running on the processor, wherein the processor, when executing the machine-executable program, implements the steps of the log control method for a database cluster according to any one of claims 1 to 7.

Images