Synchronizing changes to stale components of a distributed object using synchronization bitmaps

#Distributed data objects can have multiple data components that are mirrored with each other to provide redundancy and security for the data stored thereon. Sometimes, a component becomes unavailable for a period and the data availability and durability of the distributed data object is reduced during that period. One or more changes to the data that are not recorded in the unavailable component cause the component to become stale, such that the component must be synchronized with other up-to-date mirrored components when it becomes available again. However, during the synchronization process of the stale component, tracking the changes to the stale component for use in future synchronization processes of other components may cause the tracking data to be corrupted due to changes, made during the synchronization process, occurring in a different order than the order in which the changes were made from the original data writes.

#This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

#Solutions for enhancing the synchronization of components of a distributed data object using synchronization bitmaps are disclosed that include detecting, by a processor, a first component of a plurality of mirrored components of the distributed data object becoming available from an unavailable state, wherein the first component is stale with respect to at least one active component of the plurality of mirrored components; identifying, by the processor, a stale log sequence number (LSN) and a last committed LSN associated with the first component, wherein the stale LSN is an LSN associated with a write input/output instruction (I/O) that was committed by at least one active component of the plurality of mirrored components prior to the first component transitioning to the unavailable state, and wherein the last committed LSN is an LSN associated with a last write I/O that was committed to the first component prior to the first component transitioning to the unavailable state; creating, by the processor, a synchronization bitmap of the first component associated with an inclusive LSN range from the identified stale LSN to the identified last committed LSN, wherein the synchronization bitmap is configured to track changes to data blocks of the first component that occur after the first component becomes available; identifying, by the processor, a second component of the plurality of mirrored components based on the second component including a tracking bitmap associated with an LSN that is equal to or less than the stale LSN of the first component; and synchronizing, by the processor, the first component with data from the second component based on changed data blocks indicated in the tracking bitmap included in the second component, wherein the synchronizing includes updating the synchronization bitmap to track changes made to data blocks of the first component.

#The present description will be better understood from the following detailed description read in light of the accompanying drawings, wherein:

#FIG. 1 is a block diagram illustrating a system architecture that is comprised of a set of compute nodes interconnected with each other and a set of storage nodes according to an embodiment;

#FIGS. 2A-D are block diagrams illustrating a system configured for managing mirrored data components of a distributed data object when some data components are unavailable or stale according to an embodiment;

#Corresponding reference characters indicate corresponding parts throughout the drawings. In FIGS. 1 to 6, the systems are illustrated as schematic drawings. The drawings may not be to scale.

#Distributed data objects may be configured to store data spread out among multiple hardware devices and physical locations to both secure the data against loss due to hardware failure, software failure, or for other reasons (data durability), and to enable access to the stored data despite periodic downtimes for individual devices (data availability). Providing these features typically includes storing the data redundantly (e.g., storing the same data on multiple devices and/or in multiple locations) within data components of the distributed data object, such that, in the event that one server device fails, the data is still accessible on another server device that stores the data. For instance, data components of a distributed data object may include components configured to store a subset of the total data associated with the distributed data object, such that the total data is stored across multiple components and/or components that mirror each other. That is, the data of the distributed data object is stored redundantly on multiple components (e.g., the base components and mirrored components described herein). When a component of the distributed data object is going to become unavailable, the data durability and availability is reduced for the time period during which the component is unavailable and, when the component becomes available again, it may be in a stale state and require synchronization with an up-to-date component.

#In the described distributed data object systems, a tracking bitmap mechanism includes the process of each active mirrored component starting a new tracking bitmap when another mirrored component goes offline or otherwise becomes unavailable. The tracking bitmap is managed by each local component independently and changes are marked into the bitmap when data changes are committed by the local component. Each bitmap tracks every incoming data write to the component since the last committed write input/output (I/O) at the time and the log sequence number (LSN) of that write I/O is associated with the bitmap as the starting LSN.