When you’re running an Exchange 2013 database availability group you will eventually need to deal with a failed database copy that needs to be reseeded.
Database copies may be in a failed state due to a variety of reasons, such as a hardware failure on the underlying storage system. After resolving the root cause of a failed database copy you then need to reseed the copy, which is a process that creates a new copy of the database by replicating the data from another DAG member that hosts a healthy copy.
To demonstrate how to reseed a failed database copy I’ve first caused a failure of one of my databases, which can be seen here in the output of the Get-MailboxDatabaseCopyStatus cmdlet.
[PS] C:\>Get-MailboxDatabaseCopyStatus * Name Status ---- ------ Mailbox Database 1\E15MB1 Healthy Mailbox Database 2\E15MB1 FailedAndSuspended Mailbox Database 1\E15MB2 Mounted Mailbox Database 2\E15MB2 Mounted
If you’re looking for guidance to resolve failed content indexes in your database availability group, see PowerShell Tip: Fix All Failed Exchange Database Content Indexes.
The reseed operation can be started using either the Exchange Admin Center or the Exchange Management Shell (PowerShell).
Preparing to Reseed a Database Copy
There are a number of considerations when reseeding a database copy.
First, the time required for the reseed to complete will depend on the size of the database and the network performance between the source and destination servers.
By default the reseed will use the DAG member hosting the active database copy as the source.
If the database is 500Gb in size, that is 500Gb of database that needs to be copied across the network, plus the transaction log files and the content index for that database. This can add up to a lot of data that needs to travel across your network.
If the DAG members exist only within a single site connected by high speed LAN then this will not likely be a concern.
However if the DAG members exist in multiple sites across a WAN then it may be more of an issue.
Fortunately, you can specify a source server for the database reseed, which allows you to select a server that has better connectivity to reseed from, such as another DAG member within the same site as the server with the failed database copy.
The options for selecting a reseed source will be demonstrated below.
Reseeding a Database Copy Using the Exchange Admin Center
Open the Exchange Admin Center and navigate to Servers -> Databases. Select the database that has the failed copy.
On the database copy that is shown as failed click the Update link.
You can click Browse and specify a source server if necessary, otherwise click Save to reseed from the server that hosts the active database copy.
Wait for the reseed operation to complete.
When the reseed operation has finished the database copy should now be healthy.
Reseeding a Database Copy using the Exchange Management Shell
We can also perform reseeds using the Update-MailboxDatabaseCopy cmdlet.
The database to reseed is entered in the format “Database Name\Server Name”, for example:
[PS] C:\>Update-MailboxDatabaseCopy "Mailbox Database 2\E15MB1"
To specify a source server for the reseed use the -SourceServer parameter as well.
[PS] C:\>Update-MailboxDatabaseCopy "Mailbox Database 2\E15MB1" -SourceServer EXMB3
If you receive an error message that log files already exist in the transaction log path for the database you can use the -DeleteExistingFiles parameter to tell the Exchange server to remove those files before beginning the reseed.
[PS] C:\>Update-MailboxDatabaseCopy "Mailbox Database 2\E15MB1" -DeleteExistingFiles
Finally, for long reseeds where you do not want to leave your Exchange Management Shell open, or when scripting a reseed and you don’t want the script to have to wait for the reseed to complete, you can use the -BeginSeed parameter.
[PS] C:\>Update-MailboxDatabaseCopy "Mailbox Database 2\E15MB1" -BeginSeed
Of course those parameters can be used in conjunction with each other, for example:
[PS] C:\>Update-MailboxDatabaseCopy "Mailbox Database 2\E15MB1" -DeleteExistingFiles -BeginSeed -SourceServer E15MB3
Monitoring Database Copy Health
If you do not already have a monitoring solution in place for your Exchange 2013 DAG I encourage you to try my Get-DAGHealth.ps1 or Test-ExchangeServerHealth.ps1 scripts.
Related posts:
This article How to Reseed a Failed Database Copy in Exchange Server 2013 is © 2013 ExchangeServerPro.com
Get more Exchange Server tips at ExchangeServerPro.com