Database resource synchronization methods and related products

Abstract

This invention belongs to the field of database technology, specifically providing a database resource synchronization method and related products. The database resource synchronization method is applied to a primary-backup dual-center deployment architecture, where the primary center deploys a primary cluster and the backup center deploys a backup cluster. Both the primary and backup clusters are shared storage database clusters. The database resource synchronization method includes: identifying the replay node in the backup cluster used for redo log replay as the management node; when a requesting node in the backup cluster needs to access buffer resources, the management node locates the holding node currently holding the buffer resources and transfers the buffer resources from the holding node to the requesting node; after obtaining the buffer resources, the requesting node notifies the management node to update the global buffer resource lock information. This invention enables non-replay nodes in the backup cluster to access buffer resources normally, avoiding data inconsistency issues.

Description

Technical Field

[0001] This invention belongs to the field of database technology, and in particular relates to a database resource synchronization method and related products. Background Technology

[0002] A primary-backup dual-center architecture achieves data backup by synchronizing redo logs from the primary database to the backup database, while a shared storage database cluster enables high-concurrency read and write operations by having multiple nodes share the same storage device. Combining these two approaches, deploying a shared storage database cluster in both the primary and backup centers, improves system availability and scalability.

[0003] However, in the standby cluster, only the replay nodes load the resource information generated by the redo log replay. Other nodes, lacking resource location information, cannot obtain the latest resources and can only read outdated data in the shared storage, leading to data inconsistency issues within the standby cluster. Summary of the Invention

[0004] One objective of this invention is to overcome at least one technical defect in the prior art and to provide a database resource synchronization method and related products.

[0005] A further objective of this invention is to enable non-replay nodes in the backup cluster to access buffer resources normally, thereby avoiding data inconsistency issues.

[0006] Another further objective of this invention is to ensure consistent reads across all nodes in the backup cluster under multi-version concurrency control, thereby enabling the backup cluster to respond correctly to read requests.

[0007] Another further objective of this invention is to achieve efficient synchronization of transaction states in the backup cluster, thereby reducing network overhead and improving the overall performance of the backup cluster.

[0008] Specifically, according to a first aspect of the present invention, the present invention provides a database resource synchronization method applied to a primary-backup dual-center deployment architecture, wherein the primary center deploys a primary cluster and the backup center deploys a backup cluster, and both the primary cluster and the backup cluster are shared storage database clusters, the database resource synchronization method comprising: The replay node in the backup cluster used to perform redo log replay is identified as the management node; When a requesting node in the backup cluster needs to access the buffer resource, the management node locates the holding node that currently holds the buffer resource and transfers the buffer resource from the holding node to the requesting node. After obtaining the buffer resource, the requesting node notifies the management node to update the global buffer resource lock information.

[0009] Optionally, the step of the management node locating the holding node currently holding the buffer resource and transferring the buffer resource from the holding node to the requesting node includes: The requesting node sends a buffer resource request to the management node; The management node forwards the buffer resource request to the node currently holding the buffer resource based on the global buffer lock information. The holding node sends the buffer resources to the requesting node; The requesting node sends an update notification to the management node so that the management node updates the global buffer resource lock information.

[0010] Optionally, when the requesting node, the management node, and the holding node are the same node, the requesting node directly calls the local buffer resource; When the requesting node and the management node are the same node but different from the holding node, the management node directly requests the buffer resource from the holding node; When the management node and the holding node are the same node but different from the requesting node, the management node directly sends the buffer resources to the requesting node.

[0011] Optionally, database resource synchronization methods also include: During the redo log replay process, the replay node listens for transaction commit events; When a transaction is ready to be committed, the replay node obtains the current transaction snapshot information and sends the transaction snapshot information to other nodes in the backup cluster. Other nodes will synchronize the received transaction snapshot information to their local machines.

[0012] Optionally, database resource synchronization methods also include: Determine whether the transaction status processed by the replay node needs to be synchronized; If synchronization is required and the transaction status is completed, the replay node will send the transaction status to other nodes in the backup cluster. If synchronization is required and the transaction status is incomplete, when other nodes in the backup cluster need to access the transaction status, the other nodes send a request to the replay node via remote call, and the replay node replies with the transaction status.

[0013] Optionally, the transaction states that need to be synchronized include: transaction commit state, transaction commit sequence number state, multi-transaction commit state; and / or Transaction states that do not require synchronization include: subtransaction commit state and two-phase transaction state.

[0014] Optionally, database resource synchronization methods also include: At least one of the global lock resources, object identifiers, write-ahead logs, and cache invalid information in the backup cluster is synchronized between the nodes of the backup cluster in the same way as the synchronization between the nodes within the primary cluster.

[0015] According to a second aspect of the present invention, the present invention provides a computer program product comprising a computer program that, when executed by a processor, implements the steps of the database resource synchronization method described in any one of the above descriptions.

[0016] According to a third aspect of the present invention, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the database resource synchronization method described in any one of the above descriptions.

[0017] According to a fourth aspect of the present invention, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the computer program, when executed by the processor, implements the steps of the database resource synchronization method described in any one of the above descriptions.

[0018] The database resource synchronization method of this invention designates the replay node in the standby cluster used for redo log replay as the management node. When a requesting node in the standby cluster needs to access buffer resources, the management node locates the holding node currently holding the buffer resources and transfers the buffer resources from the holding node to the requesting node. After obtaining the buffer resources, the requesting node notifies the management node to update the global buffer resource lock information. By using the replay node as the management node to coordinate the transfer of buffer resources, non-replay nodes in the standby cluster can correctly access buffer resources, solving the data inconsistency problem caused by unclear resource locations. This allows all nodes in the standby cluster to share the read workload of the primary cluster.

[0019] Furthermore, in the database resource synchronization method of the present invention, during the redo log replay process, when a transaction is about to be committed, the replay node broadcasts its snapshot information to other nodes in the standby cluster. These other nodes receive the snapshot information and perform local synchronization. By actively broadcasting snapshot information, the replay node ensures that all nodes in the standby cluster obtain a consistent view of the transaction snapshot, thereby solving the visibility problem under multi-version concurrency control, avoiding anomalies such as dirty reads or non-repeatable reads caused by asynchronous snapshot information, and guaranteeing the consistent read capability of each node in the standby cluster.

[0020] Furthermore, the database resource synchronization method of the present invention determines whether the transaction status processed by the replay node needs to be synchronized. If synchronization is required and the transaction status is completed, the replay node sends the transaction status to other nodes in the backup cluster. If synchronization is required and the transaction status is incomplete, when other nodes in the backup cluster need to access the transaction status, the other nodes send a request to the replay node via remote call, and the replay node replies with the transaction status. By distinguishing between different processing methods for completed and incomplete transactions, completed transactions use broadcast synchronization to ensure consistency, while incomplete transactions use on-demand remote retrieval to avoid unnecessary broadcast overhead, thereby optimizing network resource consumption while ensuring transaction status consistency.

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

[0022] To more clearly illustrate the technical solution of the present invention, some embodiments of the present invention will be described below with reference to the accompanying drawings. Those skilled in the art should understand that the same reference numerals may indicate the same or similar parts or components in different drawings; the drawings of the present invention are not necessarily drawn to scale. In the drawings: Figure 1 This is a diagram of the existing dual-center deployment architecture; Figure 2 This is a diagram of the existing shared storage cluster deployment architecture. Figure 3 This is a diagram of a primary and secondary dual-center deployment architecture using a shared storage cluster, according to an embodiment of the present invention. Figure 4 yes Figure 3 The diagram illustrates how the backup cluster only replays the nodes loading resources. Figure 5 This is a flowchart of buffer resource synchronization in the database resource synchronization method of the present invention; Figure 6 This is a flowchart of snapshot resource synchronization in the database resource synchronization method of the present invention; Figure 7 This is a flowchart of the transaction state synchronization in the database resource synchronization method of the present invention; Figure 8 This is a schematic diagram of a computer program product according to an embodiment of the present invention; Figure 9 This is a schematic diagram of a computer-readable storage medium according to an embodiment of the present invention; Figure 10 This is a schematic block diagram of a computer device according to an embodiment of the present invention. Detailed Implementation

[0023] Reference will now be made in detail to embodiments of the invention, one or more of which are illustrated in the accompanying drawings. The various embodiments provided are intended to explain the invention and not to limit it. In fact, various modifications and variations to the invention will be apparent to those skilled in the art without departing from the scope or spirit of the invention. For example, a feature illustrated or described as part of one embodiment may be used with another embodiment to produce yet another embodiment. Therefore, the invention is intended to cover such modifications and variations within the scope of the appended claims and their equivalents.

[0024] In the description of this embodiment, it should be understood that the term "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified. When a feature "includes or contains" one or more of the features it covers, unless otherwise specifically described, this indicates that other features are not excluded and may be further included.

[0025] In the description of this embodiment, the terms "one embodiment," "some embodiments," "some examples," "one example," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0026] Figure 1 This is a diagram of a dual-center deployment architecture in existing technologies, such as... Figure 1 As shown, the primary center deploys the primary database, and the backup center deploys the backup database. The primary and backup databases have their own local hard disk storage, and the primary and backup databases synchronize data through redo logs.

[0027] Specifically, the primary database serves as the core processing center for the business, handling all or most of the read and write operations. During operation, the primary database continuously generates redo logs and sends them to the standby database. The standby database receives the redo logs from the primary database in real time, continuously replays and applies these logs locally to achieve data consistency with the primary database. As a complete backup of the primary database, the standby database can handle a small amount of read traffic, or act as a hot standby database for disaster recovery in the event of a primary database failure.

[0028] However, in this traditional primary-backup dual-center deployment architecture, the backup center is typically deployed as a single node, which has limited processing capacity and suffers from brief service interruptions during failover. Furthermore, the backup database can only handle a small number of read requests, failing to fully utilize the computing resources of the backup site, resulting in low resource utilization.

[0029] Figure 2 This is a diagram of the existing shared storage cluster deployment architecture, in which multiple server nodes, such as node A, node B, and node C, access the same shared hard drive within a data center.

[0030] Specifically, any node can perform read and write operations on the same dataset cluster. The cluster presents itself as a single database service instance. Regardless of which node a client request passes through, data consistency and transaction isolation are uniformly guaranteed by the cluster's internal distributed coordination mechanism. However, because multiple nodes concurrently read and write the same data, fine-grained resource synchronization is necessary between nodes. This includes: coordinating each node's modification permissions for data pages (i.e., buffer resource management), managing each node's locking status for data rows (i.e., lock resource management), and maintaining transaction commit status and visibility checks (i.e., transaction resource management). This resource synchronization mechanism is the core foundation for the normal operation of a shared storage cluster.

[0031] While this deployment architecture offers excellent high availability and scalability—meaning that the failure of a single node will not affect the overall service capability of the cluster, and system processing performance can be linearly improved by adding nodes—it is typically limited to deployment within a single data center, lacks cross-data center fault tolerance, and cannot effectively cope with catastrophic failures at the entire data center level.

[0032] Figure 3 This is a diagram of a primary and secondary dual-center deployment architecture using a shared storage cluster, as described in one embodiment of the present invention. Figure 3 As shown, the primary center deploys a primary cluster, and the backup center deploys a backup cluster. Both the primary and backup clusters are shared storage database clusters.

[0033] Specifically, the primary cluster consists of multiple nodes such as Node 1 and Node 2, and a shared hard drive. All nodes access the same dataset cluster, providing a unified database service to the outside world. Similarly, the backup cluster consists of multiple nodes such as Node 3 and Node 4, and a shared hard drive, serving as a hot backup of the primary cluster.

[0034] This combined solution offers higher availability and scalability: within a single center, the cluster's multi-node architecture provides node-level fault tolerance, ensuring that the failure of any node does not affect the overall cluster service; between two centers, the primary-backup dual-center architecture provides data center-level fault tolerance, allowing the backup center to take over services in the event of a catastrophic failure in the primary center.

[0035] Figure 4 yes Figure 3 The diagram illustrates how the backup cluster only replays the nodes loading resources. (Example:) Figure 4 As shown, the standby cluster typically requires a dedicated replay node (node ​​3 in the figure) to replay the redo logs of the primary cluster. During replay, all modified data pages, lock information, transaction states, and other resources are loaded into the local memory of this node. Due to the characteristics of shared storage clusters, these resources are not automatically synchronized to other nodes in the standby cluster (node ​​4 in the figure). This results in other nodes lacking resource location information and having to read potentially outdated data from shared storage, causing data inconsistency within the standby cluster.

[0036] To address the aforementioned problems, this invention provides a database resource synchronization method.

[0037] Figure 5 This is a flowchart of buffer resource synchronization in the database resource synchronization method of the present invention, as shown below. Figure 5 As shown, the database resource synchronization method includes at least the following steps: Step S501: The replay node in the standby cluster used to perform redo log replay is identified as the management node.

[0038] Specifically, in the standby cluster, one node is typically designated to receive and replay redo logs from the primary cluster; this node is called the replay node. During replay, the replay node continuously modifies data pages, updates lock information, and generates transaction states, thus maintaining the most complete and up-to-date resource information in its local memory. Considering that other nodes in the standby cluster only generate read requests and do not actively modify data pages, this embodiment selects the replay node as the management node for buffer resources. The management node is responsible for maintaining global buffer lock information and coordinating the transfer of buffer resources between nodes.

[0039] Step S502: When a requesting node in the standby cluster needs to access the buffer resource, the management node locates the holding node that currently holds the buffer resource and transfers the buffer resource from the holding node to the requesting node.

[0040] Specifically, when any node in the standby cluster (called the requesting node) needs to access a data page (i.e., a buffer resource), it first sends a resource request to the replay node, which acts as the management node. Upon receiving the request, the management node queries its maintained global buffer lock information to determine which node currently holds the resource (called the holding node). The management node then forwards the request to the holding node, which directly sends the required buffer resource to the requesting node. Through this mechanism, the requesting node does not need to read potentially outdated data from shared storage; instead, it obtains the latest resource copy from the holding node, thus ensuring data real-time performance and consistency.

[0041] Step S503: After obtaining the buffer resources, the requesting node notifies the management node to update the global buffer resource lock information.

[0042] Specifically, after successfully receiving the required buffer resource, the requesting node sends an update notification to the management node. Upon receiving the notification, the management node updates the global buffer lock information, changing the node currently holding the resource to the requesting node.

[0043] The "global buffer lock information" mentioned here refers to a global mapping table maintained by the management node. This table records which node currently holds each buffer resource (i.e., each data page) in the backup cluster and what lock mode it is in (e.g., shared lock or exclusive lock). This information is the core basis for the management node to accurately locate the resource holder. When a requesting node needs to access a data page, the management node determines the holding node by querying this information. After the resource is transferred between nodes, the management node updates this information to reflect the change in resource holder.

[0044] In this way, when other nodes subsequently need to access the same resource, the management node can provide accurate resource location information, ensuring the orderly flow and state synchronization of resources among nodes. This update mechanism is a key step in maintaining the accuracy of global resource location information, avoiding resource access failures or data inconsistencies caused by outdated resource location information.

[0045] Using the above method, by coordinating the transmission of buffer resources by using the replay node as the management node, non-replay nodes in the standby cluster can correctly access buffer resources, solving the data inconsistency problem caused by unclear resource location, thereby enabling all nodes in the standby cluster to share the read service pressure of the primary cluster.

[0046] Specifically, during the process of the management node locating the holding node currently holding the buffer resource and transferring the buffer resource from the holding node to the requesting node, the requesting node sends a buffer resource request to the management node. Based on the global buffer lock information, the management node forwards the buffer resource request to the holding node currently holding the buffer resource. The holding node sends the buffer resource to the requesting node, and the requesting node sends an update notification to the management node so that the management node updates the global buffer resource lock information.

[0047] The above process covers the common scenario where the requesting node, management node, and holding node are all different. In practical applications, the roles of the three may overlap, in which case the process can be simplified accordingly: When the requesting node, the managing node, and the holding node are the same node, it indicates that the required buffer resource is located locally on the requesting node. In this case, the requesting node does not need to initiate any request; it can directly access the local buffer resource.

[0048] When the requesting node and the management node are the same node but different from the holding node, it indicates that the requesting node itself is the management node. In this case, the management node does not need to send a request to itself, but directly requests the buffer resources from the holding node, saving the step of the requesting node sending a request to the management node.

[0049] When the management node and the holding node are the same node but different from the requesting node, it indicates that the management node itself is the resource holder. In this case, the management node does not need to forward the request; it directly sends the buffer resources it holds to the requesting node, saving the step of the management node forwarding the request to the holding node.

[0050] Through the above simplification mechanism, the system can automatically select the optimal transmission path based on the overlap of node identities, reduce unnecessary inter-node communication, and thus improve the efficiency of buffer resource synchronization.

[0051] Figure 6 This is a flowchart of snapshot resource synchronization in the database resource synchronization method of the present invention, as shown below. Figure 6 As shown, the database resource synchronization method also includes the following steps: Step S601: During the redo log replay process, the replay node listens for transaction commit events.

[0052] Specifically, when replay nodes continuously replay redo logs sent from the primary cluster, they parse the log content and identify the transaction operations within. To ensure other nodes can correctly determine data version visibility when performing read operations, replay nodes need to promptly inform other nodes of their current transaction snapshot information. Therefore, replay nodes first need to listen for transaction commit events to determine when to trigger snapshot information synchronization. Specifically, when a transaction reaches the prepare-to-commit phase, the replay node knows that the transaction is about to complete, which is the optimal time to broadcast snapshot information.

[0053] Step S602: When a transaction is ready to be committed, the replay node obtains the current transaction snapshot information and sends the transaction snapshot information to other nodes in the backup cluster.

[0054] Specifically, when a replay node detects a transaction preparing to commit, it immediately obtains a snapshot of the transaction at the current moment. This snapshot records the status of all active transactions in the system and key data such as the sequence numbers of committed transactions, serving as a crucial basis for other nodes to determine data version visibility. After obtaining the snapshot information, the replay node broadcasts it to all other nodes in the backup cluster. This broadcast operation ensures that other nodes can obtain the latest transaction snapshot view in a timely manner, enabling them to correctly determine which data versions are visible during subsequent read operations.

[0055] In step S603, other nodes synchronize the received transaction snapshot information to their local machines.

[0056] After receiving the transaction snapshot information broadcast by the replay node, other nodes in the standby cluster synchronize this snapshot information to their local memory, replacing or updating their existing local snapshot views. Once synchronization is complete, when these nodes subsequently receive read requests, they can accurately determine the visibility of each data version to the current transaction based on the latest local transaction snapshot information.

[0057] Using the above method, by having the replay node actively broadcast snapshot information, all nodes in the backup cluster can obtain a consistent transaction snapshot view, thereby solving the visibility problem under multi-version concurrency control, avoiding anomalies such as dirty reads or non-repeatable reads caused by asynchronous snapshot information, and ensuring the consistent read capability of each node in the backup cluster.

[0058] Figure 7 This is a flowchart of the transaction state synchronization in the database resource synchronization method of the present invention, as shown below. Figure 7 As shown, the database resource synchronization method also includes the following steps: Step S701: Determine whether the transaction status processed by the replay node needs to be synchronized. If yes, proceed to step S702; otherwise, do not process.

[0059] Specifically, during the replay of redo logs, the replay node handles various types of transaction states. First, it determines whether the current transaction state is a type that requires synchronization. If it is, it proceeds to step S702 for further processing; otherwise, it does not process the transaction state and waits for subsequent transaction states to arrive.

[0060] Step S702: Determine whether the transaction status that needs to be synchronized is already completed. If yes, proceed to step S703; otherwise, proceed to step S704.

[0061] For transaction states that need to be synchronized, the replay node further determines the completion stage of the transaction. Specifically, the replay node identifies whether the transaction has been committed. If the transaction is completed (i.e., in the committed state), it indicates that the data modified by the transaction has become visible to other nodes, and this status information needs to be immediately communicated to other nodes, so step S703 is executed. If the transaction has started but has not yet been committed (i.e., in the incomplete state), the data modified by the transaction is not yet visible to other nodes, and other nodes usually do not need to actively obtain this status, so step S704 is executed. Step S703: The replay node sends the transaction status to other nodes in the backup cluster.

[0062] When a transaction has been committed, the replay node broadcasts the transaction's status information (including transaction commit status, transaction commit sequence number status, or multiple transaction commit status) to all other nodes in the backup cluster. Upon receiving this status information, other nodes synchronize it to their local memory for use in determining transaction visibility for subsequent read operations.

[0063] Step S704: When other nodes in the backup cluster need to access the transaction status, the other nodes send a request to the replay node through a remote call, and the replay node replies with the transaction status.

[0064] When a transaction has not yet been committed, the replay node does not actively broadcast the transaction's status information. This is because data modified by an incomplete transaction is not yet visible to other nodes, and actively broadcasting it would not immediately produce any practical benefit, but would instead waste network resources.

[0065] However, in certain special circumstances (e.g., other nodes need to obtain the current state of the transaction to determine deadlock or for debugging), other nodes may need to actively query the status of incomplete transactions. To address this, this embodiment provides an on-demand retrieval mechanism: when other nodes in the backup cluster need to obtain the status of incomplete transactions, the node sends a status query request to the replay node via a remote call. Upon receiving the request, the replay node queries the transaction status information in its local memory and replies with the status information via a remote call.

[0066] Using the above method, by distinguishing between the different processing methods of completed and incomplete transactions, completed transactions are synchronized via broadcast to ensure consistency, while incomplete transactions are remotely retrieved on demand to avoid unnecessary broadcast overhead. This optimizes network resource usage while ensuring the consistency of transaction states.

[0067] In this embodiment, the transaction states that need to be synchronized include: transaction commit state, transaction commit sequence number state, and multi-transaction commit state; the transaction states that do not need to be synchronized include: sub-transaction commit state and two-phase transaction state. Specifically: Transaction commit status: This indicates whether a transaction has been successfully committed and is the fundamental basis for other nodes to determine data version visibility. If other nodes cannot know that a transaction has been committed, they may ignore the data modified by that transaction during read operations, resulting in them not being able to read the data that should be visible.

[0068] Transaction commit sequence number status: This records the unique, incrementing sequence number assigned when a transaction is committed. This sequence number determines the visibility order of the data versions modified by the transaction among other transactions, and is the core basis for the multi-version concurrency control mechanism to correctly determine "which version is visible to this transaction".

[0069] Multi-transaction commit status: This indicates the batch commit status of a group of transactions, commonly seen in batch operations or group commit scenarios. By synchronizing this status, other nodes in the backup cluster can correctly perceive the overall commit progress of a batch of transactions, avoiding data inconsistencies caused by missing status information for some transactions.

[0070] Subtransaction commit status: A subtransaction is an inner transaction unit within a nested transaction. Its commit status depends on the final commit or rollback of the parent transaction, therefore it does not require independent synchronization. Each node only needs to determine the visibility of the subtransaction data based on the final state of the parent transaction.

[0071] Two-Phase Transaction State: A two-phase transaction (2PC) consists of a preparation phase and a commit / rollback phase, and its final state depends on the coordinator's global decision. Since state changes in a two-phase transaction involve complex coordination among multiple participants, directly synchronizing this state in the backup cluster may lead to inconsistencies. Therefore, this invention does not actively broadcast synchronization but relies on other mechanisms (such as on-demand querying) to obtain the state.

[0072] Through the above classification, this embodiment efficiently synchronizes transaction states that change frequently and are crucial for visibility judgment (i.e., the types that need to be synchronized) through broadcasting, while excluding transaction states that have complex state changes or depend on parent transactions (i.e., the types that do not need to be synchronized) from broadcast synchronization, thereby reducing unnecessary network communication overhead while ensuring consistency.

[0073] In an optional embodiment, the database resource synchronization method further includes: synchronizing at least one of the global lock resources, object identifiers, write-ahead logs, and cache invalid information in the standby cluster among the nodes of the standby cluster in accordance with the synchronization method between nodes within the primary cluster.

[0074] Specifically, in addition to the aforementioned buffer resources, snapshot resources, and transaction state resources, the nodes in the standby cluster also need to synchronize other types of shared resources to ensure the normal operation of the standby cluster. These resources include, but are not limited to, the following: Global lock resources: These are used to coordinate concurrent access to the same resource by multiple nodes, such as row locks, table locks, and global dictionary locks. If other nodes in the standby cluster are unaware of the holding status of the global lock, it may lead to lock conflicts or deadlocks.

[0075] Object identifier (Oid): Used to uniquely identify various objects in the database (such as tables, indexes, functions, etc.). In a standby cluster, if different nodes have inconsistent understandings of the identifier for the same object, it will lead to object access errors.

[0076] Write-Ahead Log (WAL): Used to record database modification operations, it is the foundation of data persistence and crash recovery. Each node in the standby cluster needs to know the write progress of the WAL to ensure that the log can be correctly replayed during fault recovery.

[0077] Invalid cache information: In a multi-node shared storage architecture, this notifies other nodes that the cache for a certain data page has expired and that the latest version needs to be read from the shared storage. Failure to synchronize this information may cause nodes to continue using outdated cached data.

[0078] For the other shared resources mentioned above, this invention does not require redesigning complex synchronization mechanisms, but directly reuses existing mature synchronization methods between nodes within the main cluster. Specifically, as a shared storage database cluster, the main cluster already has synchronization protocols and communication mechanisms for the aforementioned resources between its internal nodes (e.g., message broadcasting via the cluster interconnection network, coordinating lock resources using a distributed lock manager, etc.). The nodes in the backup cluster synchronize these resources in the exact same way as the main cluster, thereby reducing implementation complexity and development costs while ensuring functional correctness.

[0079] In this way, the standby cluster can further synchronize other shared resources between nodes on the basis of synchronizing buffer resources, snapshot resources and transaction state resources. This allows the standby cluster as a whole to completely replace the primary cluster in providing services. Whether it is node-level fault tolerance or data center-level fault tolerance, it can guarantee data consistency and service continuity.

[0080] This embodiment also provides a computer program product 41, a computer-readable storage medium 42, and a computer device 43. Figure 8 This is a schematic diagram of a computer program product according to an embodiment of the present invention. Figure 9 This is a schematic diagram of a computer-readable storage medium according to an embodiment of the present invention. Figure 10 This is a schematic block diagram of a computer device according to an embodiment of the present invention.

[0081] Computer program product 41 includes computer program 411, which, when executed by processor 431, implements any of the aforementioned database resource synchronization methods. Computer-readable storage medium 42 stores the aforementioned computer program 411, which, when executed by processor 431, implements any of the aforementioned database resource synchronization methods. Computer device 43 may include memory 432, processor 431, and computer program 411 stored in memory 432 and running on processor 431.

[0082] The computer program 411 used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, status setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages ​​and procedural programming languages.

[0083] Computer program 411 may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, to perform aspects of the invention, electronic circuits including, for example, programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs) may execute computer-readable program instructions to personalize the electronic circuits by utilizing state information of computer-readable program instructions.

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

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

Claims

1. A database resource synchronization method applied to a master-slave dual-center deployment architecture, wherein, The primary center deploys a primary cluster, and the backup center deploys a backup cluster. Both the primary cluster and the backup cluster are shared storage database clusters. The database resource synchronization method includes: The replay node in the backup cluster used to perform redo log replay is identified as the management node; When a requesting node in the backup cluster needs to access the buffer resource, the management node locates the holding node that currently holds the buffer resource and transfers the buffer resource from the holding node to the requesting node. After obtaining the buffer resource, the requesting node notifies the management node to update the global buffer resource lock information.

2. The database resource synchronization method according to claim 1, characterized in that, The steps of locating the holding node currently holding the buffer resource by the management node and transferring the buffer resource from the holding node to the requesting node include: The requesting node sends a buffer resource request to the management node; The management node forwards the buffer resource request to the node currently holding the buffer resource based on the global buffer lock information. The holding node sends the buffer resources to the requesting node; The requesting node sends an update notification to the management node so that the management node updates the global buffer resource lock information.

3. The database resource synchronization method according to claim 2, characterized in that, When the requesting node, the management node, and the holding node are the same node, the requesting node directly calls the local buffer resource; When the requesting node and the management node are the same node but different from the holding node, the management node directly requests the buffer resource from the holding node; When the management node and the holding node are the same node but different from the requesting node, the management node directly sends the buffer resources to the requesting node.

4. The database resource synchronization method according to claim 1, characterized in that, Also includes: During the redo log replay process, the replay node listens for transaction commit events; When a transaction is ready to be committed, the replay node obtains the current transaction snapshot information and sends the transaction snapshot information to other nodes in the backup cluster. Other nodes will synchronize the received transaction snapshot information to their local machines.

5. The database resource synchronization method according to claim 1, characterized in that, Also includes: Determine whether the transaction status processed by the replay node needs to be synchronized; If synchronization is required and the transaction status is completed, the replay node will send the transaction status to other nodes in the backup cluster. If synchronization is required and the transaction status is incomplete, when other nodes in the backup cluster need to access the transaction status, the other nodes send a request to the replay node via remote call, and the replay node replies with the transaction status.

6. The database resource synchronization method according to claim 5, characterized in that, The transaction states that need to be synchronized include: transaction commit status, transaction commit sequence number status, and multiple transaction commit status; and / or Transaction states that do not require synchronization include: subtransaction commit state and two-phase transaction state.

7. The database resource synchronization method according to claim 1, characterized in that, Also includes: At least one of the global lock resources, object identifiers, write-ahead logs, and cache invalid information in the backup cluster is synchronized between the nodes of the backup cluster in the same way as the synchronization between the nodes within the primary cluster.

8. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the database resource synchronization method according to any one of claims 1-7.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the database resource synchronization method according to any one of claims 1-7.

10. A computer device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the computer program is executed by the processor, it implements the steps of the database resource synchronization method according to any one of claims 1-7.

Images