What Is Synchronous Database Mirroring and How Does It Work?

Synchronous database mirroring, also called High-Safety Mode, is a SQL Server mirroring configuration that guarantees zero data loss by ensuring every transaction is committed on both the principal and mirror server before the client receives confirmation. It achieves this through a coordinated write process where the principal server waits for the mirror to acknowledge that log records have been hardened to disk before completing each transaction. If protecting data integrity is your primary concern and you can tolerate a small increase in transaction latency, High-Safety Mode is the right choice.

It's worth noting upfront that database mirroring has been deprecated since SQL Server 2012. Microsoft recommends Always On Availability Groups for new deployments. That said, many production environments in Australia and globally still run mirroring, and understanding how it works remains genuinely useful for anyone managing or migrating those systems.

How Does Synchronous Database Mirroring Actually Work?

When you configure a mirroring session with TRANSACTION SAFETY = FULL, SQL Server operates the session synchronously. Here's what happens at the transaction level, step by step:

  1. A client sends a transaction to the principal server.
  2. The principal server writes the transaction log record to its local transaction log.
  3. The principal server simultaneously writes the transaction to the database and sends the log record across the network to the mirror server.
  4. The mirror server receives the log record and hardens it to disk immediately.
  5. The mirror server sends an acknowledgement back to the principal server confirming the log has been written.
  6. Only after receiving that acknowledgement does the principal server confirm the commit (or rollback) to the client.

That step 6 is the critical point. The principal server will not tell the client the transaction is done until the mirror has confirmed it. This is what guarantees zero data loss. If the principal server fails at any point after step 5, the mirror has everything it needs to take over without losing a single committed transaction.

The trade-off is latency. Every transaction carries the round-trip overhead of that acknowledgement message. On a well-configured network with low latency between the principal and mirror, this overhead is typically measured in milliseconds and is acceptable for most workloads. On a high-latency or congested network link, the impact on transaction throughput can become significant.

What Is the Synchronisation Phase?

When a mirroring session first starts, the databases are not yet in sync. The principal server begins streaming its active transaction log to the mirror server, and the mirror writes those log records to disk as fast as possible. This initial synchronising phase continues until the mirror has caught up with the principal.

The time this takes depends on three factors:

  • How far behind the mirror database is when the session starts (measured in log records).
  • The current workload on the principal database, which is generating new log records while the mirror is still catching up.
  • The hardware and network performance of the mirror system.

Once the mirror has caught up, both databases transition to a SYNCHRONIZED state. From that point forward, every committed transaction on the principal is simultaneously committed on the mirror. The mirror server also maintains a redo queue, which contains log records that have been hardened to disk but not yet applied to the mirror database. This redo queue is normal and expected. It does not indicate a problem unless it grows continuously without draining.

High-Safety Mode Without Automatic Failover

The simplest High-Safety Mode configuration uses just two servers: the principal and the mirror. No witness server is involved.

In this configuration, manual failover is supported when both partners are connected and the databases are in a SYNCHRONIZED state. You initiate the failover manually, and the mirror takes over as the new principal cleanly with no data loss.

What happens when things go wrong is where this configuration shows its limitations. If the mirror server goes down, the principal continues running but operates in an "exposed" state, meaning transactions are no longer being mirrored. Data is still being written to the principal, but the protection is gone until the mirror comes back online and re-synchronises.

If the principal server goes down, the situation is more serious. The mirror database is not automatically promoted. A DBA must manually force service to the mirror server. Microsoft documents this as "Forced Service (with Possible Data Loss)" because any transactions that were committed on the principal but not yet acknowledged by the mirror will be lost. In practice, with synchronous mirroring, this window is very small, but it is not zero if the failure occurred mid-acknowledgement.

This configuration suits environments where a witness server is not practical but a DBA is available to respond quickly to failures.

High-Safety Mode with Automatic Failover

Adding a witness server to a High-Safety Mode session enables automatic failover. This is the configuration most organisations choose when they need genuine high availability from database mirroring.

The witness server's role is narrow but important. It does not serve the database, does not participate in the synchronisation process, and does not handle client connections. Its only job is to maintain a quorum. When the principal server becomes unavailable, the mirror server consults the witness to confirm that the principal is genuinely down and not just temporarily unreachable. If the witness and mirror agree the principal is gone, automatic failover proceeds and the mirror becomes the new principal without any manual intervention.

The witness can run on a much smaller server than the principal or mirror. Many environments run the witness on a monitoring server, a domain controller, or even a shared utility server. The key requirement is that it must be on a separate physical machine from both partners, ideally in a separate fault domain, so that a single hardware failure cannot take down both the principal and the witness simultaneously.

Automatic failover requires all three of the following conditions to be true:

  • The session is operating in High-Safety Mode (TRANSACTION SAFETY = FULL).
  • A witness server is configured and connected.
  • The mirror database is in a SYNCHRONIZED state at the time of the failure.

If any of these conditions is not met, automatic failover will not occur and manual intervention is required.

Practical Considerations for Production Environments

Synchronous database mirroring performs best when the network link between principal and mirror has latency under 1 millisecond. Many organisations co-locate the principal and mirror in the same data centre for this reason, which does limit the disaster recovery value of the configuration. If you need both high availability and genuine geographic separation, Always On Availability Groups with synchronous commit replicas give you more flexibility.

Monitor your mirroring sessions actively. Key metrics to watch include the redo queue size on the mirror, the send queue size on the principal, and the transaction log send rate. SQL Server exposes these through sys.dm_db_mirroring_connections and the Database Mirroring Monitor in SQL Server Management Studio.

Also plan for the re-synchronisation overhead after any failover or mirror restart. On large databases with heavy write workloads, re-synchronisation can take time, and the principal runs exposed during that window.

Key Takeaways

  • Synchronous database mirroring (High-Safety Mode) guarantees zero data loss by requiring the mirror to acknowledge every transaction before the principal confirms it to the client.
  • The trade-off for this guarantee is increased transaction latency, proportional to the network round-trip time between principal and mirror.
  • Without a witness server, failover is manual only. Adding a witness enables automatic failover, but requires the mirror to be in a SYNCHRONIZED state when the principal fails.
  • Database mirroring is deprecated as of SQL Server 2012. Always On Availability Groups is the recommended replacement for new deployments.
  • Monitor redo queue size, send queue size, and log send rates to catch mirroring performance issues before they affect production workloads.

If you're running database mirroring in production and haven't reviewed your configuration recently, it's worth doing a structured assessment. DBA Services provides SQL Server health checks that cover mirroring and availability configurations, identifying risks like unmonitored send queues, missing witnesses, and environments overdue for migration to Always On. Get in touch to find out what a health check covers.