Before we start talking about how to perform a manual seeding of a database copy, it would be a good idea to define...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
the term seeding in terms of LCR. Seeding is the process whereby a database is added to a storage group copy. This can be a blank database or a copy of the database the storage group uses as the production database.
When you enable LCR on a storage group using the EMC or via the EMS using the Enable-DatabaseCopy and Enable-StorageGroupCopy CMDlets, seeding normally takes place automatically. If it happens automatically, why should we even care about it, then? The answer is that there are a few situations in which manually seeding is required.
- The first is after you have performed an offline defragmentation of the production database belonging to the storage group for which you have enabled LCR.
- The second is if or when Exchange detects a corrupt log file, which the Microsoft Exchange Replication Service cannot replay into the database copy.
- The third is after a page scrubbing of a database on the active node in a Cluster Continuous Replication (CCR) setup occurs, and you then want to propagate these changes to the passive node in the CCR setup.
Yes, you're right, the last one isn't really related to LCR but only continuous replication in clustered environments, where CCR is used. We'll talk much more about CCR later in this chapter.
Running this command will create a temporary temp-seeding folder, and after a little while the seeding will take place, as shown in Figure 8.19.
When seeding has taken place, the Microsoft Exchange Replication Service will start to replicate any .log, .chk, and .jrs files to the folder paths. When it's finished, you can resume LCR for the storage group, and you're back in business.
If you don't want to delete any .log, .chk, .jrs, and .edb files manually before running the Update-StorageGroupCopy CMDlet, you can tell the CMDlet to do it for you using the DeleteExistingFiles parameter. This method requires that you confirm the deletion of these files, as shown in Figure 8.20. The method you use is up to you, since they do the same thing.
In addition, you can use the ManualResume parameter if you don't want replication to occur automatically on the storage group copy.
Another method available for seeding a database copy is to dismount the database in the EMC, suspend LCR for the storage group containing the database, and then copy the .edb file to the LCR copy folder using Windows Explorer. When the file has been copied, you then mount the database again using the EMC and resume LCR. Bear in mind that if you choose this method, your end users will be disconnected until the database is mounted. So unless there's a specific reason that you would use this method, we recommend that you use the StorageGroupCopy CMDlet.
Managing Local Continuous Replication in Exchange 2007
Part 1: Exchange 2007 Local Continuous Replication overview
Part 2: Enabling Local Continuous Replication on a storage group
Part 3: Viewing the status for a Local Continuous Replication copy
Part 4: Switching to the LCR copy for database disaster recovery
Part 5: Suspending and resuming LCR for an Exchange 2007 storage group
Part 6: Manually adding an Exchange 2007 database to a storage group copy
Part 7: Use Exchange Eseutil for a passive storage group copy integrity check
Part 8: Disabling LCR on an Exchange 2007 storage group
Part 9: Adding Local Continuous Replication performance objects and counters
Part 10: Exchange 2007 LCR administration summarized
|This chapter excerpt from How to Cheat at Configuring Exchange Server 2007: Including Outlook Web, Mobile, and Voice Access, by Henrik Walther, is printed with permission from Syngress, a division of Elsevier, Copyright 2007.
Click here for the chapter download.