You are here: Introduction > Mirroring with SteelEye DataKeeper for Linux

Mirroring with SteelEye DataKeeper for Linux

SteelEye DataKeeper for Linux offers an alternative for customers who want to build a high availability cluster (using SteelEye LifeKeeper) without shared storage or who simply want to replicate business-critical data in real-time between servers. 

SteelEye DataKeeper uses either synchronous or asynchronous volume-level mirroring to replicate data from the primary server (mirror source) to one or more backup servers (mirror targets).  

DataKeeper Features

SteelEye DataKeeper includes the following features:

Synchronous vs. Asynchronous Mirroring

Understanding the differences between synchronous and asynchronous mirroring will help you choose the appropriate mirroring method for your application environment.

Synchronous Mirroring

SteelEye DataKeeper provides real-time mirroring by employing a synchronous mirroring technique in which data is written simultaneously on the primary and backup servers. For each write operation, DataKeeper forwards the write to the target device(s) and awaits remote confirmation before signaling I/O completion.  The advantage of synchronous mirroring is a high level of data protection because it ensures that all copies of the data are always identical. However, the performance may suffer due to the wait for remote confirmation, particularly in a WAN environment.

Asynchronous Mirroring

With asynchronous mirroring, each write is made to the source device and then a copy is queued to be transmitted to the target device(s). This means that at any given time, there may be numerous committed write transactions that are waiting to be sent from the source to the target device.  The advantage of asynchronous mirroring is better performance because writes are acknowledged when they reach the primary disk, but it can be less reliable because if the primary system fails, any writes that are in the asynchronous write queue will not be transmitted to the target. To mitigate this issue, SteelEye DataKeeper makes an entry to an intent log file for every write made to the primary device.

The intent log is a bitmap file indicating which data blocks are out of sync between the primary and target mirrors. In the event of a server failure, the intent log can be used to avoid a full resynchronization (or resync) of the data.

Note:  The intent log can be used in both asynchronous and synchronous mirroring modes, but the intent log with asynchronous mirroring is supported only with a 2.6.16 or higher Linux kernel.

© 2012 SIOS Technology Corp., the industry's leading provider of business continuity solutions, data replication for continuous data protection.