Exchange 2010: Using seedingPostponed results in a seeded database…

Artikel
05/21/2012

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:

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

Anonymous
July 22, 2015
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.
Anonymous
July 23, 2015
@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
Anonymous
July 24, 2015
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 :-(
Anonymous
July 26, 2015
@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

Freigeben über

Exchange 2010: Using seedingPostponed results in a seeded database…

Comments

Zusätzliche Ressourcen