Understanding Mailbox Database Availability

  • Article

[This is pre-release documentation and subject to change in future releases. This topic's current status is: Milestone-Ready.]

Applies to: Exchange Server 2010 Beta* *Topic Last Modified: 2008-12-02

Mailbox databases and the contain they contain are one of the most critical components (if not the most critical component) of any Microsoft Exchange Organization. In Microsoft Exchange Server 2010, you can protect mailbox databases by deploying them in highly available and site resilient configurations.

Understanding Database Availability Groups

Exchange Server 2007 introduced a built in data replication technology called continuous replication. Continuous replication, which was available in three forms: local, cluster, and standby, significantly reduced the cost of deploying a highly available Exchange infrastructure, and provided a much improved deployment and management experience over previous versions of Exchange. Even with these cost savings and improvements, however, running a highly available Exchange 2007 infrastructure still required a great deal of time and expertise because the integration between Exchange and Windows failover clustering wasn't seamless. In addition, customers wanted an easier way to replicate their e-mail data to a remote location, in order protect their Exchange environment against site-level disasters.

Exchange 2010 uses the same continuous replication technology found in Exchange 2007. Exchange 2010 combines on-site data replication (CCR) and off-site data replication (SCR) into a single framework called a database availability group (DAG). Once servers have been added to a DAG, administrators can add replicated database copies incrementally (up to 16 total), and Exchange 2010 switches between these copies automatically, as needed, to maintain availability.

Unlike Exchange 2007, where clustered mailbox servers required dedicated hardware, Mailbox servers in a DAG can host other Exchange roles (Client Access, Hub Transport, Unified Messaging), providing full redundancy of Exchange services and data with just two servers.

This new high availability architecture also provides simplified recovery from a variety of failures (disk-level, server-level, and datacenter-level), and it can be deployed on a variety of storage types.

For more information about DAGs, see Managing Database Availability Groups.

Active Manager

DAGs use a new component in Exchange 2010 called Active Manager. Active Manager includes functionality that replaces the failover management features provided by the Cluster service in previous versions of Exchange.

In Exchange 2010, the Microsoft Exchange Replication service periodically monitors the health of all mounted databases. In addition, it also monitors Extensible Storage Engine (ESE) for any I/O errors or failures. When the service detects a failure, it notifies Active Manager. Active Manager then determines which database copy should be mounted and what it required to mount that database. In addition, tracks the active copy of a mailbox database (based on the last mounted copy of the database) and provides the tracking results information to the RPC Client Access component on the Client Access server to which the client is connected.

When an administrator makes a database copy the active mailbox database, this process is known as a switchover. When a failure affecting a database occurs and a new database becomes the active copy, this process is known as a failover. This process also refers to a server failure in which one or more servers bring online the databases previously online on the failed server. When either a switchover or failover occurs, other Exchange 2010 server roles become aware of the switchover almost immediately and will redirect client and messaging traffic to the new active database.

For example, if an active database in a DAG fails because of an underlying storage failure, Active Manager will automatically recover by failing over to a database copy on another Mailbox server in the DAG. In the event the database is outside the automatic mount criteria and cannot be automatically mounted, an administrator can manually perform a database failover.

Mailbox Database Copies

The high availability and site resilience features in Exchange 2007 (namely, cluster continuous replication (CCR) and standby continuous replication (SCR)) no longer exist in name; however, their underlying technology (continuous replication) is used in Exchange 2010 to create and maintain database copies. The key characteristics of and changes to continuous replication in Exchange 2010 are as follows:

  • Database copies are for mailbox databases only. For redundancy and high availability for public folder databases, we recommend that you use public folder replication.
  • Multiple copies of an Exchange 2010 mailbox database can be created on multiple Mailbox servers.
  • Multiple Mailbox servers hosting copies of a database must be grouped into a database availability group (DAG). DAGs provide automatic monitoring of the server and network, and automatic recovery in the event of a failure that affects a mailbox database (e.g., database, storage, server, or datacenter failure). For more information about DAGs, see Managing Database Availability Groups.
  • All Mailbox servers in a DAG must be in the same Active Directory domain.
  • Like SCR, database copies support the concepts of a replay lag time and a truncation lag time.
  • All database copies can be backed up using Exchange-aware, Volume Shadow Copy Service (VSS)-based backup applications, or by using an application that supports the ESE streaming backup APIs.
  • Database copies can be created only on Mailbox servers that do not host the active (mounted, in-use) copy of a database. You cannot create two copies of the same database on the same server.
  • Exchange 2010 mailbox databases can be replicated only to other Exchange 2010 Mailbox servers within a DAG. You cannot replicate a database outside of a DAG, nor can you replication an Exchange 2010 mailbox database to a server running Exchange 2007.
  • All copies of a database use the same path on each server containing a copy.
  • The database and log file paths for a database copy on each Mailbox server must not conflict with any other database paths.
  • Database copies can be created in the same or different Active Directory Sites.
  • Database copies can be created on the same or different network subnets.
  • Database copies are not supported between Mailbox servers with round trip network latency greater than 250 milliseconds (ms).

Using Mailbox Database Copies

A database copy can be created by an administrator at any time. Database copies can be distributed across Mailbox servers in a flexible and granular way. You can replicate one, some, or all mailbox databases on a server in a variety of ways.

A database copy can be created by using the Add Mailbox Database Copy wizard in the Exchange Management Console, or by using the Add-MailboxDatabaseCopy cmdlet in the Exchange Management Shell.

When creating a mailbox database copy, you specify the following information:

  • The name of the database being copied.
  • The name of the Mailbox server that will host the database copy.
  • The amount of time (in minutes) for log replay delay. This is referred to as replay lag time. Setting the value for replay lag time to 0 turns off log replay delay.
  • The amount of time (in minutes) for log truncation delay. This is referred to as truncation lag time. Setting the value for truncation lag time to 0 turns off log truncation delay.
  • An activation preference number. This is referred to as a preferred list sequence number, and it represents the order of activation preference of a database copy after a failure or outage of the active copy.

For more information about creating, using and managing mailbox database copies, see Managing Mailbox Database Copies.