A transaction log and rollback point-based automatic rollback method and system for device offline upgrade failure

Abstract

This invention discloses a method and system for automatic rollback in case of offline upgrade failure of a detection device based on transaction logs and rollback points. The method includes: Step 1: After receiving an offline upgrade request, the target detection device generates a transaction identifier, initializes the transaction log corresponding to the transaction identifier, writes the transaction start record into the transaction log, and persists it; Step 2: The target detection device verifies the upgrade package stored in itself, deploys the verified upgrade package to a candidate slot to obtain a candidate version file, and writes the deployment and verification records into the transaction log; Step 3: Writes a rollback point into the transaction log and persists it, then switches the version pointer of the old version to the version pointer of the candidate version file; Step 4: Performs a health check on the candidate version file, and determines whether to perform a rollback operation based on the health result. This invention can automatically roll back and complete the verification after rollback when the switch fails, significantly reducing the probability of erroneous operation.

Description

Technical Field

[0001] This invention relates to the field of offline upgrade technology, and in particular to a method and system for automatic rollback of offline upgrade failure detection equipment based on transaction logs and rollback points. Background Technology

[0002] Energy dispersive spectrometers (EDS) and scanning electron microscopes (SEMs) are used to detect and analyze the chemical elemental composition and microstructure of materials. To ensure the security and accuracy of the material testing data, these devices are typically not networked to prevent remote data theft and virus attacks; therefore, the testing data is stored only on local offline devices. Furthermore, the SDD detector in an EDS is highly sensitive to electromagnetic noise. High-frequency electromagnetic noise generated by network devices can be received by the highly sensitive SDD detector, easily leading to serious problems such as false detections, missed detections, and quantitative errors. Therefore, when upgrading the aforementioned testing equipment, a dual-slot or multi-slot deployment method, commonly used in offline deployment environments, is adopted. The upgrade package is copied to the target host, and the upgrade script is executed to complete the replacement and switching. On-site upgrades typically require auditability, rollback capability, and self-recovery after downtime or power outages; however, most implementations still rely on manual judgment and manual rollback.

[0003] Existing offline upgrade solutions have significant drawbacks: after an upgrade failure, a semi-upgraded state is easily formed, resulting in the mixing of old and new files and the service being unavailable even though the pointer has been switched; rollback requires human intervention, involves many steps, and is prone to errors; the reasons and processes of upgrade failure lack structured documentation, making it difficult to locate and trace the cause; when problems are discovered after switching, it is often impossible to quickly return to a consistent and usable state, which seriously affects the continuity of the use of testing equipment.

[0004] Current industry technology is evolving from script-based upgrades to transactional upgrades, with a core focus on enhancing crash consistency, rollback determinism, and audit traceability. Mechanisms such as phased verification, two-phase switching, idempotent recovery, and problematic version isolation are being introduced to reduce recovery time and human error risks in offline scenarios. However, existing solutions mostly only provide backups and manual rollbacks, lacking definable rollback points, executable transaction logs, recovery rules for switchover interruptions, and post-rollback verification and problematic version isolation. Therefore, they cannot guarantee automatic recovery to a consistent and usable state after a crash. Summary of the Invention

[0005] To address the issue that existing rollback solutions for offline upgrades of testing equipment often only provide backups and manual rollbacks, lacking verifiable rollback points and executable transaction logs, and thus failing to guarantee automatic recovery to a consistent and usable state after a crash, this invention provides a method and system for automatic rollback in case of offline upgrade failures of testing equipment, based on transaction logs and rollback points. This invention establishes a transaction log and writes each process of the offline upgrade into the log, and sets a rollback point when switching version pointers, facilitating rollback in case of offline upgrade failures. This method can automatically roll back and verify the rollback upon failure after switching, while providing verifiable transaction logs and evidence packages for easy auditing and traceability.

[0006] To achieve the above objectives, the technical solution of the present invention is as follows:

[0007] The first aspect of this invention proposes a method for automatically rolling back a device in case of offline upgrade failure based on transaction logs and rollback points, comprising:

[0008] Step 1: After receiving the offline upgrade request, the target detection device generates a transaction identifier, initializes the transaction log corresponding to the transaction identifier, writes the transaction start record into the transaction log and completes persistence, so as to provide a unified tracking key for all subsequent actions, making the upgrade process recoverable, auditable and repeatable.

[0009] Step 2: The target detection device verifies the upgrade package stored in itself, deploys the verified upgrade package to the candidate slot, obtains the candidate version file, and writes the deployment and verification records in the transaction log. This ensures that the content to be deployed is not damaged and can be identified, and provides verifiable candidate version information for the deterministic rollback before the subsequent switch.

[0010] Step 3: Write the rollback point to the transaction log and persist it. Then, switch the version pointer of the old version to the version pointer of the candidate version file. This makes it easier to ensure that the version pointer switch is determinable and recoverable, avoids the uncertainty caused by the switch interruption, and ensures that the rollback target can be determined in case of failure.

[0011] Step 4: Perform a health check on the candidate version files. Based on the health results, determine whether to perform a rollback operation. If a rollback operation is required, perform the rollback based on the rollback point and transaction log. This facilitates the timely detection of problems that only surface after the system has run and triggers the rollback in the shortest possible time, preventing the system from being unavailable for an extended period of time.

[0012] Furthermore, the transaction log includes multiple structured records and a chained summary corresponding to each structured record. The structured record includes a transaction identifier, a stage number, a stage name, an action identifier, a target object, a result code, and time information.

[0013] The chained digest is expressed by the following formula:

[0014]

[0015] in, This is a chained digest of the i-th structured record, where H is a hash function. The normalized content of the i-th structured record, It is a byte sequence concatenation, where n is the total number of structured records that have been written.

[0016] Furthermore, the target detection device's verification of the upgrade package stored within itself specifically includes:

[0017] The upgrade package is subjected to integrity verification and source verification. The integrity verification includes hash verification, and the source verification includes signature or digest comparison.

[0018] Furthermore, the rollback point in step three includes the old active slot identifier, the old version pointer value, the environment fingerprint digest, and the dependency digest;

[0019] Step three, which involves switching the old version pointer to the version pointer of the candidate version file, includes: writing a switching intention in the transaction log to declare the version pointer switching operation; then determining whether the version pointer meets the preconditions; if the preconditions are met, updating the version pointer to the version pointer of the candidate version file; the preconditions are whether the actual value of the current version pointer is equal to the old active slot pointer value; if they are equal, the preconditions are met; otherwise, the preconditions are not met.

[0020] Step three also includes: collecting data from candidate version files and obtaining the commit function. If the commit function is equal to 1, a switch commit record is written to the transaction log. If the commit function is equal to 0, no switch commit record is written to the transaction log, and step four is executed directly.

[0021] Furthermore, the submission function is expressed by the following formula:

[0022]

[0023] In the formula,

[0024]

[0025]

[0026]

[0027]

[0028]

[0029]

[0030]

[0031]

[0032]

[0033] Where J is the submission function, Let min be the indicator function, where min is the minimum value. For the set of key constraints, The minimum passing threshold for the key item. , , , , , , , All are weighting coefficients. The score is based on the consistency of file versions. The total number of upgrade package files. For the Kronecker function, For file digest functions, The actual file after switching. For candidate version files, To configure consistency score, p is the total number of configuration items. Let the weight of the j-th configuration item be... This is the configuration value after the switch. Configure values ​​for candidate version files. For consistency scores, and For weight dependence, For consistency, For version constraint satisfaction, The service consistency score is given, where q represents the total number of critical services. , and As weight, This represents the running status of the l-th service. This is the ready state for the l-th service. The service port is in a normal listening state. To score routing consistency, and As weight, For valid traffic after the switch, For the total observed flow rate, This is abnormal traffic. The data consistency score is given by r, where r is the total number of data validation items. To validate the weights of the data, For the validation function of the m-th type of data, This is the actual data after the switch. Data for candidate version files, For interface consistency score, , and For interface weight, The expected state of the return code. In a delayed state, To return to the state of the body structure, For variance, For the consistency score set, For log chain integrity correction items, To submit a trusted threshold.

[0034] Furthermore, step three also includes performing a crash recovery determination after writing a switch commit record to the transaction log;

[0035] The crash recovery determination includes: if If so, then a rollback operation will be performed; if Then proceed to step four; where I represents the switching intent flag and C represents the switching submission flag. The switching intent has been written. No switch commit record was written. This has been written to the switch commit record. For logical AND.

[0036] Furthermore, step four specifically includes:

[0037] Calculate the overall health value or weighted health score of the candidate version file. If the overall health value of the candidate version file is equal to 0, a rollback operation is performed. If the overall health value of the candidate version file is not equal to 0, a rollback operation is not performed. If the weighted health score of the candidate version file is less than the rollback score threshold, a rollback operation is performed. If the weighted health score of the candidate version file is not less than the rollback score threshold, a rollback operation is not performed.

[0038] The overall health value of the candidate version files is expressed by the following formula:

[0039]

[0040] In the formula,

[0041]

[0042] Where OK represents the overall health value of the candidate version files, and ok represents the boolean value returned by the health check item. This represents the total number of health check items. For the i-th health check item, For logical AND;

[0043] The health-weighted score of the candidate version file is expressed by the following formula:

[0044]

[0045] In the formula,

[0046]

[0047] Where S is the weighted health score of the candidate version file. for The weight, This is the normalized result of the i-th health check item.

[0048] Furthermore, the rollback operation includes:

[0049] Read the switch intent and obtain the switch commit flag C to determine the upgrade failure type: when When the upgrade failure type is "failed before switching version pointers", the version pointer remains unchanged and the candidate slots are cleared; when When an upgrade fails due to a version pointer failure, the version pointer is rolled back to the old version pointed to by the rollback point, and the overall health value of the old version is calculated. If the overall health value of the old version is 1, the rollback operation is successful. After a successful rollback, the candidate slots are isolated. No commit history has been written for the switch; OK indicates the overall health value of the candidate version file. For logical AND;

[0050] Finally, an evidence package is generated based on the transaction log. The evidence package includes the transaction identifier, transaction log summary, rollback point content summary, verification result, exception code, health check result, time information, operator information, and log hash chain end summary.

[0051] Furthermore, the isolation of candidate slots after a successful rollback operation specifically includes:

[0052] The candidate slots are scored. When the score of a candidate slot is greater than the threshold, the candidate slot is isolated and the version pointer is prevented from being switched to the version pointer of the isolated candidate slot.

[0053] The second aspect of this invention proposes an automatic rollback system for detecting offline upgrade failures of devices based on transaction logs and rollback points, comprising:

[0054] The transaction log initialization module is used to generate a transaction identifier after the target detection device receives an offline upgrade request, initialize the transaction log corresponding to the transaction identifier, write the transaction start record into the transaction log and complete the persistence, so as to provide a unified tracking key for all subsequent actions, making the upgrade process recoverable, auditable and repeatable.

[0055] The verification module is used by the target detection device to verify the upgrade package stored in itself, deploy the verified upgrade package to the candidate slot, obtain the candidate version file, and write the deployment and verification records in the transaction log. This ensures that the content to be deployed is not damaged and can be identified, and provides verifiable candidate version information for deterministic rollback before subsequent switchover.

[0056] The version pointer switching module is used to write rollback points to the transaction log and persist them. Then, it switches the version pointer of the old version to the version pointer of the candidate version file. This makes it easier to ensure that the version pointer switching is determinable and recoverable, avoids uncertain states caused by switching interruption, and ensures that the rollback target can be determined in case of failure.

[0057] The rollback judgment module is used to perform health checks on candidate version files and determine whether to perform a rollback operation based on the health results. If a rollback operation is required, it is performed based on the rollback point and transaction log, which facilitates the timely detection of problems that only surface after operation and triggers the rollback in the shortest possible time, avoiding the system being in an unavailable state for a long time.

[0058] The beneficial effects of this invention are:

[0059] This invention transforms the offline upgrade of testing equipment into a transactional and traceable process. Relying on transaction logs, rollback points, and two-stage switching, it enables automatic deterministic rollback of failed offline upgrades, avoiding a half-upgrade state. Through automatic health checks and post-rollback verification, recovery time is reduced to the second level, significantly reducing human error. Combined with problem slot isolation and evidence package archiving, it meets the high availability and audit traceability requirements of offline testing equipment scenarios, significantly improving the security, reliability, and operational efficiency of offline upgrades. Attached Figure Description

[0060] Figure 1 The flowchart illustrates an automatic rollback method for detecting offline upgrade failures of a device based on transaction logs and rollback points, as provided in Embodiment 1 of the present invention.

[0061] Figure 2 This is a schematic diagram of an automatic rollback method for detecting offline upgrade failures of a detection device based on transaction logs and rollback points, provided in Embodiment 2 of the present invention.

[0062] Figure 3 This is an architecture diagram of an automatic rollback system for offline upgrade failure detection devices based on transaction logs and rollback points, provided in Embodiment 3 of the present invention. Detailed Implementation

[0063] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of the embodiments of this invention will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0064] Example 1

[0065] like Figure 1 As shown, this invention proposes a method for automatically rolling back offline upgrade failure detection devices based on transaction logs and rollback points, including:

[0066] S101: After receiving the offline upgrade request, the target detection device generates a transaction identifier, initializes the transaction log corresponding to the transaction identifier, writes the transaction start record into the transaction log and completes persistence.

[0067] S102: The target detection device verifies the upgrade package stored in itself, deploys the verified upgrade package to the candidate slot, obtains the candidate version file, and writes the deployment and verification records in the transaction log.

[0068] S103: Write the rollback point to the transaction log and persist it, then switch the old version pointer to the version pointer of the candidate version file.

[0069] S104: Perform a health check on the candidate version file and determine whether to perform a rollback operation based on the health result. If a rollback operation is required, perform the rollback based on the rollback point and transaction log.

[0070] This invention is applicable not only to offline upgrades of testing equipment, but also to offline upgrades of isolated intranet server rooms, dual-slot deployment environments, and domestically produced systems and critical business servers. It is particularly suitable for scenarios with high availability requirements and where rollback must be definitively determined. The invention first creates a transaction log, then verifies the upgrade package, deploys the verified upgrade package to a candidate slot, writes a rollback point to the transaction log before switching the version pointer, and then performs the version pointer switch. Finally, a health check is performed on the candidate version file; if the health check fails, a rollback is performed based on the rollback point and the transaction log. The testing equipment includes an energy dispersive spectrometer and a scanning electron microscope. This invention can automatically roll back and perform post-rollback verification in case of failure after switching the version pointer, significantly reducing the probability of erroneous operations.

[0071] Example 2

[0072] Based on the above embodiments, such as Figure 2 As shown, this invention proposes a method for automatically rolling back offline upgrade failure detection devices based on transaction logs and rollback points, including:

[0073] S201: After receiving the offline upgrade request, the target detection device generates a transaction identifier, initializes the transaction log corresponding to the transaction identifier, writes the transaction start record into the transaction log and completes persistence.

[0074] Specifically, after receiving an offline upgrade request, the target detection device initiates the upgrade process. Upon startup, the upgrade process generates a transaction identifier and creates a transaction context. The transaction context includes the transaction identifier, current stage sequence number, current active slot identifier, candidate slot identifier, operator information, and start time information. Simultaneously, the transaction log corresponding to the transaction identifier is initialized, and a transaction start record is written to the log and persisted. In offline environments, power outages or abnormal process exits are common. Without a transaction identifier and start record, subsequent recovery would be unable to determine if an incomplete upgrade exists, nor would it be possible to align evidence with rollback targets. This step provides a unified tracking key for all subsequent actions, making the upgrade process recoverable, auditable, and repeatable.

[0075] Preferably, power outages and abnormal exits are common in offline environments. Without staged logs, it's impossible to determine which step the upgrade has reached, and recovery relies solely on manual deduction, easily leaving a partial upgrade state and amplifying the impact. Therefore, to transform offline upgrades from a script black box into a determinate, recoverable, and traceable transaction process, providing a basis for failure triage and deterministic rollback, this invention appends a structured record to the transaction log for each stage entered or completed during the subsequent upgrade process, and persists the record, ensuring that the last stage position written to disk can still be read after a power outage or abnormal process exit.

[0076] The transaction log consists of multiple structured records and a chained digest for each structured record. The chained digest is obtained by concatenating the previous digest with the content of the current record and then calculating a hash, and is used to verify the integrity and order of the transaction log. The structured record includes a transaction identifier, stage number, stage name, action identifier, target object, result code, and time information.

[0077] Specifically, let the transaction log record sequence be... Where R is the sequence of transaction log records. This is the normalized content of the i-th transaction log entry.

[0078] The chained digest definition is expressed by the following formula:

[0079]

[0080] in, This is a chained digest of the i-th structured record, where H is a hash function. The normalized content of the i-th structured record, It is a byte sequence concatenation, where n is the total number of structured records that have been written.

[0081] Individual record verification cannot prove order and integrity. Chained digests prove both order and integrity, enabling transaction logs to serve as reliable rollback evidence in offline upgrade scenarios. Therefore, each record written... Corresponding Afterwards, the transaction log must be written to disk so that the last written record (i) can be located during recovery. A chained digest binds each record to its predecessor; any deletion, modification, or reordering will result in inconsistencies in subsequent digests, thus detecting transaction log corruption and enabling verification of evidence packages. The transaction log is appended and persisted during critical phases, with the last persisted record serving as the basis for determining crash recovery.

[0082] S202: The target detection device verifies the upgrade package stored in itself, deploys the verified upgrade package to the candidate slot, obtains the candidate version file, and writes the deployment and verification records in the transaction log.

[0083] Specifically, integrity and source verification are performed on the upgrade package. Integrity verification can be performed using hash verification, while source verification can be performed using signature or digest comparison. After the verification is passed, the upgrade package is unpacked into the candidate slot, and the file list digest and key file hash digest of the candidate slot are recorded.

[0084] Offline media propagation paths are complex and prone to copy errors or version confusion. Without prior verification, the cause of failure is difficult to determine, and unusable content may be written to candidate slots, leading to repeated failures. Therefore, this step ensures that the content to be deployed is undamaged and identifiable, providing verifiable candidate version information for deterministic rollback before subsequent switching.

[0085] S203: Write the rollback point to the transaction log and persist it, then switch the old version pointer to the version pointer of the candidate version file.

[0086] Specifically, because directly writing to the version pointer and encountering a crash during the switchover process makes it difficult to determine whether the switchover has been completed during recovery, this invention writes and persists a rollback point in the transaction log before switching the version pointer. The rollback point provides a clear target for rolling back to the old version. A two-phase switchover is then performed: first, the switchover intention is written; then, the version pointer is updated when preconditions are met; and finally, the switchover commit record is written and persisted. The two-phase switchover provides clear boundaries, and the rollback point provides a clear rollback target, making recovery independent of manual judgment. This ensures that the version pointer switchover is determinable and recoverable, avoids uncertain states caused by switchover interruptions, and guarantees a definite rollback target in case of failure. Both the switchover intention record and the switchover commit record in the two-phase switchover are written to the transaction log and persisted. When a switchover intention record is detected but a switchover commit record is not found, a rollback or retry is performed according to the incomplete switchover path.

[0087] Specifically, the rollback point is first defined as a set of fields. Two-phase switching uses two state flags: Write to the transaction log before switching. Then, it checks whether the preconditions are met. The precondition for version pointer consistency is: After switching, update the version pointer to the candidate version. Collect multidimensional consistent observations and calculate the commit function J. If J=1, write the switch commit record. And complete the formal commit; if J=0, no switch commit record is written, and the process proceeds to S204 for health monitoring and failure determination. Here, RP is the rollback point. This is an older version pointer value. This is the old activity slot label. For environmental fingerprint summary, For dependency summary, I represents the toggle intent flag, and C represents the toggle commit flag. The actual value of the current version pointer. This is the candidate slot pointer value. For assignment and update, This is a logical AND operation. The environment fingerprint digest and dependency digest are used to verify the consistency of the old version's runtime environment during the post-rollback verification phase.

[0088] The submission function is constructed using the following steps:

[0089] First, define a set of state objects. Let the state observation vector of the upgraded system be... The corresponding baseline state vector before the upgrade is ,in, This is the state observation vector of the upgraded system. This is the status of the program file. In configuration state, For dependent component state, For process and service status, Traffic routing status, For data structure and data mapping state, For critical interface status, The baseline state vector before the upgrade. This shows the state of the program files before the upgrade. This is the configuration state before the upgrade. The state of dependent components before the upgrade. To upgrade the process and service status, To upgrade the traffic routing status, This refers to the data structure and data mapping state before the upgrade. This refers to the status of key interfaces before the upgrade.

[0090] Including the actual files before the switch, Including the configuration values ​​before the switch, Including the actual set of dependent edges before the switch, This includes the running status of the l-th service before the switchover, the ready status of the l-th service, and the normal listening status of the service port. This includes effective traffic before the switchover, total observed traffic, and abnormal traffic. Including actual data before the switch, This includes the expected state of the return code before the switch, the delay state, and the return body structure state. Including the actual file after switching, Including the configuration values ​​after switching, Including the actual set of dependent edges after the switch, This includes the running status of the l-th service after the switchover, the ready status of the l-th service, and the normal listening status of the service port. This includes effective traffic after the switchover, total observed traffic, and abnormal traffic. Including the actual data after the switch, This includes the expected state of the return code after the switch, the delay state, and the return body structure state.

[0091] A consistency score is calculated based on the state observation vector of the upgraded system and the baseline state vector before the upgrade.

[0092] File consistency score: Let the set of upgrade package files be... , For the first For each file, the file consistency score is expressed by the following formula:

[0093]

[0094] in, The score is based on the consistency of file versions. The total number of upgrade package files. For file digest functions, The actual file after switching. For candidate version files, Let Kronecker function be used.

[0095] The Kronecker function is expressed by the following formula: Where x and y are the input data.

[0096] Configuration consistency score: Let the set of critical configuration items be... , For the p-th critical configuration item, the configuration consistency score is expressed by the following formula:

[0097]

[0098]

[0099] in, To configure consistency score, p is the total number of configuration items. Let the weight of the j-th configuration item be... This is the configuration value after the switch. Configure values ​​for candidate version files.

[0100] Dependency Consistency Score: Let the dependency graph be... , For dependency graph, For a set of nodes, This is the set of dependent edges. The actual set of dependent edges after the upgrade is... The set of target dependency edges (candidate version files) is Dependency consistency is expressed by the following formula:

[0101]

[0102] in, For consistency, For the set symmetric difference, It is a very small positive number. This is the actual set of dependent edges after the switch. This is the set of dependency edges for candidate version files.

[0103] Version constraint satisfaction is expressed by the following formula:

[0104]

[0105] in, Let u be the vertex, representing the degree of version constraint satisfaction. This is the actual version number of node u after the upgrade. This is the set of version numbers for node u in the candidate version file.

[0106] In summary, the dependency consistency score is expressed by the following formula:

[0107]

[0108]

[0109] in, and For weight dependence, The score is based on consistency.

[0110] Service Consistency Score: Let the set of critical services be... , For the q-th critical service, the service consistency score is expressed by the following formula:

[0111]

[0112]

[0113] in, The service consistency score is given, where q represents the total number of critical services. , and As weight, This represents the running status of the l-th service. This is the ready state for the l-th service. The service port is in a normal listening state.

[0114] Route consistency score: The route consistency score is expressed by the following formula:

[0115]

[0116]

[0117] in, To score routing consistency, and As weight, For valid traffic after the switch, For the total observed flow rate, This is abnormal traffic.

[0118] Data consistency score: Let the set of data validation items be... , For the r-th data validation item, the data consistency score is expressed by the following formula:

[0119]

[0120]

[0121] in, The data consistency score is given by r, where r is the total number of data validation items. To validate the weights of the data, For the validation function of the m-th type of data, This is the actual data after the switch. This is the data for the candidate version file.

[0122] Critical Interface Consistency Score: Let the set of critical interfaces be... , For the s-th critical interface, the critical interface consistency score is expressed by the following formula:

[0123]

[0124]

[0125] in, For interface consistency score, , and For interface weight, The expected state of the return code. In a delayed state, To return the state of the body structure.

[0126] The overall consistency score after the upgrade is expressed by the following formula:

[0127]

[0128]

[0129] in, The overall consistency score after the upgrade, , , , , , and All are weighting coefficients.

[0130] Let the key constraints be combined as .

[0131] The hard constraint function is defined by the following formula:

[0132]

[0133] in, For hard constraint functions, The minimum passing threshold for the key item.

[0134] To avoid a high average score but severe weaknesses in certain areas, a discrete penalty term is introduced, which is expressed by the following formula:

[0135]

[0136] in, For discrete penalty terms, These are the weighting coefficients. Let Variance be the variance.

[0137] Simultaneously, a log chain integrity correction item is introduced:

[0138]

[0139] in, For log chain integrity correction items, For correction factor, For log chain integrity, The log chain is incomplete.

[0140] The credibility of the submission is: ,in, To ensure credibility.

[0141] In summary, the submission function is represented by the following formula:

[0142]

[0143] Where J is the submission function.

[0144] The expanded formula of the submitted function is expressed as follows:

[0145]

[0146] In the formula,

[0147]

[0148] in, This is the set of consistency scores.

[0149] Preferably, crash recovery is determined after writing a switch commit record to the transaction log.

[0150] Specifically, crash recovery determination includes: if If so, then a rollback operation will be performed; if Then proceed to S204; where, The switching intent has been written. No switch commit record was written. This has been written to the switch commit record. This is a logical AND operation. Using I and C, the switching action is broken down into two boundaries: intent and commit, combined with consistency conditions. It avoids pointer overwriting caused by concurrent reentrancy or abnormal repeated switching, and can deterministically determine the handling path after a crash. However, it lacks a two-phase boundary between I and C, making it unreliable to determine whether the switching was complete during crash recovery. It also lacks consistency conditions. This makes it impossible to suppress concurrency and reentrancy risks, and can easily lead to unpredictable version pointer states.

[0151] S204: Perform a health check on the candidate version file and determine whether to perform a rollback operation based on the health result. If a rollback operation is required, perform the rollback based on the rollback point and transaction log.

[0152] Specifically, deployment verification can only prove that the files are correct, not that the service is available. Offline environments lack external monitoring systems, making post-switch health checks a crucial trigger for automatic rollback. Only by promptly identifying issues that only surface after operation and triggering a rollback in the shortest possible time can the system avoid prolonged unavailability. Therefore, a health check is performed on the new version after the switch. The health check consists of several items, including critical process liveness, port connectivity, core interface returns, resource thresholds, and business detection. The check results are summarized into an overall health conclusion, which serves as the basis for determining whether to trigger a rollback.

[0153] Specifically, the overall health value or weighted health score of the candidate version file is calculated. If the overall health value of the candidate version file is equal to 0, a rollback operation is performed. If the overall health value of the candidate version file is not equal to 0, a rollback operation is not performed. If the weighted health score of the candidate version file is less than the rollback score threshold, a rollback operation is performed. If the weighted health score of the candidate version file is not less than the rollback score threshold, a rollback operation is not performed.

[0154] Let the set of health check items be... Each check item returns a boolean value. The overall health assessment is expressed by the following formula:

[0155]

[0156] Where OK represents the overall health value of the candidate version files, and ok represents the boolean value returned by the health check item. This represents the total number of health check items. For the i-th health check item, For logical AND.

[0157] Failure triggering rules: .

[0158] The candidate version file health weighted score is expressed by the following formula.

[0159]

[0160] Threshold rules are used for determination: .

[0161] Where S is the weighted health score of the candidate version file. for The weight, Let be the normalized result of the i-th health check item, and T be the rollback score threshold.

[0162] Relying solely on human experience or a single indicator can lead to misjudgments and unreproducible results. Logical AND and weighted scoring formalize decision rules, enabling direct implementation and consistent results by those skilled in the art, thus meeting the requirement of full disclosure. Logical AND ensures that any failure of a critical item triggers a rollback, preventing single-point fatal failures from being masked by averaging. Weighted scoring is used to synthesize multi-dimensional signals in the absence of hard failures, resulting in a reproducible and consistent decision caliber.

[0163] The rollback operation is performed according to the following steps:

[0164] Simply rolling back the pointer does not guarantee a successful recovery; the usability of the old version must be verified. Offline upgrade rollback involves numerous steps and is prone to errors. Automated rollback and verification can significantly reduce recovery time and human risk. Based on transaction logs and switch status, the failure type is identified, and the corresponding rollback sequence is executed. In the event of a failure before the switch, the version pointer remains unchanged, and candidate slots are cleaned up. In the event of a failure after the switch, the version pointer is rolled back to the old version pointed to by the rollback point, and a health check is performed on the old version for verification. After a successful rollback, candidate slots are isolated as problematic slots to prevent switching to known faulty versions again. This invention can automatically restore to a consistent and usable state when an upgrade fails, and verify the system recovery through post-rollback verification, while preventing faulty versions from repeatedly affecting the normal operation of the testing equipment.

[0165] Specifically, the failure type determination uses a two-stage flag, indicating failure before the switch: Switching failed: .

[0166] Rollback execution, preserving the version pointer if failure occurs before the switch: If the switch fails, the version pointer will be rolled back. .

[0167] After rollback verification, the overall health is recalculated for the old version, specifically expressed by the following formula:

[0168]

[0169]

[0170] in, This is the overall health value from the old version. This is the result of the old version's check on the i-th item.

[0171] After a successful rollback operation, candidate slots are isolated. Specifically, issue slot isolation uses a cumulative scoring method, accumulating issue scores based on the severity of the exception code mapping. When the issue score reaches a threshold, the candidate slot is added to the isolation list to prevent further switching. The above process is expressed by the following formula:

[0172]

[0173]

[0174] in, Rate the current cumulative issues. Based on the cumulative score of the previous issue, This is the cumulative coefficient. The value represents the severity of this anomaly, ranging from 0 to 1, and L is the isolation threshold.

[0175] Preferably, the rollback action employs an idempotent execution mechanism. Each rollback action is assigned an action identifier, and the set of executed actions is recorded in the transaction log. When the rollback is triggered repeatedly, already executed actions are skipped. Specifically, let the set of completed actions be A, and the identifier of the action to be executed be... .when ,when .

[0176] Without failure categorization, the consistency of the action sequence cannot be guaranteed, easily leading to incomplete partial upgrades or unclear rollback targets. Without post-rollback verification, it's impossible to prove the system has recovered to a usable state. Without isolation mechanisms, it's impossible to prevent repeated switching to faulty versions. Without idempotency mechanisms, it's impossible to handle the risk of secondary damage from crashes, restarts, and repeated triggers. Therefore, using C and OK allows for the categorization of failures into pre-switch and post-switch types, ensuring the action sequence is deterministic and reproducible. Verifying the usability of the old version proves the rollback is effective. Using a scoring model and threshold isolation avoids over-isolation caused by occasional jitter, while preventing repeated switching between persistently faulty versions. Using set A to achieve idempotency avoids secondary damage caused by repeated triggering.

[0177] Finally, since offline environments cannot rely on centralized log systems, without solidified evidence, it is difficult to conduct on-site reconnaissance and prove that the system rolled back or upgraded successfully according to the rules. Therefore, to meet the needs of offline auditing and problem tracing, and to provide searchable evidence for subsequent operation and maintenance decisions, an evidence package is generated regardless of success or failure. The evidence package includes a transaction identifier, a transaction log summary, a rollback point content summary, a verification result, an exception code, health check result time information, operator information, and a summary of the end of the log hash chain. The evidence package is written to the archive directory and indexed, with index fields including at least the transaction identifier, version number, time range, and exception code.

[0178] Example 3

[0179] Based on the above embodiments, such as Figure 3 As shown, this invention proposes an automatic rollback system for detecting offline upgrade failures of devices based on transaction logs and rollback points, comprising:

[0180] The transaction log initialization module is used to generate a transaction identifier after the target detection device receives an offline upgrade request, initialize the transaction log corresponding to the transaction identifier, write the transaction start record into the transaction log and complete the persistence.

[0181] The verification module is used by the target detection device to verify the upgrade package stored in itself, deploy the verified upgrade package to the candidate slot, obtain the candidate version file, and write the deployment and verification records in the transaction log.

[0182] The version pointer switching module is used to write rollback points to the transaction log and persist them, and then switch the old version pointer to the version pointer of the candidate version file.

[0183] The rollback judgment module is used to perform health checks on candidate version files and determine whether to perform a rollback operation based on the health results. If a rollback operation is required, it is performed based on the rollback point and transaction log.

[0184] It should be noted that the automatic rollback system for detecting offline upgrade failures of devices based on transaction logs and rollback points provided in this embodiment of the invention is to implement the above-mentioned automatic rollback method for detecting offline upgrade failures of devices based on transaction logs and rollback points. Its specific functions can be referred to in the above-mentioned method embodiments, and will not be repeated here.

[0185] In summary, this invention transforms the offline upgrade of testing equipment into a transactional and traceable process. Relying on transaction logs, rollback points, and two-stage switching, it enables automatic deterministic rollback of failed offline upgrades, avoiding a half-upgrade state. Through automatic health checks and post-rollback verification, recovery time is reduced to the second level, significantly reducing human error. Combined with problem slot isolation and evidence package archiving, it meets the high availability and audit traceability requirements of offline testing equipment scenarios, significantly improving the security, reliability, and operational efficiency of offline upgrades.

[0186] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for automatically rolling back offline upgrade failure detection devices based on transaction logs and rollback points, characterized in that, include: Step 1: After receiving the offline upgrade request, the target detection device generates a transaction identifier, initializes the transaction log corresponding to the transaction identifier, writes the transaction start record into the transaction log and completes persistence; Step 2: The target detection device verifies the upgrade package stored in itself, deploys the verified upgrade package to the candidate slot, obtains the candidate version file, and writes the deployment and verification records in the transaction log; Step 3: Write the rollback point to the transaction log and persist it, then switch the old version pointer to the version pointer of the candidate version file; Step 4: Perform a health check on the candidate version file, and determine whether to perform a rollback operation based on the health result. If a rollback operation is required, perform the rollback based on the rollback point and transaction log.

2. The method for automatic rollback of offline upgrade failure detection equipment based on transaction logs and rollback points according to claim 1, characterized in that, The transaction log includes multiple structured records and a chained summary corresponding to each structured record. The structured record includes a transaction identifier, stage number, stage name, action identifier, target object, result code, and time information. The chained digest is expressed by the following formula: in, This is a chained digest of the i-th structured record, where H is a hash function. The normalized content of the i-th structured record, It is a byte sequence concatenation, where n is the total number of structured records that have been written.

3. The method for automatic rollback of offline upgrade failure detection equipment based on transaction logs and rollback points according to claim 1, characterized in that, The target detection device verifies the upgrade package stored in itself, specifically including: The upgrade package is subjected to integrity verification and source verification. The integrity verification includes hash verification, and the source verification includes signature or digest comparison.

4. The method for automatic rollback of offline upgrade failure detection equipment based on transaction logs and rollback points according to claim 1, characterized in that, The rollback point in step three includes the old active slot identifier, the old version pointer value, the environment fingerprint digest, and the dependency digest. Step three, which involves switching the old version pointer to the version pointer of the candidate version file, includes: writing a switching intention in the transaction log to declare the version pointer switching operation; then determining whether the version pointer meets the preconditions; if the preconditions are met, updating the version pointer to the version pointer of the candidate version file; the preconditions are whether the actual value of the current version pointer is equal to the old active slot pointer value; if they are equal, the preconditions are met; otherwise, the preconditions are not met. Step three also includes: collecting data from candidate version files and obtaining the commit function. If the commit function is equal to 1, a switch commit record is written to the transaction log. If the commit function is equal to 0, no switch commit record is written to the transaction log, and step four is executed directly.

5. The method for automatic rollback of offline upgrade failure detection equipment based on transaction logs and rollback points according to claim 4, characterized in that, The submission function is expressed by the following formula: In the formula, Where J is the submission function, Let min be the indicator function, where min is the minimum value. For the set of key constraints, The minimum passing threshold for the key item. , , , , , , , All are weighting coefficients. The score is based on the consistency of file versions. The total number of upgrade package files. For the Kronecker function, For file digest functions, The actual file after switching. For candidate version files, To configure consistency score, p is the total number of configuration items. Let the weight of the j-th configuration item be... This is the configuration value after the switch. Configure values ​​for candidate version files. For consistency scores, and For weight dependence, For consistency, For version constraint satisfaction, The service consistency score is given, where q represents the total number of critical services. , and As weight, This represents the running status of the l-th service. This is the ready state for the l-th service. The service port is in a normal listening state. To score routing consistency, and As weight, For valid traffic after the switch, For the total observed flow rate, This is abnormal traffic. The data consistency score is given by r, where r is the total number of data validation items. To validate the weights of the data, For the validation function of the m-th type of data, This is the actual data after the switch. Data for candidate version files, For interface consistency score, , and For interface weight, The expected state of the return code. In a delayed state, To return to the state of the body structure, For variance, For the consistency score set, For log chain integrity correction items, To submit a trusted threshold.

6. The method for automatic rollback of offline upgrade failure detection equipment based on transaction logs and rollback points according to claim 4, characterized in that, Step three also includes performing a crash recovery determination after writing a switch commit record to the transaction log; The crash recovery determination includes: if If so, then a rollback operation will be performed; if Then proceed to step four; where I represents the switching intent flag and C represents the switching submission flag. The switching intent has been written. No switch commit record was written. This has been written to the switch commit record. For logical AND.

7. The method for automatic rollback of offline upgrade failure detection equipment based on transaction logs and rollback points according to claim 4, characterized in that, Step four specifically includes: Calculate the overall health value or weighted health score of the candidate version file. If the overall health value of the candidate version file is equal to 0, a rollback operation is performed. If the overall health value of the candidate version file is not equal to 0, a rollback operation is not performed. If the weighted health score of the candidate version file is less than the rollback score threshold, a rollback operation is performed. If the weighted health score of the candidate version file is not less than the rollback score threshold, a rollback operation is not performed. The overall health value of the candidate version files is expressed by the following formula: In the formula, Where OK represents the overall health value of the candidate version files, and ok represents the boolean value returned by the health check item. This represents the total number of health check items. For the i-th health check item, For logical AND; The health-weighted score of the candidate version file is expressed by the following formula: In the formula, Where S is the weighted health score of the candidate version file. for The weight, This is the normalized result of the i-th health check item.

8. The method for automatic rollback of offline upgrade failure detection equipment based on transaction logs and rollback points according to claim 7, characterized in that, The rollback operation includes: Read the switch intent and obtain the switch commit flag C to determine the upgrade failure type: when When the upgrade failure type is "failed before switching version pointers", the version pointer remains unchanged and the candidate slots are cleared; when When an upgrade fails due to a version pointer failure, the version pointer is rolled back to the old version pointed to by the rollback point, and the overall health value of the old version is calculated. If the overall health value of the old version is 1, the rollback operation is successful. After a successful rollback, the candidate slots are isolated. No commit history has been written for the switch; OK indicates the overall health value of the candidate version file. For logical AND; Finally, an evidence package is generated based on the transaction log. The evidence package includes the transaction identifier, transaction log summary, rollback point content summary, verification result, exception code, health check result, time information, operator information, and log hash chain end summary.

9. The method for automatic rollback of offline upgrade failure detection equipment based on transaction logs and rollback points according to claim 8, characterized in that, The isolation of candidate slots after a successful rollback operation specifically includes: The candidate slots are scored. When the score of a candidate slot is greater than the threshold, the candidate slot is isolated and the version pointer is prevented from being switched to the version pointer of the isolated candidate slot.

10. A system for automatically rolling back offline upgrade failure detection of equipment based on transaction logs and rollback points, characterized in that, include: The transaction log initialization module is used to generate a transaction identifier after the target detection device receives an offline upgrade request, initialize the transaction log corresponding to the transaction identifier, write the transaction start record into the transaction log and complete the persistence. The verification module is used by the target detection device to verify the upgrade package stored in itself, deploy the verified upgrade package to the candidate slot, obtain the candidate version file, and write the deployment and verification records in the transaction log. The version pointer switching module is used to write rollback points to the transaction log and persist them, and then switch the old version pointer to the version pointer of the candidate version file. The rollback judgment module is used to perform health checks on candidate version files and determine whether to perform a rollback operation based on the health results. If a rollback operation is required, it is performed based on the rollback point and transaction log.

Images