Moving a database between DAGs

A recent email discussion between MVPs focused on a topic that I totally missed in my Microsoft Exchange Server 2010 Inside Out book (also available at Amazon.co.uk), so think of this as an update to chapter 7. The problem arises after you set up a Database Availability Group (DAG) with mailbox servers and multiple databases and copies and then discover that you need to move a database to another DAG. What’s the best way to proceed?

Database portability was a major focus for Exchange 2010 as it laid the foundation for the native high availability features centered on the DAG that now exist in the product. The unbreakable connection that exists in all previous versions of Exchange to tie a database to a specific server no longer exists and the active copy of a database can be mounted on any server within a DAG. But a limitation still exists in that Exchange defines the boundary for a database’s “switchability” to be the DAG that “owns” the database (beneath the surface, the Active Directory object for the DAG maintains a list of all the databases in the DAG). This small but important detail means that an Exchange 2010 mailbox database is much more portable than previously but boundaries still exist in some circumstances. The notion of a totally portable database is not yet implemented.

Databases owned by a DAG

Every mailbox database is “owned” by a mailbox server or a DAG. When a mailbox database is created on a standalone server, its owner or “master” is set to be that server. If the mailbox server is then added to a DAG, the databases owned by the server are taken over by the DAG as this then allows the DAG to move the database between servers in the DAG once copies are created.

The obvious solution is to use the move mailbox function to move all the mailboxes from the database to a database or databases in the second DAG. This is easy for a small number of mailboxes but requires some planning for databases that hold hundreds or even thousands of mailboxes, but it’s very feasible. In fact, Microsoft moves mailboxes all the time inside their Office 365 datacenters to balance mailboxes across the databases used for their Exchange Online service.

The steps involved are:

• Identify the mailboxes to be moved. You can use the Get-Mailbox -Database command to create a list of the mailboxes and output it to a text file or simply sort the display of EMC by database.
• Decide how and when to move the mailboxes. One approach is to move the mailboxes in batches and use the “suspend when ready to complete” flag. This tells the Mailbox Replication Service (MRS) to work in the background to create the new mailbox in the target database, enumerate the data in the source mailbox and copy it to the new mailbox and then pause to wait for you to release the move to completion. The copying of the data might be performed overnight or over a weekend when overall system and network demand is low. You can then check the move reports to ensure that all has gone well before resuming the moves. When the moves are resumed, MRS enumerates the source mailbox again to discover what changes have occurred since the move and then copy the delta to the new mailbox before switching pointers in Active Directory to complete the move.
• Check whether any arbitration mailboxes or discovery search mailboxes need to be moved. Remember that discovery search mailboxes can hold very large amounts of information retrieved through searches so these mailboxes can take a long time to move.
• After all the mailboxes have been moved, you can remove the mailbox database and its copies from the DAG and eventually delete it.

Moving mailboxes works well but can become a mundane exercise in shuttling data to and fro. A second idea was proposed by Tim McMichael of Microsoft. He thought that it would be possible to use a “swing server” to transport the database from one DAG to another. In this scenario, you would commission a specific mailbox server and introduce it into the first DAG. You then transfer a copy of the mailbox database to be transferred to that server and make it active. Next, you remove all other copies of the mailbox database so that the only copy is now present on the swing server. You then remove the swing server from the first DAG and add it to the second DAG before completing the process by creating whatever number of additional copies of the database are necessary in the second DAG. Finally, you remove the copy of the database from the swing server and remove it from the second DAG.

There’s no doubt that the swing server technique will work and I see a great deal of value in it in a situation where either multiple databases have to be moved between DAGs or the volume of the data in the mailboxes to be relocated is so large that you cannot use the move mailbox technique to accomplish the goal in a reasonable timeframe. However, there are some downsides to the swing server technique. First, it obviously requires additional hardware. Second, there will be a time when the mailbox database (or databases) lose redundancy as you have to reduce them to just one copy before it’s possible to move between DAGs. The redundancy can be reintroduced as soon as the databases join the second DAG but even so, it will take time for the copies to be seeded. Last, this is a moderately complex multi-step technique that I am loathe to recommend within a production environment.

The complexity can be largely addressed by scripting the steps to move databases, remove copies, remove from the first DAG, join the second DAG, and recreate copies but that script does not exist today and it needs to be developed, tested, and debugged. By comparison, we have lots of experience of moving mailboxes and Exchange 2010 allows the moves to be performed offline in the background, paused before final completion, and batched in convenient sets for movement. I therefore prefer the move mailbox approach.

Now that I have poured cold water on Tim’s idea, let me conclude by telling you that he is an acknowledged expert in all matters to do with Windows Failover Clustering and DAGs. Therefore, you should consider coming to listen to Tim and many other experts (including Kevin Allison, General Manager of the Microsoft Exchange engineering group) speak at the Fall 2011 Exchange Connections conference in Las Vegas (October 31 to November 3). An early bird discount of $100 is available until August 1. If you add the code “SPKR” to your registration, you’ll get an additional $50 discount.

- Tony

Advertisement