A Complete Guide on Exchange Database Replication

In Exchange Server, you can have Database Availability Groups (DAGs) for high availability and site resilience. In a DAG setup, you can have up to 16 mailbox servers that can host a set of databases. This provides automatic database-level recovery in case of failure that can impact individual databases, servers, or networks. Within the DAG, you can create up to 16 copies of the mailbox database on multiple servers, in which one of the mailbox copies is the active copy and other copies are passive copies. Each member, hosting the copy of the mailbox database, continuously replicate the data to keep the database copies consistent. This increases the chances of recoverability of data in case of failure of the server hosting the active copy. Since the replication is taking place all the time, there should be minimal disruption and no data loss. In case the server fails, apart from changing the passive copy to active, the Database Availability Group also activates the services on one of the other nodes.

Below, we will understand database replication and discuss how to manage healthy database replication.

How do databases replicate?

In a Database Availability Group (DAG), there are two methods of replication of the data between databases in the same group - the File Mode and the Block Mode.

In File Mode replication, each transaction log in the active database is written to the disk with 1 MB log file and then it is copied from the hosting server (where the active database is) to all the nodes in the group which host a passive copy of the said database. Once the other members of the Database Availability Group receive the transaction log, the log is replicated on to the passive copy that the server is hosting.

In Block Mode replication, each database transaction is not written to a transaction log but is written to the log buffer on the active server and also sent to the log buffer on the participating servers. Once this log buffer is full, the passive servers build transaction logs from that buffer information and replay the logs on the hosted passive copy of the mailbox database.

What are the benefits of database replication in Exchange Server?

There are a lot of benefits of this type of setup. This allows the server administrators to have a safe copy of the data on another server in the same building or another site (such as disaster recovery site). If something happens, all the mailboxes will failover to the secondary site. This also helps the administrators to run maintenance jobs on the servers without interrupting the business.

How to manage and maintain a healthy replication?

For a healthy replication, you can follow the given best practices:

• Ensure that the server is identical in the operating system and Exchange Server level to avoid any incompatibility issues or mismatches.
• Always ensure that the structure of the server and the hard drive sizes are proper. Also, the drive letters or mounting points are similar on all the servers.
• Always have ample storage on the servers, especially on the data and transaction logs drives.
• Have a monitoring tool or agent to check the servers and identify any issues with the server before these become serious. Put in place a monitoring system to send notification when an issue occurs with the replication.
• Regularly check the server’s Event Viewer. This will indicate any replication issue and possibly indicate the cause for it.
• Performance of CPU and RAM is crucial for a healthy replication process. If a server’s resources are not enough, this would delay the replication process and might break it. So, check the performance of the server’s resources.
• Storage is important for a healthy replication. So, ensure that there is enough free space on the active and passive copy servers.

How to check the replication status?

To check the replication status, you can use the Test-ReplicationHealth PowerShell command (as given below).

This command will check all the aspects of the replication between the nodes and databases, check the replay on the passive copies, and provide a status for a specific mailbox server in your Database Availability Group (DAG). Apart from giving the status, this will also provide a possible resolution of the issue.

You can also execute the command against an entire Database Availability Group (DAG), as given below.

How to recover the data in case of disaster?

Apart from maintaining and monitoring the databases, you should be well-prepared to cope up with a disaster. You can keep in hand Exchange Server Recovery tool, like Stellar Repair for Exchange. With this tool, you can repair corrupt Exchange database (EDB) files, extract mailboxes from EDB files, and export them directly to a live Exchange Server or Office 365 tenant.