Exchange 2010: Using seedingPostponed results in a seeded database…


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.

 

image

 

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.


Comments (4)

  1. Harry says:

    Tim, really enjoy reading your post. Question for, we had experienced one of four DAG member loss and had to go through disaster recovery procedures for the failed DAG member (Exchange 2010 SP3):
    1.remove-mailboxdatabasecopy…
    2.remove-databaseavailabiltygroupmember -server the failednode

    then run setup /M:recoverserver

    luckily the database copy .edb and log files all are located on SAN disks and can be easily added back to recover server.

    if I use Add-MailboxDatabaseCopy –Identity DB1 -MailboxServer DAG-4 –SeedingPostponed for the recovered server, after that can I just use resume-mailboxdatabasecopy to restore log shipping without reseeding every database to the recovered server?

    Is this possible? or we will have run some eseutil in order to resume the DB copy?

    Many thanks.

  2. TIMMCMIC says:

    @Harry

    Thanks for posting! I’m glad you’re enjoying them.

    That is correct – when you perform the recovery and you swing the storage back adding the copies with seeding postponed and then resuming should do the trick. This assumes though that all of the log files necessary still exist on the source. (Unfortunately
    a lot of administrators start removing log files when they figure out their running out of disk space – which makes this process impossible). Also – the process is not limited to just SAN storage – it works with any storage that can be represented to the original
    operating system.

    TIMMCMIC

  3. Harry says:

    Tim, Thanks for your quick info, so no circular log, no committed logs (such as backup with flushing log), this should do the trick. it’s my bad. I forgot disable the circular log after the server crashing. so I have to reseed the DBs now. 15 TBs in total
    🙁

  4. TIMMCMIC says:

    @Harry…

    Disabling circular logging is not required for this to work. With circular logging enabled, and a server down, the database copies are failed. anytime a copy is failed, log files will not truncate via circular logging backups -> which is what allows this to
    work.

    TIMMCMIC