File replication and failover

The mirror architecture is a primary-backup high-availability solution that is suitable for all applications. The application runs on a primary server and is restarted automatically on a secondary server if the primary server fails.

With its file-replication function, this architecture is particularly suited to providing high availability for back-end applications with critical data to protect against failure.

Microsoft SQL Server.Safe, MySQL.Safe, and Oracle.Safe are examples of "mirror" type application modules. You can write your own mirror module for your application, based on the generic module Mirror.Safe.

The backup mechanism works as follows:

Step 1: normal operation.

: Please, click to enlarge the image

Configure the application files to replicate. There are no prerequisites on disk organization for the two servers. For instance, the files to replicate may be on an internal RAID5 disk on server 1 and on a simple internal disk on server 2.

While Server 1 runs the application, SafeKit replicates the file updates made by the application. Only the file updates made by the application are replicated in real time through the network, thus limiting traffic. Thanks to the synchronous replication of file write operations on the disks of both servers, no data is lost in case of failure.

In particular, synchronous file replication guarantees that every item of data written to a disk by a transactional application is available on the secondary server—this is not possible with solutions that perform replication asynchronously.

Step 2: failover

: Please, click to enlarge the image

When Server 1 fails, Server 2 takes over: SafeKit switches the cluster’s virtual IP address and restarts the application automatically on Server 2. The application finds the files replicated by SafeKit in the identical state that they were in when Server 1 failed, thanks to the synchronous replication.

The switch-over time is equal to the fault-detection time (set to 30 seconds by default) plus the application start-up time. Unlike disk replication solutions, there is no delay for remounting file systems and running recovery procedures.

Step 3: failback

: Please, click to enlarge the image

Failback involves restarting server 1 after fixing the problem that caused it to fail, SafeKit automatically resynchronizes the files, updating only the files modified on Server 2 while Server 1 was halted.

This resynchronization takes place without disturbing the applications, which can continue running on Server 2. This is a major feature that differentiates SafeKit from other solutions, which require you to stop the applications on Server 2 in order to resynchronize Server 1.

Step 4: normal operation

: Please, click to enlarge the image

After resynchronization, the files are once again in mirror mode, as in step 1. The system is back in high-availability mode, with the application running on Server 2 and SafeKit replicating file updates to the backup Server 1. If you wish the application to run on Server 1, you can execute a “swap” command either manually or automatically through configuration.

Synchronous, fault-tolerant replication that loses no data when a server fails

There is a significant difference between synchronous replication, as offered by the SafeKit mirror solution, and asynchronous replication:

With asynchronous replication, all the data not copied to the second server is lost if the first server fails. In particular, a transactional application can lose committed updates
With SafeKit, the synchronous replication in real time of files updated by an application eliminates the loss of data in case of server failure

The bandwidth of a LAN between the servers is required to implement synchronous data replication, possibly with an extended LAN in two computer rooms located a few kilometers apart. (Asynchronous replication can be used for data replication t