In Exchange 2010 the add-mailboxdatabasecopy command is utilized to add mailbox database copies to database availability group members. When a copy is first added to a member the database is automatically seeded along with the content index. In some instances administrators desire to add a copy but not immediately invoke database seeding. In order to do this the add-mailboxdatabasecopy command is run with the –seedingPostponed switch.
In some instances administrators have noticed that when adding a database copy with the seedingPostponed switch that the copy is healthy and the database has “seeded”. Let us take a look at how this can happen…
A new database is created on the Exchange 2010 server and mounted. This results in a new log stream and a new edb file. The administrator invokes the add-mailboxdatabasecopy command with the –seedingPostponed switch.
Add-MailboxDatabaseCopy –Identity DB1 -MailboxServer DAG-2 –SeedingPostponed
The command completes successfully. The copy is verified using the get-mailboxdatabasecopystatus command.
[PS] C:\>Get-MailboxDatabaseCopyStatus DB1\*
Name Status CopyQueue ReplayQueue LastInspectedLogTime ContentIndex
Length Length State
---- ------ --------- ----------- -------------------- ------------
DB1\DAG-1 Mounted 0 0 Healthy
DB1\DAG-2 Healthy 0 0 5/7/2012 8:56:09 AM Healthy
The copy status shows healthy even though the database was not seeded. How did this occur? When a database is mounted for the first time the log sequence is created first – this is to allow us to actually log the creation of the EDB file. When looking at the log records of the first log file you can see a createDB record populated:
[PS] H:\DB1 > eseutil /ml .\E0400000001.log /v
Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 14.02
Copyright (C) Microsoft Corporation. All Rights Reserved.
Initiating FILE DUMP mode...
Base name: E04
Log file: .\E0400000001.log
lGeneration: 1 (0x1)
Checkpoint: (0x3A,FFFF,FFFF)
creation time: 05/07/2012 08:39:17
prev gen time: 00/00/1900 00:00:00
Format LGVersion: (7.3704.16.2)
Engine LGVersion: (7.3704.16.2)
Signature: Create time:05/07/2012 08:39:17 Rand:2179103003 Computer:
Env SystemPath: h:\DB1\
Env LogFilePath: h:\DB1\
Env Log Sec size: 512 (matches)
Env (CircLog,Session,Opentbl,VerPage,Cursors,LogBufs,LogFile,Buffers
( off, 1027, 51350, 16384, 51350, 2048, 2048, 29487
Using Reserved Log File: false
Circular Logging Flag (current file): off
Circular Logging Flag (past files): off
Checkpoint at log creation time: (0x1,8,0)
Last Lgpos: (0x1,A,0)
==================================
Op # Records Avg. Size
----------------------------------
Others 294 3
Begin 0 0
Commit 0 0
Rollback 0 0
Refresh 0 0
MacroOp 0 0
CreateDB 1 113
AttachDB 0 0
DetachDB 0 0
ShutDown 0 0
CreateFDP 0 0
Convert 0 0
Split 0 0
Merge 0 0
Insert 0 0
Replace 0 0
Delete 0 0
UndoInfo 0 0
Delta 0 0
SetExtHdr 0 0
Undo 0 0
EmptyTree 0 0
BeginDT 0 0
PreCommit 0 0
PreRollbk 0 0
FFlushLog 0 0
Convert 0 0
FRollLog 0 0
Split2 0 0
Merge2 0 0
Scrub 0 0
PageMove 0 0
PagePatch 0 0
McroInfo 0 0
ExtendDB 0 0
Ignored 0 0
Ignored 0 0
Ignored 0 0
Ignored 0 0
Ignored 0 0
Ignored 0 0
Ignored 0 0
==================================
Number of database page references: 0
Integrity check passed for log file: .\E0400000001.log
Operation completed successfully in 0.343 seconds.
When reviewing the file system on the target node administrators note that logs and an EDB file do exist.
Adding a database copy with seedingPostponed does not result in a copy that is suspended. The replication service acknowledges the copy has been added, determines that the first log file exist and contains the createDB record, and subsequently begins copying log files. As log files are copied they are replayed on the target server, processing the createDB record, resulting in the edb file creation. The database is effectively seeded through shipping and replaying the log sequence.
What happens when the first log file does not exist – for example in situations where a backup has been performed? After adding the copy with seedingPostponed the administrator is presented with a warning verifying that database seeding is required:
WARNING: Replication is suspended for database copy 'DB1' because the database copy needs to be seeded.
When reviewing the copy status with get-mailboxdatabasecopystatus the added copy is now suspended:
Name Status CopyQueue ReplayQueue LastInspectedLogTime ContentIndex
Length Length State
---- ------ --------- ----------- -------------------- ------------
DB1\DAG-1 Mounted 0 0 Healthy
DB1\DAG-2 FailedAndSus... 63 0 Failed
At this time the database can be manually seeded using the update-mailboxdatabasecopycommand.
It is important to remember that seedingPostponed does not always results in a suspended copy. If using seedingPostpostponed with a new database that has the first log file the administrator must manually suspend the copy after adding it to ensure that no logs ship and no database is created on the target until manual seeding is performed.