Database management method, high availability component and system for semiconductor manufacturing

Abstract

The application provides a database management method, a high-availability component and a system for semiconductor manufacturing, belongs to the field of semiconductor manufacturing, and comprises the high-availability component judging whether to trigger the failover of a master database; when it is judged that the failover is triggered, the high-availability component selects a current standby database from a database cluster as a new master database; a distributed service registration center receives the latest first log record of an old master database and removes the master database identifier; the distributed service registration center updates the second log record of the new master database according to the first log record through all high-availability components; and the distributed service registration center reconstructs the topology connection of the database cluster and adjusts the current synchronization mode between the master database and the standby database of the database cluster. Through the processing scheme, the application-database network reachability is introduced as a master selection key index, the new master database and each application node maintain the best network path after the failover, and the business continuity and high availability are truly realized.

Description

Technical Field

[0001] This application relates to the field of database management, and in particular to a database management method, high-availability component, and system for semiconductor manufacturing. Background Technology

[0002] In today's information age, database systems play a crucial role in various information systems. To ensure the continuity and reliability of business systems, high availability design has become a core part of database architecture design. Especially in the semiconductor industry, any database downtime or data loss can lead to reduced or even halted production efficiency in semiconductor companies, disrupting production processes and causing serious consequences.

[0003] PostgreSQL is a popular open-source relational database system. Due to its high scalability, SQL compatibility, and rich data types (such as arrays, JSON, XML, geospatial data, etc.), PostgreSQL can effectively store and manage various complex data structures in the semiconductor field, such as hierarchical data for chip design and material property data. However, to ensure normal enterprise management, the database system needs to operate continuously under various failure conditions, minimizing downtime. This requires high availability. PostgreSQL itself does not provide native cluster high availability capabilities; its high availability implementation is typically based on PostgreSQL streaming replication technology, combined with third-party tools such as repmgr, pgpool-II, and patroni to achieve failover.

[0004] However, none of these third-party tools can be promoted: Taking repmgr as an example, its configuration is complex, requiring manual configuration of multiple parameters and scripts. In some complex scenarios, such as large-scale clusters or special network environments, its automation and flexibility are weak, which may not meet complex business needs. In addition, after failover, the old master node needs to be manually re-registered. If the operation is not done properly, omissions can easily occur, leading to abnormal cluster status and increasing the maintenance cost and workload of operation and maintenance personnel. Furthermore, after reconfiguring the database, without verifying the consistency of the standby database configuration, problems may arise due to parameter differences after the switch, affecting the normal operation of the database.

[0005] Taking pgpool-II as an example, in addition to high availability, it also features a variety of complex usage modes, such as replication mode, master-slave mode, and parallel query mode. For beginners, the learning curve is steep, and a slight misconfiguration can easily lead to major accidents due to improper configuration, resulting in high configuration complexity. Meanwhile, the practicality of its functions is limited: the mode that can be used in enterprises is mainly the "streaming replication + standby master / slave mode," while other modes are not very practical. This makes the complexity of its configuration and maintenance disproportionate to the actual benefits. Moreover, operations such as failover may require the use of custom scripts, which increases the complexity of implementation and the possibility of errors.

[0006] Taking Patroni as an example, it relies on distributed coordination services (such as etcd, ZooKeeper, etc.) to achieve strong consistency. This increases the complexity of the overall architecture and the difficulty of deployment. It requires the maintenance of an additional DCS cluster, and the stability of the DCS cluster will also affect the reliability of the entire high-availability system, making the architecture more complex. Furthermore, when the Patroni process crashes, the original master node may continue to provide services, leading to data splitting. Additional measures such as VIP or load balancers are needed to avoid this problem. Patroni does not detect master-slave replication latency during operation. Even if the replica database replication is interrupted, it may still be marked as healthy, making it impossible to detect potential problems in time, which affects fault diagnosis and handling.

[0007] In summary, these tools all increase management complexity and additional operational costs, which is not conducive to the management of semiconductor databases and cannot prevent data loss. Summary of the Invention

[0008] Therefore, in order to overcome the shortcomings of the prior art, the present invention provides a database management method, apparatus, system and equipment for semiconductor manufacturing. By introducing application-database network reachability as a key indicator for master database selection, it ensures that the new master database and each application node maintain the best network path after failover, thus truly achieving business continuity and high availability.

[0009] To achieve the above objectives, this invention provides a database management method for semiconductor manufacturing, comprising: a high-availability component determining whether to trigger a failover of the primary database based on preset rules, the current number of reachable nodes in the primary database, and the current number of reachable nodes in the standby database of the database cluster; when the failover is triggered, the high-availability component that acquires the exclusive lock has the authority to execute the primary database election decision, and the high-availability component that has not acquired the exclusive lock collects indicator information of the list of all surviving standby database nodes; the high-availability component that acquires the exclusive lock selects a current standby database from the current standby databases of the database cluster as the new primary database based on priority and the indicator information; the high-availability component that acquires the exclusive lock updates the primary database identifier and the primary database key-value pair, and releases the exclusive lock; the distributed service registry receives the latest first log record of the old primary database and removes the primary database identifier of the old primary database; the distributed service registry updates the second log record of the new primary database through all high-availability components based on the first log record; the distributed service registry rebuilds the topology connection of the database cluster and adjusts the current synchronization method between the primary and standby databases of the database cluster.

[0010] In one embodiment, when the high availability component determines that the indicator information of the old primary database is healthy, the distributed service registry updates the status information of the old primary database to the standby database node list through the high availability component, and adds a connection between the new primary database and the old primary database in the topology connection.

[0011] In one embodiment, the system further includes: the high availability component performing database status checks on the application system and the database cluster according to a preset periodic task, and updating the current status information obtained from the checks; determining the current synchronization method between the primary and standby databases of the database cluster based on the current status information; when it is determined that the current synchronization method has changed, the high availability component obtains a key-value pair representing execution permissions from the distributed service registry and generates an execution lock based on the key-value pair; adjusting the historical synchronization method between the primary and standby databases of the database cluster to the current synchronization method based on the execution lock, and performing database management based on the current synchronization method.

[0012] In one embodiment, the high availability component performs database status checks on the application system and the database cluster according to a preset periodic task, and updates the current status information obtained from the checks. This includes: the distributed service registry verifying the reachability information of each database node in the database cluster and each application port of the application system; the distributed service registry obtaining the working status information between the high availability component and the distributed service registry; the distributed service registry acquiring information about the primary and standby databases in the database cluster and their corresponding latest logs; the distributed service registry analyzing the corresponding latest logs based on the information about the primary and standby databases in the database cluster and generating analysis results; and the distributed service registry integrating the reachability information, the working status information, and the analysis results to update the current status information.

[0013] In one embodiment, the database management based on the current synchronization method includes: when the synchronization method between the primary and backup databases of the database cluster is changed from strong synchronization mode to asynchronous mode, the distributed service registry obtains the process status table of each database in the database cluster through the high availability component; the high availability component adjusts and updates the progress status of blocked processes in the process status table of each database, and marks the adjusted database cluster as downgraded.

[0014] In one embodiment, adjusting the historical synchronization mode between the primary and standby databases of the database cluster to the current synchronization mode according to the execution lock includes: when the synchronization mode between the primary and standby databases of the database cluster is adjusted from asynchronous mode to strong synchronization mode, the high availability component clears the degradation flag according to the execution lock.

[0015] In one embodiment, determining the current synchronization mode between the primary and standby databases of the database cluster based on the current status information includes: the high availability component determining, based on the current status information, that data communication between the application system and the database cluster has returned to normal and that the database cluster has a degradation flag; the high availability component determining, based on the generation time of the degradation flag and the current time, that the database cluster synchronization has returned to normal, and adjusting the current synchronization mode between the primary and standby databases of the database cluster to strong synchronization mode.

[0016] A high-availability component, used in the above method, comprises: a configuration management module for storing various metadata information, the metadata information including at least: database cluster information, connection parameter information of the distributed service registry, high-availability component running instance identifier, and deployment location running metadata; a health detection module for performing real-time database status detection on the application system and the database cluster respectively, updating the detected current status information, and reporting the current status information to the service registry in real time; a policy engine module for continuously monitoring the current status information and generating corresponding processing decisions based on the current status information and predefined policies and business rules; an execution controller module for calling predefined execution scripts or API commands according to the processing decisions generated by the policy engine module; and a log and alarm notification module for recording various log information generated during system operation and issuing alarm notifications in a timely manner when abnormal events, fault conditions, or important decisions are detected.

[0017] A high-availability database system for semiconductor manufacturing, characterized in that it comprises: a database cluster including at least one primary database node and multiple backup database nodes; an application system consisting of multiple independent nodes forming a cluster, generating data application instructions; high-availability components respectively disposed on the nodes of the application system and the nodes of the database cluster; a distributed service registry center communicating with the nodes of the database cluster or the application system through the high-availability components; and a shared storage device for storing log data, wherein the high-availability component is the aforementioned high-availability component.

[0018] A computer device includes a memory and a processor, the memory storing a computer program, characterized in that the processor executes the computer program to implement the steps of the above-described method.

[0019] Compared with existing technologies, the advantages of this invention are: deploying high-availability components on the application system and database cluster to achieve state synchronization and decision collaboration; moreover, the high-availability components perform database status detection on the application system and database cluster according to preset periodic tasks, continuously probing and collecting multi-dimensional health information. When the primary database becomes unreachable or service is interrupted, a failover process is initiated. The system automatically introduces application-database network reachability as a key indicator for primary database selection, elects and promotes the optimal standby database as the new primary database, and ensures that the new primary database and each application node maintain the best network path after failover, truly achieving business continuity and high availability. Attached Figure Description

[0020] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a schematic flowchart of a database management method for semiconductor manufacturing in one embodiment of the present invention; Figure 2 This is a flowchart illustrating the dynamic switching steps of data synchronization mode in one embodiment of the present invention; Figure 3 This is a flowchart illustrating the database failover steps in another embodiment of the present invention; Figure 4 This is a flowchart illustrating the database failover steps in another embodiment of the present invention; Figure 5 This is a structural block diagram of a database high-availability system for semiconductor manufacturing, as described in one embodiment of the present invention. Figure 6 This is an internal structural diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0022] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0023] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. This application can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0024] It should be noted that the following description covers various aspects of embodiments within the scope of protection of this invention. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this application, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number and aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using other structures and / or functionalities besides one or more of the aspects set forth herein.

[0025] It should also be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. The drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0026] Furthermore, specific details are provided in the following description to facilitate a thorough understanding of the examples. However, those skilled in the art will understand that the described aspects can be practiced without these specific details.

[0027] PostgreSQL achieves data synchronization by having the master node write data modification records to the write-ahead log (WAL). The WAL is then transmitted over the network to the standby node, which replays the WAL, thus synchronizing the data. This method is called streaming replication. Streaming replication has two modes: strong synchronous and asynchronous. However, both modes have drawbacks: Asynchronous mode carries the risk of data loss. When the master writes a new WAL log, it only needs to wait for the log to be written to the master's local disk before replying to the client with "transaction committed successfully," without caring whether the standby has received the log. If the master server suddenly crashes, some WAL logs may not have been sent to the standby server, leading to data loss. Strong synchronous mode carries the risk of update blocking. After the master writes a new WAL log, it must wait for the standby to receive this new log before replying to the client with "transaction committed successfully." If the standby server crashes or the network is interrupted, the master's WAL log cannot be written to the standby, causing all transactions on the master to fail to commit, and data updates to be blocked.

[0028] This application provides a database management method for semiconductor manufacturing, which can be applied to servers or terminals. Terminals can be, but are not limited to, various personal computers, laptops, smartphones, tablets, and portable smart devices. Servers can be implemented using independent servers or server clusters composed of multiple servers. For example... Figure 1As shown, the method is applied to a server as an example, and includes the following steps: Step 101: The high availability component determines whether to trigger a failover of the primary database based on preset rules, the current number of reachable nodes of the primary database, and the current number of reachable nodes of the standby database in the database cluster.

[0029] The high-availability component performs database status checks on the application system and database cluster according to preset periodic tasks, obtaining the current number of reachable nodes for the primary and standby databases in real time. The database cluster must contain at least two databases, with at least one primary and one standby database. To ensure high availability, the application system and the database cluster must each have at least two nodes (databases). To better provide service and avoid split-brain scenarios, the number of database nodes can be odd. Databases can be PostgreSQL, etc.

[0030] The application system and database cluster are installed on separate servers. The distributed service registry can share nodes with the application system or database, or it can be set up on a separate server. To ensure high availability and data consistency, the total number of nodes in the distributed service registry is an odd number of at least 3. The distributed service registry provides a centralized storage location, allowing service instances to register their addresses and status information with the distributed service registry, while other services can find and discover these service instances through the distributed service registry. Service instances can be application systems or individual database nodes in the database cluster. The distributed service registry can communicate independently with each node in the application system or database through a high-availability component. The high-availability component can be installed on each node in the application system and database cluster, and monitors various status information of each node in the application system and database cluster through pre-edited configuration information.

[0031] Configuration information may include at least one of the following: the high availability component's own node identifier, the distributed service registry cluster address information, the PostgreSQL database cluster node connection information, the application system node information, the WAL shared storage path, data synchronization mode control parameters, degradation wait timeout (sync_wait_timeout), minimum upgrade interval (min_recover_interval), failover strategy control parameters, minimum primary database connectivity (min_primary_act), maximum standby database connectivity (max_standby_act), and failover priority.

[0032] High availability components are software or hardware modules used to ensure that systems, services, or applications can quickly recover and continue operating in the event of a failure. These components improve system reliability and availability, reduce downtime, and ensure service continuity through various mechanisms. High availability components typically involve multiple files and configurations that work together to ensure that the database can quickly recover and maintain data consistency in the event of a failure. From a logical architecture perspective, high availability components can consist of a configuration management module, a health monitoring module, a policy engine module, an execution controller module, and a logging and alarm notification module.

[0033] The configuration management module stores various metadata information, providing basic support for the initialization, operation, and collaboration of various modules in the high-availability system.

[0034] The health monitoring module performs real-time database status checks on the application system and database cluster, updates the current status information obtained from the checks, and reports the current status information to the distributed service registry center in real time.

[0035] The strategy engine module continuously monitors the current state information and generates corresponding processing decisions based on the current state information and predefined strategies and business rules.

[0036] The execution controller module is used to invoke predefined execution scripts or API commands based on the processing decisions generated by the policy engine module.

[0037] The log and alarm notification module records various log information generated during system operation and promptly issues alarm notifications when abnormal events, fault conditions, or important decisions are detected.

[0038] The high availability component determines whether to trigger a failover of the primary database based on preset rules, the number of currently reachable nodes of the primary database, and the number of currently reachable nodes of the standby database in the database cluster.

[0039] A preset rule could be: trigger failover when the actual number of reachable nodes for the primary database is less than the theoretical number, while the number of reachable nodes for the standby database is greater than the theoretical number. This preset rule can detect database availability from the perspective of application nodes. When it is found that some application nodes cannot connect to the primary database, the number of other nodes that can connect to the primary database is less than the theoretical number of reachable nodes, and more application nodes can connect to the standby database, triggering failover ensures that the database provides services to more application nodes.

[0040] The default rule can also be: trigger failover when the actual number of reachable nodes of the primary database is 0. This default rule detects database availability from the perspective of the database nodes. When the primary database instance or server fails, all application nodes will inevitably lose connectivity to the database. In this case, triggering failover ensures that other available standby databases can continue to provide services.

[0041] Step 102: When a failover is triggered, the high-availability component that acquires the exclusive lock has the authority to execute the master election decision, while the high-availability component that does not acquire the exclusive lock collects the indicator information of the list of all surviving standby nodes.

[0042] When a failover is triggered, each high-availability component competes for an exclusive lock. The component that acquires the exclusive lock has the authority to execute the leader election decision. Other high-availability components that have not acquired the exclusive lock, after recognizing the leader election flag, give up competing for the exclusive lock and begin collecting various health indicator information from the list of all surviving standby nodes to provide a basis for subsequent leader election decisions.

[0043] Step 103: The high availability component that obtains the exclusive lock selects the current standby database from the current standby databases of the database cluster as the new primary database based on priority and indicator information.

[0044] The high-availability component that has not acquired the exclusive lock collects a list of all live nodes with the role of 'standby' and continuously writes health metrics such as application node connectivity, candidate priority, replication latency, and instance startup time to the distributed service registry. The high-availability component that acquires the exclusive lock reads these key-value pairs, compares them according to priority from high to low, and selects the most suitable one as the new primary. The selection rule for the new primary can adopt at least one of the following rules: The number of TCP connections that can reach the application system's port to the backup database; the higher the value, the higher the priority for application connectivity. In the configuration, the user sets a priority value for this node; the larger the value, the higher the priority. Replication latency: By comparing the latest WAL filenames and the LSN (Log Sequence Number) difference of the last WAL log in the shared storage between the primary and standby databases, the smaller the value (lower latency) is prioritized. Longer survival time results in higher priority; If all the above metrics are the same, then sort by node name (or ID) in lexicographical order, and the database with the first node in the list will be the new master database.

[0045] Step 104: The high-availability component that acquires the exclusive lock updates the master database identifier and the master database key-value pair, and releases the exclusive lock. The distributed service registry receives the latest first log record of the old master database and removes the master database identifier of the old master database.

[0046] The high-availability component that acquires the exclusive lock updates the master database identifier and key-value pairs in the distributed service registry, and releases the exclusive lock. The distributed service registry receives the latest first log record from the old master database and removes the master database identifier from the old master database. The high-availability component notifies the old master database (if it is still accessible) to stop the database service and remove the Virtual IP Address (VIP), ensuring that the old master database no longer accepts any operations and can no longer issue WAL logs in the name of the master database.

[0047] Distributed service registries provide distributed locking mechanisms to coordinate multiple instances in a distributed system. These locking mechanisms ensure that only one instance can perform certain operations at a time. For example, execution locks in a distributed service registry ensure that only one instance can acquire the lock at a time; exclusive locks are used for leader election, ensuring that a leader is elected from among multiple instances. Distributed service registries can choose from ZooKeeper, etcd, Consul, or Nacos. In one embodiment, the distributed service registry primarily stores four types of health data: the liveness status of each node in the PostgreSQL cluster, the liveness status of each application, the liveness status of high-availability components, and the TCP connectivity reachability between the application and the database.

[0048] Step 105: The distributed service registry updates the second log record of the new master database based on the first log record through all high-availability components.

[0049] The high availability component retrieves the last WAL filename (first log record) and its last LSN (which can be parsed from the end of the WAL file or obtained through system tools) of the old primary database. It also retrieves the current WAL filename (second log record) and its last LSN of the new primary database. The high availability component compares the first and second log records. If the new primary database's WAL filename lags behind the old primary database's, it copies the missing WAL file from the shared storage device to the corresponding directory on the new primary database, overwriting the existing file. If the new and old primary databases have the same WAL filename but the new primary database's LSN is smaller, the high availability component only copies the latest WAL log segment from the first log record to overwrite the second log record. Shared storage devices refer to storage resources that can be accessed and used simultaneously by multiple nodes (servers). Implementation methods include SAN (Storage Area Network), NFS (Network File System), and distributed file systems (such as GlusterFS and CephFS). This application embodiment uses shared storage. The database WAL file is stored in the shared storage. Even if the primary database server crashes, the standby database can still access the shared storage normally, retrieve the primary database WAL file from the shared storage, fill in the missing transaction logs, and avoid data loss.

[0050] The latest LSN of the new primary database is compared with the last LSN of the old primary database. When they are equal, it indicates that the new primary database has completely replayed all historical WALs. The distributed service registry executes a promotion command on the node where the new primary database resides, updating the standby database to the new primary database. It checks the database role in the distributed service registry; when the role changes to Primary, the node promotion is considered successful, and a VIP is then set for that node. At this point, the node's role changes from standby to primary, and it begins accepting read and write requests. Application systems can access the database through the newly set VIP.

[0051] Step 106: The distributed service registry rebuilds the topology connection of the database cluster and adjusts the current synchronization method between the primary and standby databases.

[0052] The distributed service registry rebuilds the database cluster topology and adjusts the connections between the application system and the rebuilt database cluster. The distributed service registry regenerates its configuration files, adding the `primary_conninfo` item to the configuration files on the remaining standby databases, pointing to the new primary database, for example, `primary_conninfo = 'host='`.<new_primary_host> port= <port>user=<repl_user>password= <pwd>Then restart the PostgreSQL services of the other standby databases to ensure they establish streaming replication connections with the new master database.

[0053] The high-availability component on the server continuously monitors changes to key-value pairs in the distributed service registry. Once a change is detected...<new_primary_node_id> It automatically modifies the application system's configuration files, pointing the database connection to the new master database address (including VIP or bare IP), and refreshes the page to make the changes effective. The application server is also a node in the distributed service registry.

[0054] The above method deploys high-availability components on the application system and database cluster to achieve state synchronization and collaborative decision-making. Moreover, the high-availability components perform database status checks on the application system and database cluster according to preset periodic tasks, continuously probing and collecting multi-dimensional health information. When the primary database becomes unreachable or service is interrupted, a failover process is initiated. The system automatically introduces application-database network reachability as a key indicator for primary database selection, elects and promotes the optimal standby database as the new primary database, and ensures that the new primary database and each application node maintain the best network path after failover, truly achieving business continuity and high availability.

[0055] In one embodiment, when the high availability component determines that the old master database's metrics are healthy, the distributed service registry updates the status information of the old master database to the standby database node list through the high availability component, and adds a connection between the new master database and the old master database in the topology connection.

[0056] When the high availability component determines that the old master database's metrics are healthy, the server can use pg_rewind to quickly "rewind" the old master database's data directory to the standby database's state, so that it can rejoin the database cluster without needing to re-synchronize the entire database. Then, configure standby.signal, modify primary_conninfo to point to the new master database, restart PostgreSQL, and add the old master database to the new topology connection.

[0057] The above method allows the old master database to be rejoined to the topology connection after it has regained connectivity, thus avoiding idle time for the old master database.

[0058] In one embodiment, such as Figure 2 As shown, when the primary database becomes unreachable or service is interrupted, a failover process is initiated, and the system automatically elects and promotes the best standby database to the new primary database.

[0059] (1) Fault detection The high availability component has two master database unreachability fault detection strategies.

[0060] Strategy 1: If the parameters `primary_reachable_nodes` and `standby_reachable_nodes` are predefined, and the value of `primary_reachable_nodes` is greater than 0, and the value of `standby_reachable_nodes` is greater than `primary_reachable_nodes`, then when the actual number of reachable nodes on the primary database is less than `primary_reachable_nodes`, and the number of reachable nodes on the standby database is greater than `standby_reachable_nodes`, a failover is triggered. The significance of this strategy is that it probes database availability from the perspective of application nodes. When it is found that some application nodes cannot connect to the primary database, the number of other nodes that can connect to the primary database is less than `primary_reachable_nodes`, and more application nodes can connect to the standby database, triggering a failover ensures that the database can provide services to more application nodes.

[0061] Strategy 2: If the parameter `primary_reachable_nodes` is not set or is set to 0, a failover is triggered when the actual number of reachable nodes is 0. The significance of this strategy is to detect database availability from the perspective of database nodes. When the primary database instance or server fails, all application nodes will inevitably lose connectivity to the database. Triggering a failover ensures that other available standby databases can continue to provide services.

[0062] (2) Executing the decision to elect a leader Before executing the leader election decision, each high-availability component competes for an exclusive lock. The component that acquires the exclusive lock has the right to execute the leader election decision. After other high-availability components identify the leader election flag, they give up competing for the exclusive lock and begin collecting various health indicator information to provide a basis for the leader election decision.

[0063] The high availability component collects a list of all live nodes with the role of 'standby' and continuously writes health metrics such as application node connectivity, candidate priority, replication latency, and instance startup time to etcd. The high availability component reads these key-value pairs, compares them from highest to lowest priority, and selects the most suitable node as the new primary. The selection rules for the new primary follow the order below until a new primary is selected: The number of TCP connections that can reach the application system's port to the backup database. The higher the value, the higher the priority of application connectivity (if the number of reachable nodes is the same, the next rule is used). In the configuration, the user sets a priority value for this node. The larger the priority value, the higher the priority (if the priority values ​​are the same, the next rule is used). Replication latency: By comparing the latest WAL file names and the LSN (Log Sequence Number) difference of the last WAL log in the shared storage between the primary and standby databases, the smaller the value (lower latency) is given priority (if the latency values ​​are the same, the next rule is used). Longer survival time takes precedence (if survival time is the same, the next rule applies). If all the above metrics are the same, then sort by node name (or ID) in lexicographical order, and the database with the first node in the list will be the new master database.

[0064] The high-availability component updates the master database identifier, writes the key-value pair of the new master database to etcd, indicating that the master election decision has been completed and the identity of the new master database has been determined, and releases the exclusive master election lock.

[0065] (3) Promote the standby database to the new primary database The high availability component notifies the old master (if still accessible) to stop the database service and remove the Virtual IP Address (VIP). This ensures that the old master no longer accepts any operations and can no longer issue old WAL logs.

[0066] The high availability component obtains the last WAL file name and its last LSN of the old master database (which can be parsed from the end of the WAL file or obtained through system tools); Get the current WAL file name and last LSN of the new master database; if the new master database's WAL file is behind the old master database: copy the missing WAL file from shared storage to the corresponding directory of the new master database, overwriting the existing file; if the new master database and the old master database have the same WAL file name but the LSN is less than that of the old master database: copy only the latest WAL log segment to overwrite.

[0067] Wait for the new master to automatically replay to the latest LSN. When the new master compares the last LSN of the old master with the LSN, it means that the new master has completely replayed all historical WAL.

[0068] Execute the promotion command on the new primary node to promote the standby database to the new primary. Check the database role; if the role changes to Primary, the promotion is successful. Then, set a VIP for the node. At this point, the node's role changes from standby to primary, and it begins accepting read and write requests. Application systems can access the database through the newly set VIP.

[0069] The high-availability component rebuilds the replication topology. The configuration files are regenerated, and a `primary_conninfo` item is added to the configuration files on the remaining standby databases, pointing to the new primary database, for example, `primary_conninfo = 'host='`.<new_primary_host> port= <port>user=<repl_user>password= <pwd>Then restart the PostgreSQL services on the other standby databases to ensure they establish streaming replication connections with the new master: pg_ctl restart -D $PGDATA.

[0070] If a fixed VIP is used, the high availability component on the application server continuously monitors changes to the / ha / leader key in etcd, and once a change is detected...<new_primary_node_id> It automatically modifies the application system's configuration file, points the database connection to the new master database address (including VIP or bare IP), and refreshes it to make it effective.

[0071] In one embodiment, such as Figure 3 As shown, the database management method for semiconductor manufacturing may further include the following steps: Step 301: The high availability component performs database status checks on the application system and database cluster according to a preset periodic task, and updates the current status information obtained from the checks.

[0072] The high-availability component performs database status checks on the application system and database cluster according to preset periodic tasks, and updates the current status information obtained from the checks. The high-availability component also monitors various global configuration information in the distributed service registry, and detects and synchronizes changes to local configuration files in real time.

[0073] For example, high availability components can monitor various global configuration information in the distributed service registry, perform database status checks on the application system and database cluster, update the detected current status information, and store the detected information as key-value pairs (KV) in the distributed service registry. For example, high availability components can perform TCP connectivity checks. The distributed service registry uses the high availability component to call the nc tool to probe ports and verify the reachability of the high availability component with each database node and application port, for example, `nc -zv -w3`. <host> <port>The high-availability component can also perform connection blocking detection. It queries the process status table pg_stat_activity on the primary database to check if there are any active processes waiting for an ACK response from the standby database, and if the waiting time exceeds a predefined time. Based on the detection results, it generates blocking information.

[0074] The high-availability component periodically probes each node in the application system and database, reporting the results to the service registry and setting expiration times (leases). It then continuously monitors these item values. Once data changes, the distributed service registry immediately pushes the change event to registered listening clients. Using this information, the high-availability component gains a comprehensive understanding of the database, application system, and their connectivity, enabling more informed decisions during database failover.

[0075] Step 302: Determine the current synchronization method between the primary and standby databases of the database cluster based on the current status information.

[0076] The high availability component determines the current synchronization method between the primary and standby databases in the database cluster based on the current status information. It then decides whether to adjust the current synchronization method between the application system and the database cluster. For example, the high availability component can determine from blocking information that there is data transmission blockage between the application system and the database cluster, requiring the current synchronization method to be changed from "strong synchronization" to "asynchronous".

[0077] When multiple current status messages are collected by the high availability component, the component analyzes each message. If the high availability component determines that the current synchronization mode includes both "strong synchronization" and "asynchronous" modes based on all current status messages, it determines that the current synchronization mode between the primary and secondary databases is "asynchronous." If the high availability component determines that the current synchronization mode only includes "strong synchronization," it determines that the current synchronization mode between the primary and secondary databases is "strong synchronization." If the high availability component determines that the current synchronization mode only includes "asynchronous," it determines that the current synchronization mode between the primary and secondary databases is "asynchronous."

[0078] Step 303: When it is determined that the current synchronization method has changed, the high availability component obtains the key-value pair representing the execution permission from the distributed service registry and generates an execution lock based on the key-value pair.

[0079] The high-availability component obtains the historical synchronization method from the distributed service registry and compares the historical synchronization method with the current synchronization method. When it is determined that the current synchronization method has changed, the high-availability component obtains the key-value pair representing the execution permission from the distributed service registry and generates an execution lock based on the key-value pair.

[0080] All highly available components attempt to create key-value pairs representing execution permissions with the distributed service registry. Through the CAS (Compare And Swap) functionality provided by the distributed service registry, it is ensured that when multiple components simultaneously create key-value pairs, only one will successfully create the pair, acquire the lock representing execution permissions, and then execute subsequent operations, thus avoiding conflicts and chaos caused by concurrent operations. Highly available components continuously verify and switch between strong synchronous and asynchronous modes using a two-way strategy, significantly reducing master database blocking caused by data synchronization delays, while ensuring automatic reversion to strong synchronization after recovery.

[0081] Step 304: Adjust the historical synchronization method between the primary and standby databases of the database cluster to the current synchronization method based on the execution lock, and perform database management based on the current synchronization method.

[0082] The high-availability component adjusts the historical synchronization method between the application system and the database cluster to the current synchronization method based on execution locks. For example, when the current synchronization method is changed from "strong synchronization" to "asynchronous," the high-availability component executes the script "synchronous mode downgrade," modifies the data synchronization mode to asynchronous, refreshes the configuration information in the distributed service registry to make it take effect immediately, so that the high-availability component releases the execution locks it has acquired, writes a "data synchronization downgrade" downgrade identifier to the distributed service registry, and provides a basis for subsequent synchronization mode upgrades. The high-availability component manages the database based on the current synchronization method.

[0083] The above method also solves the problem of potential data loss or update blocking during native streaming replication. When the data synchronization mode is configured as strong synchronization, it can automatically switch to asynchronous replication upon detecting blocking, and automatically switch back to strong synchronization after data synchronization is restored. Users can use strong synchronization mode with confidence without worrying about update blocking issues.

[0084] In one embodiment, the high availability component performs database status checks on the application system and database cluster according to a preset periodic task, and updates the current status information obtained from the checks. This includes: the distributed service registry verifying the reachability information of each database node in the database cluster and each application port of the application system; the distributed service registry obtaining the working status information between the high availability component and the distributed service registry; the distributed service registry obtaining information about the primary and standby databases in the database cluster and the corresponding latest logs; the distributed service registry analyzing the corresponding latest logs based on the information of the primary and standby databases in the database cluster and generating analysis results; and the distributed service registry integrating the reachability information, working status information, and analysis results to update the current status information.

[0085] The high availability component periodically executes various probes by calling commands or scripts according to preset tasks, and writes the results as key-value pairs (KV) to etcd. The high availability component verifies the reachability information of each database node in the database cluster of the distributed service registry and each application port of the application system.

[0086] Specifically, the high availability component performs TCP connectivity checks: the high availability component calls the nc tool to probe ports and verify the reachability information between the high availability component and each database node and application port.

[0087] High-availability components perform component availability checks: High-availability components can poll the service status of their local counterparts via an API query interface to obtain operational status information between the high-availability component and the distributed service registry. Alternatively, high-availability components can poll the service status of their local counterparts via an HTTP / RPC interface to obtain operational status information between the high-availability component and the distributed service registry.

[0088] High availability components implement role awareness: On each database node, the high availability component can use a query function to determine whether the node is currently the primary or secondary database. The query function can be something like pg_is_in_recovery().

[0089] The high availability component performs connection blocking detection: It queries the process status table `pg_stat_activity` on the primary database to check for any active processes waiting for an ACK from the standby database, and if the waiting time exceeds a predefined time. For example: `select count(*) from pg_stat_activity where state='active' and wait_event_type='IPC' and wait_event='SyncRep' and EXTRACT(EPOCH FROM now() -query_start)>$sync_wait_timeout`. When such active processes exist, the high availability component generates blocking information.

[0090] The high availability component performs a data synchronization channel check: The high availability component queries the data synchronization status table pg_stat_replication in the primary database to check whether the standby database has completed replaying the WAL logs; it checks whether the standby database has completed replaying the WAL logs; if there are completed replaying WAL logs in the standby database, the high availability component obtains the earliest time when data synchronization was performed and generates analysis results.

[0091] The high-availability component integrates reachability information, operational status information, and analysis results from each node in the distributed service registry to update the current status information. The high-availability component writes the reachability information, operational status information, and analysis results to the corresponding key-value pair in the distributed service registry, along with a lease that automatically expires. If an older health status already exists in the distributed service registry, the new report will overwrite it and automatically renew the lease, ensuring that the distributed service registry always stores the latest current status information.

[0092] The above method involves the high-availability component performing health checks on the application system and database cluster according to preset periodic tasks. It continuously collects multi-dimensional health information and reports the status in a timely manner, which facilitates real-time adjustment of the synchronization method based on the current status information. This significantly reduces master database blocking caused by data synchronization delays or ensures automatic return to strong synchronization after recovery, thus guaranteeing data transmission efficiency.

[0093] In one embodiment, database management based on the current synchronization method includes: when the synchronization method between the application system and the database cluster is changed from strong synchronization mode to asynchronous mode, the distributed service registry obtains the process status table of each database in the database cluster through the high availability component; the high availability component adjusts and updates the progress status of blocked processes in the process status table of each database, and marks the adjusted database cluster as downgraded.

[0094] When the synchronization mode between the application system and the database cluster is changed from strong synchronization mode to asynchronous mode, the distributed service registry obtains the process status tables of each database in the database cluster through the high availability component. The high availability component also modifies the data synchronization mode stored in the distributed service registry to asynchronous mode and refreshes the configuration to make it take effect immediately. The high availability component adjusts and updates the progress status of blocked processes in the process status tables of each database and marks the adjusted database cluster as degraded. For example, the high availability component can first execute an interrupt command on the blocked processes to ensure that there are no blocked processes in the process status table; then refresh the database connection status and write the current status information to the distributed service registry. At the same time, other high availability components immediately realize that the status has returned to normal and stop acquiring execution locks; the high availability component releases the acquired execution locks and writes a "data synchronization degraded" degraded flag to the distributed service registry, providing a basis for subsequent synchronization mode upgrades.

[0095] The above method switches from strong synchronous mode to asynchronous mode and marks the adjusted database cluster as downgraded. This not only reduces primary database blocking caused by data synchronization delays but also facilitates automatic reverting to strong synchronous mode based on the downgrade marker. Furthermore, when the data synchronization mode is configured as asynchronous, shared storage and WAL completion mechanisms ensure automatic retrieval of the primary database logs after failover, preventing data loss. Asynchronous mode eliminates the need to wait for a backup database response, resulting in no loss of update speed and providing high-performance services for write latency-sensitive systems.

[0096] In one embodiment, determining the current synchronization mode between the primary and standby databases of the database cluster based on the current status information includes: the high availability component determining, based on the current status information, that data communication between the application system and the database cluster has returned to normal and that the database cluster has a degradation flag; the high availability component determining, based on the generation time of the degradation flag and the current time, that database cluster synchronization has returned to normal, and adjusting the current synchronization mode between the application system and the database cluster to strong synchronization mode.

[0097] The high-availability component periodically probes the data synchronization status. If it finds that data synchronization has returned to normal, the database cluster has a degradation flag, and the minimum recovery interval (min_recover_interval, the duration of normal recovery) has been exceeded, it indicates that the standby database data synchronization has returned to normal and has remained normal for at least the given time. In this case, it executes a decision to upgrade the synchronization mode. The high-availability component determines that the database cluster synchronization has returned to normal based on the generation time of the degradation flag and the current time, and adjusts the current synchronization mode between the application system and the database cluster to strong synchronization mode.

[0098] Before executing a decision, all high-availability components compete for an exclusive lock. The component that acquires the exclusive lock has the authority to execute the decision. The high-availability component changes the data synchronization mode to strong synchronization, refreshes the configuration to make it effective immediately, and all transactions thereafter use the strong synchronization mode. The high-availability component releases the acquired execution lock, clears the previous "data synchronization degradation" degradation flag, and restores normal strategy judgment.

[0099] The above method uses a two-way strategy to continuously verify and switch between strong synchronous and asynchronous modes, which can significantly reduce the blocking of the master database caused by data synchronization delay, while ensuring that it automatically returns to strong synchronization after recovery.

[0100] In one embodiment, such as Figure 4 As shown, the high-availability component dynamically adjusts the synchronization mode between the application system and the database cluster. The high-availability component uses a two-way strategy to continuously verify and switch between strong synchronization and asynchronous modes, significantly reducing master database blocking caused by data synchronization delays, while ensuring automatic reversion to strong synchronization after recovery. Taking etcd as the distributed service registry as an example, the high-availability component periodically probes and monitors the database connection status. When it detects that data updates are blocked due to strong synchronization mode, it checks the automatic switching switch and the blocking time. If the automatic switching switch is enabled (sync_auto_switch=true) and the blocking time has expired (exceeding the predefined parameter sync_wait_timeout), it executes a decision to downgrade the synchronization mode (this decision is determined by the high-availability component).

[0101] Before executing a decision, all highly available components attempt to create key-value pairs representing execution permissions with etcd. Through the CAS (Compare And Swap) function provided by etcd, it is ensured that when multiple components create key-value pairs at the same time, only one can successfully create the key-value pair, acquire the lock representing the execution permission, and then perform subsequent operations, thereby avoiding conflicts and chaos caused by multiple concurrent components.

[0102] The high-availability component executes the script "Synchronous Mode Degradation", changes the data synchronization mode to asynchronous, refreshes the configuration to make it take effect immediately, and then checks the process status table pg_stat_activity. If there are any blocked processes, it executes the interrupt command to ensure that there are no more blocked processes.

[0103] The high-availability component refreshes the database connection status and writes this current information to etcd. At the same time, other high-availability components immediately realize that the status has returned to normal and stop acquiring execution locks. Then, the high-availability component releases the execution locks it has acquired and writes a "data synchronization degradation" flag to etcd, providing a basis for subsequent synchronization mode upgrades.

[0104] The high-availability component periodically probes the data synchronization status. If it finds that data synchronization has returned to normal, the database cluster has a degradation flag, and the minimum recovery interval (min_recover_interval, the duration of normal recovery) has been exceeded, it means that the standby database data synchronization has returned to normal and has remained normal for at least the given time. Then, it executes the decision to upgrade the synchronization mode.

[0105] Before executing a decision, all highly available components compete for an exclusive lock. The component that acquires the exclusive lock has the right to execute the decision.

[0106] The high-availability component executes a script called "Synchronization Mode Upgrade," which changes the data synchronization mode to strong synchronization, refreshes the configuration to make it take effect immediately, and then all transactions use the strong synchronization mode.

[0107] The high-availability component releases the acquired execution locks and clears the previous "data synchronization degradation" flag, restoring normal policy judgment.

[0108] In one embodiment, adjusting the historical synchronization mode between the application system and the database cluster to the current synchronization mode based on the execution lock includes: when the synchronization mode between the application system and the database cluster is changed from asynchronous mode to strong synchronization mode, the high availability component clears the degradation flag based on the execution lock.

[0109] The high availability component periodically probes the data synchronization status. If the high availability component finds that the data synchronization has returned to normal, the database cluster has a degradation flag, and the minimum recovery interval (min_recover_interval, the duration of normal recovery) has been exceeded, it means that the backup database data synchronization has returned to normal and has remained normal for at least the given time. Then the high availability component determines to change the synchronization mode between the application system and the database cluster from asynchronous mode to strong synchronization mode, and the high availability component executes the decision to upgrade the synchronization mode.

[0110] Before executing a decision, all high-availability components compete for an exclusive lock. The high-availability component that acquires the exclusive lock has the authority to execute the decision. Then, the high-availability component executes the decision to upgrade to synchronous mode. The high-availability component executes a script called "Synchronization Mode Upgrade," which changes the data synchronization mode to strong synchronization, refreshes the configuration to make it take effect immediately, and then all transactions use the strong synchronization mode. The high-availability component releases the acquired execution locks and clears the previous "data synchronization degradation" degradation flag, restoring normal policy judgment (normal policy judgment is the most efficient policy judgment).

[0111] It should be understood that, although Figure 1-4 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 1-3 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0112] In one embodiment, such as Figure 5 As shown, a database management device for semiconductor manufacturing is provided, comprising a database cluster, an application system, high-availability components, a distributed service registry, and a shared storage device.

[0113] A database cluster consists of at least one primary database node and multiple standby database nodes. The primary and standby nodes synchronize data via streaming replication. Each node's data files are stored on its local disk, while the WAL file is stored on shared storage. N can be an even number greater than 2.

[0114] The application system consists of a cluster of multiple independent nodes that generate data application commands. The application system comprises a cluster of M independent nodes, connecting to the Primary node to write data and connecting to the Standby node to read data, thus achieving read-write separation. M is a natural number.

[0115] High availability components are deployed on various nodes of the application system and database cluster, providing a complete solution for database high availability. These components monitor the liveness and connectivity of the application system and database, report the results to the distributed service registry, continuously listen for status changes, and make corresponding decisions based on those changes.

[0116] A distributed service registry communicates with nodes in a database cluster or application system through high-availability components. A distributed service registry is a middleware or infrastructure component in a distributed system used to implement key coordination functions such as service discovery, configuration management, distributed locks, and master node election. These components use a simple key-value pair storage model, employ consistency algorithms (Paxos, Raft) to provide strong data consistency, and achieve high availability of the service itself through a multi-node redundancy mechanism. This embodiment uses a service registry to primarily store four types of health data: the liveness status of each node in the PostgreSQL cluster, the liveness status of each application, the liveness status of the high-availability component, and the TCP connectivity reachability between the application and the database.

[0117] Shared storage devices can be used to store log data. Shared storage devices refer to storage resources that can be accessed and used simultaneously by multiple nodes (servers). Implementation methods include SAN (Storage Area Network), NFS (Network File System), and distributed file systems (such as GlusterFS and CephFS). This embodiment uses shared storage; the database WAL file is stored in shared storage. Even if the primary database server fails, the standby database can still access the shared storage normally, retrieve the primary database WAL file from the shared storage, and fill in the missing transaction logs, avoiding data loss.

[0118] In one embodiment, the high-availability component includes a configuration management module, a health detection module, a policy engine module, an execution controller module, and a logging and alarm notification module.

[0119] The configuration management module stores various metadata information, including at least: database cluster information, connection parameters of the distributed service registry, high-availability component instance identifiers, and deployment location metadata. This module stores various metadata information, providing fundamental support for the initialization, operation, and collaboration of each module in the high-availability system. Metadata information may include at least one of the following: a list of database cluster nodes (connection information, priority for promotion to primary database), storage structure information (data directory path, WAL directory, archive configuration), service registry connection parameters, high-availability component instance identifiers, deployment location metadata, decision strategy parameters (such as latency thresholds, arbitration timeouts), and user-defined parameters (whether data synchronization degradation is allowed, degradation wait timeout).

[0120] The health monitoring module performs real-time database status checks on the application system and database cluster, updates the current status information obtained from the checks, and reports the current status information to the service registry in real time. This module detects the liveness status of each node in the database cluster, checks the health of the master node process and its service capabilities (such as whether it can accept read and write requests), detects the running status of high availability control components (such as arbitration / coordination components), detects the connectivity status between the application and the database (TCP connection reachability), and reports all status information to the service registry in real time.

[0121] The strategy engine module continuously monitors current status information and generates corresponding processing decisions based on this information, predefined policies, and business rules. This module continuously monitors various status information from the service registry, performs logical judgments and fault analysis based on status changes, predefined policies, and business rules, and generates corresponding processing decisions, including but not limited to: downgrading to asynchronous mode (from synchronous); electing a suitable standby database for master promotion when the master database fails; and rebuilding the replication topology and establishing a new master-standby relationship (rebuild / rejoin) after detecting other standby databases.

[0122] The execution controller module is used to invoke predefined execution scripts or API commands based on the processing decisions generated by the strategy engine module. This module invokes predefined execution scripts or API commands based on the processing decisions generated by the strategy engine module to complete specific operations, including but not limited to: promoting a specified standby database to a new master database; modifying master-slave replication configuration and restarting the replication stream; dynamically modifying database synchronization-related parameters; notifying the application system to perform a master database switchover operation; and writing heartbeat information, status information, or identification information to the service registry.

[0123] The logging and alarm notification module records various log information generated during system operation and promptly issues alarm notifications when abnormal events, faults, or important decisions are detected. This module records various log information generated during system operation and sends timely and accurate alarm notifications to maintenance personnel or monitoring systems when abnormal events, faults, or important decisions are detected, ensuring system observability and problem response capabilities.

[0124] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 6 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores data such as the liveness status of cluster nodes, the liveness status of various applications, the liveness status of high-availability components, and TCP connectivity reachability between applications and the database. The network interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a database management method for semiconductor manufacturing.

[0125] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0126] In one embodiment, a computer device is provided, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to perform the following steps: a high-availability component determines whether to trigger a failover of the primary database based on preset rules, the current number of reachable nodes in the primary database, and the current number of reachable nodes in the standby database of the database cluster; when the failover is triggered, the high-availability component that acquires the exclusive lock has the authority to execute the primary database election decision, and the high-availability component that does not acquire the exclusive lock collects indicator information of the list of all surviving standby database nodes; the high-availability component that acquires the exclusive lock selects a current standby database from the current standby databases of the database cluster as the new primary database based on priority and the indicator information; the high-availability component that acquires the exclusive lock updates the primary database identifier and the primary database key-value pair, and releases the exclusive lock; the distributed service registry receives the latest first log record of the old primary database and removes the primary database identifier of the old primary database; the distributed service registry updates the second log record of the new primary database through all high-availability components based on the first log record; the distributed service registry rebuilds the topology connection of the database cluster and adjusts the current synchronization method between the primary and standby databases of the database cluster.

[0127] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.< / port> < / host> < / pwd> < / port> < / pwd> < / port>

Claims

1. A database management method for semiconductor manufacturing, characterized in that, include: The high availability component determines whether to trigger a failover of the primary database based on preset rules, the current number of reachable nodes of the primary database, and the current number of reachable nodes of the standby database in the database cluster. The preset rule detects the availability of the database from the perspective of the application node. When the number of reachable nodes of the current primary database is less than the theoretical number of reachable nodes of the primary database, and the number of reachable nodes of the standby database is greater than the theoretical number of reachable nodes of the standby database, a failover is triggered. When the failover is triggered, the high-availability component that acquires the exclusive lock has the authority to execute the leader election decision, while the high-availability component that does not acquire the exclusive lock collects the indicator information of the list of all surviving standby nodes. The high-availability component that acquires the exclusive lock selects the current standby database from the current standby databases of the database cluster as the new primary database based on priority and the indicator information. The high-availability component that acquires the exclusive lock updates the master database identifier and the master database key-value pair, and releases the exclusive lock. The distributed service registry receives the latest first log record of the old master database and removes the master database identifier of the old master database. The distributed service registry updates the second log record of the new primary database based on the first log record through all high-availability components. The first log record is stored in shared storage. When the primary database server fails, the new primary database accesses the shared storage normally, retrieves the latest first log record of the old primary database from the shared storage, and updates the second log record of the new primary database. The distributed service registry updates the current backup database as the new primary database and accepts read and write requests from the outside. The distributed service registry reconstructs the topology connection of the database cluster and adjusts the current synchronization method between the primary and standby databases of the database cluster.

2. The database management method according to claim 1, characterized in that, When the high availability component determines that the indicator information of the old primary database is healthy, the distributed service registry updates the status information of the old primary database to the standby database node list through the high availability component, and adds a connection between the new primary database and the old primary database in the topology connection.

3. The database management method according to claim 1, characterized in that, Also includes: The high availability component performs database status checks on the application system and the database cluster according to a preset periodic task, and updates the current status information obtained from the checks. Determine the current synchronization method between the primary and standby databases of the database cluster based on the current status information; When it is determined that the current synchronization method has changed, the high availability component obtains a key-value pair representing execution permission from the distributed service registry and generates an execution lock based on the key-value pair; The historical synchronization method between the primary and standby databases of the database cluster is adjusted to the current synchronization method according to the execution lock, and database management is performed based on the current synchronization method.

4. The database management method according to claim 3, characterized in that, The high availability component performs database status checks on the application system and the database cluster according to a preset periodic task, and updates the current status information obtained from the checks, including: The distributed service registry verifies the reachability information of each database node in the database cluster and each application port of the application system. The distributed service registry obtains the working status information between the high-availability component and the distributed service registry. The distributed service registry obtains information about the primary and standby databases in the database cluster, as well as the latest logs. The distributed service registry analyzes the latest logs corresponding to the primary and backup databases in the database cluster and generates analysis results. The distributed service registry integrates the reachability information, the working status information, and the analysis results to update the current status information.

5. The database management method according to claim 3, characterized in that, The database management based on the current synchronization method includes: When the synchronization mode between the primary and standby databases of the database cluster is changed from strong synchronization mode to asynchronous mode, the distributed service registry obtains the process status table of each database in the database cluster through the high availability component. The high availability component adjusts and updates the progress status of blocked processes in the process status table of each database, and marks the adjusted database cluster as downgraded.

6. The database management method according to claim 3, characterized in that, The step of adjusting the historical synchronization mode between the primary and standby databases of the database cluster to the current synchronization mode based on the execution lock includes: When the synchronization mode between the primary and standby databases of the database cluster is changed from asynchronous mode to strong synchronization mode, the high availability component clears the degradation flag according to the execution lock.

7. The database management method according to claim 3, characterized in that, Determining the current synchronization method between the primary and standby databases of the database cluster based on the current status information includes: The high availability component determines, based on the current status information, that the data communication between the application system and the database cluster has returned to normal and that the database cluster has a degradation flag. The high availability component determines that the database cluster synchronization has returned to normal based on the generation time of the degradation flag and the current time, and adjusts the current synchronization mode between the primary and standby databases of the database cluster to strong synchronization mode.

8. A high-availability component, used in the method of any one of claims 1 to 7, characterized in that, Include: The configuration management module is used to store various metadata information, which includes at least: database cluster information, connection parameter information of the distributed service registry, high availability component running instance identifier, and deployment location running metadata information; The health monitoring module is used to perform database status monitoring on the application system and the database cluster in real time, update the current status information obtained from the monitoring, and report the current status information to the distributed service registry in real time. The strategy engine module continuously monitors the current state information and generates corresponding processing decisions based on the current state information and predefined strategies and business rules. The execution controller module is used to invoke predefined execution scripts or API commands based on the processing decisions generated by the strategy engine module. The log and alarm notification module records various log information generated during system operation and promptly issues alarm notifications when abnormal events, fault conditions, or important decisions are detected.

9. A high-availability database system for semiconductor manufacturing, characterized in that, The method used in any one of claims 1 to 7 comprises: A database cluster, consisting of at least one master database node and multiple slave database nodes; The application system consists of a cluster of multiple independent nodes that generate data application commands; High availability components are respectively set on the nodes of the application system and the nodes of the database cluster; A distributed service registry communicates with the database cluster or the nodes of the application system through the high-availability component. Shared storage devices are used to store log data. The high availability component is the high availability component as described in claim 8.

10. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

Images