The Problem
The mailbox databases in a DAG can be in a failed state (for whatever reason). If we compare the Get-MailboxCopyStatus output for two DAG partners, we may see something like this:
Get-MailboxDatabaseCopyStatus DB1\EX13-1 | fl Name,Status,CopyQueueLength,ReplayQueueLength,ContentIndexState
Name : DB1\EX13-1
Status : Mounted
CopyQueueLength : 0
ReplayQueueLength : 0
ContentIndexState : Healthy
Get-MailboxDatabaseCopyStatus DB1\EX13-2 | fl Name,Status,CopyQueueLength,ReplayQueueLength,ContentIndexState
Name : DB1\EX13-2
Status : Failed
CopyQueueLength : 3
ReplayQueueLength : 0
ContentIndexState : Healthy
The "ContentIndexState" for both copies is "Healthy" but the status for database copy DB1\EX13-2 is "Failed". We can see the status for the mounted database in the output for DB1\EXCH-1 ("Mounted").
I do not have a screenshot of this particular situation but in the EMC, at the Organization level, Mailbox (role) section, we would see what we see here, except that the Copy Status for DB1 on the EX13-2 server would be "Failed" instead of Healthy.
The Solution
We have to reseed the database with the data from a healthy copy.
But first, we must suspend replication (no reseed possible if replication is not suspended).
So we suspend replication with this command:
[PS] C:\>Suspend-MailboxDatabaseCopy DB1\EX13-2
This would produce the same result in the EMC:
That operation changes the copy status of the database:
[PS] C:\>Get-MailboxDatabaseCopyStatus DB1\EX13-2 | fl Name,Status,CopyQueueLength,ReplayQueueLength,ContentIndexState
Name : DB1\EX13-2
Status : FailedAndSuspended
CopyQueueLength : 3
ReplayQueueLength : 0
ContentIndexState : Failed
We then update (or reseed) the failed database copy with the data from a good copy:
[PS] C:\>Update-MailboxDatabaseCopy DB1\EX13-2 -DeleteExistingFiles
Note: we have to overwrite the existing files, if present.
Here is the EMC equivalent:
We can select various options on this screen:
We click on "Update" to start the operation.
Note: heed the warning about the possible duration of the reseeding operation which could require several hours for larger databases.
In my case, the update process requires less than a minute (small test databases).
This is the result (to be compared to the original output above):
[PS] C:\>Get-MailboxDatabaseCopyStatus | fl Name,Status,CopyQueueLength,ReplayQueueLength,ContentIndexState
Name : DB1\EX13-1
Status : Mounted
CopyQueueLength : 0
ReplayQueueLength : 0
ContentIndexState : Healthy
[PS] C:\>Get-MailboxDatabaseCopyStatus DB1\EX13-2 | fl Name,Status,CopyQueueLength,ReplayQueueLength,ContentIndexState
Name : DB1\EX13-2
Status : Healthy
CopyQueueLength : 0
ReplayQueueLength : 0
ContentIndexState : Healthy
Thank you for reading the article about Exchange 2010 - DAG (Database Availability Group) - Part 3 - "Status - Fail" - suspend and reseed on the blog NEW TECH If you want to disseminate this article on please list the link as the source, and if this article was helpful please bookmark this page in your web browser by pressing Ctrl + D on your keyboard keys.
1 komentar :
Exchange 2010 - Dag (Database Availability Group) - Part 3 - "Status - Fail" - Suspend And Reseed ~ New Tech >>>>> Download Now
Balas>>>>> Download Full
Exchange 2010 - Dag (Database Availability Group) - Part 3 - "Status - Fail" - Suspend And Reseed ~ New Tech >>>>> Download LINK
>>>>> Download Now
Exchange 2010 - Dag (Database Availability Group) - Part 3 - "Status - Fail" - Suspend And Reseed ~ New Tech >>>>> Download Full
>>>>> Download LINK