A verification method, device and medium based on a database transaction trusted chain

Abstract

The embodiment of the application discloses a kind of based on database transaction trusted chain's check method, equipment and medium, belong to database check technical field, solve the problem that present technique is difficult to make effective judgment to the credibility of the overall link that database transaction recovery depends on. Including, in database initialization phase, build database trusted baseline file;Before database service process starts, based on trusted baseline file, execute pre-consistency check;In the process of database business operation, the trusted digest of the prewrite log record of each transaction is generated, and the prewrite log record of each transaction is linked into trusted log chain;The integrity digest of the archived log file is written into the archive check record;In response to runtime integrity check request, the actual integrity digest of each archived log file is recalculated, compared with the archive check record, and based on the comparison result and the verification result of trusted log chain, the credibility of database transaction trusted chain is determined.

Description

Technical Field

[0001] This application relates to the field of database verification technology, and in particular to a verification method, device and medium based on a database transaction trust chain. Background Technology

[0002] As the core infrastructure of information systems, database management systems are responsible for storing, processing, and recovering critical business data.

[0003] To ensure data recoverability in abnormal situations, database management systems commonly employ a write-ahead log (WAL) mechanism: before data page modifications are written to disk, the modifications are first written to the log file in WAL record order; in the event of a database crash, the database is restored to a consistent state by replaying the WAL. To support point-in-time recovery and master-slave replication, the database also uses archive mode parameters and archive commands to copy the full WAL file to the archive location, and the standby database retrieves and replays the archived WAL to achieve synchronization with the master database.

[0004] However, during the initialization, startup, operation, WAL archiving, transaction recovery, and master-slave synchronization processes described above, there is a security risk that the database executable files, dynamic libraries, initialization parameters, WAL log files, archived logs, and data pages may be illegally modified, replaced, deleted, or forged. Once such tampering occurs, it will lead to problems such as an untrusted database operating environment, incomplete transaction log links, and unverifiable WAL replay results.

[0005] However, existing database integrity verification typically only verifies a single object, such as only executable files, only data pages, only WAL files, or only operating system permission controls. These methods are isolated from each other and can only be verified afterward, making it difficult to effectively judge the trustworthiness of the entire chain upon which database transaction recovery depends. Summary of the Invention

[0006] This application provides a verification method, device, and medium based on a trusted chain of database transactions to solve the following technical problem: Existing database integrity verification usually only verifies a single object, which is isolated from each other and can only be checked afterward, making it difficult to make an effective judgment on the trustworthiness of the overall chain on which database transaction recovery depends.

[0007] The embodiments of this application adopt the following technical solutions: This application provides a verification method based on a trusted chain of database transactions. The method includes: during the database initialization phase, constructing a trusted baseline file based on preset key directories and effective key startup parameters in the database installation directory; responding to the database startup command and performing a pre-consistency verification based on the trusted baseline file before the database service process starts; after successful verification, generating trusted digests of the write-ahead log records for each transaction during database operation, and chaining the write-ahead log records of each transaction into a trusted log chain according to the correlation between different trusted digests; archiving the write-ahead logs, determining the integrity digests of the archived log files, and writing the integrity digests into the archived verification record; responding to a runtime integrity verification request, recalculating the actual integrity digests of each archived log file, comparing the actual integrity digests with the integrity digests in the archived verification record, and performing continuity verification on each write-ahead log record based on the trusted log chain, thereby determining the trustworthiness of the trusted chain of database transactions based on the comparison and verification results.

[0008] In one implementation of this application, during the database initialization phase, a trusted database baseline file is constructed based on preset key directories in the database installation directory and effective key startup parameters. Specifically, this includes: triggering a baseline generation process in response to a database initialization completion command; traversing preset key directories and determining a reference directory summary based on the file content of each preset key directory, thereby generating a trusted runtime environment baseline file based on the reference directory summary; obtaining the key startup parameters effective during the database initialization phase, and generating a trusted startup parameter baseline file based on the parameter values ​​and parameter attribute information of the key startup parameters; wherein the parameter attribute information includes at least the parameter name, parameter type, and activation method; and obtaining the trusted database baseline file based on the trusted runtime environment baseline file and the trusted startup parameter baseline file.

[0009] In one implementation of this application, a pre-consistency check is performed based on a trusted baseline file, specifically including: when a database startup or restart command is detected to carry runtime environment verification parameters, determining the current directory summary corresponding to each preset key directory, and comparing the current directory summary with the reference directory summary recorded in the runtime environment trusted baseline file to obtain the directory verification result; if the directory verification result is inconsistent, preventing the database service process from starting and outputting an error message; if the directory verification result is consistent, recording the verification log and starting the database service process.

[0010] In one implementation of this application, a pre-consistency check is performed based on a trusted baseline file, specifically including: if the preset global configuration parameter is enabled, the startup parameter trusted baseline file is read to obtain the actual values ​​of the currently effective key startup parameters, and the actual values ​​are compared with the parameter values ​​recorded in the startup parameter trusted baseline file parameter by parameter; if the comparison result is inconsistent, an alarm message is reported, and the database service process is selectively blocked from starting according to a preset strategy; if the comparison result is consistent, a verification log is recorded and the database service process continues to start.

[0011] In one implementation of this application, a trusted digest of each transaction's write-ahead log record is generated, and the write-ahead log records of each transaction are chained together into a trusted log chain based on the association between different trusted digests. Specifically, this includes: during the write-ahead log writing process, obtaining the preceding digest and record feature information corresponding to each transaction, and performing a hash function operation on the combination of the preceding digest and record feature information to obtain a trusted digest of each transaction's write-ahead log record; wherein, the record feature information includes at least the log sequence number, record content, and generation time, and the preceding digest is a trusted digest of the write-ahead log record of the preceding adjacent transaction; the trusted digest of each transaction is used as the preceding digest of the write-ahead log record of the subsequent adjacent transaction, and the write-ahead log records of each transaction are sequentially associated according to the generation order to construct a trusted log chain.

[0012] In one implementation of this application, the write-ahead log is archived, the integrity digest of the archived log file is determined, and the integrity digest is written to the archive verification record. Specifically, this includes: executing an archive command to copy the write-ahead log file to the archive location; determining whether the archiving is successful; if the archiving fails, no archive verification record is recorded and the process ends; if the archiving is successful, the archive callback function set in the write-ahead log archiving process is called, and the full path of the archived write-ahead log file is passed to the archive callback function; the integrity digest of the archived write-ahead log file is determined through the archive callback function, and the full path, integrity digest, and archiving time are written to the archive verification record.

[0013] In one implementation of this application, in response to a runtime integrity verification request, the actual integrity digest of each archived log file is recalculated, and the actual integrity digest is compared with the integrity digest in the archived verification record. Continuity verification is performed on each write-ahead log record based on the trusted log chain. Based on the comparison and verification results, the trustworthiness of the database transaction trusted chain is determined. Specifically, this includes: in response to a runtime integrity verification request, reading the archived verification record to obtain each archived log file and its corresponding integrity digest recorded therein; locating each archived log file based on the full path recorded in the archived verification record; reading the content of the located file, recalculating the actual integrity digest of the archived log file based on the file content, and comparing the actual integrity digest with the integrity digest recorded in the archived verification record one by one to obtain a file-level verification result; performing continuity verification on each write-ahead log record based on the trusted log chain, and verifying checkpoint boundaries to obtain a record-level verification result; and determining the trustworthiness of the database transaction trusted chain based on the file-level verification result and the record-level verification result.

[0014] In one implementation of this application, after determining the trustworthiness of the database transaction trust chain based on the comparison results and verification results, the method further includes: obtaining abnormal information generated during the verification process; identifying the abnormal level corresponding to the abnormal information; and executing an abnormal handling operation matching the abnormal level according to the pre-set handling rules corresponding to each abnormal level; wherein the abnormal handling operation includes at least one of database startup control, log output, or verification result information recording.

[0015] This application provides a verification device based on a database transaction trusted chain, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to: during the database initialization phase, construct a database trusted baseline file based on preset key directories and effective key startup parameters in the database installation directory; in response to a database startup command, perform a pre-consistency verification based on the trusted baseline file before the database service process starts; after the verification passes, during the database business operation, generate trusted digests of the write-ahead log records of each transaction, and concatenate the write-ahead log records of each transaction into a trusted log chain according to the correlation between different trusted digests; archive the write-ahead logs, determine the integrity digests of the archived log files, and write the integrity digests into the archived verification record; in response to a runtime integrity verification request, recalculate the actual integrity digests of each archived log file, compare the actual integrity digests with the integrity digests in the archived verification record, and perform continuity verification on each write-ahead log record based on the trusted log chain, so as to determine the trustworthiness of the database transaction trusted chain based on the comparison results and verification results.

[0016] This application provides a non-volatile computer storage medium storing computer-executable instructions. These instructions are configured to: during the database initialization phase, construct a database trusted baseline file based on preset key directories and effective key startup parameters in the database installation directory; respond to a database startup command, perform a pre-consistency check based on the trusted baseline file before the database service process starts; after successful verification, generate trusted digests of the write-ahead log records for each transaction during database operation, and chain the write-ahead log records of each transaction into a trusted log chain based on the correlation between different trusted digests; archive the write-ahead logs, determine the integrity digests of the archived log files, and write the integrity digests into the archive verification record; respond to a runtime integrity verification request, recalculate the actual integrity digests of each archived log file, compare the actual integrity digests with the integrity digests in the archive verification record, and perform continuity verification on each write-ahead log record based on the trusted log chain, thereby determining the trustworthiness of the database transaction trusted chain based on the comparison and verification results.

[0017] The above-mentioned technical solutions adopted in this application embodiment can achieve the following beneficial effects: This application embodiment constructs a trusted baseline file during the database initialization phase, so that the baseline is automatically generated with the database creation action and intrinsically coupled with the database initialization process, providing a trusted reference covering the operating environment and startup parameters for subsequent verification. Before the database service process starts, a pre-consistency check is performed based on this baseline, transforming post-event verification into pre-event blocking, ensuring that subsequent WAL generation and archiving behaviors are based on a trusted operating environment and startup parameters. During business operation, a trusted digest is generated for each write-ahead log record and chained into a trusted log chain. Based on the chain dependency of records, any modification or deletion of a record will cause subsequent digests to fail to match, thereby reliably identifying log chain corruption. During the operation phase, in response to verification requests, the recalculated actual integrity digest is compared with the digest in the archived verification record, and continuity verification is performed based on the trusted log chain. Through two complementary verification lines of file-level comparison and record-level verification, the trustworthiness of the database transaction trusted chain is determined, making the log foundation on which crash recovery and master-slave replay depend verifiable and traceable. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings: Figure 1 A flowchart of a verification method based on a database transaction trust chain provided for embodiments of this application; Figure 2 A flowchart of an initdb initialization trusted baseline generation process is provided for an embodiment of this application; Figure 3 A flowchart for catalog summary verification is provided for an embodiment of this application; Figure 4 A flowchart for verifying database startup parameters is provided in this application embodiment; Figure 5 A schematic diagram of a database transaction trusted chain dependency relationship is provided for an embodiment of this application; Figure 6 A flowchart illustrating the execution of a WAL archiving callback function is provided in this embodiment of the application. Figure 7 A flowchart of the WAL active verification function execution provided in this application embodiment; Figure 8 A flowchart of a verification method based on a transaction trust chain is provided for an embodiment of this application; Figure 9 This is a schematic diagram of the structure of a verification device based on a database transaction trust chain, provided in an embodiment of this application.

[0019] Figure label: 200: Verification device based on database transaction trust chain; 201: Processor; 202: Memory. Detailed Implementation

[0020] This application provides a verification method, device, and medium based on a database transaction trust chain.

[0021] To enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0022] Figure 1 A flowchart of a verification method based on a database transaction trust chain is provided for embodiments of this application, as follows: Figure 1 As shown, the verification method based on the database transaction trust chain includes the following steps: Step 101: During the database initialization phase, construct a trusted database baseline file based on the preset key directories and effective key startup parameters in the database installation directory.

[0023] In one implementation of this application, baseline generation is automatically triggered upon completion of database initialization: a preset key directory is traversed, a reference directory summary is determined based on the file content, and a trusted baseline file for the runtime environment is generated. Simultaneously, key startup parameters effective during the initialization phase are obtained, and a trusted baseline file for startup parameters is generated based on their parameter values ​​and attribute information.

[0024] Figure 2 A flowchart for generating a trusted baseline during initdb initialization is provided for embodiments of this application, as follows: Figure 2 As shown, the process of generating a trusted baseline is as follows: First, the user executes the `initdb` command to initialize the database. After `initdb` initialization is complete, the baseline generation process is automatically triggered, eliminating the need for operations personnel to execute external scripts or baseline generation commands at the operating system level.

[0025] Furthermore, in this embodiment of the application, the trusted baseline file for the operating environment and the trusted baseline file for the startup parameters are generated in parallel.

[0026] The process of generating a trusted baseline file for the runtime environment is as follows: Iterate through the four preset key directories bin, lib, include, and share under the database installation directory, and read the contents of the files in each directory one by one: For the bin directory, read the contents of the database executable files and command-line tools. For the lib directory, read the contents of the dynamic library files and extension library files; For the include directory, read the contents of the header files within it; For the share directory, read the contents of the initialization script, SQL script, control file, and shared resource file.

[0027] For each preset key directory, a shell script is used to calculate the MD5 hash of all files in that directory.

[0028] Example commands are as follows: cat`find{directory}-typef`|md5sum.

[0029] Write the calculated MD5 digest values ​​for each directory, along with the directory name, baseline generation time, database version information, and database installation path, into the baseline file, categorized by field: The directory_name field records the directory name; md5_value is the MD5 value calculated for all files in this directory; generate_time is the baseline generation time; database_version is the database version information; install_path is the database installation path.

[0030] A .md5 file is generated and written to the etc directory under the database installation directory, i.e., $PGHOME / etc / .md5, to form a trusted baseline for the database runtime environment. This baseline is used for subsequent detection of modifications to database executable files, command-line tools, dynamic library files, extension library files, initialization scripts, SQL scripts, control files, and shared resource files, as well as file replacement, deletion, directory digest comparison, abnormal changes to dynamic libraries, and tampering of extension scripts.

[0031] The process of generating a trusted baseline file for startup parameters is as follows: Collect key startup parameters that take effect during the database initialization phase, read the values ​​of each key startup parameter, and record parameter attribute information such as parameter name, parameter value, type, and activation method. Recordable parameters include, but are not limited to: archive_mode (archive mode), archive_command (archive command), wal_level (write-ahead log level), shared_preload_libraries (preload dynamic libraries), dynamic_library_path (dynamic library path), ssl (secure connection), ssl_cert_file (secure connection certificate file), ssl_key_file (secure connection key file), hba_file (client authentication configuration file), config_file (configuration file), data_directory (data directory).

[0032] Write each key startup parameter into the baseline file by field.

[0033] Generate a .hg_config_checksum file and write it to the database data directory, i.e., $PGDATA / .hg_config_checksum, to record the reliable values ​​of key parameters during the database initialization phase for subsequent consistency verification during pg_ctl startup.

[0034] After the two branches are completed, they merge to perform a check on the two types of baseline files generated. This check verifies whether both baseline files were successfully written to the corresponding storage paths, whether they can be read normally, and whether the recorded fields are complete and correctly formatted. If the check passes, the trusted database baseline is confirmed to be established. The trusted database baseline file is composed of $PGHOME / etc / .md5 and $PGDATA / .hg_config_checksum.

[0035] Step 102: Respond to the database startup command and perform a pre-consistency check based on the trusted baseline file before the database service process starts.

[0036] In one implementation of this application, when runtime environment verification parameters are detected in the database startup or restart command, the current directory summary corresponding to each preset key directory is determined, and the current directory summary is compared with the reference directory summary recorded in the runtime environment trusted baseline file to obtain the directory verification result. If the directory verification result is inconsistent, the database service process is prevented from starting and an error message is output. If the parameter verification result is consistent, a verification log is recorded and the database service process is started.

[0037] Specifically, this application embodiment extends the pg_ctl command by adding a consistency detection parameter: Short parameter: -C; Long parameter: --consistency-check; The parameter means: perform runtime environment and parameter integrity checks before start or restart.

[0038] This parameter is only triggered in the following commands: pg_ctlstart / restart, and not in commands such as stop, status, and reload. The help information further explains: -C,--consistency-check: Before starting or restarting, check the database's executable files, library files, WAL integrity baseline, and startup parameters.

[0039] Figure 3 A flowchart for catalog summary verification is provided for embodiments of this application, such as... Figure 3 As shown, the startup verification process is as follows: After the process begins, the user executes a startup command (pg_ctlstart -C) carrying consistency verification parameters. The system parses the consistency verification parameters and determines whether the current command is a startup command or a restart command. If not, the verification is skipped and the command is executed directly. If it is, the system reads the runtime environment baseline file in the configuration file directory under the database installation directory and calculates the current directory summary of the preset key directories (executable file directory, dynamic library directory, header file directory, and shared resource directory). The system then determines whether the summary is consistent with the reference directory summary recorded in the runtime environment baseline file. If they are inconsistent, the system determines that the directory verification has failed, prevents the database service process from starting, and outputs an error message. If they are consistent, the system records the verification log and starts the database service process.

[0040] In one implementation of this application, if the preset global configuration parameter is set to "on", the startup parameter trusted baseline file is read to obtain the actual values ​​of the currently effective key startup parameters. The actual values ​​are then compared parameter by parameter with those recorded in the startup parameter trusted baseline file. If the comparison results are inconsistent, an alarm is reported, and the database service process is selectively prevented from starting according to a preset policy. If the comparison results are consistent, a verification log is recorded, and the database service process continues to start.

[0041] Specifically, Figure 4 A flowchart for verifying database startup parameters is provided as an embodiment of this application, such as... Figure 4 As shown, the specific process for verifying database startup parameters is as follows: Users start the database via pg_ctl, initiating the database startup process. During startup, the value of the preset global configuration parameter online_check.enable is read and its status (on) is determined. This global configuration parameter is of type bool, has a default value of off, and requires a restart to take effect; that is, changes to its value will only take effect after a database restart.

[0042] If online_check.enable is set to "off", parameter validation will be skipped and the database will continue to start until startup is complete.

[0043] If `online_check.enable` is set to "on", then the integrity verification of initialization parameters is performed: the trusted baseline file for startup parameters in the database data directory is read. This trusted baseline file records key parameter values ​​during the database initialization phase or the initial database configuration phase. Its contents include: parameter name (GUC parameter name), parameter value (trusted value of the parameter during initialization), parameter type (bool / integer / string, etc.), and generation time (baseline generation timestamp). The recorded key startup parameters include, but are not limited to (specific parameters can be set through template files): `archive_mode`, `archive_command`, `wal_level`, `shared_preload_libraries`, `dynamic_library_path`, `ssl`, `ssl_cert_file`, `ssl_key_file`, `hba_file`, `config_file`, and `data_directory`.

[0044] Read the currently effective key startup parameters mentioned above and obtain the actual values ​​of each key startup parameter. The obtained actual values ​​are read from the database configuration file or obtained by querying the configuration query function provided by the database.

[0045] Using parameter names as indices, the system iterates through each key startup parameter recorded in the trusted baseline file, extracting its recorded value one by one and comparing it with the actual value of the corresponding parameter to determine if they match. During the iteration, key startup parameters that are recorded in the baseline file but no longer exist in the current instance, as well as key startup parameters that exist but are not recorded in the baseline file, are handled according to pre-defined default rules, such as not participating in the comparison or treating them as inconsistent.

[0046] If the comparison results are inconsistent, an alarm message is reported, and the database service process is selectively blocked from starting according to a preset strategy. The preset strategy in this embodiment is as follows: if there are inconsistent target startup parameters, the actual value of the target startup parameters is used for configuration, and a shadow database instance is created in an isolated operating environment. The shadow database instance is isolated from the database service process and does not carry business connections. A preset probe transaction set is executed on the shadow database instance to generate a probe write-ahead log sequence. The probe transaction set is a pre-constructed set of read-only or rollbackable transactions covering predetermined operation types. Behavioral fingerprints corresponding to the probe write-ahead log sequence are collected, and the behavioral fingerprints are compared with preset baseline behavioral fingerprints to obtain behavioral deviation results. The behavioral fingerprints are used to characterize the actual impact of the target startup parameters on write-ahead log generation and archiving behaviors. A pre-recovery simulation is performed on the probe write-ahead log sequence on the shadow database instance. The recovery fingerprints corresponding to the pre-recovery simulation are collected, and the recovery fingerprints are compared with preset expected recovery fingerprints to obtain a recoverability measure. The pre-recovery simulation is used to simulate the recovery process based on the probe write-ahead log sequence after a database crash, and the recovery fingerprints are used to characterize the consistency between the recovery termination position and the recovery result. The handling strategy is determined based on the behavioral deviation results and recoverability metrics. If the recoverability metrics indicate that the pre-simulated recovery was unsuccessful or the recovery fingerprint does not match the expected recovery fingerprint, the database service process is prevented from starting. If the recoverability metrics indicate that the pre-simulated recovery was successful and the recovery fingerprint matches the expected recovery fingerprint, but the behavioral deviation results indicate a deviation, the database service process is started in restricted mode, which is the operating mode with the database's write-ahead log archiving function disabled. If the recoverability metrics indicate that the pre-simulated recovery was successful and the recovery fingerprint matches the expected recovery fingerprint, and the behavioral deviation results indicate no deviation, the parameter values ​​of the corresponding records in the startup parameter trusted baseline file are updated with the actual values, and the database service process continues to start.

[0047] Specifically, after the trusted baseline file for startup parameters is generated during the database initialization phase, or during baseline updates, a baseline calibration process is performed: Using the parameter values ​​recorded in the trusted baseline file as configuration, a shadow database instance is created in the isolated operating environment. A pre-defined probe transaction set is executed on this instance to collect baseline behavioral fingerprints. Subsequently, a pre-recovery simulation is performed on the probe's pre-written log sequence to collect the expected recovery fingerprint. The collected baseline behavioral fingerprints and expected recovery fingerprints, along with their corresponding parameter values, are persistently saved as a benchmark for subsequent comparisons. The baseline behavioral fingerprints and expected recovery fingerprints can be stored in a separate fingerprint file under the database data directory, or stored as extended fields of the baseline file along with the trusted baseline file for startup parameters. This baseline calibration process is re-executed after each baseline update.

[0048] During the database startup process, in the startup parameter integrity verification step, the actual values ​​of the currently effective key startup parameters are compared parameter by parameter with the parameter values ​​recorded in the startup parameter trusted baseline file to identify target startup parameters with inconsistencies. When multiple target startup parameters exist, the actual values ​​of each target startup parameter are used together as the configuration of the shadow database instance, and the startup process of the database service is selectively blocked. Alternatively, the selective blocking of the database service process can be performed separately for each target startup parameter.

[0049] A shadow database instance is created in an isolated runtime environment with the actual values ​​of the target startup parameters configured. The isolated runtime environment is at least one of the following: a database instance created with a RAM disk as its data directory, a database instance created with a copy-on-write snapshot of the database's data directory, or a database instance listening on a non-business port and not providing external connection services. The creation process of the shadow instance is as follows: An independent temporary data directory is allocated; the contents of the initial database data directory are mapped to this temporary data directory using copy-on-write, thereby obtaining a data copy that is isolated from the production data and has the same initial state; the actual values ​​of the target startup parameters to be verified are written to the configuration file of the shadow instance; the shadow instance is started on a non-business port, and external business connections are prohibited, allowing it to only carry out the execution of probe transaction sets. The shadow database instance is isolated from the database service process and does not carry business connections. It is independent of the production environment in terms of process space, data directory, and network port, ensuring that any operations performed on it do not affect the data and operating status of the production database.

[0050] Based on the write-ahead log generation behavior affected by the target startup parameters, at least one affected target operation type is selected from the pre-defined operation type set, and a corresponding probe transaction is generated for each target operation type to construct a probe transaction set. The pre-defined operation type set includes at least data insertion, data update, data deletion, index building, transaction commit, and transaction rollback; the correspondence between parameters and affected operation types is pre-defined as a mapping table. For example, the write-ahead log level parameter affects the level of detail in log recording for all operation types, the archive mode parameter and archive command parameter affect log switching and archive triggering behavior, and the preload dynamic library parameter affects the log generation behavior of extension-related operations. Each transaction in the generated probe transaction set is a read-only transaction or a rollbackable transaction, constructed in an independent temporary mode so that it can be rolled back or discarded as a whole after execution, and is not retained in the persistent data of the shadow instance.

[0051] On the shadow database instance, a set of probe transactions is executed in a predetermined order. Operation records generated during the execution of each probe transaction are sequentially written to the write-ahead log, resulting in a probe write-ahead log sequence. At least one log switch is forced during execution to ensure the generated write-ahead log files meet archiving conditions, thereby triggering and observing archiving behavior. After execution, the execution duration and the amount of write-ahead log data generated are recorded.

[0052] Behavioral fingerprints are collected corresponding to the probe write-ahead log sequence. These behavioral fingerprints characterize the actual impact of target startup parameters on write-ahead log generation and archiving behaviors. The collected behavioral fingerprints include at least one of the following: the set of write-ahead log record types contained in the probe write-ahead log sequence, the data volume of the probe write-ahead log sequence, whether the write-ahead log archiving function is triggered, and the final path of the generated archive file. The collection method is as follows: traverse the probe write-ahead log sequence, count the types and quantities of each record type to obtain the record type set; count the total number of bytes in the sequence to obtain the data volume; detect whether a new archive file is generated at the archiving location to obtain the archiving trigger identifier; when archiving is triggered, record the complete path of the generated archive file to obtain the archive final path. The collected items are organized into behavioral fingerprint records according to preset fields.

[0053] The collected behavioral fingerprints are compared field by field with the preset baseline behavioral fingerprints. During the comparison, the record type set is judged by set equality, the data volume is judged by whether the relative deviation exceeds the preset tolerance, the archive trigger identifier is judged by Boolean equality, and the archive landing path is judged by the equality of the normalized string. When the comparison result of any field is inconsistent, a behavioral deviation result indicating that there is a deviation is obtained; when the comparison results of all fields are consistent, a behavioral deviation result indicating that there is no deviation is obtained.

[0054] On the shadow database instance, a pre-recovery simulation is performed on the probe write-ahead log sequence. This simulation simulates the recovery process following a database crash. The pre-recovery process involves: forcibly stopping the current data state of the shadow instance to simulate a database crash, placing the shadow instance in an abnormal shutdown state; then restarting the shadow instance to initiate the recovery process; starting from the most recent checkpoint, sequentially replaying each write-ahead log record in the probe write-ahead log sequence until the end of the sequence is reached or the recovery process terminates; after the recovery process is complete, a consistency check is performed on the recovered data.

[0055] A recovery fingerprint is collected corresponding to the pre-recovery recovery. The recovery fingerprint is used to characterize the consistency status between the recovery termination position and the recovery result. The collected recovery fingerprint includes at least one of the following: the termination log sequence number of the pre-recovery recovery, the consistency check value calculated on the recovered data after the pre-recovery recovery, the number of write-ahead log records replayed during the pre-recovery recovery, and whether the pre-recovery recovery was successful. The termination log sequence number is taken from the log position corresponding to the end of the recovery process; the consistency check value is calculated on the recovered data set using a preset digest algorithm; the number of replayed records is the number of write-ahead log records actually replayed during the recovery process; whether the recovery was successful is determined based on whether the recovery process ended normally and no recovery errors occurred.

[0056] The collected recovered fingerprint is compared field by field with the preset expected recovered fingerprint to obtain a recoverability measure. When the recovered fingerprint indicates that the pre-recovery was unsuccessful, or when any field of the recovered fingerprint and the expected recovered fingerprint does not match, the recoverability measure takes the value indicating that it is unsolvable; when the recovered fingerprint indicates that the pre-recovery was successful and matches all fields of the expected recovered fingerprint, the recoverability measure takes the value indicating that it is solvable.

[0057] The following rules shall be used to determine the handling strategy: (i) Prevent startup: If the recoverability metric indicates that the simulated recovery failed, or the recovery fingerprint does not match the expected recovery fingerprint, then it is determined that the target startup parameters have caused the database to lose recoverability, the database service process is prevented from starting, and an error message is output. The output error message includes the parameter name of the target startup parameter, the baseline value, the actual value, the termination log sequence number of the simulated recovery, and the name of the mismatched field.

[0058] (II) Restricted Mode Startup: If the recoverability metric indicates successful pre-recovery and the recovery fingerprint matches the expected recovery fingerprint, but the behavior deviation result indicates a deviation, then it is determined that the target startup parameters have not yet compromised recoverability but have altered the write-ahead log generation behavior or archiving behavior. The database service process is then started in restricted mode. Restricted mode is a running mode that disables the database's write-ahead log archiving function. Specifically, it involves forcibly setting the archiving mode parameter to off at startup, preventing archiving from being triggered after the write-ahead log switch, thereby blocking the spread of potentially abnormal archiving behavior to the archiving chain. In restricted mode, the database is further restricted to read-only mode, database connections are restricted to local connections only, master-slave replication is disabled, or checkpointing is prohibited. After startup, a confirmation message is output, indicating to the administrator that there is a deviation in startup parameters and confirmation is required.

[0059] (III) Allow and update the baseline. If the recoverability metric indicates successful pre-recovery and the recovery fingerprint matches the expected recovery fingerprint, and the behavior deviation result indicates no deviation, then it is determined that although the target startup parameters are inconsistent with the baseline record, they have not had an actual impact. Update the parameter values ​​of the corresponding records in the trusted baseline file with the actual values, and continue to start the database service process. During the update, record the update time and update source of this baseline update, update the behavior fingerprint obtained in this collection to the baseline behavior fingerprint, and update the recovery fingerprint to the expected recovery fingerprint, completing the automatic resynchronization of the baseline.

[0060] Once the disposal strategy is determined, the shadow database instance is destroyed, releasing its occupied temporary data directory, RAM disk space, and network ports, and cleaning up temporary files generated during the process. When using copy-on-write snapshots, the destruction process involves unmapping the snapshot mapping and deleting the incremental data layer; when using RAM disks, the destruction process involves unmounting the RAM disk and releasing the corresponding memory area. The destruction operation does not affect any data or state of the production database.

[0061] After startup in restricted mode, in response to the administrator's confirmation command for the target startup parameters, the parameter values ​​in the corresponding records of the startup parameter trusted baseline file are updated with the actual values, and the database is switched from restricted mode to normal mode, restoring the write-ahead log archiving function. In response to the administrator's denial command, the database is prevented from continuing to run in restricted mode, an error message is output, and the database service process is stopped. Confirmation and denial commands are input via preset configuration commands or management functions.

[0062] Before creating a shadow database instance in the isolated operating environment, a query is performed to check if historical probe execution records exist. If they exist and the actual values ​​corresponding to the historical probe execution records are the same as the actual values ​​of the target startup parameters, the behavioral fingerprints and recovery fingerprints corresponding to the historical probe execution records are directly reused. The probe transaction set and pre-recovery are not repeated on the shadow instance, and the handling strategy is directly determined. Historical probe execution records are stored with parameter value sets as keys and behavioral fingerprints and recovery fingerprints as values, and their collection time is recorded. When the collection time exceeds the preset validity period from the current time, it is determined to be invalid, and the probe and pre-recovery are re-executed.

[0063] If the comparison results are consistent, a verification log is recorded, and the database service process continues to start. The verification log records the verification execution time, the number of key startup parameters involved in the verification, and the verification conclusion, and is written to the database log file.

[0064] All the above branches eventually merge, and the database startup is complete.

[0065] Step 103: After the verification is passed, during the database business operation, a trusted digest of the write-ahead log record of each transaction is generated, and the write-ahead log records of each transaction are linked together into a trusted log chain according to the correlation between different trusted digests.

[0066] In one implementation of this application, during the write-ahead log writing process, the preceding digest and record feature information corresponding to each transaction are obtained. The preceding digest and record feature information are then combined and hashed to obtain a trusted digest of each transaction's write-ahead log record. The record feature information includes at least the log sequence number, record content, and generation time. The preceding digest is a trusted digest of the preceding write-ahead log record of the adjacent transaction. The trusted digests of each transaction are used as the preceding digests of the write-ahead log records of subsequent adjacent transactions. The write-ahead log records of each transaction are sequentially associated according to their generation order to construct a trusted log chain.

[0067] Specifically, during the database's business operations, the modifications performed during transactions are sequentially written to the write-ahead log file in the form of write-ahead log records before the corresponding data pages are written to disk. In this embodiment, during the write-ahead log writing process, a chain of trusted digests is generated for each write-ahead log record, meaning that a trusted digest is generated for each write-ahead log record.

[0068] For the current write-ahead log record to be written, its pre-write hash (prev_wal_hash) is obtained. This pre-write hash is used to establish a chain-like relationship between the current write-ahead log record and its preceding adjacent write-ahead log record. Specifically, if the current write-ahead log record is the first write-ahead log record in the current write-ahead log stream, its pre-write hash is taken from a preset initial value; this preset initial value can be a fixed constant, such as a string of all zeros or a preset fixed hash value. If the current write-ahead log record is one of the other write-ahead log records besides the first one, its pre-write hash is taken from the trusted hash of its preceding adjacent write-ahead log record.

[0069] Retrieve the record characteristic information of the current write-ahead log record. The record characteristic information includes: Log sequence number (wal_lsn): The log sequence number of the current write-ahead log record, used to identify the position of the write-ahead log record in the write-ahead log stream; Record content (wal_record): The complete content of the current write-ahead log record, used to ensure that the content of this write-ahead log record has not been tampered with; Generation time (timestamp): The generation time of the current write-ahead log record, used to add a time dimension anti-tampering factor to the write-ahead log record.

[0070] The obtained pre-write log digest is combined with the obtained log sequence number, record content, and generation time. Specifically, all parameters determined by HASH(prev_wal_hash + wal_lsn + wal_record + timestamp) are used as input to the hash function. After hash function operation, a trusted digest (current_wal_hash) of the current write-ahead log record is obtained. This trusted digest is the final hash value of this write-ahead log record. Specifically, this combination involves concatenating the pre-write log digest, log sequence number, record content, and generation time in this order as a string or byte stream as input to the hash function. The hash function can use at least one of the following hash algorithms: MD5, SHA-256, or SM3.

[0071] This write-ahead log entry, along with its trusted digest, will be written to the write-ahead log file. The trusted digest can be written as a separate field along with the write-ahead log entry, or it can be recorded in a separate digest file.

[0072] For each subsequent write-ahead log record, the following steps are performed: the trusted digest of the previous write-ahead log record is used as the pre-order digest of the next adjacent write-ahead log record; that is, the prev_wal_hash of the Nth write-ahead log record is taken as the current_wal_hash of the (N-1)th write-ahead log record. Thus, each write-ahead log record is sequentially associated according to its generation order, forming a chain-like dependency structure that points sequentially to each other, constructing a trusted log chain. All subsequent write-ahead log records follow this same principle.

[0073] Based on the aforementioned trusted log chain, at least one of the following verification capabilities can be achieved: continuity verification of write-ahead log records, tampering detection of write-ahead log records, missing write-ahead log records, abnormal order detection of write-ahead log records, replacement detection of write-ahead log records, trusted verification of the recovery chain during database crash recovery, and trusted verification of the source of write-ahead logs replayed by the standby database during master-slave replication.

[0074] Figure 5 This application provides a schematic diagram of a database transaction trusted chain dependency relationship, as shown in the embodiments. Figure 5As shown, the trustworthiness of the executable file (corresponding to the bin directory) is the head of the chain, and its trustworthiness is a prerequisite for the trustworthiness of the dynamic library (corresponding to the lib directory). Together, they constitute a trustworthy runtime environment. A trustworthy runtime environment further points to trustworthy startup parameters. That is, the trustworthiness of startup parameters is only meaningful if the executable file and dynamic library have not been tampered with and the database runtime environment is trustworthy. Trustworthy startup parameters unidirectionally depend on and determine the trustworthiness of WAL generation. Specifically, parameters such as the archiving mode, archiving command, and write-ahead log level directly determine the generation and archiving behavior of the write-ahead log. Therefore, if the parameters are untrustworthy, the generated write-ahead log will also be untrustworthy. Trustworthy WAL generation further points to trustworthy WAL archiving. That is, the generation of the write-ahead log is a prerequisite for its archiving. Only if the generation stage is trustworthy can the archived log file have a trustworthy basis. Simultaneously, the trustworthiness of the archiving command points to the trustworthiness of the archiving parameters, and together with the trustworthiness of the archiving parameters, directly points to the final stage. This indicates that an untrustworthy archiving command itself will directly destroy the archiving result and thus jeopardize the transaction recovery chain, without needing to be passed through other stages. All the dependencies mentioned above ultimately converge on the ultimate trustworthy goal of the transaction recovery chain. That is, whether the entire log chain on which database crash recovery and master-slave replay depend is trustworthy depends on whether each preceding step, from the operating environment, startup parameters, write-ahead log generation to archiving, is trustworthy. If any preceding step fails, its untrustworthiness will be passed down level by level along the arrow direction, eventually leading to the untrustworthiness of the transaction recovery chain.

[0075] Step 104: Archive the write-ahead logs, determine the integrity summary of the archived log files, and write the integrity summary into the archive verification record.

[0076] In one implementation of this application, an archive command is executed to copy the write-ahead log file to the archive location, and the success of the archive is determined. If the archive fails, no archive verification record is recorded and the process ends. If the archive succeeds, the archive callback function set within the write-ahead log archive process is called, and the full path of the archived write-ahead log file is passed to the archive callback function. The integrity digest of the archived write-ahead log file is determined through the archive callback function, and the full path, integrity digest, and archive time are written to the archive verification record.

[0077] Specifically, Figure 6 A flowchart of the execution of a WAL archiving callback function is provided for an embodiment of this application, such as... Figure 6 As shown, the execution process of the WAL archiving callback function is as follows: When the database is enabled in archive mode (archive_mode) and the archive command (archive_command) is configured, the write-ahead log archive process enters the preparation archiving state when the write-ahead log file is full and a log switch occurs, and performs archiving on the write-ahead log file to be archived.

[0078] The write-ahead log archiving process executes an archive command, copying the write-ahead log file to be archived from the write-ahead log directory to the archive location, which is determined by the target path specified in the archive command. This copying process is implemented by calling operating system commands or file copying interfaces, copying the source write-ahead log file to the target path in binary mode while keeping its filename unchanged.

[0079] Obtain the execution result of the archive command and determine whether the archive was successful based on the result. Specifically: read the exit status code returned after the archive command is executed; if the exit status code is zero, the archive is considered successful; if the exit status code is non-zero, the archive is considered to have failed.

[0080] If archiving fails, the process enters the archiving failure handling phase, without writing any content to the archiving verification record, and the current archiving process ends. When archiving fails, an archiving failure log can be recorded, and the archiving process can be re-executed on the write-ahead log file later.

[0081] If archiving is successful, the archiving callback function, xlog_md5_w, which is pre-placed in the write-ahead log archiving process, is called. The full path of the archived write-ahead log file is passed to the archiving callback function. The full path includes the filename of the archived write-ahead log file and its complete path under the archiving location.

[0082] The archive callback function locates the archived write-ahead log file based on the passed full path, reads the file content, and performs a digest operation on the read content to obtain a complete digest of the archived write-ahead log file. In this embodiment, the digest operation is an MD5 digest operation, and the resulting complete digest is the MD5 digest value. Specifically: the archived write-ahead log file pointed to by the full path is opened in read-only mode, and all its bytes are read sequentially in blocks. The read byte stream is then input into the MD5 digest algorithm to update each block. After reading is complete, a fixed-length MD5 digest value is output and converted into a hexadecimal string.

[0083] The current time is obtained as the archiving time, which is the system timestamp corresponding to the time when the digest calculation was completed or the time when archiving was completed. The archiving callback function writes the full path of the archived write-ahead log file, the integrity digest obtained in step six, and the archiving time into the archiving verification record in the format "path|MD5|time". That is, it writes to the checklog.txt file ($PGDATA / pg_wal / checklog.txt) in the write-ahead log directory under the database data directory, where the recorded content is "full path|MD5|archiving time". When writing, a new record is added to the end of the checklog.txt file in append mode. This record records the full path, MD5 digest value, and archiving time in sequence, with each field separated by a vertical bar. If the checklog.txt file does not exist, it is created first before writing.

[0084] After the above writing is completed, the archiving verification record of this write-ahead log file is completed, and the write-ahead log archiving process continues to wait for the archiving of the next write-ahead log file.

[0085] Step 105: In response to the runtime integrity verification request, recalculate the actual integrity digest for each archived log file, compare the actual integrity digest with the integrity digest in the archived verification record, and perform continuity verification on each write-ahead log record based on the trusted log chain. Based on the comparison and verification results, determine the trustworthiness of the database transaction trusted chain.

[0086] In one implementation of this application, in response to a runtime integrity verification request, an archived verification record is read to obtain each archived log file and its corresponding integrity summary. Based on the full path recorded in the archived verification record, each archived log file is located. The content of the located file is read, and the actual integrity summary of the archived log file is recalculated based on this content. The actual integrity summary is then compared one by one with the integrity summaries recorded in the archived verification record to obtain a file-level verification result. Based on the trusted log chain, the continuity of each write-ahead log record is verified, and checkpoint boundaries are checked to obtain a record-level verification result. Based on the file-level and record-level verification results, the trustworthiness of the database transaction trusted chain is determined.

[0087] Specifically, Figure 7 A flowchart of the WAL active verification function execution provided in this application embodiment is shown below. Figure 7 As shown, the execution process of the WAL active verification function is as follows: Users initiate runtime integrity checks by calling a pre-defined write-ahead log proactive verification function, specifically the `hg_security.wal_integrity_check()` function. This function is a parameterless Structured Query Language function that returns a boolean value.

[0088] Read the value of the preset global configuration parameter hg_wal_integrity.enable for log integrity verification and determine whether it is enabled. This parameter is of type bool, has a default value of off, and takes effect only after being overridden by the configuration overload function pg_reload_conf() (sighup).

[0089] If the value of this parameter is off, an error message indicating that the representation function is off will be returned directly, i.e., the error message "ERROR:hg_wal_integrity.enableisoff", and the current verification will end without executing subsequent steps.

[0090] If this parameter is set to "on", then it checks whether the archive mode parameter (archive_mode) and archive command parameter (archive_command) are configured, i.e., whether their values ​​are empty. If the archive mode parameter or archive command parameter is not configured correctly, an error message or alarm message is output, and the current verification ends.

[0091] If both the archive mode parameters and the archive command parameters are configured, the system checks if an archive verification record, i.e., the checklog.txt file, exists. If the archive verification record does not exist, a warning message is output and the current verification ends. If the archive verification record exists, the active verification function internally calls the write-ahead log digest detailed verification function, i.e., calls hg_security.pg_wal_md5_verify, which performs file-level and record-level verification. This detailed verification function is a parameterless Structured Query Language function, and its return value is a table structure.

[0092] Read the archived verification record (checklog.txt) to obtain the archived log files and their corresponding integrity digests. The archived verification record is recorded line by line in the format "path|MD5|time". During reading, each line is parsed, yielding the full path name (wal_filename) of an archived log file and its corresponding integrity digest. This integrity digest is the expected MD5 value (expected_md5), taken from the baseline value recorded in the archived verification record. This establishes the correspondence between each archived log file to be verified and its expected integrity digest.

[0093] For each archived log file obtained, based on the full path recorded in the archive verification record, the file located at the archive location is identified. The file content of the identified file is read, and a digest operation is performed on the read content to recalculate the actual integrity digest of the archived log file, i.e., the actual MD5 value (actual_md5). The digest algorithm used in the recalculation is consistent with the digest algorithm used to generate the integrity digest during the archiving stage, i.e., the MD5 digest algorithm is used. During the calculation, the file pointed to by the full path is opened in read-only mode, and its entire file content is read sequentially and input into the digest algorithm to obtain the actual MD5 value of the file. If the file pointed to by the full path does not exist or is unreadable, the actual integrity digest is not calculated, and the corresponding prompt message is directly recorded as the file does not exist or the file is unreadable.

[0094] The recalculated actual integrity digest (actual_md5) is compared one by one with the obtained expected integrity digest (expected_md5) corresponding to the archived log file to determine if they match, thus obtaining the file-level verification result. The file-level verification result is output in a table structure, with fields including: write-ahead log file name (wal_filename), expected integrity digest (expected_md5), actual integrity digest (actual_md5), match (is_match), and info. The match field is true when the actual value matches the expected value and false when they do not. The info field records the corresponding message when the file does not exist, the file is unreadable, or the verification fails. The comparison is performed record by record in the archived verification record, and the file-level verification result is obtained after traversing all archived log files.

[0095] Based on this trusted log chain, continuity verification is performed on each write-ahead log record. This involves verifying whether each write-ahead log record is sequentially connected in the write-ahead log stream and whether it has been modified, deleted, inserted, reordered, or replaced, based on the chained relationship between the preceding digest and the trusted digest of each record. Simultaneously, checkpoint boundaries are verified to obtain record-level verification results. Continuity verification involves recalculating the trusted digest of each write-ahead log record and comparing the recalculated result with the trusted digest recorded in that record to verify the chained association. Checkpoint boundary verification verifies whether the log position determined by the checkpoint matches the corresponding write-ahead log record in the trusted log chain.

[0096] If any write-ahead log line fails to pass verification in either the file-level or record-level verification results, the failed write-ahead log line is recorded, and a first return value (false) indicating a verification failure is returned. If no failed write-ahead log line fails, a second return value (true) indicating all verifications passed is returned, and the verification ends. The recorded failed write-ahead log line contains the full path name of the write-ahead log file, the expected integrity digest, the actual integrity digest, whether a match is found, and a warning message, allowing operations personnel to locate the specific archived log file that has been tampered with, deleted, or is unreadable.

[0097] Based on the file-level verification results and the record-level verification results obtained in step nine, the trustworthiness of the database transaction trust chain is determined: when both the file-level and record-level verification results pass, the database transaction trust chain is determined to be trustworthy, and the archived log base upon which the transaction recovery link depends has not been tampered with, deleted, or forged; when either the file-level or record-level verification result fails, the database transaction trust chain is determined to be untrustworthy. The determined trustworthiness conclusion is output as a Boolean return value by the active verification function, and detailed verification details are output in a table structure by the detailed verification function, thereby supporting the trustworthiness verification of the recovery link during database crash recovery and the source trustworthiness verification of the replay write-ahead logs in the standby database during master-slave replication.

[0098] In one implementation of this application, abnormal information generated during the verification process is obtained, the abnormality level corresponding to the abnormal information is identified, and an abnormality handling operation matching the abnormality level is executed according to the pre-set handling rules corresponding to each abnormality level. The abnormality handling operation includes at least one of database startup control, log output, or verification result information recording.

[0099] Specifically, the database integrity verification function supports tiered exception handling. It pre-defines the correspondence between each exception level, trigger scenario, and handling method, and adopts different handling strategies based on the severity and scope of the exception. The tiered exception handling strategies are as follows: For the severe blocking level, the trigger scenario is the failure of pg_ctl startup to verify the bin / lib directory; the handling method is to prevent the database from starting and output detailed error information. For the high-risk alarm level, the trigger scenarios are inconsistencies between startup parameters and the trusted baseline, or tampering with critical GUCs; the handling method is to output an ERROR-level log and optionally prevent startup. For the runtime warning level, the trigger scenarios are the failure of WAL file MD5 verification and chain hash mismatch; the handling method is to return false and output a WARNING-level warning. For the normal exception level, the trigger scenarios are the absence of the WAL file or the file being unreadable; the handling method is to record detailed reasons in the info field. For the notification level, the trigger scenario is the absence of checklog.txt, i.e., no archived records yet; the handling method is to output a NOTICE-level notification message.

[0100] During the database startup phase, the write-ahead log archiving phase, and the runtime integrity verification phase, corresponding integrity checks are performed, and any exceptions generated during the verification process are captured. The captured exception information includes the exception type, the object identifier corresponding to the exception (e.g., directory name, parameter name, write-ahead log file name), and the expected and actual values ​​obtained from the verification.

[0101] Based on the acquired anomaly information, its corresponding anomaly level is identified, that is, it is determined whether the anomaly belongs to the category of severe blockage, high-risk alarm, operational warning, ordinary anomaly, or prompt message. The identification process is based on the stage in which the anomaly occurred and the verification objects involved: if it occurs during the pg_ctl startup phase and involves preset critical directories, it is identified as severe blockage; if it occurs during the startup phase and involves critical startup parameters, it is identified as a high-risk alarm; if it occurs during runtime integrity verification and involves digest comparison or chain verification, it is identified as an operational warning or ordinary anomaly; if it involves missing archive verification records, it is identified as a prompt message.

[0102] Based on the pre-defined handling rules corresponding to each anomaly level, execute the anomaly handling operation matching that anomaly level. Supported anomaly handling operations include at least one of the following: database startup control, log output, and verification result information recording, as detailed below: Severe Block: During the pg_ctl startup phase, a severe block is triggered when the directory-level integrity digest of the executable file directory bin or the dynamic library directory lib is inconsistent with the reference directory digest recorded in the runtime environment's trusted baseline file. This prevents the database from starting and outputs detailed error information. The output error information includes the name of the directory where the verification failed, the baseline digest value, and the current actual digest value.

[0103] High-risk alert: When startup parameters are inconsistent with the trusted baseline, or critical GUC parameters are tampered with, a high-risk alert is triggered: an ERROR-level log is output, and startup can be optionally prevented. That is, after reporting the alert information, the database startup is either prevented or allowed to continue, based on a preset policy. The output alert information includes the inconsistent parameter name, baseline value, and actual value.

[0104] Runtime Warning: During runtime integrity verification, if the MD5 checksum of the write-ahead log file fails or the write-ahead log chain hash does not match, a runtime warning is triggered: It returns false, outputs a WARNING level warning, and records the verification details. The recorded details include the full path name of the write-ahead log file, the expected integrity digest, the actual integrity digest, and whether they match. For cases of chain hash mismatch, the anomaly location is further located, i.e., the specific write-ahead log record where the chain association is broken.

[0105] Normal Exception: When the write-ahead log file does not exist or is unreadable, a normal exception is triggered: a warning is output, and the detailed reason is recorded in the info field of the verification result table, indicating that the file does not exist or is unreadable. This write-ahead log file will no longer participate in the digest comparison. In this case, the verification function continues to perform verification on the remaining write-ahead log files and eventually returns a conclusion indicating that the verification failed.

[0106] Warning message: When the archived verification record checklog.txt does not exist, i.e., there is no archived record yet, a NOTICE-level warning message will be triggered, indicating that there is currently no archived verification record available for verification. In this case, the verification is not considered a failure.

[0107] The results of the execution of the handling operations will be output and retained: For handling operations related to database startup control, the result of startup being blocked or startup being allowed will be output; for handling operations related to log output, the result will be output to the database log according to the corresponding ERROR, WARNING, or NOTICE level; for handling operations related to verification result information recording, the detailed reasons, verification details, and the location of the anomaly will be recorded in the corresponding fields of the verification result table for subsequent traceability and auditing.

[0108] In one embodiment, this application further includes an hg_integrity_check plugin module: A new plugin, named hg_integrity_check, has been added. This plugin performs the verification work for all the functions described above.

[0109] Plugin installation timing: This plugin is automatically created during the initdb phase and does not require manual installation by the user.

[0110] This plugin provides an active verification function, adding the hg_integrity_check function, which calls the aforementioned functional interface functions to complete the relevant functional verification.

[0111] The plugin includes the following capabilities: WAL log integrity verification verifies the consistency of the MD5 hash of archived WAL logs. Parse the checklog.txt file, parse the archived verification record file, and extract baseline data; WAL file actual MD5 calculation, calculates the MD5 value of the current WAL file in real time; WAL chained hash verification verifies the chained hash continuity between WAL records. The SQL function interface provides user-callable SQL validation functions; GUC parameter control is enabled via the GUC parameter control verification function. Record the reasons for the error, and record in detail the specific reasons for the verification failure; The verification result is returned; the structured version returns the complete verification result.

[0112] Figure 8 A flowchart of a verification method based on a transaction trust chain is provided for embodiments of this application, as follows: Figure 8As shown, the verification method based on the transaction trust chain is as follows: First, the database is initialized by executing `initdb`. During the initialization phase, a runtime environment baseline file (.md5) and a startup parameter trust baseline file (.hg_config_checksum) are generated, completing the construction of the trust baseline. Then, a startup command (pg_ctlstart-C) carrying consistency verification parameters is executed. Before the database service process starts, the above two types of baseline files are read and a startup verification is performed to determine whether the startup verification passes. If the verification fails, an error message is output and the database startup is prevented, thus blocking the untrusted runtime environment before startup. If the verification passes, the database starts normally and enters the business operation process. During database operation, transactions are generated, resulting in WAL records. A chained hash is calculated for each WAL record to form a trust log chain with sequential relationships. During checkpoint execution, the current WAL tail hash is recorded to establish the trust boundary. When the WAL log file is full and a switch occurs, WAL archiving is performed. Upon successful archiving, an archive verification record (checklog.txt) is generated, containing the path, integrity summary, and archiving time of the archived log file. Subsequently, the user initiates runtime integrity verification by calling the WAL integrity verification function (wal_integrity_check()). The system reads the archive verification record and recalculates the actual integrity summary of each archived log file for comparison. Simultaneously, it verifies the continuity of each WAL record and checkpoint boundaries based on the trusted log chain, determining whether all verifications pass. If any verification fails, a warning is output and failure details are recorded. If all verifications pass, the verification result is returned and the process ends, completing the full lifecycle verification of the database transaction trusted chain.

[0113] Figure 9 A schematic diagram of the structure of a verification device based on a database transaction trust chain provided in this application embodiment is shown below. Figure 9As shown, the verification device 200 based on the database transaction trust chain includes: at least one processor 201; and a memory 202 communicatively connected to the at least one processor 201; wherein the memory 202 stores instructions executable by the at least one processor 201, which, when executed by the at least one processor 201, enable the at least one processor 201 to: during the database initialization phase, construct a database trust baseline file based on preset key directories and effective key startup parameters in the database installation directory; respond to the database startup command, perform a pre-consistency verification based on the trust baseline file before the database service process starts; and after the verification passes, perform a pre-consistency verification on the database transaction trust chain. During database operations, a trusted digest of each transaction's write-ahead log record is generated. Based on the correlation between different trusted digests, the write-ahead log records of each transaction are chained together into a trusted log chain. The write-ahead logs are archived, and the integrity digest of the archived log files is determined and written to the archive verification record. In response to runtime integrity verification requests, the actual integrity digest of each archived log file is recalculated, and the actual integrity digest is compared with the integrity digest in the archive verification record. The continuity of each write-ahead log record is verified based on the trusted log chain. Based on the comparison and verification results, the trustworthiness of the database transaction trusted chain is determined.

[0114] This application provides a non-volatile computer storage medium storing computer-executable instructions. These instructions are configured to: during the database initialization phase, construct a database trusted baseline file based on preset key directories and effective key startup parameters in the database installation directory; respond to a database startup command, perform a pre-consistency check based on the trusted baseline file before the database service process starts; after successful verification, generate trusted digests of the write-ahead log records for each transaction during database operation, and chain the write-ahead log records of each transaction into a trusted log chain based on the correlation between different trusted digests; archive the write-ahead logs, determine the integrity digests of the archived log files, and write the integrity digests into the archive verification record; respond to a runtime integrity verification request, recalculate the actual integrity digests of each archived log file, compare the actual integrity digests with the integrity digests in the archive verification record, and perform continuity verification on each write-ahead log record based on the trusted log chain, thereby determining the trustworthiness of the database transaction trusted chain based on the comparison and verification results.

[0115] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments for devices and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0116] The above descriptions are merely embodiments of this application and are not intended to limit the scope of this application. For those skilled in the art, various modifications and variations can be made to the embodiments of this application. These modifications or substitutions do not cause the essence of the corresponding technical solutions to depart from the spirit and scope of the technical solutions in the embodiments of this application.

Claims

1. A verification method based on a database transaction trust chain, characterized in that, The method includes: During the database initialization phase, a trusted baseline file for the database is constructed based on the preset key directories in the database installation directory and the effective key startup parameters. In response to the database startup command, a pre-consistency check is performed based on the trusted baseline file before the database service process starts. After the verification is passed, during the database business operation, a trusted digest of the write-ahead log record of each transaction is generated, and the write-ahead log records of each transaction are linked together into a trusted log chain according to the correlation between the different trusted digests. The write-ahead log is archived, the integrity summary of the archived log file is determined, and the integrity summary is written into the archive verification record; In response to a runtime integrity verification request, the actual integrity digest of each archived log file is recalculated, and the actual integrity digest is compared with the integrity digest in the archived verification record. The continuity of each write-ahead log record is verified based on the trusted log chain, and the trustworthiness of the database transaction trusted chain is determined based on the comparison and verification results.

2. The verification method based on a database transaction trust chain according to claim 1, characterized in that, During the database initialization phase, a trusted database baseline file is constructed based on preset key directories and effective key startup parameters in the database installation directory. This specifically includes: In response to the database initialization completion command, the baseline generation process is triggered; Traverse the preset key directories, determine the reference directory summary based on the file content of each preset key directory, and generate a trusted baseline file for the runtime environment based on the reference directory summary; Obtain the key startup parameters that take effect during the database initialization phase, and generate a reliable baseline file for startup parameters based on the parameter values ​​and parameter attribute information of the key startup parameters; wherein, the parameter attribute information includes at least the parameter name, parameter type, and activation method; Based on the trusted baseline file of the operating environment and the trusted baseline file of the startup parameters, the trusted baseline file of the database is obtained.

3. The verification method based on a database transaction trust chain according to claim 2, characterized in that, The pre-consistency check performed based on the trusted baseline file specifically includes: When the database startup or restart command is detected to carry runtime environment verification parameters, the current directory summary corresponding to each of the preset key directories is determined, and the current directory summary is compared with the reference directory summary recorded in the runtime environment trusted baseline file to obtain the directory verification result. If the directory verification result is inconsistent, then the database service process will be prevented from starting and an error message will be output. If the directory verification results are consistent, then the verification log is recorded and the database service process is started.

4. The verification method based on a database transaction trust chain according to claim 2, characterized in that, The pre-consistency check performed based on the trusted baseline file specifically includes: If the preset global configuration parameter is set to "on", then the startup parameter trusted baseline file is read to obtain the actual value of the currently effective key startup parameter, and the actual value is compared with the parameter value recorded in the startup parameter trusted baseline file parameter by parameter. If the comparison results are inconsistent, an alarm message will be reported, and the database service process will be selectively blocked from starting according to a preset strategy. If the comparison results are consistent, the verification log is recorded and the database service process is restarted.

5. The verification method based on a database transaction trust chain according to claim 1, characterized in that, The process of generating trusted digests of the write-ahead log records for each transaction, and chaining the write-ahead log records of each transaction into a trusted log chain based on the correlation between different trusted digests, specifically includes: During the write-ahead log writing process, the preceding summary and record feature information corresponding to each transaction are obtained, and the preceding summary and the record feature information are combined and hashed to obtain a reliable summary of each transaction's write-ahead log record; wherein, the record feature information includes at least the log sequence number, record content and generation time, and the preceding summary is a reliable summary of the previous adjacent transaction's write-ahead log record. The trusted summary of each transaction is used as the preorder summary of the write-ahead log record of the adjacent transaction. The write-ahead log records of each transaction are sequentially associated in the order of generation to construct the trusted log chain.

6. The verification method based on a database transaction trust chain according to claim 1, characterized in that, The process of archiving the write-ahead log, determining the integrity digest of the archived log file, and writing the integrity digest into the archive verification record specifically includes: The archive command copies the write-ahead log file to the archive location; Determine if archiving was successful; If archiving fails, do not record the archiving verification record and end the process; If archiving is successful, the archiving callback function set in the write-ahead log archiving process is invoked, and the full path of the archived write-ahead log file is passed to the archiving callback function; The archive callback function determines the integrity summary of the archived write-ahead log file, and writes the full path, the integrity summary, and the archive time into the archive verification record.

7. The verification method based on a database transaction trust chain according to claim 1, characterized in that, In response to a runtime integrity verification request, the actual integrity digest of each archived log file is recalculated, and the actual integrity digest is compared with the integrity digest in the archived verification record. Continuity verification is performed on each write-ahead log record based on the trusted log chain. Based on the comparison and verification results, the trustworthiness of the database transaction trusted chain is determined. Specifically, this includes: In response to a runtime integrity verification request, the archived verification record is read to obtain each archived log file and its corresponding integrity summary. Based on the full path recorded in the archive verification record, each of the archived log files is located; Read the content of the located file, recalculate the actual integrity summary of the archived log file based on the content of the file, and compare the actual integrity summary with the integrity summary recorded in the archived verification record one by one to obtain the file-level verification result; Based on the trusted log chain, the continuity of each write-ahead log record is verified, and the checkpoint boundaries are checked to obtain the record-level verification results. The trustworthiness of the database transaction trust chain is determined based on the file-level verification results and the record-level verification results.

8. The verification method based on a database transaction trust chain according to claim 1, characterized in that, After determining the trustworthiness of the database transaction trust chain based on the comparison and verification results, the method further includes: Obtain error information generated during the verification process; Identify the anomaly level corresponding to the anomaly information; Based on the pre-set handling rules corresponding to each anomaly level, execute the anomaly handling operation that matches the anomaly level; The exception handling operations include at least one of database startup control, log output, or verification result information recording.

9. A verification device based on a database transaction trust chain, characterized in that, The device includes a memory for storing computer program instructions and a processor for executing the program instructions, wherein when the computer program instructions are executed by the processor, the device is triggered to perform the method according to any one of claims 1-8.

10. A non-volatile computer storage medium storing computer-executable instructions, characterized in that, The computer-executable instructions are capable of performing the method described in any one of claims 1-8.

Images