Home > Storage > Unity XT > Data Protection > Dell Unity: Replication Technologies > Data Protection Mechanisms
Synchronous replication has mechanisms to resync data differences between the source and/or destination resources in the event of replication disruption thereby preventing the need for full synchronization. The fracture log protects primarily against loss of communication with the destination resource. The write intent log protects primarily against interruptions to the source resource. Both of these structures exist to enable partial synchronizations in the event of interruptions to the source or destination resources.
The fracture log is a bitmap held in the memory of the storage processor that owns the source resource. It indicates which physical areas of the source have been updated since communication was interrupted with the destination.
The fracture log is automatically invoked when the destination resource of a replication session is lost for any reason and becomes out of sync. The replication session is out of sync (no longer replicating) if the destination is not available, or it can be administratively paused through Unisphere or UEMCLI. Dell Unity sets a replication session as out of sync if an outstanding I/O to the destination is not acknowledged within 25 seconds. While in a state of out of sync, the source pings the destination every 20 seconds to determine if communication has been restored.
The fracture log tracks changes on the source resource for as long as the destination resource is unreachable. It is a bitmap that represents areas of the source resource with regions called extents. The amount of data represented by an extent depends on the size of the data resource. Since the fracture log is a bitmap and tracks changed areas of the source resource, it is not possible to run out of fracture log capacity.
When the destination resource returns to service, it must be synchronized with the source. This is accomplished by reading those areas of the source addressed by the fracture log and writing them to the destination resource. This activity occurs in parallel with any writes coming into the source and replicated to the destination. Bits in the fracture log are cleared once the area of the source marked by an extent is copied to the destination. This ability to perform a partial synchronization can result in significant time savings. It may be necessary, depending on the length of the outage and the amount of write activity, to resynchronize the entire dataset.
By default, the fracture log is stored in memory. Therefore, it would be possible for a full resynchronization to be required if a destination resource is out of sync and an interruption in service occurs on the source SP. To protect against such scenarios, the write intent log is used.
The write intent log is a record stored in persistent memory (disk) on the storage system on which the source resource resides. During normal operation, the write intent log tracks in-flight writes to both the source and destination resources in a sync replication relationship. Much like the fracture log, the write intent log is a bitmap composed of extents indicating where data is written. The write intent log is always active, but the fracture log is only enabled when the replication session is out of sync.
When in use, Dell Unity makes an entry in the write intent log of its intent to update the source and destination resources at a particular location, then proceeds with the attempted update. After both images respond that data has been written (that is written to write cache), the system clears previous write intent log entries. For performance reasons, the write intent log is not cleared immediately following the acknowledgment from the source and destination resources. It will be cleared while subsequent write intent log operations are performed.
In a recovery situation, the write intent log can be used to determine which extents must be synchronized from the source storage system to the destination system. For instance, if a single SP becomes unavailable (for example during a reboot or failure), there may be in-flight writes that were sent to the destination, but not acknowledged before the outage. These writes will remain marked in the write intent log. Then server software trespasses the resource to the peer SP. The remaining SP directly accesses the unavailable SP’s write intent log and recovers the recent modification history. The SP then resends the data marked by the extents in the write intent log. This allows for recovery using only a partial resynchronization, rather than a full resynchronization because it ensures that any writes in process at the time of the failure are acknowledged by the destination resource. If the entire array becomes unavailable, then the write intent log is used to facilitate a partial resynchronization from source to destination once the source array is recovered.