Leaving the paths unchanged is preferred to minimize confusion as to where
the active copy should be. In this scenario, it is necessary to move the files, or mount the passive node
LUNs to replace the failed active ones.
Restore-StorageGroupCopy -Identity ???MB100ccr\first storage group\mailbox database???
If it is not possible to recover by moving the files or swapping LUNs, then the
Restore-StorageGroupCopy cmdlet should include the ReplaceLocations option to alter the
database and system paths:
Restore-StorageGroupCopy -Identity ???MB100ccr\first storage group\mailbox
database??? - ReplaceLocations:$true
Finally, the database can be mounted with the Mount-Database cmdlet:
Mount-Database -Identity ???MB100ccr\first storage group\mailbox database???
It is easy to see how the addition of LCR can greatly reduce the downtime due to disk failure or
corruption. LCR can be used to alter the standard backup process because the first level of recovery is
online disk. A company may choose to have short SLAs for database recovery, but use longer SLAs for
server failures.
Failover in Continuous Cluster Replication
Unlike LCR, CCR has a fully automated unplanned failover process. There are administrative settings
that tune the failover process. Because an unplanned failover may have data loss, it is possible to set the
rules under which the passive node will mount databases.
Pages:
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502