Understanding Mailbox Database Copies

Microsoft Exchange Server 2010 introduces the concept of database mobility, which is Exchange-managed database-level failovers. An enhanced version of the continuous replication feature first introduced in Exchange Server 2007 is used in Exchange 2010 to create and maintain database copies.

Database mobility disconnects databases from servers, adds support for up to 16 copies of a single database, and provides a native experience for adding database copies to a database. In Exchange 2007, a feature called database portability also enabled you to move a mailbox database between servers. A significant distinction between database portability and database mobility, however, is that with database mobility, all copies of a database have the same GUID.

Because clustered mailbox servers and storage groups have been removed from Exchange 2010, continuous replication now operates at the database level. In Exchange 2010, transaction logs are replicated to one or more Mailbox servers and replayed into a copy of a mailbox database that's stored on those servers. A failover or switchover can occur at either the database level or at the server level.

Key Characteristics

The key characteristics of mailbox database copies are:

  • Database copies are for mailbox databases only. For redundancy and high availability for public folder databases, we recommend that you use public folder replication.
  • Up to 16 copies of an Exchange 2010 mailbox database can be created on multiple Mailbox servers, provided the servers are grouped into a database availability group (DAG), which is a boundary for continuous replication. Exchange 2010 mailbox databases can be replicated only to other Exchange 2010 Mailbox servers within a DAG. You can't replicate a database outside of a DAG, nor can you replicate an Exchange 2010 mailbox database to a server running Exchange 2007. For detailed information about DAGs, see Understanding Database Availability Groups.
  • All Mailbox servers in a DAG must be in the same Active Directory domain.
  • Like standby continuous replication (SCR), all mailbox database copies support the concepts of replay lag time and truncation lag time. Note however, careful planning must be performed before enabling these features.
  • All database copies can be backed up using an Exchange-aware, Volume Shadow Copy Service (VSS)-based backup application. However, the built-in support for Windows Server Backup is for active copies only. You can't use Windows Server Backup to back up passive copies.
  • Database copies can be created only on Mailbox servers that don't host the active (mounted and in-use) copy of a database. You can't create two copies of the same database on the same server.
  • 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, and on the same or different network subnets.
  • Database copies aren't supported between Mailbox servers with round trip network latency greater than 250 milliseconds (ms).

Mailbox Database Copies

You can create a mailbox database copy at any time. Mailbox 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.

You can create a mailbox database copy 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, specify the following information:

  • The name of the database being copied. Database names must be unique within the Exchange organization.
  • The name of the Mailbox server that will host the database copy. This server must be a member of the same DAG and must not already host a copy of the database.
  • 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 a numeric value used to break ties during database activation when multiple database copies meet the same criteria for activating. When Active Manager determines that multiple database copies meet the same criteria for activation, it looks to this value. The copy assigned the lowest activation preference number will be activated.

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