Admission control methods for database replication

Abstract

This application provides an admission control method for database replication. This method decouples basic backup permissions from log replication permissions by separating one-time bootstrap authorization credentials from streaming replication authorization credentials. Even if a credential is leaked, an attacker can only obtain static data (if a one-time credential is leaked) or incremental logs (if a streaming credential is leaked), but not both simultaneously. This significantly reduces the risk of a single leak of the entire database due to a high-privilege credential leak. Furthermore, by incorporating the basic backup fingerprint and authorization information into a causal window commitment, a multi-dimensional binding anti-reuse mechanism is formed. Any attempt to use a legitimate credential for a non-original authorization scenario will result in handshake verification failure or runtime circuit breaking, thereby reducing the probability of unauthorized reuse of streaming authorization credentials. This method improves database replication security.

Description

Technical Field

[0001] This application relates to the field of database technology, and in particular to an admission control method for database replication. Background Technology

[0002] Database master-slave replication, cascading replication, and failover mechanisms are crucial foundations for achieving high availability, disaster recovery, and read-write separation in databases. Existing database replication mechanisms typically rely on replication accounts, long-term passwords, static certificates, IP whitelists, or simple connection strings for access control.

[0003] While this method is relatively inexpensive to implement, once high-privilege credentials are leaked, attackers can not only establish unauthorized copying sessions but may also directly obtain basic backup data, resulting in the leakage of the entire database. Summary of the Invention

[0004] To address the existing technical problems, this application provides an admission control method for database replication that can improve database replication security.

[0005] Firstly, a database replication admission control method is provided, applied to a database replication system including a master node, slave nodes, and an authentication controller, the method comprising: The slave node generates a node identity key pair, collects static metric vectors and runtime attitude vectors, and reports them to the authentication controller. The authentication controller constructs a replication intent graph and calculates a replication intent graph digest; The authentication controller calculates an initial comprehensive trust score based on the static metric vector and the operational attitude vector. When the initial comprehensive trust score meets the admission threshold, it issues a one-time boot authorization credential for basic backup. The master node opens the basic backup to the slave node based on the one-time boot authorization credential, and generates a basic backup fingerprint which is sent to the authentication controller; The authentication controller generates a causal window commitment based on the basic backup fingerprint, authorization information, and slave node public key, and issues streaming replication authorization credentials for log replication. During the log replication handshake process, the master node reconstructs the replication intent graph summary and causal window commitment, and when the reconstruction result is consistent with the replication intent graph summary and causal window commitment carried in the streaming replication authorization certificate, it allows the slave node to join the target replication group.

[0006] The database replication access control method provided in the above embodiments decouples basic backup permissions from log replication permissions by separating one-time bootstrap authorization credentials from streaming replication authorization credentials. Even if a credential is leaked, an attacker can only obtain static data (if a one-time credential is leaked) or incremental logs (if a streaming credential is leaked), but cannot obtain both simultaneously. This significantly reduces the risk of a single outflow of the entire database due to the leakage of high-privilege credentials. Simultaneously, by incorporating the basic backup fingerprint and authorization information into a causal window commitment, a multi-dimensional binding anti-reuse mechanism is formed. Any attempt to use a legitimate credential for a non-original authorization scenario will result in handshake verification failure or runtime circuit breaking, thereby reducing the probability of unauthorized reuse of streaming authorization credentials. This method improves database replication security. Attached Figure Description

[0007] Figure 1 This is a schematic diagram of the architecture of a database replication system in one embodiment.

[0008] Figure 2 This is a flowchart of an admission control method for database replication in one embodiment.

[0009] Figure 3 This is a schematic diagram of the fault handover term migration and authorization credential rebinding process in one embodiment.

[0010] Figure 4 This is a schematic diagram of the causal window commitment generation process in one embodiment.

[0011] Figure 5 This is a flowchart of an admission control method for database replication in another embodiment. Detailed Implementation

[0012] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0013] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0014] In the following description, the phrase "some embodiments" refers to a subset of all possible embodiments. It should be noted that "some embodiments" can be the same subset or different subsets of all possible embodiments, and can be combined with each other without conflict.

[0015] In the following description, the terms "first, second, and third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, and third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0016] like Figure 1 As shown, a database replication system according to one embodiment includes at least: a master node. Slave node Authentication controller Audited ledgers and an optional set of witness nodes .

[0017] The master node is used to provide basic backup, log stream and replication slot management capabilities, and performs refactoring verification of replication intent graph summary and causal window commitment during the handshake phase.

[0018] The slave node is used to request basic backups and log replication, and periodically outputs the continuous execution proof chain value.

[0019] The authentication controller is used to perform trust scoring, replication intent map generation, causal window commitment generation, authorization credential issuance, risk assessment, and audit logging.

[0020] The audit ledger is used to record certification, issuance, handshake, renewal, failover, and handling events.

[0021] The witness node set is used to perform threshold signature confirmation of term migration certificates in failover scenarios.

[0022] Based on the aforementioned database replication system, this application provides an admission control method for database replication. This method is applied to the aforementioned database replication system, such as... Figure 2 As shown, it includes: Step 202: The slave node generates a node identity key pair, collects a static metric vector and a running attitude vector, and reports them to the authentication controller.

[0023] Specifically, the slave node generates a node identity key pair in a trusted execution environment, trusted platform module, or protected key area, collects static metric vectors and runtime attitude vectors, and reports them to the authentication controller.

[0024] The static metric vector is a set of features collected before or during system startup or component loading that reflects the static trust baseline of the slave node. These features include hardware fingerprints, firmware, operating system and boot chain, database binary and configuration files, and container / virtualization environment. These metrics are relatively stable during runtime and are used to verify whether the node starts from a trusted state.

[0025] The operational attitude vector is a set of features continuously collected during database replication operations that reflect the compliance of the dynamic behavior of slave nodes. These features include replication process sets, dynamically loaded libraries and plugins, log capture status, runtime environment variables and security policies, and replication queue behavior. These metrics change over time and are used to detect abnormal behavior or deviations from the expected baseline during node operation.

[0026] Step 204: The authentication controller constructs a copy intent graph and calculates a copy intent graph summary.

[0027] The replication intent graph is a directed graph structure built by the authentication controller based on replication policies, node role relationships, target master databases, replication slots, failover terms, allowed log sub-windows, basic backup constraints, and renewal policies. It is represented as follows: Where: Vertex set It must include at least: master database vertex, slave database vertex, replication slot vertex, term vertex, basic backup vertex, and log window vertex; edge set. It must include at least: edges that allow basic backup, edges that allow log replication, edges that allow renewal, edges that allow term migration, and edges that allow window expansion; vertex attribute mapping. Attach static or dynamic attributes such as identity, state, and parameters to each vertex; edge attribute mapping. Add authorization conditions, constraints, and operation permissions to each edge.

[0028] The replication intent graph is used to uniformly express the authorization relationships, dependency constraints, and policy intents in database replication admission control, and its integrity and immutability are ensured by computing its cryptographic digest.

[0029] Step 206: The authentication controller calculates an initial comprehensive trust score based on the static metric vector and the operational attitude vector. When the initial comprehensive trust score meets the admission threshold, a one-time boot authorization credential for basic backup is issued.

[0030] One-time boot authorization certificate Basic backup permissions used in the basic backup phase, and subject to a single-use constraint, can be represented as: in, Indicates the validity period of the basic backup authorization. This represents a one-time random number, which, in conjunction with the single-redemption constraint, ensures that the voucher can only be used once, preventing replay attacks. Indicates the scope of basic backup permissions. Indicates the current failover term number, and binds the credentials to a specific term; This indicates the copy slot identifier, which limits the copy slots that this certificate can use and prevents unauthorized slots from being used for backups; This is a unique identifier for the target primary database, ensuring that the credential can only be used to request a basic backup from the specified primary database, thus preventing abuse across primary databases. This represents the hash value of the slave node's public key, used to bind credentials to the identity of a specific slave node and prevent other nodes from impersonating it.

[0031] Traditional replication authentication primarily verifies the validity of credentials, but struggles to confirm whether the node holding the credential is in an approved hardware, firmware, operating system, database software, and deployment environment state. There is a lack of effective binding between node identity and node state. In this embodiment, a one-time boot authorization credential for basic backup is issued only when the initial comprehensive trust score calculated based on the static metric vector and the operational attitude vector meets the admission threshold. This ensures that only trusted slave nodes that have undergone dual identity and environment verification can obtain basic backups.

[0032] Step 208: The master node opens the basic backup to the slave node based on the one-time boot authorization credential.

[0033] Specifically, the authentication controller issues a one-time boot authorization credential to the slave node. When requesting basic backup, the slave node sends the one-time boot authorization credential to the master node. The master node verifies the signature, validity period, master-master binding relationship, node public key binding relationship, and single redemption constraint of the one-time boot authorization credential. After successful verification, the master node opens the basic backup to the slave node.

[0034] Meanwhile, the master node generates a basic backup fingerprint, summarizes the backup data, and sends it to the authentication controller as evidence that the backup operation was successful and the data is complete.

[0035] Step 210: The authentication controller generates a causal window commitment based on the base backup fingerprint, authorization information and slave node public key, and issues streaming replication authorization credentials for log replication.

[0036] Authorization information includes tenure, replication slots, log window range, etc. Streaming replication authorization credentials. This is used to grant only log replication permissions during the log replication phase, and can be represented as: in, Indicates the duration of the streaming replication license. Represents a random number. This indicates the scope of log replication permissions. Streaming replication authorization credentials do not grant basic backup permissions; This represents the hash value of the slave node's public key, used to bind credentials to the identity of a specific slave, ensuring that only the slave with the corresponding private key can use the credential. This represents a summary of the intent to copy. This indicates a causal window commitment. This represents the hash value of the base backup fingerprint. It binds credentials to a specific initial baseline dataset, preventing them from being used on unauthorized or tampered backup copies. This indicates the role of the slave node in the replication group. This indicates the term number for fault handover.

[0037] By generating a causal window commitment using the base backup fingerprint, authorization information, and slave public key, the issued streaming replication authorization certificate can only be used for log replication based on the specific base backup, specific slave identity, and specific authorization information (such as tenure, replication slot, and log window range), and cannot be reused for other backup sets or other slaves.

[0038] Step 212: During the log replication handshake process, the master node reconstructs the replication intent graph summary and causal window commitment. When the reconstruction result is consistent with the replication intent graph summary and causal window commitment carried in the streaming replication authorization certificate, the slave node is allowed to join the target replication group.

[0039] When a slave node initiates a log replication handshake with the master node carrying streaming replication authorization credentials, the master node reconstructs the replication intent graph summary based on the current session context. and causal window commitment And verify: as well as: in, This represents a summary of the intent graph for refactoring. This represents a summary of the replication intent graph carried in the streaming replication authorization certificate; This represents the causal window commitment to reconstruction. This indicates the causal window commitment carried in the streaming replication license.

[0040] Additionally, the validity of the streaming replication authorization certificate can be further verified based on the node's public key digest, node role, current term, and replication slot identifier. Only when all the above conditions are met will the master node allow the slave node to join the corresponding replication group and open the corresponding replication slot.

[0041] In this way, by having the master node perform real-time, bidirectional integrity verification on the streaming replication authorization credentials held by the slave nodes, it ensures that the authorized content is consistent with the current system policies and constraints, preventing tampering, replay, or unauthorized binding. Offline-issued credentials are aligned with the real-time status of the master node, ensuring that every replication handshake is performed under the premise of legitimate, trusted, and tamper-proof authorization.

[0042] This database replication admission control method decouples basic backup permissions from log replication permissions by separating one-time bootstrap authorization credentials from streaming replication authorization credentials. Even if a credential is leaked, an attacker can only obtain static data (if a one-time credential is leaked) or incremental logs (if a streaming credential is leaked), but not both simultaneously. This significantly reduces the risk of a single leak of the entire database due to a high-privilege credential leak. Furthermore, by incorporating the basic backup fingerprint and authorization information into a causal window commitment, a multi-dimensional binding anti-reuse mechanism is formed. Any attempt to use a legitimate credential for a non-original authorization scenario will result in handshake verification failure or runtime circuit breaking, thereby reducing the probability of unauthorized reuse of streaming authorization credentials. This method improves database replication security.

[0043] In one embodiment, the admission control method for database replication further includes: During the replication process, the master node or authentication controller periodically receives the continuous execution proof chain value from the slave node and the runtime attitude quantity summary generated from the current runtime attitude quantity vector, updates the comprehensive trust score, and calculates the replication risk score based on the updated comprehensive trust score and multi-dimensional risk deviation measures. The risk deviation measures include at least two of the following: graph deviation, window deviation, runtime drift, behavior anomaly, and failover deviation. When the replication risk score reaches the disposal conditions, execute at least one of the following control operations: replication slot freeze, log stream circuit breaker, window shrink, voucher revocation, renewal rejection, or forced reboot.

[0044] The continuous execution proof chain is a hash chain continuously generated and reported by the slave node during log replication. This chain is used to verify whether the execution environment of the slave node is continuous and trustworthy from the time replication is established to the present moment. The master or authentication controller can determine whether the slave has been tampered with or attacked during operation by checking whether the chain value is continuous (without breakpoints), whether it has been reused by other nodes, and whether a rollback has occurred.

[0045] Given that a node's trust status is not static, during initial admission, the authentication controller calculates an initial overall trust score based solely on static metrics and initial runtime attitude metrics, and issues a one-time boot authorization credential accordingly. However, during subsequent long-term replication, a node's environment may change (e.g., dynamic loading of malware, configuration file tampering, process injection, abnormal replication behavior, etc.). Continuing to make decisions based solely on the initial score would miss runtime risks.

[0046] In this embodiment, the execution environment of the slave database is verified by continuously executing the proof chain to ensure that it has not been interrupted, rolled back, or impersonated. The comprehensive trust score is updated based on the continuous execution proof chain and the runtime attitude quantity digest. The trustworthiness of nodes is continuously verified throughout the replication process.

[0047] Based on the comprehensive credibility score and multidimensional risk deviation measurement, the replication risk score is calculated, which quantifies the degree of risk in the replication process.

[0048] Among them, the multidimensional risk deviation measurement includes at least two of the following: graph deviation, window deviation, runtime drift, abnormal behavior, and failover deviation. These measures quantify the risk level of slave nodes from multiple dimensions, such as policy consistency, log window compliance, runtime environment stability, replication behavior abnormality, and failover succession correctness.

[0049] In one embodiment, during the replication process, the master node or authentication controller calculates the graph deviation. Window deviation Degree of operational drift Degree of behavioral abnormality and fault switching deviation .

[0050] Among them, graph deviation This is used to represent the degree of difference between the replication intent graph reconstructed by the primary node in the current session context and the replication intent graph registered in the authorization credential. Let the replication intent graph summary carried in the authorization credential be... The summary obtained from the reconstruction of the master node is Then the deviation of the graph is defined as: When using strict summary consistency comparison Window deviation This represents the degree of difference between the log range corresponding to the current replication request and the authorized causal window commitment. Let the authorized window set be... The actual set of request windows is Then it can be defined as: in, This is a smoothing term.

[0051] Running drift degree This is used to represent the degree of difference between the current operational attitude quantity and the baseline operational state. Let the current operational attitude quantity vector be... The baseline vector is ,but: in, This is the drift sensitivity coefficient.

[0052] Degree of behavioral abnormality The formula used to measure abnormal log fetch rates, abnormal request frequencies, and the intensity of sudden behavior during the replication process is as follows: in, Indicates the current log fetch rate. Indicates the baseline log fetch rate. Indicates the current request frequency. Indicates the baseline request frequency. Indicates the intensity of sudden behavior. This is a smoothing term.

[0053] Fault switching deviation This measure, used to quantify the deviation between the current replication session and failover legacy information, includes at least tenure deviation, master database identity deviation, and secure failover location deviation, and can be defined as: in, For indicator functions, , and Derived from term-of-office migration certificate, Indicates the term number used by the current replication session. This indicates the new term number registered in the term migration certificate; Indicates the identifier of the master database to which the current replication session is connected; This indicates the new master database identifier registered in the term migration certificate; This indicates the current log sequence number position of the slave that has been consumed or requested. Indicates the location of the security handover log registered in the term migration certificate; and These are the weighting coefficients, and .

[0054] Copy risk score Calculate according to the following formula: in, , This represents the overall credibility score.

[0055] By conducting a comprehensive risk assessment based on runtime drift, behavioral anomalies, graph deviation, window deviation, and fault switching deviation, dynamic risk control and refined handling can be achieved during the database replication process.

[0056] Based on the updated comprehensive trust score and multi-dimensional risk deviation measures, a replication risk score is calculated. This quantitatively integrates the trust status and multi-dimensional operational anomalies of the slave node to characterize the risks during the replication process. The higher the score, the greater the likelihood or severity of problems with the slave node in terms of identity, environment, behavior, authorization compliance, and fault propagation.

[0057] When the replication risk score reaches the disposal condition, at least one of the following control operations is executed: replication slot freezing, log stream circuit breaking, window shrinking, credential revocation, renewal rejection, or forced reboot. Thus, adaptive protection based on real-time risk scores automatically executes matching degradation, isolation, or reset actions before the risk deteriorates, thereby achieving a balance between security and availability.

[0058] For example, when the replication risk score reaches the handling conditions, freezing replication slots or circuit breaking log streams can immediately sever the data synchronization channel between the slave node and the master, preventing malicious or faulty nodes from continuing to pull incremental logs, thereby blocking the risk from spreading within the cluster. Window shrinking operations can compress the log range that the slave is allowed to access to to a safer subset, dynamically reducing its permissions and exposure surface even if credentials have not expired. Revoking credentials, refusing renewal, or forcing a reboot will cause the slave to lose its existing authorization, requiring it to re-execute the basic backup and access certification process, thereby clearing its potentially contaminated environment and returning it to a trusted state. Timely circuit breaking of abnormal replication links can prevent abnormal behavior of a single slave (such as excessively high log pulling rates) from exhausting master or network resources, thus maintaining the stability of the cluster's external services.

[0059] In one embodiment, when the replication risk score is less than the warning threshold, the current replication relationship is maintained. At this time, the system considers the slave node to be in a safe, trustworthy, and compliant state, requiring no intervention and ensuring replication performance and low latency.

[0060] In one embodiment, when the replication risk score reaches the warning threshold but not the handling threshold, it indicates that the risk is increasing. At this time, flexible risk control measures such as increasing the reporting frequency of continuous execution proof, shrinking the allowed log window, or limiting the replication rate can be adopted to avoid the interruption of normal business due to excessive sensitivity, and to prevent the risk from further escalating to the handling threshold, thus achieving early intervention before the risk deteriorates.

[0061] Specifically, the reporting frequency of continuous execution certificates This indicates the frequency at which the slave node submits continuous execution proof chain values ​​and runtime attitude quantity summaries during the replication process. It can be set according to a fixed time interval, a fixed log volume interval, or an event triggering method.

[0062] Under normal circumstances, the reporting frequency of proofs is based on the fundamental frequency. When the replication risk score reaches the warning threshold but has not yet reached the handling threshold, the proof frequency will be increased to: in, To maximize the allowed proof frequency, To increase the coefficient, This indicates the intensity of the warning. Increasing the frequency of proofs aims to shorten the detection latency of broken, rolled-back, or reused proof chains, improve the sampling resolution of runtime drift and abnormal log capture, and achieve flexible risk control through higher-density verification without immediately severing the replication link. This provides a more sufficient basis for subsequent decisions on whether to implement rate limiting, window shrinking, or authorization credential revocation.

[0063] By shrinking the allowed log window, the range of logs that can be pulled from the slave can be dynamically reduced (e.g., only the most recent small window is allowed). Even if the credentials have not expired, this can effectively limit the amount of data that can be accessed in the future, reducing the risk of data leakage or unauthorized access.

[0064] By limiting the replication rate, the log retrieval speed of the slave database can be reduced, preventing abnormal high-speed consumption from consuming master database or network resources. At the same time, more time is gained for anomaly detection, reducing the impact of sudden behavior on cluster stability.

[0065] In one embodiment, the handling threshold is dynamically determined based on cluster load status, failover sensitivity, historical risk debt, and audit health; wherein: when cluster load status increases, failover sensitivity increases, or historical risk debt worsens, the handling threshold decreases; when audit health is high, the handling threshold increases.

[0066] Among them, cluster load status can be represented by cluster load factor, failover sensitivity can be represented by failover sensitivity factor, historical risk debt can be represented by historical risk debt factor, and audit health can be represented by audit health factor.

[0067] Specifically, in order to balance security and availability, risk handling thresholds... Adjust dynamically according to the following formula: in, The default threshold for offline calibration is preferably normalized to a range. ; Indicates the cluster load factor. Indicates the fault-tolerant factor, Indicates historical risk debt factor, This indicates the audit health factor; , , and For weights.

[0068] The parameters can be further defined as follows: (1) Cluster load factor Indicates the current database cluster in time The overall load level can be calculated by weighting CPU utilization, memory usage, network bandwidth usage, and replication queue backlog: in, ; Indicates CPU utilization; Indicates memory usage; Indicates network bandwidth utilization; This indicates the degree of backlog in the replication queue.

[0069] (2) Fault switching sensitive factors This indicates whether the current system is in a failover window or a sensitive observation period after a failover, and can be defined as: in, Indicates whether the current window is in the event switching state. Indicates the most recent switching time. This represents the decay constant during the sensitive period.

[0070] (3) Historical risk debt factor This refers to the risk burden accumulated but not yet fully eliminated during historical cycles, which can be determined based on past data. Calculation of cumulative residuals for exceeding the threshold risk within a time window: in, The attenuation coefficient; Indicates the current time point; Indicates the first The replication risk score for each time window; Indicates the first Risk management thresholds for each time window.

[0071] (4) Audit health factor This indicates the completeness, accessibility, and synchronization of the audit chain and audit ledger, which can be determined comprehensively based on the audit reporting completeness rate, signature verification pass rate, and ledger synchronization delay. in, Indicates the completeness rate of audit reports. This indicates the pass rate of audit signature verification. This indicates a delay in the synchronization of the normalized ledger, and All of the above parameters can be normalized to an interval. This is to ensure the comparability and stability of risk management thresholds.

[0072] In this embodiment, the handling threshold is dynamically determined based on the cluster load status, failover sensitivity, historical risk debt, and audit health, thereby adaptively changing the sensitivity of risk handling under different system states and achieving a dynamic balance between security and availability.

[0073] In one embodiment, such as Figure 3 As shown, the admission control method for database replication also includes: In the event of a failover, the new master node initiates the application, and the old master node and witness node set confirm the failover event, and all parties sign to form a term migration certificate. The authentication controller verifies the term migration certificate, including: verifying whether the signature set meets the preset quorum threshold; verifying whether the new term identifier is greater than the old term identifier; verifying whether the new master identifier and the old master identifier are different and correspond to the old master and new master registration information respectively; verifying whether the replication slot inheritance digest is consistent with the inheritance record of the replication slot to be restored; verifying whether the security switch log position is within the allowed switch interval; and verifying whether the certificate has expired and has not been revoked. When verification is successful, the system returns to the execution authentication controller to build a replication intent graph and calculates the replication intent graph summary and subsequent steps to obtain streaming replication authorization credentials for the new term. All streaming replication authorization credentials for the old term are added to the revocation list and become invalid immediately. If the term migration certificate verification fails, the system refuses to continue and requires a re-execution of the basic backup or entry into the manual arbitration process.

[0074] Specifically, in a failover scenario, a term migration certificate is generated from the old master database, the new master database, and the set of witness nodes. Upon detecting a primary database switchover, planned switchover, or failover event, the new primary database node initiates a term migration certificate request, and the old primary database node, the set of witness nodes, or the arbitration module confirm the switchover event. The authentication controller collects the following information: old term identifier. New term markers Old Master Database Identifier New master database identifier Safely switch log locations Copy slots follow the summary Switching reason identifier and event timestamp .

[0075] A term migration certificate is generated when the following conditions are met: the new master node has been confirmed by the cluster consensus module or a quorum witness node; Not less than the last confirmed commit position of the old master and not greater than the replay position that the new master can handle; replication slot inheritance summary The registration information is consistent with the old term; there was no conflicting primary identity during the role switch from the old master database to the new master database; the switch event did not hit the revocation list or abnormal blocking rules.

[0076] The term migration certificate is generated according to the following formula: in, A set of signatures representing a quorum; Indicates the old term of office; Indicates the new term of office; Indicates that the copy slot follows the digest. Indicates a safe change of location; Indicates the old master database identifier; Indicates the new master database identifier; Indicates the reason for switching. This indicates a change in timestamp.

[0077] Verification of the validity of a term-of-office migration certificate includes at least: verifying the signature set. Does the preset legal quorum threshold need to be met? (Verification) ;verify and They are different and correspond to the old master database and the new master database registration information respectively; verification Consistent with the lineage record of the replica slot to be recovered; verification It is located within the allowed switching range; the verification certificate has not expired and has not been revoked.

[0078] The certification controller only allows the replication intent map reconstruction and streaming replication credential reissue process under the new term to proceed if the term migration certificate verification is successful. The replication intent map summary and causal window commitment are then recalculated based on the new term. All streaming replication credentials issued under the previous term are added to the revocation list and become immediately invalid. If the term migration certificate verification fails, continuation is refused, and a re-execution of the basic backup or initiation of a manual arbitration process is required.

[0079] In traditional replication schemes, after failover, master-slave role switching, and topology reorganization, the original replication relationships, replication slot inheritance relationships, and log lineage relationships lack a unified and verifiable proof mechanism, which can easily lead to problems such as erroneous continuation, cross-term reuse, and difficulties in audit tracing. In this embodiment, the legitimate lineage relationship after failover is verified through term migration certificates, which can reduce the risks of erroneous continuation, illegal rebinding, and cross-term reuse of old credentials after failover.

[0080] In one embodiment, the authentication controller constructs a replication intent graph and calculates a replication intent graph digest, including: The authentication controller uses the master database, slave database, replication slot, term, basic backup, and log window as vertices, and allows basic backup, log replication, renewal, term migration, and window expansion as edges. Vertex attribute mappings are added to the vertices, and edge attribute mappings are added to the edges to construct a replication intent graph. The Merkle root value of the vertex set, the Merkle root value of the edge set, the current policy version number, and the failover term of the replicated intent graph are concatenated, and then a cryptographic hash function is used to calculate the replicated intent graph digest.

[0081] Specifically, the authentication controller constructs a replication intent graph based on replication topology policies, node role relationships, target master database, replication slots, failover terms, allowed log subwindow sets, basic backup constraints, and renewal policies. : Among them, the vertex set It includes at least the master database vertex, slave database vertex, replication slot vertex, tenure vertex, base backup vertex, and log window vertex; edge set. It should include at least the following: allow basic backup edge, allow log replication edge, allow renewal edge, allow term migration edge, and allow window expansion edge; For vertex attribute mapping, Mapping edge attributes.

[0082] To achieve unified verification of graph structures, the authentication controller calculates the copied intent graph summary according to the following formula: in, Represents a cryptographic hash function. Indicates the policy version number. Indicates the term of fault handover.

[0083] In this embodiment, by constructing a replication intent graph, the master database, slave database, replication slot, node role, log window, renewal rules and failover term are incorporated into a unified model, so that the replication relationship has structured and verifiable semantic constraints.

[0084] In one embodiment, the authorization information includes: fault handover term, copy slot identifier, window start and end log sequence number, and window purpose label.

[0085] like Figure 4 As shown, the authentication controller generates a causal window commitment based on the base backup fingerprint, authorization information, and slave node public key, including: After the basic backup is completed, the master node generates a basic backup fingerprint and sends it to the authentication controller. After the basic backup is completed, either the master node or the slave node generates a basic backup fingerprint for the backup dataset. The authentication controller concatenates the failover term, replication slot identifier, window start and end log sequence number, window purpose label, slave public key hash, and basic backup fingerprint hash to calculate the hash value, thus obtaining the hash value corresponding to each log sub-window. A Merkle tree is constructed using the hash value corresponding to each log sub-window as the leaf node, and the calculated root hash value is used as the causal window commitment.

[0086] Specifically, the authentication controller determines the set of log subwindows that are allowed to be copied. in, Indicates the first The starting log sequence number of each log sub-window; Indicates the first The end log sequence number of each log sub-window; This indicates the total number of log sub-windows.

[0087] Constructing causal window commitment : in, Indicates the fault handover term number; Indicates the copy slot identifier. Indicates the first The orientation or purpose label for each log sub-window This represents the public key of the slave node. This indicates the basic backup fingerprint.

[0088] Existing replication authentication methods typically fail to establish strong binding relationships between replication credentials and specific master databases, replication slots, replication roles, failover terms, base backup sources, and log sequence number ranges. This results in old credentials being reused on different nodes, across different replication chains, and even under different terms. In this embodiment, replication permissions can be precisely limited to approved log causal ranges, such as binding to specific master databases, specific replication slots, specific terms, specific log ranges, and base backups, rather than granting generalized permissions to any future logs.

[0089] In one embodiment, the master node or slave node generates a basic backup fingerprint for the backup dataset, including: concatenating each backup page block of the backup dataset, the corresponding page verification information, and the segment identifier, and then calculating the hash value to obtain the hash value of each page block; concatenating all page block hash values ​​in sequence and then calculating the hash to obtain the basic backup fingerprint.

[0090] Specifically, after the master node grants basic backup access to the slave node based on the one-time boot authorization credential, the master node, the slave node, or both can collaboratively generate a basic backup fingerprint from the basic backup dataset. : in, Indicates the first One backup page block, This indicates the corresponding page verification information. This indicates the segment identifier. By incorporating the base backup fingerprint into subsequent log replication authorization, attackers can prevent legitimate log replication credentials from binding initial copies from unauthorized sources.

[0091] In one embodiment, the static metric vector includes hardware fingerprint metrics, firmware metrics, operating system and boot chain metrics, database binary and configuration metrics, and container or virtualization environment metrics; the runtime attitude metric vector includes replication process set metrics, dynamically loaded library and plugin metrics, log capture status metrics, runtime environment variable and security policy metrics, and replication queue behavior metrics. The master node or authentication controller periodically receives the continuous execution proof chain value and the operation attitude quantity summary generated from the current operation attitude quantity vector from the slave node, and updates the comprehensive credibility score. This includes: the authentication controller calculates the distance exponential decay term and cosine similarity term for each type of feature based on the current static metric vector and the baseline vector, and sums the two by weight to obtain the sub-score for each feature. The sub-scores of each feature are multiplied by their corresponding weights and then summed to obtain the static credibility score; the operation attitude quantity and its summary generated from the current operation attitude quantity vector are obtained. If the operation attitude quantity summary is verified, each operation attitude quantity term is normalized. The operation state credibility score is obtained by the weighted sum of the normalized values ​​of each operation attitude quantity term; the continuity score is calculated based on the breakpoint status of the continuous execution proof chain, the cross-node chain value reuse status, and the chain value rollback status; and the comprehensive credibility score is updated based on the static credibility score, the operation state credibility score, and the continuity score.

[0092] At least a static metric vector is collected from the library node. and the vector of operating attitude .

[0093] The static metric vector is represented as: in, This represents a hardware fingerprint metric. Represents firmware metrics. This represents the operating system and boot chain metrics. Represents database binary and configuration metrics. This represents the deployment environment metric, which can be a container, virtualization, or deployment environment metric.

[0094] The attitude vector is represented as follows: in, This represents a measure of the replication process set. This indicates that library and plugin metrics have been loaded. This represents the log capture status metric. This represents runtime environment variables and security policy metrics. This represents a metric for replicating queue behavior.

[0095] For the static metric, the first Each component has a normalized score. Calculate according to the following formula: in, Represents the current observation vector With baseline vector The distance between them Indicates the tolerance scale. Here, represents the fusion coefficient; where represents the static baseline vector. The preferred sources are those from the initial trusted registration or the results of the guided verification.

[0096] Static Credibility Score Calculate according to the following formula: Summary of operational attitude It is composed of the attitude vector of operation The summary value obtained after filtering, normalizing, and hashing the predetermined key components in the data can be expressed as: in, This indicates normalization processing. This indicates the current time slice or sampling sequence number. The running attitude vector is used for credibility scoring, drift analysis, and fine-grained anomaly identification.

[0097] Obtain the operational attitude quantity and its summary generated based on the current operational attitude quantity vector. If the operational attitude quantity summary passes the verification, normalize each operational attitude quantity item. Obtain the operational state credibility score based on the weighted sum of the normalized values ​​of each operational attitude quantity item.

[0098] For the first in dynamic measurement Each component, its time Normalized score Calculate using the following formula: in, Indicates the current time The observed first A dynamic metric Indicates the first The reference vector corresponding to each dynamic metric is preferably derived from the continuous vector during the stable replication phase. The mean, median, or weighted average of each observation period; the corresponding baseline can be refreshed after a legitimate upgrade, patch update, or configuration change has occurred and has been re-verified. Indicates the tolerance scale; This represents the fusion coefficient.

[0099] Runtime reliability score Calculate according to the following formula: , in, Indicates the first The normalized score of each operational attitude item.

[0100] Overall Credibility Score Calculate according to the following formula: in, Indicates continuous scores, and .

[0101] To continuously verify the continuity of the slave node's execution environment after replication is established, the slave node iteratively generates a chain of continuous execution proofs according to the following formula: in, The chain value at the previous time step. This is the current position in the consumption log. For the binary digest of the copying process, Summary of key configurations, For process tree summary, It is a monotonically increasing counter.

[0102] Continuity score It can be calculated using the following formula: in, This indicates the length of the chain break point. Indicates a cross-node chain value reuse indicator. This indicates the amount of chain value rollback indication.

[0103] In this embodiment, by continuously executing the proof chain to continuously prove the replication process, key configurations, process tree, and log consumption position, the behavior of process replacement, mirror rollback, chain value reuse, and credential borrowing can be effectively identified.

[0104] In one embodiment, the access control method for database replication further includes: the authentication controller writing events such as node certification, replication intent graph generation, one-time bootstrap authorization credential issuance, basic backup access, basic backup fingerprint registration, causal window commitment generation, streaming replication authorization credential issuance, handshake verification, continuous execution proof updates, risk handling, and failover rebinding into an audit ledger. Through the audit ledger, complete traceability and accountability throughout the entire database replication lifecycle can be achieved.

[0105] In one embodiment, such as Figure 5 As shown, the admission control method for database replication includes the following stages: Phase 1: Node preparation phase.

[0106] During this phase, the slave node generates a non-derivative node identity key pair (public key) in the Trusted Execution Environment (TEE), Trusted Platform Module (TPM), or Protected Key Area. (private key).

[0107] Collect static metric vectors from library nodes: hardware fingerprints, firmware, operating system and boot chain, database binary and configuration, and container / virtualization environment.

[0108] Collect runtime attitude vectors: replication process set, dynamically loaded libraries / plugins, log capture status, runtime environment variables and security policies, and replication queue behavior.

[0109] The slave node reports the above metric information to the authentication controller.

[0110] Phase Two: Credible Scoring Phase.

[0111] In this phase: the authentication controller verifies, normalizes, and matches the received metric information to the baseline.

[0112] Calculate static confidence score For each feature class, calculate the weighted sum of the distance exponential decay term and the cosine similarity term, and then sum the weighted sum of the sub-scores of each feature.

[0113] Calculate the initial running state confidence score The normalized score of each operational attitude item is multiplied by its weight and then summed.

[0114] The fusion yields a comprehensive credibility score. (Continuous scoring at this point) Not yet generated; can be ignored for now or the default value is 1).

[0115] Determine if the overall credibility score meets the requirements. Does it meet the admission threshold?

[0116] Phase Three: Guiding and Authorization Phase At this stage, if the overall trust score meets the admission threshold, the authentication controller issues a one-time bootstrap authorization credential to the slave node.

[0117] Phase 4: Basic Backup Phase.

[0118] During this phase, the slave node requests a basic backup from the master node using a one-time bootstrap authorization credential. The master node verifies the credential signature, validity period, master-slave binding relationship, node public key binding relationship, and single-transaction constraints. After successful verification, the master node opens full basic backup data transmission to the slave node. After the backup is completed, the master node, slave node, or both collaboratively generate a basic backup fingerprint and send it to the authentication controller.

[0119] Phase 5: Streaming authorization phase.

[0120] During this phase, the authentication controller constructs a causal window commitment based on the base backup fingerprint, authorization information (failover term, replication slot identifier, allowed set of log subwindows, window purpose label), and slave node public key hash.

[0121] Issue streaming replication authorization credentials to slave nodes.

[0122] Phase 6: Log Replication.

[0123] During this phase, the slave node holds the streaming replication authorization credential and initiates a log replication handshake with the master node.

[0124] Summary of the master node reconstruction replication intent graph and causal window commitment These are respectively compared with the replication intent graph summary in the streaming replication authorization certificate. Causal window commitment Comparison.

[0125] If the replication credentials are consistent and valid, the slave is allowed to join the replication group, and a session key is derived.

[0126] Specifically, after the handshake is successful, the master node and the slave node negotiate the session random number. And derive the session key according to the following formula: in, This represents the public key of the master node. This represents the random number in the streaming replication authorization certificate. This session key can be used to protect replication control messages or attach verification data.

[0127] Continuous log stream replication: pulls incremental logs from the authorized window of the library.

[0128] Periodic continuous execution proof: The slave database generates a chain of continuous execution proof values ​​at fixed intervals or log volume intervals, and reports them to the master database or authentication controller along with a summary of the running attitude.

[0129] The master database or authentication controller calculates the continuity score based on the chain of proof, updates the runtime trust score, and updates the overall trust score. And calculate the replication risk score. .

[0130] Replication risk score When the warning threshold is reached, replication continues.

[0131] When the warning threshold is ≤ When the threshold is reached, increase the frequency of verification, shrink the log window, or limit the copy rate.

[0132] exist When handling thresholds, execute actions such as freezing replication slots, suspending log streams, revoking credentials, refusing renewals, or forcibly rebooting.

[0133] Phase 7: Renewal or Cancellation.

[0134] If the overall trust score of the slave database still meets the requirements and the revocation conditions are not triggered before the certificate expires, the authentication controller can issue a new streaming replication authorization certificate.

[0135] A certificate becomes immediately invalid when added to the revocation list under the following circumstances: the replication risk score reaches the disposal threshold; after a failover, all streaming replication certificates from the original term are revoked in batches; the certificate expires naturally; a serious anomaly occurs in the continuous execution proof chain (such as reuse, rollback, or breakpoints exceeding the limit); or manual operation and maintenance actively revokes the certificate.

[0136] The database replication admission control method of this application has the following effects: 1. By constructing a replication intent graph, the master database, slave database, replication slots, node roles, log windows, renewal rules, and failover terms are incorporated into a unified model, giving replication relationships structured and verifiable semantic constraints.

[0137] 2. By setting one-time boot authorization credentials and streaming replication authorization credentials, basic backup permissions and log replication permissions are strictly separated, reducing the risk of leakage of the entire database due to the leakage of high-privilege credentials.

[0138] 3. By incorporating the basic backup fingerprint, node public key digest, replication slot identifier, failover term, and log sub-window set into the causal window commitment, the reuse of old credentials across the master database, replication slot, term, and log range can be effectively suppressed.

[0139] 4. By continuously proving the replication process, key configurations, process tree, and log consumption position through continuous execution of the proof chain, it can effectively identify process replacement, mirror rollback, chain value reuse, and credential borrowing behaviors.

[0140] 5. Verifying the legitimate succession relationship after a failover through term migration certificates can reduce the risks of incorrect continuation, illegal rebinding, and reuse of old credentials across terms after a failover.

[0141] 6. Through comprehensive risk assessment based on runtime drift, behavioral anomalies, graph deviation, window deviation, and fault switching deviation, dynamic risk control and refined handling can be achieved during the database replication process.

[0142] In summary, this method, through the collaborative design of replication intent graphs, causal window commitments, basic backup fingerprints, continuous execution proof chains, and term migration certificates, ensures that replication access not only depends on node identity but is also constrained by replication intent, basic backup source, log causal scope, execution continuity, and failover inheritance relationships. This enhances the security and controllability of the entire database replication lifecycle. This method addresses technical issues in existing technologies such as unverifiable replication subject status, mixed use of basic backup and log replication permissions, insufficient replication semantic binding, reuse of old credentials after failover, and lack of continuous trusted control over the replication process. It achieves database replication access control covering basic backup, log replication, renewal, and failover scenarios, exhibiting good security, verifiability, and engineering applicability.

[0143] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0144] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0145] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. An admission control method for database replication, characterized in that, Applied to a database replication system including a master node, slave nodes, and an authentication controller, the method includes: The slave node generates a node identity key pair, collects static metric vectors and runtime attitude vectors, and reports them to the authentication controller. The authentication controller constructs a replication intent graph and calculates a replication intent graph digest; The authentication controller calculates an initial comprehensive trust score based on the static metric vector and the operational attitude vector. When the initial comprehensive trust score meets the admission threshold, it issues a one-time boot authorization credential for basic backup. The master node opens the basic backup to the slave node based on the one-time boot authorization credential, and generates a basic backup fingerprint which is sent to the authentication controller; The authentication controller generates a causal window commitment based on the basic backup fingerprint, authorization information, and slave node public key, and issues streaming replication authorization credentials for log replication. During the log replication handshake process, the master node reconstructs the replication intent graph summary and causal window commitment, and allows the slave node to join the target replication group when the reconstruction result is consistent with the replication intent graph summary and causal window commitment carried in the streaming replication authorization certificate. During the replication process, the master node or authentication controller periodically receives the continuous execution proof chain value from the slave node and the runtime attitude quantity summary generated from the current runtime attitude quantity vector, updates the comprehensive trust score, and calculates the replication risk score based on the updated comprehensive trust score and multi-dimensional risk deviation measures. The risk deviation measures include at least two of the following: graph deviation, window deviation, runtime drift degree, behavior anomaly degree, and fault switching deviation. When the replication risk score reaches the disposal condition, at least one of the following control operations is executed: replication slot freezing, log stream circuit breaking, window shrinking, credential revocation, renewal rejection, or forced reboot.

2. The admission control method for database replication according to claim 1, wherein, The method further includes at least one of the following: When the replication risk score is less than the warning threshold, the current replication relationship is maintained; When the replication risk score reaches the warning threshold but not the handling threshold, the reporting frequency of continuous execution proof is increased, the allowed log window is narrowed, or the replication rate is limited. Wherein, the handling threshold is greater than the warning threshold.

3. The database replication admission control method according to claim 1 or 2, characterized in that, The method further includes: The handling threshold is dynamically determined based on cluster load status, failover sensitivity, historical risk debt, and audit health. Specifically, the handling threshold decreases when the cluster load status increases, failover sensitivity increases, or historical risk debt worsens, and increases when the audit health is high.

4. The database replication admission control method according to claim 1, characterized in that, The database replication system also includes a set of witness nodes; The method further includes: In the event of a failover, the new master node initiates the application, and the old master node and witness node set confirm the failover event, and all parties sign to form a term migration certificate. The authentication controller verifies the term migration certificate, including: verifying whether the signature set meets the preset quorum threshold; verifying whether the new term identifier is greater than the old term identifier; verifying whether the new master identifier and the old master identifier are different and correspond to the old master and new master registration information respectively; verifying whether the replication slot inheritance digest is consistent with the inheritance record of the replication slot to be restored; verifying whether the security switch log position is within the allowed switch interval; and verifying whether the certificate has expired and has not been revoked. When verification is successful, the process returns to the authentication controller to construct a replication intent graph, calculates the replication intent graph summary and subsequent steps to obtain streaming replication authorization credentials for the new term. All streaming replication authorization credentials for the old term are added to the revocation list and become invalid immediately. If the term migration certificate verification fails, the continuation is rejected and a re-execution of the basic backup is required, or the process enters the manual arbitration process.

5. The database replication admission control method according to claim 1, characterized in that, The authentication controller constructs a replication intent graph and calculates a replication intent graph digest, including: The authentication controller uses the master database, slave database, replication slot, term, basic backup, and log window as vertices, and allows basic backup, log replication, renewal, term migration, and window expansion as edges. Vertex attribute mappings are added to the vertices, and edge attribute mappings are added to the edges to construct a replication intent graph. The Merkle root value of the vertex set, the Merkle root value of the edge set, the current policy version number, and the failover term of the replicated intent graph are concatenated, and then a cryptographic hash function is used to calculate the replicated intent graph digest.

6. The database replication admission control method according to claim 1, characterized in that, The authorization information includes: fault switch term, duplication slot identifier, window start and end log sequence number, and window purpose label; The authentication controller generates a causal window commitment based on the base backup fingerprint, authorization information, and slave node public key, including: After the basic backup is completed, the master node generates a basic backup fingerprint for the backup dataset; The authentication controller concatenates the fault switch term, replication slot identifier, window start and end log sequence number, window purpose label, slave public key hash, and the basic backup fingerprint hash to calculate the hash value, thus obtaining the hash value corresponding to each log sub-window. A Merkle tree is constructed using the hash value corresponding to each log sub-window as the leaf node, and the calculated root hash value is used as the causal window commitment.

7. The database replication admission control method according to claim 6, characterized in that, The master node generates a basic backup fingerprint for the backup dataset, including: The hash value of each page block is calculated by concatenating the corresponding page verification information and segment identifier of each backup page block in the backup dataset. The basic backup fingerprint is obtained by concatenating all page block hash values ​​in order and then calculating the hash.

8. The database replication admission control method according to claim 1, characterized in that, The static metric vector includes hardware fingerprint metrics, firmware metrics, operating system and bootstrap chain metrics, database binary and configuration metrics, and deployment environment metrics; the runtime attitude metric vector includes replication process set metrics, dynamically loaded library and plugin metrics, log capture status metrics, runtime environment variable and security policy metrics, and replication queue behavior metrics. The process of periodically receiving the continuous execution proof chain value from the slave nodes and the execution attitude quantity summary generated from the current execution attitude quantity vector by the master node or authentication controller, and updating the comprehensive trust score, includes: The authentication controller calculates the distance exponential decay term and cosine similarity term for each feature based on the current static metric vector and the baseline vector, and then sums the two terms with weights to obtain the sub-score for each feature. The sub-scores of each feature are multiplied by their corresponding weights and then summed to obtain the static credibility score. Obtain the operational attitude quantity and its summary generated based on the current operational attitude quantity vector. If the operational attitude quantity summary passes the verification, normalize each operational attitude quantity item. Obtain the operational status credibility score based on the weighted sum of the normalized values ​​of each operational attitude quantity item. The continuity score is calculated based on the breakpoints in the continuous execution proof chain, the cross-node chain value reuse, and the chain value rollback status. The overall trust score is updated based on the static trust score, the operational trust score, and the continuity score.

9. The database replication admission control method according to claim 1, characterized in that, The method further includes: The authentication controller writes node proof, replication intent graph generation, one-time bootstrap authorization credential issuance, basic backup opening, basic backup fingerprint registration, causal window commitment generation, streaming replication authorization credential issuance, handshake verification, continuous execution proof update, and risk disposal into the audit ledger.

Images