Storage system, leader preemption and data replication method, device, medium, and program product

Abstract

Embodiments of the present invention provide a storage system, a leader preemption and data replication method, a device, a medium, and a program product. In a storage resource shared by a plurality of storage nodes, a synchronization state field for recording a synchronization state of data stored by master and slave nodes and a target master node field for recording an identifier of a master node closest to the current time are added, and a storage node queries the synchronization state field and the target master node field during leader election. When the value of the synchronization state field is a first identifier representing data asynchrony between the master and slave nodes, if the value of the target master node field is the value of the storage node, it indicates that the storage node is the master node when the storage system is abnormal, and the data stored in the storage node is the latest and complete. Therefore, the storage node is qualified as a master node to take over services, so as to reduce the probability of data loss in the storage system, and even avoid data loss in the storage system, thereby ensuring the reliability of the storage system.

Description

Storage systems, master-snatching and data replication methods, devices, media and software products

[0001] This disclosure claims priority to Chinese Patent Application No. 202411217215.9, filed with the China Patent Office on August 30, 2024, entitled “Storage System, Method, Apparatus, Medium and Program Product for Preemptive Mastery and Data Replication”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This disclosure relates to the field of data storage technology, and in particular to a storage system, a method, apparatus, medium, and program product for master grabbing and data replication. Background Technology

[0003] With the development of cloud computing and big data technologies, distributed storage systems have been widely used in various industries due to their high scalability and high availability. In distributed storage systems, data is typically replicated across multiple storage nodes to improve data reliability and availability. These nodes can be divided into two categories: master nodes and slave nodes. The master node is responsible for receiving and responding to write requests, while the slave nodes maintain data consistency between the master and slave nodes by replicating the data from the master node.

[0004] To ensure high availability of storage services, the data stored on multiple storage nodes must also be highly available. If one of the storage nodes fails, the new master node must be able to obtain the complete data to ensure the reliability of the storage service. Summary of the Invention

[0005] This disclosure provides a storage system, master-snatching and data replication method, device, media, and program product for reducing the probability of data loss.

[0006] This disclosure provides a storage system, including: multiple storage nodes;

[0007] The master node and the slave node in the plurality of storage nodes use a synchronous replication method to copy the data stored in the master node to the slave node;

[0008] The shared storage resources of the multiple storage nodes store a synchronization status field and a target master node field, which are used to record the synchronization status between the data stored by the slave node and the data stored by the master node; the target master node field is used to record the identifier of the master node closest to the current time.

[0009] If, during the master election process for any storage node, the value of the synchronization status field is found to be a first identifier indicating asynchronous behavior, and the value of the target master node field is its own identifier, then a master grabbing operation is performed.

[0010] Optionally, any of the storage nodes is further configured to:

[0011] If the value of the synchronization status field is the first identifier and the value of the target master node field is not its own identifier, it is determined that any storage node is not qualified to become a master node, and no master grabbing operation is performed;

[0012] or,

[0013] If the value of the synchronization status field is found to be a second identifier representing synchronization, it is determined that any of the storage nodes is qualified to become the master node, and a master grabbing operation is performed.

[0014] Optionally, the storage system is a cloud storage gateway service system, and the multiple storage nodes are multiple cloud storage gateway nodes; the multiple cloud storage gateway nodes use the log structure merged tree structure to store the metadata of the cloud storage gateway service system.

[0015] This disclosure also provides a master-preemption method applicable to any one of multiple storage nodes. The shared storage resources of the multiple storage nodes store a synchronization status field and a target master node field, used to record the synchronization status between the data stored by the slave nodes and the data stored by the master node. The target master node field records the identifier of the master node closest to the current time. The master node and slave nodes of the multiple storage nodes use a synchronous replication method to copy the data stored by the master node to the slave node.

[0016] The method includes:

[0017] During the master election process, the synchronization status field and the target master node field are queried;

[0018] If the value of the synchronization status field is found to be a first identifier indicating asynchronous operation, and the value of the target master node field is its own identifier, then any storage node is determined to be qualified to become a master node, and a master grabbing operation is performed.

[0019] Optionally, the master-grabbing method further includes: if the value of the synchronization status field is the first identifier and the value of the target master node field is not its own identifier, determining that any storage node is not qualified to become a master node and not performing the master-grabbing operation;

[0020] or,

[0021] If the value of the synchronization status field is found to be a second identifier representing synchronization, it is determined that any of the storage nodes is qualified to become the master node, and a master grabbing operation is performed.

[0022] This disclosure also provides a data replication method applicable to any one of multiple storage nodes, wherein the multiple storage nodes use a log structure merged tree structure to store data; the shared storage resources of the multiple storage nodes store an acknowledgment point field; the master node and the slave node of the multiple storage nodes use a synchronous replication method to copy the write-ahead log stored by the master node to the slave node;

[0023] The method includes:

[0024] When any of the storage nodes acts as the first master node, in response to a successful synchronization replication event or a synchronization state switching event, the target log sequence number of the most recently successfully replicated data is determined from the write-ahead log stored on any of the storage nodes.

[0025] Write the target log sequence number into the confirmation point field;

[0026] In response to an abnormal recovery event, target data with a log sequence number greater than or equal to the value of the confirmation point field is determined from the second master node; the second master node is any other storage node among the plurality of storage nodes except for any of the storage nodes, and is promoted to master node in the event of an abnormality of the first master node;

[0027] The target data is copied to the write-ahead log of any of the storage nodes.

[0028] This disclosure also provides an electronic device, including: a memory and a processor; wherein the memory is used to store a computer program;

[0029] The processor is coupled to the memory and is used to execute the computer program for performing the steps in the aforementioned master-grabbing method and / or data copying method.

[0030] This disclosure also provides a computer-readable storage medium storing computer instructions that, when executed by one or more processors, cause the one or more processors to perform the steps in the aforementioned master-preemption method and / or data copying method.

[0031] This disclosure also provides a computer program product, including a computer program that, when executed by one or more processors, causes the one or more processors to perform the steps in the aforementioned master-preemption method and / or data copying method.

[0032] In this embodiment, a synchronization status field is added to the storage resources shared by multiple storage nodes to record the synchronization status of the data stored by the master and slave nodes, and a target master node field is added to record the identifier of the master node closest to the current time. During the master election process, storage nodes can query the synchronization status field and the target master node field. When the value of the synchronization status field is a first identifier indicating that the data of the master and slave nodes is not synchronized, if the value of the target master node field is the value of that storage node, it means that when the storage system malfunctions, that storage node is the master node, and the data it stores is the latest and complete. Therefore, this storage node is qualified to become the master node and take over the service, which can reduce the probability of data loss in the storage system, and may even prevent data loss altogether, ensuring the reliability of the storage system. Attached Figure Description

[0033] The accompanying drawings, which are included to provide a further understanding of this disclosure and form part of this disclosure, illustrate exemplary embodiments of the present disclosure and are used to explain the disclosure, but do not constitute an undue limitation of the disclosure. In the drawings:

[0034] Figure 1 is a schematic diagram of the structure of the storage system provided in an embodiment of this disclosure;

[0035] Figure 2 is a schematic diagram of the LSM-Tree structure provided in an embodiment of this disclosure;

[0036] Figures 3 and 4 are schematic diagrams illustrating the process of master-slave node synchronous data replication provided in the embodiments of this disclosure;

[0037] Figure 5 is a schematic diagram of the process of data error caused by master node abnormality provided in the embodiment of this disclosure;

[0038] Figure 6 is a schematic diagram of the CSG service system provided in an embodiment of this disclosure;

[0039] Figure 7 is a flowchart illustrating the method for preempting the host provided in an embodiment of this disclosure;

[0040] Figure 8 is a flowchart illustrating the data copying method provided in an embodiment of this disclosure;

[0041] Figure 9 is a schematic diagram of the structure of the electronic device provided in the embodiment of this disclosure. Detailed Implementation

[0042] To make the objectives, technical solutions, and advantages of this disclosure clearer, the technical solutions of this disclosure will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without creative effort are within the scope of protection of this disclosure.

[0043] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0044] In some traditional systems, a master-slave synchronous replication scheme using incremental replication and periodic backups is employed. New data added to the master database is simultaneously replicated to multiple slave databases to increase the number of databases that can be used as the master database during storage system recovery. This scheme reduces the risk of data loss by increasing redundancy. However, if a storage system anomaly occurs before the new data is replicated from the master to the slave databases, inconsistencies will arise between the master and slave databases. After the storage system recovers from the anomaly, if a slave database successfully takes over as master, the data in the slave database will be incomplete, resulting in data loss.

[0045] In some embodiments of this disclosure, a synchronization status field is added to the storage resources shared by multiple storage nodes to record the synchronization status of data stored by master and slave nodes, and a target master node field is added to record the identifier of the master node closest to the current time. During the master election process, storage nodes can query the synchronization status field and the target master node field. When the value of the synchronization status field is a first identifier indicating that the data stored by the master and slave nodes is not synchronized, if the value of the target master node field is the value of that storage node, it means that when the storage system malfunctions, that storage node is the master node, and the data it stores is the latest and complete. Therefore, that storage node is qualified to become the master node and take over the service, which can reduce the probability of data loss in the storage system, and may even prevent data loss altogether, ensuring the reliability of the storage system.

[0046] The technical solutions provided by the embodiments of this disclosure are described in detail below with reference to the accompanying drawings.

[0047] It should be noted that the same reference numerals denote the same object in the following figures and embodiments. Therefore, once an object is defined in one figure or embodiment, it does not need to be discussed further in subsequent figures and embodiments.

[0048] Figure 1 is a schematic diagram of the storage system provided in an embodiment of this disclosure. As shown in Figure 1, the storage system includes multiple storage nodes 10. "Multiple" means two or more. Figure 1 only illustrates two storage nodes. A storage node 10 refers to any device, apparatus, or cloud server, etc., that has storage space and performs data storage. Each storage node 10 has independent storage resources, which are not shared with other storage nodes.

[0049] To ensure data reliability and high availability, multiple storage nodes 10 can be divided into master nodes and slave nodes. The master node is responsible for receiving and responding to write requests, while the slave nodes maintain data consistency by replicating the data from the master node. The master and slave nodes can be determined through a master election operation. The data stored on the storage nodes 10 can be of any data structure, such as key-value pairs (KV), text data, image data, or tabular data.

[0050] In this embodiment, the specific method by which storage node 10 elects a leader is not limited. In some embodiments, storage node 10 may use a distributed lock service for leader election. Specifically, during election, each storage node attempts to acquire a distributed lock. A short timeout period can be set to allow for quick lock acquisition in the absence of competitors, or to abandon the attempt if the lock cannot be acquired for an extended period. The first storage node to successfully acquire the distributed lock becomes a candidate leader. If multiple nodes attempt to acquire the lock simultaneously, the distributed lock service determines which node ultimately acquires the lock based on its internal mechanism. The node that acquires the lock becomes the leader node. For example, the leader node can be determined based on some order rule, such as node identity (ID) or timestamp. Once the candidate leader acquires the lock, it becomes the actual leader node. The leader node maintains its holding of the distributed lock until it completes its work, encounters an exception, or the lease expires.

[0051] In this embodiment, the master node is responsible for receiving and responding to write requests, and the slave nodes maintain data consistency by replicating the master node's data. In this embodiment, the master and slave nodes use synchronous replication, copying the data stored on the master node to the slave node. In some embodiments, the data stored on storage node 10 is configured with sequence numbers set according to the writing order. The sequence numbers corresponding to the data stored on storage node 10 can be natural numbers such as 1, 2, 3, ...

[0052] For example, in some embodiments, storage node 10 uses a Log-Structure-Merge Tree (LSM-Tree) structure to store data. The LSM-Tree structure is particularly suitable for write-intensive workloads. It improves write performance and reduces disk input / output (I / O) operations by writing data to memory first and then writing it to disk in batches. The LSM-Tree structure is especially suitable for key-value (KV) storage.

[0053] As shown in Figure 2, the LSM-Tree structure can include: a memory table (Memtable), a sorted string table (SSTable), and a write-ahead log (WAL). The LSM-Tree structure improves system write performance by transforming random writes into sequential writes through WAL writes. Before data is written to the memory table, related operations are recorded in the WAL. The WAL is stored on disk, ensuring that even if the system crashes, the data in the memory table can be recovered by replaying the WAL.

[0054] In the Write-Ahead Log (WAL), log sequence numbers (also often called serial numbers) are used to identify the position or order of log entries in the log file. Each log entry is given a unique identifier, making each entry clearly distinguishable. Log sequence numbers typically increment in the order in which log entries are written, thus allowing the tracking of log entries by sequence number. In the event of a system crash or restart, log sequence numbers determine which log entries have been persisted to disk and which have not. This helps in correctly replaying log entries during system recovery. In some systems, log entries can be safely deleted from the log file, freeing up space, once all transactions associated with a given log sequence number and all log entries preceding that number have been completed.

[0055] Log sequence numbers can be implemented as incremental numeric numbers. That is, each newly written log entry is assigned an incremental integer sequence number. For example, the first entry has a log sequence number of 1, the second entry has a log sequence number of 2, and so on. Alternatively, log sequence numbers can be implemented as timestamps, where the timestamp of the data being written is used as the log entry's sequence number, reflecting the chronological order in which entries were written.

[0056] A memtable is an in-memory data structure used to temporarily store new data. When new data is written, it is first added to the memtable. A memtable is typically an ordered data structure, such as a skip list or a B+ tree. When the amount of data written to the memtable reaches a certain threshold, it is flushed to disk, forming an SSTable file. SSTable files are ordered, usually contain multiple data entries, and are immutable. Over time, multiple SSTable files are generated, and these files need to be merged periodically to reduce disk fragmentation. As shown in Figure 2, to reduce disk fragmentation and improve read performance, LSM-Tree periodically performs a merge operation, combining multiple smaller SSTable files into a larger SSTable file, and deleting invalid data entries in the process. After data is flushed to the SSTable, that data in the WAL (Write-Ahead Allocation) is eligible for garbage collection (GC).

[0057] Specifically, the master node and slave node adopt a synchronous replication method, and the data stored in the master node is copied to the slave node in ascending order of the data sequence number.

[0058] In the embodiment where storage node 10 uses an LSM-Tree structure to store data, the data copied from the master node to the slave node mainly refers to the Write-Ahead Log (WAL). The master and slave nodes use a synchronous replication method, copying the write-ahead log stored on the master node to the slave node. Specifically, the master and slave nodes use a synchronous replication method, copying the write-ahead log stored on the master node to the slave node in the order of the log sequence number in the write-ahead log.

[0059] Synchronous replication means that the master node considers the data to have been successfully written only after the slave node has successfully copied the data stored on the master node to the slave node. The following example, using WAL (Write-Ahead Log) data copied from the master node to the slave node, illustrates the synchronous replication method.

[0060] Specifically, as shown in Figures 3 and 4, the master node can determine the data to be replicated to the slave node from the stored Write-Ahead Log (WAL). In some embodiments, the master node can use the data to be written each time data is written as the data to be replicated. Specifically, as shown in Figures 3 and 4, in response to a write request, the master node writes the data to be written to the Write-Ahead Log (WAL) stored by the master node, and configures a log sequence number for the data to be written in the WAL based on the existing log sequence numbers in the WAL stored by the master node. For example, the maximum existing log sequence number in the WAL stored by the master node can be increased by 1 to serve as the log sequence number for the data to be written.

[0061] In other embodiments, batch replication between master and slave nodes reduces I / O operations and improves system throughput. In this embodiment, a data volume threshold can be configured in the master node. When the amount of data in the master node's Write-Ahead Log (WAL) that has not been replicated to the slave node reaches the preset threshold, the unreplicated data is determined from the master node's WAL and designated as data to be replicated. The data volume threshold can be represented by the number of data items. For example, if the storage node stores key-value pairs, the data volume threshold can be represented by the number of key-value pairs. Alternatively, the data volume threshold can be represented by the size of the data.

[0062] Specifically, each time data is written, the master node can determine whether the amount of data in its current WAL (Write-Ahead Log) that has not been replicated to the slave node has reached a preset data volume threshold. If it has, the master node determines the data that has not been replicated to the slave node from its WAL and uses it as data to be replicated. If it has not reached the threshold, it continues to wait for new data to be written until the amount of data in the master node's WAL that has not been replicated to the slave node reaches the preset data volume threshold. After that, the master node can determine the data that has not been replicated to the slave node from its local WAL and use it as data to be replicated.

[0063] In some embodiments, as shown in Figure 3, the master node can proactively send data to be replicated to the slave nodes. Accordingly, when the master node determines that the amount of data in its currently stored WAL that has not been replicated to the slave nodes reaches a preset data volume threshold, it can identify the data not replicated to the slave nodes from its WAL, designate it as the data to be replicated, and send the data to be replicated to the slave nodes. The master node can send the data to be replicated to the slave nodes in batches. For example, the master node can send the data to be replicated to the slave nodes all at once.

[0064] Specifically, as shown in Figure 3, the replication thread of the master node can start timing the waiting time at the beginning of the replication process and wait for new data to be written to the local WAL. When new data is detected being written to the local WAL, it determines whether the amount of data not yet replicated to the slave node in the current WAL reaches a preset data volume threshold, and whether the waiting time reaches a set duration threshold. If the amount of data not yet replicated to the slave node in the current WAL is less than (i.e., does not reach) the preset data volume threshold, and the waiting time does not reach the set duration threshold (i.e., the judgment result in Figure 3 is negative), then it continues to wait for new data to be written to the local WAL and continues timing the waiting time. If the amount of data not yet replicated to the slave node in the current WAL reaches (greater than or equal to) the preset data volume threshold, and / or the waiting time reaches the set duration threshold (i.e., the judgment result in Figure 3 is positive), then the master node determines the data not yet replicated to the slave node from the current WAL as data to be replicated. In some implementations, if the amount of data not replicated to the slave node in the current WAL is less than a preset data volume threshold, but the waiting time has reached a set time threshold, the master node determines all data not replicated to the slave node in the current WAL as data to be replicated. If the amount of data not replicated to the slave node in the current WAL is greater than or equal to the preset data volume threshold, but the waiting time has not reached (is less than) or has reached the set time threshold, the master node determines the data corresponding to the starting log sequence number to the ending log sequence number from the locally stored WAL in ascending order as data to be replicated. The amount of data corresponding to the starting log sequence number to the ending log sequence number is the preset data volume threshold. In other embodiments, the slave node pulls data from the master node. Specifically, as shown in Figure 4, the slave node can start the replication engine during data replication and use the replication engine to send a replication request to the master node. Specifically, the slave node can determine the starting log sequence number of the data to be replicated. For example, the slave node can add 1 to the maximum log sequence number of the locally stored WAL as the starting log sequence number of the data to be replicated. The master node receives a replication request, responds to it, and determines data from its locally stored Write-Ahead Log (WAL) with a sequence number greater than or equal to the starting log number as the data to be replicated. If the amount of data with a sequence number greater than or equal to the starting log number is greater than or equal to a preset data volume threshold, then the master node determines the data from the locally stored WAL, in ascending order of log sequence number, from the starting log number to the ending log number, as the data to be replicated. The amount of data from the starting log number to the ending log number is the preset data volume threshold. Furthermore, the master node can send the data to be replicated to the slave nodes in batches. For example, the master node can send the data to be replicated to the slave nodes all at once.

[0065] Accordingly, a slave node can copy data to be replicated from the master node to its WAL. Specifically, a slave node can write the data to be replicated into its WAL in a batch at once.

[0066] Afterwards, the master node can wait for the slave node to copy the data to be copied to the slave node's WAL (Write-Ahead Log). If the slave node successfully copies the data to its WAL, the master node determines that the data copying was successful. If the slave node fails to copy, the master node considers the data copying to have failed. For example, if the master node does not receive a copy success message from the slave node within a set time, it determines that the slave node failed to copy the data, i.e., the copy timeout caused the copying failure. If the slave node fails to copy the data, the master node can consider the data copying to have failed and block all I / O operations. In the embodiment shown in Figure 3 where the master node actively sends the data to be copied to the slave node, the copy thread can also notify the write thread of the copying failure if the slave node fails to copy the data.

[0067] In this embodiment of the disclosure, the master and slave nodes use the aforementioned synchronous replication method to copy the WAL stored by the master node to the slave node. The master and slave nodes primarily use a single thread (i.e., the aforementioned replication thread) to copy the WAL stored by the master node to the slave node.

[0068] In practical applications, if a storage system experiences an anomaly while the data on the master and slave nodes is synchronized, any one of the storage nodes can become the master node and provide complete data during recovery, since the data across multiple storage nodes is synchronized. However, if the storage system experiences an anomaly while the data on the master and slave nodes is out of sync, if the storage node that was previously a slave node successfully becomes the master during recovery, data loss or errors will occur, impacting the reliability of the storage system's service.

[0069] To ensure the reliability of the storage system and guarantee service availability even with only one storage node, additional status information is needed to help the storage system determine whether the data on a particular storage node is up-to-date and whether it can provide services. In this embodiment, as shown in Figure 1, a synchronization state (SyncState) field and a target master node (LastMaster) field are added. The synchronization state field records the synchronization status between the data stored on the slave node (e.g., WAL) and the data stored on the master node (e.g., WAL). Synchronization means the data on the master and slave nodes (e.g., WAL) are identical; asynchrony means the data stored on the slave node (e.g., WAL) is not synchronized with the data stored on the master node (e.g., WAL). In this embodiment, the synchronization status between the data stored on the slave node (e.g., WAL) and the data stored on the master node (e.g., WAL) can be represented using an identifier indicating synchronization and an identifier indicating asynchrony. In this embodiment, for ease of description and distinction, the identifier indicating asynchrony is defined as the first identifier, and the identifier indicating synchronization is defined as the second identifier. The first identifier can be "UNSYNCED", and the second identifier can be "SYNCED". The target master node field is used to record the identifier of the master node closest to the current time, that is, the identifier of the latest master node.

[0070] To enable multiple storage nodes 10 to access and view the synchronization status field and the target master node field, as shown in Figure 1, this embodiment introduces a shared storage resource 20 for multiple storage nodes. The shared storage resource 20 is an external storage resource for the multiple storage nodes and can be located on other storage nodes besides the multiple storage nodes 10. The shared storage resource 20 stores the synchronization status field and the target master node field. The shared storage resource 20 can be any storage resource accessible to all multiple storage nodes 10. For example, the shared storage resource 20 can be a storage resource in a shared storage system such as OSS. Alternatively, if the multiple storage nodes 10 use a distributed lock service for master election, the shared storage resource 20 can also be a storage resource provided by the node providing the distributed lock service, etc.

[0071] In this embodiment, if the slave node successfully replicates data from the master node, the master node can write a synchronization identifier into the synchronization status field. Correspondingly, if the slave node successfully replicates data from the master node, the master node can write a second synchronization identifier (e.g., SYNCED) into the synchronization status field. If the slave node fails to replicate data from the master node, the master node can write a first synchronization identifier (e.g., UNSYNCED) into the synchronization status field. For example, as shown in Figures 3 and 4, the master node can update the synchronization status field by writing the first synchronization identifier (e.g., UNSYNCED) into the synchronization status field if the replication of the data to be replicated times out.

[0072] Regarding the target master node field, storage node 10 can write its own identifier into the target master node field if it successfully acquires the master node.

[0073] Based on the synchronization status field and the target master node field, as shown in step 1 of Figure 1, during the master election process, storage node 10 can query the synchronization status field and the target master node field stored in the storage resource 20 shared by multiple storage nodes. As shown in step 2.2 of Figure 1, if the value of the synchronization status field is found to be a second identifier representing synchronization, it indicates that the data (such as WAL) stored by multiple storage nodes 10 is synchronized, that is, the data is consistent, and each storage node 10 can take over the service and continue to provide services. Therefore, it can be determined that the storage node 10 is qualified to be a successful master node and can perform the master grabbing operation.

[0074] As shown in step 2.1 of Figure 1, if the value of the synchronization status field is the first identifier indicating asynchronous operation, and the value of the target master node field is its own identifier, then storage node 10 is the master node when the storage system is abnormal. That is, storage node 10 is the closest master node, and its stored data is the latest and complete. Therefore, it can be determined that this storage node is qualified to be a successful master node and can perform the master-grabbing operation. Correspondingly, as shown in step 2.3 of Figure 1, if the value of the synchronization status field is the first identifier indicating asynchronous operation, and the value of the target master node field is not its own identifier, then it is the slave node when the storage system is abnormal. Its stored data is lost compared to the master node at that time. Therefore, it can be determined that this storage node is not qualified to be a successful master node and will not perform the master-grabbing operation. In this way, even if an anomaly occurs when the master and slave nodes are in an asynchronous state, during anomaly recovery, the slave node at the time of the anomaly will not be qualified to grab the master and will not become the master node to take over the service. This prevents storage nodes with incomplete stored data (such as WAL) from taking over the service, helping to ensure service reliability.

[0075] In this embodiment, a synchronization status field is added to the storage resources shared by multiple storage nodes to record the synchronization status of data (such as WAL) stored by the master and slave nodes, and a target master node field is added to record the identifier of the master node closest to the current time. During the master election process, storage nodes can query the synchronization status field and the target master node field. When the value of the synchronization status field is a first identifier indicating that the data (such as WAL) stored by the master and slave nodes is out of sync, if the value of the target master node field is the value of that storage node, it means that when the storage system experienced an anomaly, that storage node was the master node, and the data it stored was the latest and complete. Therefore, that storage node is qualified to become the master node and take over the service. If this storage node takes over the service, the probability of data loss in the storage system can be reduced, or even avoided altogether, ensuring the reliability of the storage system.

[0076] The storage system provided in this disclosure maintains good reliability even in a two-node master-slave synchronous replication architecture with two storage nodes. In this two-node architecture, there is only one master node and one slave node. If a storage node experiences an anomaly or failure, the individual storage node can still determine its eligibility to become the master node, i.e., whether it can take over the service, using the methods described above. If the storage node is qualified to become the master node, it can directly take over the service. Therefore, this disclosure supports single-node service, and the storage system can still be repeatedly restarted to provide related services even when operating as a single-node system.

[0077] The master-slave node synchronous replication method provided in the aforementioned embodiments can handle most system anomalies to ensure no data loss or corruption. However, there is still a risk of data loss in some situations. For example, there may be a risk of data loss if the master node fails. Specifically, as shown in Figure 5, in scenario 1, the data to be written (i.e., data C with log sequence number 3) was successfully written to the WAL of the master node (node ​​1), but data C has not yet been replicated to the slave node. At this time, the master node (node ​​1) fails, and from the perspective of the write request, the write of data C is unsuccessful.

[0078] In scenario 2, since the master node (node ​​1) is abnormal, and logically the write of data C failed, logically, both node 1 and node 2 should contain two data entries, A and B, meaning that node 2's data is logically synchronized with node 1's data. However, in reality, node 2's data is physically out of sync with node 1's data. In this situation, node 2 is promoted to master node to provide services.

[0079] In scenario 3, the master node (node ​​2) provides single-node service and writes data D and E, with corresponding log sequence numbers 3 and 4, respectively.

[0080] In scenario 4, node 1 comes back online and acts as a slave node of node 2 to synchronously replicate node 2's data. However, according to the aforementioned master-slave synchronous replication process, the data with log sequence number 3 on node 1 is already occupied, which conflicts with the data D with log sequence number 3 on node 2. Continuing to replicate the data according to the aforementioned master-slave synchronous replication process will result in data errors.

[0081] To address this issue, a CommitPoint field is introduced in some embodiments of this disclosure. In embodiments where multiple storage nodes store data in an LSM-Tree structure, the CommitPoint field is used to record the log sequence number of the most recently synchronized data between the master and slave nodes, defined as the target log sequence number. In this embodiment, since any storage node can become the master node, the CommitPoint field can be stored in the shared storage resource 20 of the aforementioned multiple storage nodes 10, making it accessible to all storage nodes.

[0082] In this embodiment, the storage node, acting as the master node, can monitor successful synchronization replication events and / or synchronization state switching events. A synchronization state switching event refers to an event in which the synchronization state of the master and slave nodes changes, such as switching from synchronous to asynchronous, or vice versa.

[0083] Specifically, the master node can determine a successful synchronization replication event when the slave node successfully replicates data from the master node's WAL. Further, in response to the successful synchronization replication event, the master node can determine the target log sequence number of the most recently successfully replicated data from its stored write-ahead log. Specifically, the master node can determine the log sequence number of the currently successfully replicated data from the master node's WAL as the target log sequence number of the most recently successfully replicated data. Further, the master node can write or update the target log sequence number to the acknowledgment point field.

[0084] If the acknowledgment point field is updated every time the slave node successfully replicates the master node's WAL, it increases the I / O pressure on the shared storage resources of multiple storage nodes. Therefore, in some embodiments, to reduce the I / O pressure on the shared storage resources of multiple storage nodes, the acknowledgment point field value may not be updated with each master-slave synchronization replication. For example, the master node can monitor synchronization state switching events. Specifically, the master node can monitor the value of the synchronization state field and, when the value of the synchronization state field switches from a first identifier to a second identifier, determine that a first synchronization state switching event has occurred, transitioning from an asynchronous state to a synchronous state. Further, in response to the first synchronization state switching event, the log sequence number of the data successfully replicated by the slave node in this synchronization can be determined as the target log sequence number of the most recently replicated data. Further, the master node can write or update the target log sequence number to the acknowledgment point field.

[0085] Accordingly, if the master node detects that the value of the synchronization status field has switched from the second identifier to the first identifier, it determines that a second synchronization status switch event has occurred, transitioning from a synchronized state to a desynchronized state. Furthermore, in response to the second synchronization status switch event, the master node can determine the log sequence number of the data from the previous successfully replicated synchronization that failed on the slave node, using this as the target log sequence number of the most recent successfully replicated synchronization. Furthermore, the master node can write or update the target log sequence number to the acknowledgment point field.

[0086] In summary, the master node can respond to the synchronization state transition event by determining the target log sequence number of the most recently successfully replicated data from the write-ahead log stored on the master node, and then write or update the target log sequence number to the acknowledgment point field.

[0087] If the aforementioned primary node fails, other storage nodes can be promoted to the new primary node through a master-preemption operation. In this embodiment of the disclosure, for ease of description and distinction, the original primary node is defined as the first primary node, and the new primary node promoted through a master-preemption operation when the first primary node fails is defined as the second primary node.

[0088] A storage node acting as a slave node to the second master node can determine the target data with a log sequence number greater than or equal to the aforementioned confirmation point field value from the second master node, and copy the target data to the slave node's write-ahead log. The slave node acting as the second master node can include the aforementioned first master node; that is, after an anomaly recovery, the storage node acting as the first master node can act as a slave node to the second master node, copying the target data with a log sequence number greater than or equal to the confirmation point field value from the second master node's write-ahead log to its own write-ahead log. In this way, even if the first master node experiences the anomaly shown in Figure 5, it can copy data with a log sequence number greater than or equal to the target log sequence number from the new master node's write-ahead log, discarding the previously stored data with a log sequence number greater than or equal to the target log sequence number, maintaining data consistency between the master and slave nodes, preventing data errors, and even making the Recovery Point Objective (RPO) 0. RPO mainly refers to the amount of data loss that a storage system can potentially experience.

[0089] For example, in the master node anomaly scenario shown in Figure 5, if node 1 successfully replicates the data with log sequence number 2 from node 2, it determines that a successful replication event has occurred and writes 2 as the target log sequence number into the acknowledgment point field. After node 1 recovers from the anomaly and comes back online, as a slave node of the new master node (node ​​2), it can replicate data with log sequence number greater than or equal to 2 from node 2's write-ahead log to node 1's write-ahead log. In this way, the data with log sequence number 3 originally stored in node 1 is overwritten and discarded, ensuring data consistency between the new master and slave nodes.

[0090] Alternatively, if after node 1 and node 2 synchronously replicate the data of log sequence number 1, their synchronization state switches from asynchronous to synchronous, then a synchronization state switch event is determined to have occurred, and 1 is written as the target log sequence number to the acknowledgment point field. The data of log sequence number 3 originally stored in node 1 is overwritten and discarded, ensuring data consistency between the new master and slave nodes.

[0091] In the embodiment where storage node 10 stores data in an LSM-Tree structure, based on the working principle of the LSM-Tree structure shown in Figure 2, the Write-Ahead Log (WAL) records all operations written to the in-memory table. Before data is written to the in-memory table, related operations are first recorded in the WAL. When new data needs to be written, it is first written to the WAL. Then, the same data is asynchronously written to the in-memory table. When the in-memory table reaches a certain size threshold, it becomes an immutable memtable. The immutable memtable is asynchronously flushed to disk, forming an SSTable file. Once the data in the in-memory table is successfully written to the SSTable file, the corresponding WAL can be cleaned up.

[0092] In storage engines based on the LSM-Tree structure, the memory table is continuously flushed to disk. Since the Write-Ahead Log (WAL) records the operations written to the memory table, if erroneous data is written to the WAL, the data written to the memory table will also be erroneous. If erroneous data written to the memory table is flushed to disk, causing erroneous data written to the WAL to also be flushed to disk, this erroneous data cannot be easily discarded. For example, in the master node scenario shown in Figure 5 above, in scenario 2, if the data with log sequence number 3 is flushed to the ordered string table (SSTable) of node 1, but the data with log sequence number 3 needs to be discarded after node 1 recovers from the anomaly, this results in the erroneous data (the data with log sequence number 3) being flushed to the disk of node 1.

[0093] To prevent erroneous data in the WAL from being flushed to disk, a maximum log sequence number (MaxFlushableSeqno) that can be flushed to the ordered string table (SSTable) is added to the in-memory table. The master node's in-memory table maintains this maximum log sequence number.

[0094] Specifically, in response to a successful replication synchronization event, the master node can write the log sequence number of the data successfully replicated from the slave node into the memory table, using this as the maximum log sequence number that can be flushed to the ordered string table. Further, the master node can flush the data stored in the memory table to the ordered string table (SSTable) if all log sequence numbers of the data stored in the memory table are less than or equal to the aforementioned maximum log sequence number, and if the amount of data stored in the memory table reaches a set data size threshold. This set data size threshold is the size threshold of the memory table that becomes immutable when it reaches a certain size threshold. In this embodiment, since the maximum log sequence number that can be flushed to the ordered string table is dynamically updated based on the log sequence number of the data successfully replicated from the slave node (i.e., the maximum log sequence number is the maximum log sequence number of the data successfully replicated from the slave node), the fact that all log sequence numbers of the data stored in the memory table are less than or equal to the maximum log sequence number that can be flushed to the ordered string table ensures that conflicting erroneous data between the master and slave nodes will not be flushed to disk.

[0095] For example, in the master node anomaly scenario shown in Figure 5, when node 1 is acting as the master node, it can write log sequence number 2 as the maximum log sequence number that can be flushed to the ordered string table when the data with log sequence number 2 is successfully replicated from the slave node. This way, even if the data volume threshold when flushing the memory table to the SSTable is less than or equal to 2, node 1 will not flush the conflicting log sequence number C (log sequence number 3) from nodes 1 and 2 to the SSTable; that is, it will not flush the conflicting log sequence number C from nodes 1 and 2 to the disk.

[0096] When the master node recovers from an anomaly and comes back online, it can act as a slave node of the new master node and perform WAL replay. During WAL replay, the value of the acknowledgment point field can be obtained from the storage resource 20 shared by multiple storage nodes, and data in the slave node's WAL with a log sequence number greater than or equal to the value of the acknowledgment point field can be deleted or skipped.

[0097] When a slave node performs a WAL replay, it can read the data from the WAL. This data is arranged chronologically and may include all changes that were not flushed to the SSTable before the node's failure. The same write operation can be performed on the in-memory table according to the log sequence number, from smallest to largest, to restore the state before the failure. When encountering data with a log sequence number greater than or equal to the acknowledgment point field value, this data is skipped, and no write operation is performed on the in-memory table for that data record. This ensures that erroneous data in the WAL is correctly discarded, and even if the original master node recovers and comes back online as a slave node, the erroneous data will not be flushed to the disk (SSTable).

[0098] In the storage system provided in this embodiment, the number of storage nodes can be two, achieving a minimum two-node deployment. When there are two storage nodes, the solution provided in the foregoing embodiments can also be used to reduce data loss and ensure the reliability of the storage system. The two-node storage system represents a minimum two-node deployment, resulting in lower storage system resource requirements.

[0099] It is worth noting that the storage system provided in this disclosure can be implemented as any system that requires master and slave nodes for data storage to ensure high availability. For example, the storage system can be implemented as a distributed storage system or a Cloud Storage Gateway (CSG) service system. In a CSG system, the storage node can be a CSG node. The following describes an example implementation of the CGS system using the aforementioned scheme to ensure system reliability, with reference to Figure 6.

[0100] As shown in Figure 6, in the CSG service system, storage node 10 can be implemented as CSG node 30. The Cloud Storage Gateway (CSG) is a hybrid cloud storage service that provides a file system semantic interface to the Object Storage Service (OSS) system. CSG node 30 can be deployed in both user's on-premises data center and cloud data center. CSG node 30 uses the OSS system as its backend storage, providing standard file service access protocols for both cloud and on-premises applications, such as Network File System (NFS), Server Message Block (SMB), and block storage service protocols, such as Small Computer System Interface (SCSI).

[0101] CSG node 30 stores the metadata of the CSG service system in an LSM-Tree structure. This metadata may include: the transformation of the OSS system 40's tiled directory structure into a file system's tree-like directory structure, the mapping of cached file data on disk, user request operation logs, and internal persistent data of the CSG service, etc. CSG node 30 can utilize this metadata to provide CSG services. The metadata of the CSG service system can be in key-value (KV) format.

[0102] To ensure data reliability and high availability, multiple CSG nodes 30 can be divided into master nodes and slave nodes. The master node is responsible for receiving and responding to write requests, while the slave nodes maintain data consistency by replicating the data of the master node. The master and slave nodes can be determined through a master election operation. For details on the implementation of master election among multiple CSG nodes, please refer to the relevant content of the aforementioned storage system; it will not be repeated here.

[0103] In this embodiment, the master node and slave node employ a synchronous replication method, copying the write-ahead log stored on the master node to the slave node. Specifically, the master node and slave node use a synchronous replication method, copying the write-ahead log stored on the master node to the slave node in the order of the log sequence number in the write-ahead log. For the implementation method of copying the write-ahead log stored on the master node to the slave node using a synchronous replication method, please refer to the relevant content in the foregoing embodiments, which will not be repeated here.

[0104] In practical applications, if an anomaly occurs in the CSG service system when the WAL (Write-Ahead Log) of the master node and the WAL of the slave nodes are synchronized, then upon recovery, since the WALs of multiple CSG nodes are synchronized, any CSG node can become the master node and provide complete data. However, if an anomaly occurs when the WALs of the master node and the WALs of the slave nodes are out of sync, then if a CSG node that was previously a slave node successfully becomes the master node upon recovery, data loss or errors will occur, affecting the reliability of the storage system service.

[0105] To ensure the reliability of the CSG service system, as shown in Figure 6, a Synchronization State field and a LastMaster field are added. The Synchronization State field records the synchronization status between the write-ahead logs of the slave nodes and the write-ahead logs of the master node. The LastMaster field records the identifier of the master node closest to the current time, i.e., the identifier of the most recent master node.

[0106] To enable multiple CSG nodes 30 to access and view the synchronization status field and the target master node field, as shown in Figure 6, this embodiment introduces a shared storage resource 20 for multiple CSG nodes. The synchronization status field and the target master node field are stored in the shared storage resource 20. The shared storage resource 20 can be any storage resource accessible to all CSG nodes. For example, the shared storage resource 20 can be a storage resource in a shared storage system such as an OSS system. Alternatively, if multiple CSG nodes use a distributed lock service for master election, the shared storage resource 20 can also be a storage resource provided by the node providing the distributed lock service. For details on how the synchronization status field and the target master node field are updated, please refer to the relevant content in the aforementioned storage system embodiment; further details will not be repeated here.

[0107] Based on the synchronization status field and the target master node field, as shown in step 1 of Figure 6, during the master election process, CSG node 30 can query the synchronization status field and the target master node field stored in the storage resource 20 shared by multiple CSG nodes. As shown in step 2.2 of Figure 1, if the value of the synchronization status field is found to be a second identifier representing synchronization, it indicates that the WAL data stored by multiple CSG nodes 30 is synchronized, that is, the data is consistent, and each CSG node can take over the service and continue to provide services. Therefore, it can be determined that the CSG node is qualified to be a successful master node and can perform the master-grabbing operation.

[0108] As shown in step 2.1 of Figure 6, if the value of the synchronization status field is the first identifier indicating asynchronous operation, and the value of the target master node field is its own identifier, it indicates that the CSG node was the master node when the storage system was abnormal. That is, the CSG node is the closest master node, and its WAL (Write-Ahead Log) data is the latest and complete. Therefore, it can be determined that the CSG node is qualified to be a successful master node and can perform a master-grabbing operation. Conversely, as shown in step 2.3 of Figure 6, if the value of the synchronization status field is the first identifier indicating asynchronous operation, and the value of the target master node field is not its own identifier, it indicates that the CSG node was a slave node when the storage system was abnormal. Its WAL data was lost compared to the master node at that time. Therefore, it can be determined that the CSG node is not qualified to be a successful master node and will not perform a master-grabbing operation. In this way, even if an anomaly occurs in the asynchronous state of the master and slave nodes' WALs, during anomaly recovery, the slave node at the time of the anomaly will not be qualified to grab master status and will not become the master node to take over the service. This prevents CSG nodes with incomplete WALs from taking over the service, helping to ensure service reliability.

[0109] In this embodiment, a synchronization status field is added to the storage resources shared by multiple CSG nodes to record the WAL synchronization status of master and slave nodes, and a target master node field is added to record the identifier of the master node closest to the current time. During the master election process, CSG nodes can query the synchronization status field and the target master node field. When the value of the synchronization status field is a first identifier indicating that the WAL of the master and slave nodes is not synchronized, if the value of the target master node field is the value of that CSG node, it means that when the storage system malfunctioned, that CSG node was the master node, and the data stored in its WAL is the latest and complete. Therefore, that CSG node is qualified to become the master node and take over the service. If the service is taken over by that CSG node, the probability of data loss in the storage system can be reduced, or even avoided altogether, ensuring the reliability of the storage system.

[0110] The CSG service system provided in this disclosure maintains good reliability even in a two-node master-slave synchronous replication architecture with two CSG nodes. In this two-CSG node architecture, if one CSG node malfunctions or fails, the individual CSG node can still determine its eligibility to become the master node, i.e., whether it can take over the service, using the methods described above. If the CSG node is qualified to become the master node, it can directly take over the CSG service. Therefore, this disclosure supports single-node service, and even when the CSG service system is a single-node service, it can still be repeatedly restarted to provide the relevant CSG services.

[0111] The master-slave node synchronous replication method provided in the aforementioned embodiments can handle most system anomalies to ensure that data is not lost or misplaced. However, there is still a risk of data loss in some situations. For example, in the event of a master node failure, there may be a risk of data loss, as detailed in Figure 5 above.

[0112] To address this issue, a CommitPoint field is introduced in some embodiments of this disclosure. This field records the log sequence number of the most recent synchronized data between the master and slave nodes, defined as the target log sequence number. In this embodiment, since any CSG node can become the master node, the CommitPoint field can be stored in the shared storage resource 20 of the aforementioned multiple CSG nodes, making it accessible to all CSG nodes.

[0113] In this embodiment, the CSG node, acting as the master node, can monitor synchronization replication success events and / or synchronization state transition events. In response to the detected synchronization replication success events and / or synchronization state transition events, the master node can determine the target log sequence number of the most recent successfully replicated data from its write-ahead log and write or update the target log sequence number to the acknowledgment point field. For specific implementation details regarding the master node's monitoring of synchronization replication success events and synchronization state transition events, please refer to the relevant content in the foregoing embodiments; further details will not be repeated here.

[0114] If the aforementioned master node fails, other CSG nodes can be promoted to the new master node by preempting the master node. In this embodiment of the disclosure, for ease of description and distinction, the original master node is defined as the first master node, and the new master node promoted by the master node through the preemption operation when the first master node fails is defined as the second master node.

[0115] The CSG node, acting as a slave node of the second master node, can determine the target data whose log sequence number is greater than or equal to the aforementioned confirmation point field value from the second master node, and copy the target data to the slave node's write-ahead log. The slave node acting as the second master node can include the aforementioned first master node; that is, after the CSG node acting as the first master node recovers from the anomaly, it can act as a slave node of the second master node, copying the target data whose log sequence number is greater than or equal to the confirmation point field value from the second master node's write-ahead log to its own write-ahead log. In this way, even if the first master node experiences the anomaly shown in Figure 5, it can still copy data with a log sequence number greater than or equal to the target log sequence number from the new master node's write-ahead log, discarding the previously stored data with a log sequence number greater than or equal to the target log sequence number, maintaining data consistency between the master and slave nodes, preventing data errors, and even achieving an RPO of 0.

[0116] Since CSG nodes store data in an LSM-Tree structure, and considering the working principle of the LSM-Tree structure shown in Figure 2, the memory table is continuously flushed to disk. Because the Write-Ahead Log (WAL) records write operations to the memory table, if erroneous data is written to the WAL, the data written to the memory table will also be erroneous. If erroneous data written to the memory table is flushed to disk, causing erroneous data written to the WAL to be flushed to disk, this erroneous data cannot be easily discarded. To prevent erroneous data in the WAL from being flushed to disk, a maximum log sequence number (MaxFlushableSeqno) that can be flushed to the ordered string table (SSTable) is added to the memory table. The master node's memory table can maintain this maximum log sequence number.

[0117] Specifically, in response to a successful replication synchronization event, the master node can write the log sequence number of the data successfully replicated from the slave node into the memory table, using this as the maximum log sequence number that can be flushed to the ordered string table. Further, the master node can flush the data stored in the memory table to the ordered string table (SSTable) if all log sequence numbers of the data stored in the memory table are less than or equal to the aforementioned maximum log sequence number, and if the amount of data stored in the memory table reaches a set data size threshold. This set data size threshold is the size threshold of the memory table that becomes immutable when it reaches a certain size threshold. In this embodiment, since the maximum log sequence number that can be flushed to the ordered string table is dynamically updated based on the log sequence number of the data successfully replicated from the slave node (i.e., the maximum log sequence number is the maximum log sequence number of the data successfully replicated from the slave node), the fact that all log sequence numbers of the data stored in the memory table are less than or equal to the maximum log sequence number that can be flushed to the ordered string table ensures that conflicting erroneous data between the master and slave nodes will not be flushed to disk.

[0118] When the master node recovers from an anomaly and comes back online, it can act as a slave node of the new master node and perform WAL replay. During WAL replay, the value of the acknowledgment point field can be obtained from the storage resource 20 shared by multiple CSG nodes, and data in the slave node's WAL with a log sequence number greater than or equal to the value of the acknowledgment point field can be deleted or skipped.

[0119] When a slave node performs a WAL replay, it can read the data from the WAL. This data is arranged chronologically and may include all changes that were not flushed to the SSTable before the node's failure. The same write operation can be performed on the in-memory table according to the log sequence number, from smallest to largest, to restore the state before the failure. When encountering data with a log sequence number greater than or equal to the acknowledgment point field value, this data is skipped, and no write operation is performed on the in-memory table for that data record. This ensures that erroneous data in the WAL is correctly discarded, and even if the original master node recovers and comes back online as a slave node, the erroneous data will not be flushed to the disk (SSTable).

[0120] In the CSG service system provided in this embodiment, the number of CSG nodes can be two, achieving a minimum two-node deployment. When there are two CSG nodes, the solution provided in the foregoing embodiments can also be used to reduce data loss and ensure the reliability of the storage system. The storage system with two CSG nodes represents a minimum two-node deployment, resulting in lower storage system resource requirements.

[0121] In addition to the storage system and CSG service system provided in the foregoing embodiments, this disclosure also provides a master-grabbing method and a data replication method. The master-grabbing method and data replication method provided in this disclosure are described by way of example below.

[0122] Figure 7 is a flowchart illustrating the master-grabbing method provided in this embodiment. This master-grabbing method is applicable to any one of multiple storage nodes, i. The shared storage resources of the multiple storage nodes store a synchronization status field and a target master node field. The synchronization status field records the synchronization status of the write-ahead logs between the slave node and the master node; the target master node field records the identifier of the master node closest to the current time. The master node and slave nodes among the multiple storage nodes use a synchronous replication method to copy the data stored on the master node to the slave node. As shown in Figure 7, for storage node i, the master-grabbing method mainly includes:

[0123] 701. During the master election process, query the synchronization status field and the target master node field.

[0124] 702. If the value of the synchronization status field is found to be the first identifier indicating non-synchronization, and the value of the target master node field is its own identifier, then the storage node i is determined to be qualified to become the master node, and the master grabbing operation is performed.

[0125] In this embodiment, the master node and slave node employ a synchronous replication method, copying the data stored on the master node to the slave node. Specifically, the master node and slave node can sequentially copy the data stored on the master node to the slave node according to the ascending order of the stored data number. Specifically, when the storage node acts as the master node, it can determine the data to be copied to the slave node from the data stored on the master node; if the slave node successfully copies the data to be copied to the slave node, it is determined that the data to be copied has been successfully written. The storage node, acting as a slave node, can copy the data to be copied from the master node to the slave node. For details on the implementation of the synchronous replication method between the master and slave nodes, please refer to the relevant content of the aforementioned system embodiment, which will not be repeated here.

[0126] To ensure the reliability of the storage system, this embodiment adds a Synchronization State field and a LastMaster field. The Synchronization State field records the synchronization status between the data stored on the slave node (e.g., WAL) and the data stored on the master node (e.g., WAL), specifically whether the data stored on the slave node (e.g., WAL) is synchronized with the data stored on the master node (e.g., WAL). The LastMaster field records the identifier of the master node closest to the current time, i.e., the identifier of the most recent master node.

[0127] To enable multiple storage nodes to access and view the synchronization status field and the target master node field, a shared storage resource is introduced. This shared storage resource stores the synchronization status field and the target master node field.

[0128] In this embodiment, if the slave node successfully replicates data from the master node, the storage node, acting as the master node, can write a synchronization identifier into the synchronization status field. Correspondingly, if the slave node successfully replicates data from the master node, the master node can write a second synchronization identifier (e.g., SYNCED) into the synchronization status field. If the slave node fails to replicate data from the master node, the master node can write a first synchronization identifier (e.g., UNSYNCED) into the synchronization status field.

[0129] For the target master node field, the storage node can write its own identifier into the target master node field if it successfully acquires the master node.

[0130] Based on the synchronization status field and the target master node field, for any storage node, in step 701, during the master election process, the synchronization status field and the target master node field stored in the storage resources shared by multiple storage nodes can be queried. If the value of the synchronization status field is found to be a second identifier representing synchronization, it indicates that the data (such as WAL) stored by multiple storage nodes is synchronized, that is, the data is consistent, and each storage node can take over the service and continue to provide services. Therefore, it can be determined that the storage node is qualified to be a successful master node and can perform the master grabbing operation.

[0131] If the value of the synchronization status field indicates the first identifier of asynchronous operation, and the value of the target master node field is its own identifier, then this storage node was the master node when the storage system was abnormal. In other words, the storage node is the closest master node, and its WAL (Write-Ahead Log) data is up-to-date and complete. Therefore, in step 702, it can be determined that this storage node is qualified to become a successful master node and can perform a master-grabbing operation. Conversely, if the value of the synchronization status field indicates the first identifier of asynchronous operation, and the value of the target master node field is not its own identifier, then this storage node was a slave node when the storage system was abnormal. Its stored data (such as WAL) is lost compared to the master node at that time. Therefore, it can be determined that this storage node is not qualified to become a successful master node and will not perform a master-grabbing operation. In this way, even if an abnormality occurs in the storage system when the data (such as WAL) stored by the master and slave nodes is asynchronous, during recovery, the slave node at the time of the abnormality will not be qualified to become a master node and will not take over the service. This prevents a storage node with incomplete stored data (such as WAL) from taking over the service, thus helping to ensure service reliability.

[0132] In this embodiment, a synchronization status field is added to the storage resources shared by multiple storage nodes to record the synchronization status of data (such as WAL) stored by the master and slave nodes, and a target master node field is added to record the identifier of the master node closest to the current time. During the master election process, storage nodes can query the synchronization status field and the target master node field. When the value of the synchronization status field is a first identifier indicating that the data (such as WAL) stored by the master and slave nodes is out of sync, if the value of the target master node field is the value of that storage node, it means that when the storage system experienced an anomaly, that storage node was the master node, and the data it stored was the latest and complete. Therefore, that storage node is qualified to become the master node and take over the service. If this storage node takes over the service, the probability of data loss in the storage system can be reduced, or even avoided altogether, ensuring the reliability of the storage system.

[0133] The master-slave node synchronous replication method provided in the aforementioned embodiments can handle most system anomalies to ensure data is not lost or corrupted. However, there is still a risk of data loss in some situations. For example, there may be a risk of data loss if the master node fails.

[0134] To address this issue, a CommitPoint field is introduced in some embodiments of this disclosure. In embodiments where multiple storage nodes store data in an LSM-Tree structure, the CommitPoint field is used to record the log sequence number of the most recently synchronized data between the master and slave nodes, defined as the target log sequence number. In this embodiment, since any storage node can become the master node, the CommitPoint field can be stored in a shared storage resource among the aforementioned multiple storage nodes, making it accessible to all storage nodes. Based on the CommitPoint field, embodiments of this disclosure also provide a data replication method. As shown in Figure 8, this data replication method mainly includes the following steps:

[0135] 801. For any storage node i, when acting as the first master node, in response to a successful synchronization replication event or a synchronization state switch event, determine the target log sequence number of the most recently successfully replicated data from the write-ahead log stored on storage node i.

[0136] 802. Write the target log sequence number into the confirmation point field.

[0137] 803. In response to an abnormal recovery event, determine the target data from the second master node whose log sequence number is greater than or equal to the value of the acknowledgment point field; the second master node is one of the other storage nodes besides storage node i, which is promoted to master node in the event of an abnormality of the first master node.

[0138] 804. Copy the target data to the write-ahead log of storage node i.

[0139] In this embodiment, the storage node, acting as the master node, can monitor successful synchronization replication events and / or synchronization state switching events. A synchronization state switching event refers to an event in which the synchronization state of the master and slave nodes changes, such as switching from synchronous to asynchronous, or vice versa.

[0140] Specifically, the master node can determine a successful synchronization replication event when the slave node successfully replicates data from the master node's WAL. Further, in response to the successful synchronization replication event, the master node can determine the target log sequence number of the most recently successfully replicated data from its stored write-ahead log. Specifically, the master node can determine the log sequence number of the currently successfully replicated data from the master node's WAL as the target log sequence number of the most recently successfully replicated data. Further, the master node can write or update the target log sequence number to the acknowledgment point field.

[0141] If the acknowledgment point field is updated every time the slave node successfully replicates the master node's WAL, it increases the I / O pressure on the shared storage resources of multiple storage nodes. Therefore, in some embodiments, to reduce the I / O pressure on the shared storage resources of multiple storage nodes, the acknowledgment point field value may not be updated with each master-slave synchronization replication. For example, the master node can monitor synchronization state switching events. Specifically, the master node can monitor the value of the synchronization state field and, when the value of the synchronization state field switches from a first identifier to a second identifier, determine that a first synchronization state switching event has occurred, transitioning from an asynchronous state to a synchronous state. Further, in response to the first synchronization state switching event, the log sequence number of the data successfully replicated by the slave node in this synchronization can be determined as the target log sequence number of the most recently replicated data. Further, the master node can write or update the target log sequence number to the acknowledgment point field.

[0142] Accordingly, if the master node detects that the value of the synchronization status field has switched from the second identifier to the first identifier, it determines that a second synchronization status switch event has occurred, transitioning from a synchronized state to a desynchronized state. Furthermore, in response to the second synchronization status switch event, the master node can determine the log sequence number of the data from the previous successfully replicated synchronization that failed on the slave node, using this as the target log sequence number of the most recent successfully replicated synchronization. Furthermore, the master node can write or update the target log sequence number to the acknowledgment point field.

[0143] In summary, the master node can respond to the synchronization state transition event by determining the target log sequence number of the most recently successfully replicated data from the write-ahead log stored on the master node, and then write or update the target log sequence number to the acknowledgment point field.

[0144] If the aforementioned primary node fails, other storage nodes can be promoted to the new primary node through a master-preemption operation. In this embodiment of the disclosure, for ease of description and distinction, the original primary node is defined as the first primary node, and the new primary node promoted through a master-preemption operation when the first primary node fails is defined as the second primary node.

[0145] The storage node acting as a slave node of the second master node can determine the target data whose log sequence number is greater than or equal to the aforementioned confirmation point field value from the second master node, and copy the target data to the write-ahead log of the slave node. The slave node acting as the second master node can include the aforementioned first master node; that is, after the storage node acting as the first master node recovers from the anomaly, it can act as a slave node of the second master node, copying the target data whose log sequence number is greater than or equal to the confirmation point field value from the second master node's write-ahead log to its own write-ahead log. In this way, even if the first master node experiences the anomaly shown in Figure 5, it can copy data with a log sequence number greater than or equal to the target log sequence number from the new master node's write-ahead log, discarding the previously stored data with a log sequence number greater than or equal to the target log sequence number, maintaining data consistency between the master and slave nodes, preventing data errors, and even achieving an RPO of 0.

[0146] Since the storage nodes store data in an LSM-Tree structure, and based on the working principle of the LSM-Tree structure shown in Figure 2, the memory table is continuously flushed to the disk. Because the Write-Ahead Log (WAL) records the operations written to the memory table, if erroneous data is written to the WAL, the data written to the memory table will also be erroneous. If erroneous data written to the memory table is flushed to the disk, causing potentially erroneous data written to the WAL to be flushed to the disk, this erroneous data cannot be easily discarded.

[0147] To prevent erroneous data in the WAL from being flushed to disk, a maximum log sequence number (MaxFlushableSeqno) that can be flushed to the ordered string table (SSTable) is added to the in-memory table. The master node's in-memory table maintains this maximum log sequence number.

[0148] Specifically, when any storage node acts as the master node, in response to a successful synchronization replication event, it can write the log sequence number of the data currently successfully replicated from the slave node as the maximum log sequence number that can be flushed to the ordered string table and write it into the memory table. Further, if the log sequence numbers of all data stored in the memory table are less than or equal to the aforementioned maximum log sequence number, and the amount of data stored in the memory table reaches a set data volume threshold, the data stored in the memory table can be flushed to the ordered string table (SSTable). The set data volume threshold here is the size threshold of the memory table that becomes immutable when it reaches a certain size threshold. In this embodiment, since the maximum log sequence number that can be flushed to the ordered string table is dynamically updated based on the log sequence number of the data successfully replicated from the slave node (i.e., the maximum log sequence number is the maximum log sequence number successfully replicated from the slave node), the fact that the log sequence numbers of all data stored in the memory table are less than or equal to the maximum log sequence number that can be flushed to the ordered string table ensures that conflicting erroneous data between the master and slave nodes will not be flushed to disk.

[0149] When the master node recovers from an anomaly and comes back online, it can act as a slave node of the new master node and perform WAL replay. During WAL replay, the value of the acknowledgment point field can be obtained from the storage resources shared by multiple storage nodes, and data in the slave node's WAL with a log sequence number greater than or equal to the value of the acknowledgment point field can be deleted or skipped.

[0150] When a slave node performs a WAL replay, it can read the data from the WAL. This data is arranged chronologically and may include all changes that were not flushed to the SSTable before the node's failure. The same write operation can be performed on the in-memory table according to the log sequence number, from smallest to largest, to restore the state before the failure. When encountering data with a log sequence number greater than or equal to the acknowledgment point field value, this data is skipped, and no write operation is performed on the in-memory table for that data record. This ensures that erroneous data in the WAL is correctly discarded, and even if the original master node recovers and comes back online as a slave node, the erroneous data will not be flushed to the disk (SSTable).

[0151] In the storage system provided in this embodiment, the number of storage nodes can be two, achieving a minimum two-node deployment. When there are two storage nodes, the solution provided in the foregoing embodiments can also be used to reduce data loss and ensure the reliability of the storage system. The two-node storage system represents a minimum two-node deployment, resulting in lower storage system resource requirements.

[0152] It is worth noting that the master-grabbing method and data replication method provided in this disclosure can also be applied to CSG nodes in a CSG service system. The CSG service system includes multiple CSG nodes. The shared storage resources of the multiple CSG nodes store a synchronization status field and a target master node field. The multiple CSG nodes use a log structure merged tree (LSM-Tree) structure to store the metadata of the CSG service system. In the CSG service system, the CSG node is implemented as the aforementioned storage node. For specific implementation methods of master-grabbing and data replication by CSG nodes, please refer to the relevant content on master-grabbing and data replication by storage nodes, which will not be repeated here.

[0153] It should be noted that the execution subject of each step of the method provided in the above embodiments can be the same device, or the method can be executed by different devices. For example, the execution subject of steps 701 and 702 can be device A; or the execution subject of step 701 can be device A, and the execution subject of step 702 can be device B; and so on.

[0154] Furthermore, some processes described in the above embodiments and accompanying drawings include multiple operations that appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The operation numbers, such as 701, 702, etc., are merely used to distinguish different operations and do not represent any execution order. In addition, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel.

[0155] Accordingly, embodiments of this disclosure also provide a computer-readable storage medium storing computer instructions, which, when executed by one or more processors, cause one or more processors to perform the steps in the above-described master-preemption method and / or data copying method.

[0156] This disclosure also provides a computer program product, including a computer program that, when executed by one or more processors, causes the one or more processors to perform the steps in the above-described master-snatching method and / or data copying method. In this disclosure, the specific implementation of the computer program product is not limited. In some embodiments, the computer program product may be implemented as an application (APP), a mini-program, a PC-side client, a program module, a plug-in, an installation package, a software development kit (SDK), an optical disc image file (such as an ISO file), a plug-in, or software in the form of Software as a Service (SaaS), etc., but is not limited thereto.

[0157] Figure 9 is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. As shown in Figure 9, the electronic device includes a memory 90a and a processor 90b. The memory 90a is used to store computer programs.

[0158] The processor 90b is coupled to the memory 90a and is used to execute computer programs to perform the steps in the master-preemption method and / or data copying method provided in the foregoing embodiments. Specific implementation details of each step can be found in the relevant descriptions of the foregoing embodiments, and will not be repeated here.

[0159] In some alternative embodiments, as shown in FIG9, the electronic device may further include optional components such as a communication component 90c, a power supply component 90d, a display component 90e, and an audio component 90f. FIG9 only schematically shows some components and does not mean that the electronic device must include all the components shown in FIG9, nor does it mean that the electronic device can only include the components shown in FIG9.

[0160] Furthermore, the components within the dashed boxes in Figure 9 are optional, not mandatory, and their specific requirements depend on the product form of the electronic device. The electronic device in this embodiment can be a desktop computer, laptop computer, mobile phone, or IoT device; it can also be a traditional server, cloud server, or server cluster, or other server equipment.

[0161] In embodiments of this disclosure, the memory is used to store computer programs and can be configured to store various other data to support operation on its host device. The processor can execute the computer programs stored in the memory to implement corresponding control logic. The memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Electrically Programmable Read Only Memory (EPROM), Programmable Read Only Memory (PROM), Read Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0162] In this embodiment of the disclosure, the processor can be any hardware processing device capable of executing the above-described method logic. Optionally, the processor can be a central processing unit (CPU), a graphics processing unit (GPU), or a microcontroller unit (MCU); it can also be a programmable device such as a field-programmable gate array (FPGA), a programmable array logic (PAL), a general array logic (GAL), or a complex programmable logic device (CPLD); or it can be an advanced RISC machine (ARM) or a system on chip (SoC), etc., but is not limited thereto.

[0163] In embodiments of this disclosure, the communication component is configured to facilitate wired or wireless communication between its host device and other devices. The device housing the communication component can access wireless networks based on communication standards, such as Wireless Fidelity (WiFi), 2G or 3G, 4G, 5G, or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In another exemplary embodiment, the communication component may also be implemented based on Near Field Communication (NFC), Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Ultra Wide Band (UWB), Bluetooth (BT), or other technologies.

[0164] In embodiments of this disclosure, the display component may include a liquid crystal display (LCD) and a touch panel (TP). If the display component includes a touch panel, the display component may be implemented as a touchscreen to receive input signals from a user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors may sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation.

[0165] In embodiments of this disclosure, a power supply component is configured to provide power to various components of the device in which it resides. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which the power supply component resides.

[0166] In embodiments of this disclosure, the audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals can be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals. For example, in devices with voice interaction capabilities, voice interaction with a user can be achieved through the audio component.

[0167] It should be noted that the terms "first" and "second" in this article are used to distinguish different messages, devices, modules, etc., and do not represent a chronological order, nor do they limit "first" and "second" to different types.

[0168] Those skilled in the art will understand that embodiments of this disclosure can be provided as methods, systems, or computer program products. Therefore, this disclosure can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this disclosure can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, compact disc read-only memory (CD-ROM), optical storage, etc.) containing computer-usable program code.

[0169] This disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more flowchart illustrations and / or one or more block diagrams.

[0170] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0171] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0172] In a typical configuration, a computing device includes one or more processors (CPU, etc.), input / output interfaces, network interfaces, and memory.

[0173] Memory may include non-persistent storage in computer-readable media, such as random-access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0174] Computer storage media are readable storage media, also known as removable media. Removable and non-removable media can be used to store information by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, Digital Video Disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient media, such as modulated data signals and carrier waves.

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

[0176] The above description is merely an embodiment of this disclosure and is not intended to limit the scope of this disclosure. Various modifications and variations can be made to this disclosure by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the scope of the claims of this disclosure.

Claims

1. A storage system, wherein, include: Multiple storage nodes; The master node and the slave node in the plurality of storage nodes use a synchronous replication method to copy the data stored in the master node to the slave node; The shared storage resources of the multiple storage nodes store a synchronization status field and a target master node field. The synchronization status field is used to record the synchronization status between the data stored by the slave node and the data stored by the master node. The target master node field is used to record the identifier of the master node closest to the current time. If, during the master election process, the value of the synchronization status field is found to be a first identifier indicating asynchronous behavior, and the value of the target master node field is its own identifier, then the storage node will perform a master-grabbing operation.

2. The system according to claim 1, wherein, Each of the storage nodes is also used for: If the value of the synchronization status field is the first identifier and the value of the target master node field is not its own identifier, then it is determined that any of the storage nodes is not qualified to become a master node, and no master grabbing operation is performed. or, If the value of the synchronization status field is found to be a second identifier representing synchronization, then it is determined that any of the storage nodes is qualified to become the master node, and a master grabbing operation is performed.

3. The system according to claim 1 or 2, wherein, The multiple storage nodes use a log structure merged into a tree structure to store data; the storage node acting as the first master node is used for: In response to a successful synchronization replication event or a synchronization state switching event, the target log sequence number of the most recent successfully replicated data is determined from the write-ahead log stored in the first master node, and the target log sequence number is written into the confirmation point field stored in the shared storage resource. The storage node, which serves as a slave node to the first master node, is also used to: perform a master-preemption operation in the event of an anomaly in the first master node, so as to be promoted to the second master node; As a storage node that is a slave node of the second master node, it is also used to: copy target data with a log sequence number greater than or equal to the value of the confirmation point field from the write-ahead log of the second master node to the write-ahead log of the slave node of the second master node.

4. The system according to any one of claims 1-3, wherein, The multiple storage nodes use a log structure merged into a tree structure to store data; the master node's memory table maintains the maximum log sequence number that has been refreshed into the ordered string table; The master node is configured to: in response to a successful synchronization replication event, write the log sequence number of the data currently successfully synchronized and replicated by the slave node as the maximum log sequence number into the memory table; If the log sequence numbers of the data stored in the memory table are all less than or equal to the maximum log sequence number, and the amount of data stored in the memory table reaches the set data amount threshold, the data stored in the memory table will be refreshed to the ordered string table.

5. The system according to any one of claims 1-4, wherein, The storage system is a cloud storage gateway service system, and the multiple storage nodes are multiple cloud storage gateway nodes; the multiple cloud storage gateway nodes use a log structure merged tree structure to store the metadata of the cloud storage gateway service system.

6. A master-preemption method applicable to any one of multiple storage nodes, wherein, The shared storage resources of the multiple storage nodes store a synchronization status field and a target master node field. The synchronization status field is used to record the synchronization status between the data stored by the slave nodes and the data stored by the master node. The target master node field is used to record the identifier of the master node closest to the current time; The master node and the slave node in the plurality of storage nodes use a synchronous replication method to copy the data stored in the master node to the slave node; The method includes: During the master election process, the synchronization status field and the target master node field are queried; If the value of the synchronization status field is found to be a first identifier indicating non-synchronization, and the value of the target master node field is its own identifier, then a master-grabbing operation is performed.

7. The method according to claim 6, wherein, Also includes: If the value of the synchronization status field is the first identifier and the value of the target master node field is not its own identifier, then it is determined that any of the storage nodes is not qualified to become a master node, and no master grabbing operation is performed. or, If the value of the synchronization status field is found to be a second identifier representing synchronization, then it is determined that any of the storage nodes is qualified to become the master node, and a master grabbing operation is performed.

8. The method according to claim 6 or 7, wherein, Also includes: When acting as a master node, its own identifier is written into the target master node field; If the slave node successfully replicates data from the master node, a second identifier representing synchronization is written to the synchronization status field; or, if the slave node fails to replicate data from the master node, the first identifier is written to the synchronization status field.

9. The method according to claim 7 or 8, wherein, The multiple storage nodes use a log structure merged into a tree structure to store data; the method further includes: When any of the storage nodes acts as the first master node, in response to a successful synchronization replication event or a synchronization state switching event, the target log sequence number of the most recently successfully replicated data is determined from the write-ahead log stored on any of the storage nodes. Write the target log sequence number into the confirmation point field stored in the shared storage resource; In response to an abnormal recovery event, target data with a log sequence number greater than or equal to the value of the confirmation point field is determined from the second master node; the second master node is any other storage node among the plurality of storage nodes except for any of the storage nodes, and is promoted to master node in the event of an abnormality of the first master node; The target data is copied to the write-ahead log of any of the storage nodes.

10. The method according to claim 9, wherein, When any of the storage nodes acts as the first master node, in response to a successful synchronization replication event or a synchronization state transition event, the target log sequence number of the most recently successfully replicated data is determined from the write-ahead log stored on any of the storage nodes, including: If the slave node of the first master node successfully replicates data from the first master node, a synchronization replication success event is determined to have occurred, and in response to the synchronization replication success event, the log sequence number of the data currently successfully replicated by the slave node of the first master node is determined as the target log sequence number; or, If the value of the synchronization status field changes from the first identifier to the second identifier, a first synchronization status switch event is determined to have occurred, and in response to the first synchronization status switch event, the log sequence number of the data successfully replicated by the slave node of the first master node is determined as the target log sequence number. or, If the value of the synchronization status field changes from the second identifier to the first identifier, a second synchronization status switch event is determined to have occurred, switching from the synchronization state to the asynchronous state. In response to the second synchronization status switch event, the log sequence number of the data from the previous successful synchronization replication of the slave node of the first master node that failed to replicate this time is determined as the target log sequence number.

11. The method according to any one of claims 6-10, wherein, The multiple storage nodes use a log structure to merge a tree structure to store data; The master node's memory table maintains the maximum log sequence number that can be stored in an ordered string table; The method further includes: When acting as the master node, in response to a successful synchronization replication event, the log sequence number of the data that has been successfully synchronized and replicated by the slave node is used as the maximum log sequence number and written into the memory table. If the log sequence numbers of the data stored in the memory table are all less than or equal to the maximum log sequence number, and the amount of data stored in the memory table reaches the set data amount threshold, the data stored in the memory table will be stored in the ordered string table.

12. The method according to any one of claims 6-11, wherein, The multiple storage nodes are multiple cloud storage gateway nodes, and the metadata of the cloud storage gateway service system is stored using a log structure merged tree structure.

13. A data replication method applicable to any one of multiple storage nodes, wherein, The multiple storage nodes use a log structure merged into a tree structure to store data; the storage resources shared by the multiple storage nodes store an acknowledgment point field; The master node and the slave node in the plurality of storage nodes use a synchronous replication method to copy the write-ahead log stored in the master node to the slave node; The method includes: When any of the storage nodes acts as the first master node, in response to a successful synchronization replication event or a synchronization state switching event, the target log sequence number of the most recently successfully replicated data is determined from the write-ahead log stored on any of the storage nodes. Write the target log sequence number into the confirmation point field; In response to an abnormal recovery event, target data with a log sequence number greater than or equal to the value of the confirmation point field is determined from the second master node; the second master node is any other storage node among the plurality of storage nodes except for any of the storage nodes, and is promoted to master node in the event of an abnormality of the first master node; The target data is copied to the write-ahead log of any of the storage nodes.

14. An electronic device, wherein, include: A memory and a processor; wherein the memory is used to store computer programs; The processor is coupled to the memory for executing the computer program to perform the steps of the method according to any one of claims 6-13.

15. A computer-readable storage medium storing computer instructions, wherein, When the computer instructions are executed by one or more processors, the one or more processors are caused to perform the steps of the method according to any one of claims 6-13.

16. A computer program product, wherein, Includes a computer program that, when executed by one or more processors, causes the one or more processors to perform the steps of the method according to any one of claims 6-13.

Images