Storage system, preempting and data copying method and device, medium and program product

Abstract

The embodiment of the invention provides a storage system, a robbing method, a data copying method, equipment, a medium and a program product. Wherein in a storage resource shared by a plurality of storage nodes, a synchronization state field for recording the synchronization state of data stored in the master and slave nodes and a target master node field for recording the identifier of the master node closest to the current time are added, and the synchronization state field and the target master node field are queried in the master selection process of the storage nodes. When the value of the synchronization state field is the first identifier representing that the data of the master node and the data of the slave node are not synchronized, if the value of the target master node field is the value of the storage node, it is indicated that the storage node is the master node when the storage system is abnormal, and the stored data are newest and complete, so that the storage efficiency is improved. The storage node has the qualification of becoming the main node to take over the service, the probability of data loss of the storage system can be reduced, even the data loss of the storage system can be avoided, and the reliability of the storage system is ensured.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data storage, and particularly relates to a storage system, a master stealing method and a data replication method, equipment, a medium and a program product. BACKGROUND

[0002] With the development of cloud computing and big data technology, distributed storage systems have been widely used in various industries due to their high scalability and high availability. In a distributed storage system, data is usually replicated to multiple storage nodes to improve the reliability and availability of data. These nodes can be divided into two categories: master nodes (Master) and slave nodes (Slave). The master node is responsible for receiving write requests and responding to write requests, and the slave node maintains the consistency of the data between the master and slave nodes by replicating the data of the master node.

[0003] In order to ensure the high availability of storage services, the data stored in multiple storage nodes must also be highly available. If an abnormality occurs in one of the storage nodes, the new master node needs to be able to obtain complete data to ensure the reliability of the storage service. SUMMARY

[0004] Aspects of the present application provide a storage system, a master stealing method and a data replication method, equipment, a medium and a program product to reduce the probability of data loss.

[0005] The present application provides a storage system, comprising: a plurality of storage nodes;

[0006] The master node in the plurality of storage nodes and the slave node in the plurality of storage nodes replicate the data stored by the master node to the slave node in a synchronous replication manner;

[0007] The storage resource shared by the plurality of storage nodes stores a synchronization state field and a target master node field, which are used to record the synchronization state of 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 identification of the master node closest to the current time;

[0008] For any storage node in the master selection process, if the value of the synchronization state field is queried to be a first identification representing non-synchronization, and the value of the target master node field is the identification of itself, a master stealing operation is performed.

[0009] Optionally, the any storage node is further configured to:

[0010] If the value of the synchronization state field is queried to be the first identification, and the value of the target master node field is not the identification of itself, it is determined that the any storage node does not have the qualification to become a master node, and the master stealing operation is not performed;

[0011] Alternatively,

[0012] If the value of the synchronization state field is the second identifier representing synchronization, it is determined that the any storage node has the qualification to become the master node, and a master node capture operation is performed.

[0013] Optionally, the storage system is a cloud storage gateway service system, and the plurality of storage nodes are a plurality of cloud storage gateway nodes; the plurality of cloud storage gateway nodes store metadata of the cloud storage gateway service system using the log-structured merge tree structure.

[0014] Embodiments of the present application also provide a master node capture method, applicable to any storage node in a plurality of storage nodes, a storage resource shared by the plurality of storage nodes storing a synchronization state field and a target master node field, for recording a synchronization state of data stored by a slave node in the plurality of storage nodes and data stored by a master node; the target master node field is used to record an identifier of a master node closest to a current time; the master node in the plurality of storage nodes and the slave node in the plurality of storage nodes copy the data stored by the master node to the slave node in a synchronous replication manner.

[0015] The method comprises:

[0016] In a master node selection process, the synchronization state field and the target master node field are queried.

[0017] If the value of the synchronization state field is the first identifier representing non-synchronization, and the value of the target master node field is an identifier of the any storage node, it is determined that the any storage node has the qualification to become the master node, and a master node capture operation is performed.

[0018] Optionally, the master node capture method further comprises: if the value of the synchronization state field is the first identifier, and the value of the target master node field is not the identifier of the any storage node, it is determined that the any storage node does not have the qualification to become the master node, and a master node capture operation is not performed.

[0019] Alternatively,

[0020] If the value of the synchronization state field is the second identifier representing synchronization, it is determined that the any storage node has the qualification to become the master node, and a master node capture operation is performed.

[0021] Embodiments of the present application also provide a data replication method, applicable to any storage node in a plurality of storage nodes, the plurality of storage nodes storing data using a log-structured merge tree structure; a storage resource shared by the plurality of storage nodes storing a checkpoint field; a master node in the plurality of storage nodes and a slave node in the plurality of storage nodes copying prewrite logs stored by the master node to the slave node in a synchronous replication manner.

[0022] The method comprises:

[0023] In response to a synchronous replication success event or a synchronous state switching event, when the any storage node is the first master node, determining a target log sequence number of the data that is successfully replicated synchronously and closest to the current time from the pre-write log stored in the any storage node;

[0024] writing the target log sequence number into the confirmation point field;

[0025] In response to an abnormal recovery event, determining target data with a log sequence number greater than or equal to the value of the confirmation point field from a second master node; the second master node is another storage node in the plurality of storage nodes except the any storage node, and is the master node upgraded in the case of abnormality of the first master node;

[0026] copying the target data into the pre-write log of the any storage node.

[0027] Embodiments of the present application also provide an electronic device, comprising a memory and a processor; wherein the memory is configured to store a computer program;

[0028] The processor is coupled to the memory and is configured to execute the computer program to perform the steps in the preceding master stealing method and / or data replication method.

[0029] Embodiments of the present application also provide a computer readable storage medium storing computer instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps in the preceding master stealing method and / or data replication method.

[0030] Embodiments of the present application also provide a computer program product comprising a computer program, which, when executed by one or more processors, cause the one or more processors to perform the steps in the preceding master stealing method and / or data replication method.

[0031] In the storage resource shared by the plurality of storage nodes, a synchronization state field for recording the synchronization state of the stored data of the master and slave nodes is added, and a target master node field for recording the identification of the master node closest to the current time is added. In the master selection process, the storage node can query the synchronization state field and the target master node field. When the value of the synchronization state field is a first identification representing that the data of the master and slave nodes is not synchronized, and 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 saved by the storage node is the latest and complete data. Therefore, the storage node has the qualification to become the master node to take over the service, which can reduce the probability of data loss of the storage system, and even avoid the data loss of the storage system, and ensure the reliability of the storage system. BRIEF DESCRIPTION OF DRAWINGS

[0032] The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiments of the application and serve to explain the principles of the application. In the drawings:

[0033] Figure 1 A structural schematic diagram of a storage system provided by an embodiment of the application is shown in the figure;

[0034] Figure 2 A structural schematic diagram of an LSM-Tree provided by an embodiment of the application is shown in the figure;

[0035] Figure 3 And Figure 4 A process schematic diagram of master-slave node synchronization and data replication provided by an embodiment of the application is shown in the figure;

[0036] Figure 5 A process schematic diagram of master node abnormality leading to data error provided by an embodiment of the application is shown in the figure;

[0037] Figure 6 A structural schematic diagram of a CSG service system provided by an embodiment of the application is shown in the figure;

[0038] Figure 7 A flowchart of a master seizing method provided by an embodiment of the application is shown in the figure;

[0039] Figure 8 A flowchart of a data replication method provided by an embodiment of the application is shown in the figure;

[0040] Figure 9 A structural schematic diagram of an electronic device provided by an embodiment of the application is shown in the figure. DETAILED DESCRIPTION

[0041] In order to make the purposes, technical solutions and advantages of the present application clearer, the technical solutions of the present application will be described in detail below with reference to the embodiments of the present application and the corresponding drawings. Obviously, the described embodiments are only some of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of protection of the present application.

[0042] It should be noted that the user information (including but not limited to user equipment information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the present application are all information and data authorized by the user or authorized by all parties, and the collection, use and processing of related data need to comply with relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation portal for user to choose authorization or refusal.

[0043] In some conventional systems, a master-slave synchronization replication scheme of incremental replication plus periodic backup is adopted, and the newly added data in the master database (DB) is simultaneously replicated to multiple slave DBs to increase the number of DBs that can be used as master DBs during recovery of the storage system. This scheme can reduce the risk of data loss by increasing redundancy. However, if the storage system abnormally occurs before the newly added data in the master DB is replicated to the slave DB, the data in the slave DB and the master DB is inconsistent. After the storage system is recovered abnormally, if the slave DB successfully takes over the master, the data in the slave DB is incomplete, resulting in data loss.

[0044] In some embodiments of the present application, a synchronization state field for recording the synchronization state of the data stored by the master and slave nodes, and a target master node field for recording the identification of the master node closest to the current time are added in the storage resource shared by multiple storage nodes, and the storage nodes can query the synchronization state field and the target master node field during the master selection process. When the value of the synchronization state field is a first identification representing that the data stored by the master and slave nodes is not synchronized, and 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 abnormally occurs, and the data saved by the storage node is the latest and complete, therefore, the storage node has the qualification to become the master node to take over the service, which can reduce the probability of data loss of the storage system, and even avoid the data loss of the storage system, and ensure the reliability of the storage system.

[0045] The technical solutions provided by the embodiments of the present application will be described in detail below with reference to the accompanying drawings.

[0046] 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.

[0047] Figure 1 This is a schematic diagram of the structure of a storage system provided in an embodiment of this application. Figure 1 As shown, the storage system includes: multiple storage nodes 10. "Multiple" means two or more. Figure 1 The diagram only shows two storage nodes. Storage node 10 refers to any device, apparatus, or cloud server that has storage space and performs data storage. Storage node 10 has independent storage resources, which are not shared with other storage nodes.

[0048] 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.

[0049] 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. For example, the leader 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. The leader maintains its holding of the distributed lock until it completes its work, encounters an exception, or the lease expires.

[0050] 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, ...

[0051] For example, in some embodiments, storage node 10 uses a Log-Structure-MergeTree (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.

[0052] like Figure 2 As shown, 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.

[0053] 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.

[0054] 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.

[0055] 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 will be generated, and these files need to be merged periodically to reduce disk fragmentation. Figure 2 As shown, 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 items in the process. Once data is flushed to the SSTable, it can be garbage collected (GC) in the WAL.

[0056] 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.

[0057] 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.

[0058] 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.

[0059] Specifically, such as Figure 3 and Figure 4As shown, the master node can determine the data to be replicated to the slave node from the stored WAL (Write-Ahead Log). 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... Figure 3 and Figure 4 As shown, in response to a write request, the master node writes the data to be written to the write-ahead log (WAL) stored on 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 master node's WAL. For example, the maximum existing log sequence number in the master node's WAL can be increased by 1 to serve as the log sequence number for the data to be written.

[0060] 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.

[0061] 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.

[0062] In some embodiments, such as Figure 3 As shown, the master node can proactively send data to be replicated to the slave nodes. Correspondingly, when the master node determines that the amount of data in its current WAL (Write-Ahead Log) that has not been replicated to the slave nodes has reached a preset data volume threshold, it can identify this unreplicated data from its own WAL, designate it as the data to be replicated, and send it 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.

[0063] Specifically, such as Figure 3As shown, the replication thread on 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 checks 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, then... Figure 3 If the result of the initial judgment is negative, then continue waiting for new data to be written to the local WAL and continue timing the waiting period. If the amount of data in the current WAL that has not been copied to the slave node reaches (greater than or equal to) a preset data amount threshold, and / or the waiting period reaches a set duration threshold (i.e., ... Figure 3 If the judgment result is yes, the master node determines the data that has not been copied to the slave node from the current WAL as the data to be copied. Specifically, if the amount of data not copied 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 copied to the slave node in the current WAL as the data to be copied. If the amount of data not copied 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 (or is less than) or has reached the set time threshold, the master node determines the data corresponding to the starting log number to the ending log number from the locally stored WAL in ascending order of log sequence number as the data to be copied. The amount of data corresponding to the starting log number to the ending log number is the preset data volume threshold. In other embodiments, the slave node pulls data from the master node. Specifically, as shown... Figure 4 As shown, during data replication, the slave node can start the replication engine and use it to send replication requests 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 increment the maximum log sequence number of its locally stored WAL by 1 as the starting log sequence number of the data to be replicated. The master node receives the replication request, responds to it, and determines data from its locally stored WAL whose log sequence number is greater than or equal to the starting log sequence number as the data to be replicated. If the amount of data whose log sequence number is greater than or equal to the starting log sequence number is greater than or equal to a preset data volume threshold, then the master node determines the data from the locally stored WAL, from the starting log sequence number to the ending log sequence number, in ascending order, as the data to be replicated. The amount of data from the starting log sequence number to the ending log sequence number is the preset data volume threshold. Furthermore, the master node can send the data to be replicated to the slave node in batches. For example, the master node can send the data to be replicated to the slave node all at once.

[0064] 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.

[0065] Afterwards, the master node can wait for the slave node to copy the data to be replicated to the slave node's WAL (Write-Ahead Log). If the slave node successfully copies the data to its WAL, the master node considers the data write to have failed. If the slave node fails to replicate, the master node considers the data write to have failed. For example, if the master node does not receive a replication success message from the slave node within a set time period, it can determine that the slave node failed to replicate the data, i.e., replication timeout caused the replication failure. If the slave node fails to replicate the data, the master node can consider the data write to have failed and block all I / O operations. Figure 3 The illustrated embodiment shows the master node actively sending the data to be replicated to the slave node. In the event that the slave node fails to replicate the data, the replication thread can also notify the write thread of the replication failure.

[0066] In this embodiment, 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.

[0067] 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.

[0068] 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 the embodiments of this application, such as... Figure 1As shown, a Synchronization State (SyncState) field and a Target Master (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 (e.g., WAL) on the master and slave nodes are synchronized, i.e., identical. Dissynchronization means the data (e.g., WAL) stored on the slave node is not synchronized with the data (e.g., WAL) stored on the master node, i.e., different. In this embodiment, the synchronization status between the data (e.g., WAL) on the slave node and the data (e.g., WAL) on the master node can be represented using an identifier indicating synchronization and an identifier indicating dissynchronization. In this embodiment, for ease of description and distinction, the identifier indicating dissynchronization 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 field records the identifier of the master node closest to the current time, i.e., the identifier of the latest master node.

[0069] To enable multiple storage nodes 10 to access and view the synchronization status field and the target master node field, such as Figure 1 As shown in the embodiment of this application, a shared storage resource 20 is introduced among 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 a synchronization status field and a target master node field. The shared storage resource 20 can be any storage resource accessible to all the 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.

[0070] 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... Figure 3 and Figure 4 As shown, the master node can update the synchronization status field if the replication of the data to be replicated times out, that is, write the first identifier indicating non-synchronization (such as UNSYNCED) into the synchronization status field.

[0071] 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.

[0072] Based on the synchronization status field and the target master node field, such as Figure 1 As shown in step 1, during the master election process, storage node 10 can query the synchronization status field and the target master node field of the storage resource 20 shared by multiple storage nodes. For example... Figure 1 As shown in step 2.2, if the value of the synchronization status field is the second identifier representing synchronization, it means that the data (such as WAL) stored by multiple storage nodes 10 are 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 takeover operation.

[0073] like Figure 1 As shown in step 2.1, if the value of the synchronization status field is the first identifier representing asynchronous operation, and the value of the target master node field is its own identifier, then it indicates that storage node 10 is the master node when the storage system is abnormal. That is, storage node 10 is the closest master node, and the data it stores 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 a master-grabbing operation. Accordingly, as... Figure 1 As shown in step 2.3, if the value of the synchronization status field is the first identifier representing asynchronous operation, and the value of the target master node field is not its own identifier, it indicates that the storage node was a slave node when the storage system experienced an anomaly. The data stored on this slave node was lost compared to the master node at that time. Therefore, it can be determined that this storage node does not qualify to become a successful master node and will not perform a master takeover operation. In this way, even if an anomaly occurs in the storage system while the master and slave nodes are in an asynchronous state, the slave node at the time of the anomaly will not be eligible to take over the master during recovery 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, thus helping to ensure service reliability.

[0074] 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.

[0075] The storage system provided in this application embodiment 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 application embodiment 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.

[0076] 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, data loss risks still exist in some situations. For example, data loss may occur if the master node fails. Specifically, as... Figure 5 As shown, 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 copied to the slave node. At this time, the master node (node ​​1) encountered an error, and from the perspective of the write request, the write of data C was unsuccessful.

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

[0078] 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.

[0079] 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.

[0080] To address this issue, a CommitPoint field is introduced in some embodiments of this application. 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.

[0081] 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.

[0082] 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.

[0083] 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.

[0084] 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.

[0085] 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.

[0086] 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, 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.

[0087] As a slave node of the second master node, the storage node can determine the target data with a log sequence number greater than or equal to the aforementioned acknowledgment point field value from the second master node, and copy the target data to the slave node's write-ahead log. The slave node of the second master node may 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 with a log sequence number greater than or equal to the acknowledgment point field value from the second master node's write-ahead log to its write-ahead log. Thus, even if the first master node experiences an anomaly... Figure 5 The anomaly shown can also be addressed by copying 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, while discarding the previously stored data with a log sequence number greater than or equal to the target log sequence number. This maintains data consistency between the master and slave nodes, prevents data errors, and can even make the Recovery Point Objective (RPO) zero. RPO mainly refers to the amount of data loss that a storage system can afford.

[0088] For example, in the aforementioned Figure 5In the illustrated master node anomaly scenario, 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.

[0089] 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.

[0090] In the embodiment where storage node 10 stores data in an LSM-Tree structure, since storage node 10 stores data in an LSM-Tree structure, in conjunction with the aforementioned... Figure 2 The LSM-Tree structure illustrates how it works: 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 has been successfully written to the SSTable file, the corresponding WAL can be cleaned up.

[0091] In storage engines based on the LSM-Tree architecture, the in-memory table is continuously flushed to disk. Since the Write-Ahead Log (WAL) records write operations to the in-memory table, if erroneous data is written to the WAL, the data written to the in-memory table will also be erroneous. If erroneous data written to the in-memory table is flushed to disk, causing erroneous data written to the WAL to also be flushed to disk, then this erroneous data cannot be easily discarded. For example, as mentioned above... Figure 5 In the master node scenario shown, 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 will cause the erroneous data (the data with log sequence number 3) to be flushed to the disk of node 1.

[0092] 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.

[0093] 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.

[0094] For example, regarding the aforementioned Figure 5 In the illustrated master node exception scenario, 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, into the memory 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 (log sequence number 3) from nodes 1 and 2 to disk.

[0095] 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.

[0096] 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).

[0097] 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 aforementioned 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.

[0098] It is worth noting that the storage system provided in this application embodiment 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 section combines... Figure 6 An example is given to illustrate how the aforementioned approach can be used to ensure the reliability of the CGS system.

[0099] like Figure 6 As shown, 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).

[0100] 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.

[0101] 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.

[0102] 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.

[0103] 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.

[0104] To ensure the reliability of the CSG service system, such as Figure 6 As shown, a Synchronization State (SyncState) field and a LastMaster (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.

[0105] To enable multiple CSG nodes 30 to access and view the synchronization status field and the target master node field, such as Figure 6As shown in the embodiment of this application, a shared storage resource 20 is introduced for multiple CSG nodes. The synchronization status field and the target master node field are stored in the shared storage resource 20 for multiple CSG nodes. The shared storage resource 20 can be any storage resource accessible to multiple CSG nodes. For example, the shared storage resource 20 for multiple CSG nodes 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 to elect a master, the shared storage resource 20 can also be a storage resource provided by the node providing the distributed lock service. For details on the update methods of the synchronization status field and the target master node field, please refer to the relevant content of the aforementioned storage system embodiment, which will not be repeated here.

[0106] Based on the synchronization status field and the target master node field, such as Figure 6 As shown in step 1, during the master election process, CSG node 30 can query the synchronization status field and the target master node field stored in the shared storage resource 20 of multiple CSG nodes. For example... Figure 1 As shown in step 2.2, if the value of the synchronization status field is the second identifier representing synchronization, it means 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 takeover operation.

[0107] like Figure 6 As shown in step 2.1, if the value of the synchronization status field is the first identifier representing asynchronous behavior, and the value of the target master node field is its own identifier, then 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 storage data is the latest and complete. Therefore, it can be determined that the CSG node is qualified to become a successful master node and can perform a master-grabbing operation. Accordingly, as... Figure 6 As shown in step 2.3, if the value of the synchronization status field is the first identifier representing 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 experienced an anomaly. Its WAL (Write-Ahead Log) data was lost compared to that of the master node at the time. Therefore, it can be determined that the CSG node does not qualify to become a successful master node and will not perform the master takeover operation. In this way, even if an anomaly occurs in the asynchronous WAL state between the master and slave nodes, the slave node at the time of the anomaly will not be eligible to take over the master during recovery, thus preventing a CSG node with an incomplete WAL from taking over the service and helping to ensure service reliability.

[0108] 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.

[0109] The CSG service system provided in this application embodiment 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 experiences an anomaly or failure, 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 application embodiment 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.

[0110] The master-slave node synchronous replication method provided in the aforementioned embodiments can handle most system anomalies, ensuring no data loss or corruption. However, data loss risks still exist in some situations. For example, in the event of a master node failure, there may be a risk of data loss, as detailed in the preceding descriptions. Figure 5 Related content.

[0111] To address this issue, a CommitPoint field is introduced in some embodiments of this application. This field records 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 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.

[0112] 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.

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

[0114] A CSG node acting as a slave node to the second master node can determine target data with a log sequence number greater than or equal to the aforementioned acknowledgment point field value from the second master node and copy the target data to its 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 aforementioned CSG node acting as the first master node can act as a slave node to the second master node, copying target data with a log sequence number greater than or equal to the acknowledgment point field value from the second master node's write-ahead log to its write-ahead log. Thus, even if the first master node experiences an anomaly... Figure 5 The anomaly shown can also be addressed by copying 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, while discarding the previously stored data with a log sequence number greater than or equal to the target log sequence number, thus maintaining data consistency between the master and slave nodes, preventing data errors, and even making the RPO 0.

[0115] Since CSG nodes store data in an LSM-Tree structure, combined with the aforementioned Figure 2 As illustrated by the LSM-Tree structure, the in-memory table is continuously flushed to disk. Since the Write-Ahead Log (WAL) records write operations to the in-memory table, if erroneous data is written to the WAL, the data written to the in-memory table will also be erroneous. If erroneous data written to the in-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 in-memory table. The master node's in-memory table maintains this maximum log sequence number.

[0116] 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.

[0117] 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.

[0118] 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).

[0119] In the CSG service system provided in this application embodiment, the number of CSG nodes can be two, achieving a minimum two-node deployment. When there are two CSG nodes, the scheme provided in the aforementioned embodiment 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.

[0120] In addition to the storage system and CSG service system provided in the foregoing embodiments, this application also provides a master-grabbing method and a data replication method. The master-grabbing method and data replication method provided in this application are described exemplarily below.

[0121] Figure 7 This is a flowchart illustrating the master-preemption method provided in this application embodiment. This 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. For example... Figure 7 As shown, for storage node i, this master-grabbing method mainly includes:

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

[0123] 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.

[0124] 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.

[0125] 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.

[0126] 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.

[0127] 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.

[0128] 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.

[0129] 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.

[0130] 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.

[0131] 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.

[0132] 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.

[0133] To address this issue, a CommitPoint field is introduced in some embodiments of this application. 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 application can also provide a data replication method. Figure 8 As shown, this data copying method mainly includes the following steps:

[0134] 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.

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

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

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

[0138] 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.

[0139] 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.

[0140] 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.

[0141] 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.

[0142] 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.

[0143] 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, 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.

[0144] As a slave node of the second master node, the storage node can determine the target data with a log sequence number greater than or equal to the aforementioned acknowledgment point field value from the second master node, and copy the target data to the slave node's write-ahead log. The slave node of the second master node may 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 with a log sequence number greater than or equal to the acknowledgment point field value from the second master node's write-ahead log to its write-ahead log. Thus, even if the first master node experiences an anomaly... Figure 5 The anomaly shown can also be addressed by copying 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, while discarding the previously stored data with a log sequence number greater than or equal to the target log sequence number, thus maintaining data consistency between the master and slave nodes, preventing data errors, and even making the RPO 0.

[0145] Since the storage nodes store data in an LSM-Tree structure, combined with the aforementioned Figure 2 As illustrated by the LSM-Tree structure, the memory table is continuously flushed to disk. Since 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, potentially erroneous data written to the WAL will also be flushed to disk, making it impossible to easily discard that erroneous data.

[0146] 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.

[0147] 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.

[0148] 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.

[0149] 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).

[0150] 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 aforementioned 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.

[0151] It is worth noting that the master-grabbing method and data replication method provided in this application embodiment 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.

[0152] 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.

[0153] 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.

[0154] Accordingly, embodiments of this application 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.

[0155] This application 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 application, 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.

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

[0157] 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.

[0158] In some alternative implementations, such as Figure 9 As shown, the electronic device may also include optional components such as a communication component 90c, a power supply component 90d, a display component 90e, and an audio component 90f. Figure 9 The diagram only shows some components and does not mean that the electronic device must contain them. Figure 9 The inclusion of all components does not imply that an electronic device can only include... Figure 9 The components shown.

[0159] in addition, Figure 9 The components within the dashed box are optional, not mandatory, and their specific requirements depend on the form factor 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.

[0160] In this embodiment, 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.

[0161] In the embodiments of this application, 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 field-programmable gate array (FPGA), a programmable array logic (PAL), a general array logic (GAL), a complex programmable logic device (CPLD), or other programmable devices; or it can be an advanced RISC machine (ARM) or a system on chip (SoC), etc., but is not limited thereto.

[0162] In this embodiment, 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.

[0163] In embodiments of this application, 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 can 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 can sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation.

[0164] In this embodiment, 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.

[0165] In embodiments of this application, the audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC), which is configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, and 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 the user can be achieved through the audio component.

[0166] 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.

[0167] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product implemented 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.

[0168] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. 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, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0169] 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, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0170] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

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

[0172] 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.

[0173] 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.

[0174] 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.

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

Claims

1. A storage system, characterized by, The application relates to a storage system, comprising: a plurality of storage nodes; a master node in the plurality of storage nodes and a slave node in the plurality of storage nodes, which adopt a synchronous replication mode to copy data stored in the master node to the slave node; a storage resource shared by the plurality of storage nodes, wherein a synchronization state field and a target master node field are stored in the storage resource, the synchronization state field is used for recording a synchronization state of data stored in the slave node and data stored in the master node, and the target master node field is used for recording an identification of a master node closest to a current time; in a master selection process of any storage node, if a value of the synchronization state field is a first identification representing non-synchronization and a value of the target master node field is an identification of the any storage node, the any storage node performs a master stealing operation.

2. The system of claim 1, wherein, The any storage node is further used for: if the value of the synchronization state field is the first identification and the value of the target master node field is not the identification of the any storage node, it is determined that the any storage node does not have the qualification of becoming a master node, and the master stealing operation is not performed; or, if the value of the synchronization state field is a second identification representing synchronization, it is determined that the any storage node has the qualification of becoming a master node, and the master stealing operation is performed.

3. The system of claim 1 or 2, wherein, The plurality of storage nodes store data by using a log-structured merge tree structure; as a first master node, a storage node is used for: in response to a synchronous replication success event or a synchronization state switching event, determining a target log sequence number of data closest to a current time and successfully synchronized from prewrite logs of the first master node, and writing the target log sequence number into a confirmation point field of the shared storage resource; as a slave node of the first master node, a storage node is further used for: in the case of an exception of the first master node, performing a master stealing operation to upgrade to a second master node; as a slave node of the second master node, a storage node is further used for: copying target data with a log sequence number greater than or equal to a value of the confirmation point field from the prewrite logs of the second master node into the prewrite logs of the slave node of the second master node.

4. The system of claim 1 or 2, wherein, The plurality of storage nodes store data by using a log-structured merge tree structure; a memory table of the master node maintains a maximum log sequence number flushed to an ordered string table; the master node is used for: in response to a synchronous replication success event, writing a log sequence number of data currently successfully synchronized by the slave node into the memory table as the maximum log sequence number; in the case that all log sequence numbers of data stored in the memory table are less than or equal to the maximum log sequence number and a data amount of the data stored in the memory table reaches a set data amount threshold, flushing the data stored in the memory table to the ordered string table.

5. The system of claim 1 or 2, wherein, The storage system is a cloud storage gateway service system, and the plurality of storage nodes are a plurality of cloud storage gateway nodes; the plurality of cloud storage gateway nodes store metadata of the cloud storage gateway service system by using a log-structured merge tree structure.

6. A method of race condition resolution, applicable to any storage node in a plurality of storage nodes, the method comprising: The shared storage resource of the plurality of storage nodes stores a synchronization state field and a target master node field, the synchronization state field is used to record a synchronization state of data stored in a slave node and data stored in a master node in the plurality of storage nodes; The target master node field is used to record an identification of a master node closest to a current time; The master node in the plurality of storage nodes and the slave node in the plurality of storage nodes copy the data stored in the master node to the slave node in a synchronous replication manner; The method comprises: In a master selection process, the synchronization state field and the target master node field are queried; If a value of the synchronization state field is a first identification representing non-synchronization, and a value of the target master node field is an identification of the self, a master stealing operation is performed.

7. The method of claim 6, wherein, Further comprising: If the value of the synchronization state field is the first identification, and the value of the target master node field is not the identification of the self, it is determined that the any storage node does not have a qualification of becoming a master node, and the master stealing operation is not performed; Or, If the value of the synchronization state field is a second identification representing synchronization, it is determined that the any storage node has the qualification of becoming the master node, and the master stealing operation is performed.

8. The method according to claim 6 or 7, characterized in that, Further comprising: In a case of being the master node, the identification of the self is written into the target master node field; In a case that the slave node successfully copies data from the master node, a second identification representing synchronization is written into the synchronization state field; or in a case that the slave node fails to copy data from the master node, the first identification is written into the synchronization state field.

9. The method according to claim 6 or 7, characterized in that, The plurality of storage nodes store data using a log-structured merge tree structure; the method further comprises: In a case that the any storage node is a first master node, in response to a synchronous replication success event or a synchronization state switching event, a target log sequence number of data successfully replicated synchronously closest to a current time is determined from a prewrite log stored in the any storage node; The target log sequence number is written into a 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 a value of the confirmation point field is determined from a second master node; the second master node is a storage node other than the any storage node in the plurality of storage nodes, and is a master node upgraded in a case of an abnormality of the first master node; The target data is copied into the prewrite log of the any storage node.

10. The method of claim 9, wherein, The any storage node is a first master node, in response to a synchronous replication success event or a synchronization state switching event, a target log sequence number of data successfully replicated synchronously closest to a current time is determined from a prewrite log stored in the any storage node, comprising: In a case that a slave node of the first master node successfully copies data from the first master node, it is determined that a synchronous replication success event occurs, and in response to the synchronous replication success event, a log sequence number of 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 state field switches from the first identifier to the second identifier, a first synchronization state switching event of switching from an unsynchronized state to a synchronized state is determined to occur, and in response to the first synchronization state switching event, a log sequence number of data successfully synchronized and replicated this time by the slave node of the first master node is determined as the target log sequence number; Or, If the value of the synchronization state field switches from the second identifier to the first identifier, a second synchronization state switching event of switching from a synchronized state to an unsynchronized state is determined to occur, and in response to the second synchronization state switching event, a log sequence number of data successfully synchronized and replicated last time by the slave node of the first master node is determined as the target log sequence number.

11. The method of claim 6 or 7, wherein, The plurality of storage nodes store data using a log-structured merge tree structure; and the memory table of the master node maintains a maximum log sequence number supporting storage into the ordered string table; The method further comprises: When serving as the master node, in response to a synchronization and replication success event, writing, into the memory table, a log sequence number of data currently successfully synchronized and replicated by the slave node as the maximum log sequence number; In a case where the log sequence numbers of data stored in the memory table are all less than or equal to the maximum log sequence number, and an amount of data stored in the memory table reaches a set data amount threshold, storing the data stored in the memory table into the ordered string table.

12. The method of claim 6 or 7, wherein, The plurality of storage nodes are a plurality of cloud storage gateway nodes, and the plurality of storage nodes store metadata of a cloud storage gateway service system using a log-structured merge tree structure.

13. A data replication method, applicable to any storage node in a plurality of storage nodes, characterized in that, The plurality of storage nodes store data using a log-structured merge tree structure; and a storage resource shared by the plurality of storage nodes stores a checkpoint field; The master node of the plurality of storage nodes and the slave node of the plurality of storage nodes copy, in a synchronization and replication manner, prewrite logs stored in the master node to the slave node; The method comprises: When the any storage node serves as a first master node, in response to a synchronization and replication success event or a synchronization state switching event, determining, from the prewrite logs stored in the any storage node, a target log sequence number of data successfully synchronized and replicated closest to a current time; Writing the target log sequence number into the checkpoint field; In response to an abnormal recovery event, determining, from a second master node, target data having a log sequence number greater than or equal to a value of the checkpoint field; the second master node is another storage node of the plurality of storage nodes other than the any storage node, and is a master node upgraded in a case where the first master node is abnormal; Copying the target data into the prewrite logs of the any storage node.

14. An electronic device, comprising: Comprise: a memory and a processor; wherein the memory is configured to store a computer program; the processor is coupled to the memory and is configured to execute the computer program to perform the steps in the method of any one of claims 6-13.

15. A computer readable storage medium having stored thereon 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 in the method of any one of claims 6-13.

16. A computer program product, characterised in that, A computer program product comprising a computer program that, when executed using one or more processors, causes the one or more processors to perform the steps of the method of any of claims 6-13.

Images