There is a significant difference between synchronous replication vs. asynchronous replication. Depending on the choice, you may experience data loss during an application failover.
It is important to understand that these solutions are complementary. While SafeKitβs synchronous replication protects your environment against hardware or software failures to maintain 24/7 uptime, a backup solution secures your historical data against logical errors and cyber threats like ransomware.
To help you make the right decision when choosing the best architecture for your needs, we explain the technical mechanisms and the impact on application failover below.
Comparison of synchronous and asynchronous replication impact on data loss during application failover.
In asynchronous replication , the primary server acknowledges write operations immediately, updating replicas later in scheduled batches with delay. This decoupling overcomes the latency issues of long-distance replication , making it a preferred strategy for backups and disaster recovery across remote sites.
However, this efficiency introduces the challenge of consistency , where the secondary server may hold outdated information. Because the secondary update occurs after the primary write is finalized, any failure of the primary server will result in the loss of in-flight data.
With synchronous replication as implemented by SafeKit, when a disk I/O operation is performed by the application or the file system cache on the primary server, the system ensures data consistency through a double-acknowledgment process.
SafeKit waits for the I/O acknowledgment from both the local disk and the secondary server before sending the final acknowledgment back to the application or the file system cache. This synchronous mechanism is essential for the failover of transactional applications , ensuring that transactions are fully secured on both nodes before they are considered committed.
Semi-synchronous replication serves as a hybrid approach to data integrity. Like synchronous replication, SafeKit waits for an acknowledgment from both the primary and secondary servers before confirming the I/O operation to the application or file system cache.
The critical difference lies in the secondary server’s response timing. In the semi-synchronous case, the secondary server sends an acknowledgment to the primary immediately upon receiving the data in memory , committing it to disk afterward. In contrast, synchronous replication requires the secondary server to write the I/O to the physical disk before sending the acknowledgment.
The choice between synchronous vs. asynchronous replication is a trade-off between absolute data integrity and network performance. For mission-critical infrastructures, this decision directly determines your Recovery Point Objective (RPO).
In summary:
β SafeKit Recommendation: For critical applications, always prioritize synchronous or semi-synchronous replication to guarantee business continuity, maximize performance, and eliminate the risks associated with inconsistent failover.
| Feature | Synchronous | Semi-Synchronous | Asynchronous |
|---|---|---|---|
| RPO (Potential Data Loss) | Zero | Zero | Not Zero (Data loss: depends on last asynchronous copy) |
| Remote I/O Acknowledgment | After remote disk write | After remote RAM write | Does not wait acknowledgment |
| Performance Impact | Requires a low latency network - Depends on Round Trip Time (typically RTT<2ms) | Requires a low latency network - Depends on Round Trip Time (typically RTT<2ms) | Supports low latency network |
| Distance Limits | Local / Stretched VLAN | Local / Stretched VLAN | Wide Area Network (WAN) |
| Best For | High Availability (Automatic failover) | High Availability (Automatic failover) | Backup Solutions (Manual Failover) |
In this video, discover how SafeKit implements a mirror HA cluster without the complexity of a SAN. While this demonstration uses Microsoft SQL Server, the solution works identically for other databases and applications.
&amp;amp;amp;amp;lt;br /&amp;amp;amp;amp;gt;
No. SafeKit utilizes byte-level replication. It intercepts specific I/O modifications inside files and replicates only the changed bytes, minimizing network traffic.
No. Replication occurs only when the application requests an I/O commit to the local disk. SafeKit ensures this data is acknowledged by the secondary server before completing the write.
Latency is tied to the Network Round Trip Time (RTT). On a LAN, the impact is negligible (similar to NAS/SAN storage). On high-latency WANs, asynchronous modes are often preferred to avoid performance bottlenecks and a backup solution (not SafeKit) is required.
Choose Synchronous for High Availability (automatic failover, zero data loss). Choose Asynchronous for Backup/DR where distance prevents real-time syncing and automatic failover is not required.
No. SafeKit is an HA solution requiring zero data loss for automatic failover. For purely asynchronous needs, look for Backup solutions.
No, high availability does not remove the need for a comprehensive backup solution.
While real-time replication solutions like SafeKit provide continuous business continuity, they serve a different purpose than backups. Real-time replication is designed to protect against hardware failure and server downtime, but it cannot protect against cyber threats like ransomware encrypting both nodes simultaneously. Only a backup solution with a retention policy can solve this issue.
You can use a 3-node hybrid architecture : a 2-node local cluster with synchronous replication for HA, and a third remote copy via a backup solution with asynchronous replication for Disaster Recovery.
See for more information: SafeKit High Availability and Disaster Recovery (HADR)
Explore SafeKit: Features, technical videos, documentation, and free trial
| Resource Type | Description | Direct Link |
|---|---|---|
| Key Features | Why Choose SafeKit for Simple and Cost-Effective High Availability? | See Why Choose SafeKit for High Availability |
| Use Cases | Explore How SafeKit Ensures the High Availability of Critical Infrastructure | See All Use Cases (OEM Software, Edge Servers, SCADA, and more) |
| Deployment Model | All-in-One SANless HA: Shared-Nothing Software Clustering | See SafeKit All-in-One SANless HA |
| HA Strategies | SafeKit: Infrastructure (VM) vs. Application-Level High Availability | See SafeKit HA & Redundancy: VM vs. Application Level |
| Technical Specifications | Technical Limitations for SafeKit Clustering | See SafeKit High Availability Limitations |
| Proof of Concept | SafeKit: High Availability Configuration & Failover Demos | See SafeKit Failover Tutorials |
| Architecture | How the SafeKit Mirror Cluster works (Real-Time Replication & Failover) | See SafeKit Mirror Cluster: Real-Time Replication & Failover |
| Architecture | How the SafeKit Farm Cluster works (Network Load Balancing & Failover) | See SafeKit Farm Cluster: Network Load Balancing & Failover |
| Competitive Advantages | Comparison: SafeKit vs. Traditional High Availability (HA) Clusters | See SafeKit vs. Traditional HA Cluster Comparison |
| Technical Resources | SafeKit High Availability: Documentation, Downloads & Trial | See SafeKit HA Free Trial & Technical Documentation |
| Pre-configured Solutions | SafeKit Application Module Library: Ready-to-Use HA Solutions | See SafeKit High Availability Application Modules |