スタンバイ連続レプリケーションの管理
適用先: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1
トピックの最終更新日: 2008-11-19
Microsoft Exchange 組織の日常的な管理タスクに加えて、スタンバイ連続レプリケーション (SCR) に固有のタスクがあります。一般に、SCR のための管理タスクには以下のものがあります。
- SCR のためのディスク格納域の構成とディスク ボリュームの管理。
- SCR の有効化と無効化。
- レプリケーション処理の監視。
- データベースのマウント、マウント解除、作成、および削除。
- ストレージ グループで SCR を有効にしている場合のストレージ グループ内の格納域またはデータベース ファイルの場所の移動。
- SCR ターゲットの状態の確認。
- レプリケーションと再生処理の管理。
- 破損からの回復。
これらのタスクについては後で説明します。
SCR の有効化および管理は、Exchange 管理シェルを使用してのみ行えます。Exchange 管理コンソールを使用して、SCR の有効化または無効化、SCR の状態の表示、SCR のさまざまな面の管理を行うことはできません。
スタンバイ連続レプリケーションのためのディスク格納域の構成
SCR には、特別に構成されたディスク格納域は必要ありません。SCR には、十分な要領を提供する格納域が必要です。同じストレージ グループに構成されているすべての SCR ターゲットに、同等のストレージ ソリューションを構成する必要があります。構成を完了させるには、ストレージ ベンダにより提供された構成手順に従うことをお勧めします。
SCR 環境でのディスク ボリュームの管理
SCR 環境の管理中は、Exchange サーバーに接続されたディスク ボリュームを管理することが必要になる場合があります。たとえば、保守やその他の理由で、ボリュームをシステムから一時的に切り離すことが必要になる場合があります。ストレージ グループのアクティブ コピーを含むディスク ボリュームに対して保守を実行する必要が生じた場合、ストレージ グループのアクティブ コピー内のデータベースをマウント解除する必要があります。ストレージ グループのパッシブ コピーを含むディスク ボリュームに対して保守を実行する必要が生じた場合は、レプリケーションを中断することによって、そのボリュームのすべての入出力 (I/O) を停止する必要があります。ディスク ボリュームの管理の詳細については、「SCR を使用する場合のディスク管理処理の準備方法」を参照してください。
スタンバイ連続レプリケーションの有効化
SCR は、Exchange 管理シェルを使用して New-StorageGroup コマンドレットまたは Enable-StorageGroupCopy コマンドレットを実行することによってのみ、有効にすることができます。どちらのコマンドレットにも、Microsoft Exchange Server 2007 Service Pack 1 (SP1) でいくつかの新しいパラメータが追加されています。
- -StandbyMachine このパラメータは、SCR ターゲットが含まれているコンピュータの名前を指定する際に使用します。このパラメータの値は、SCR を有効化するストレージ グループの msExchStandbyCopyMachines 属性の値の一部として設定します。msExchStandbyCopyMachines 属性は、Exchange 2007 SP1 を Exchange 組織に導入する際に Active Directory ディレクトリ サービス スキーマに追加される、複数値の Unicode 文字列です。
- -ReplayLagTime SCR ターゲット コンピュータにコピーされたログ ファイルを再生する前に Microsoft Exchange レプリケーション サービスが待つ時間の長さを指定します。このパラメータの形式は、(日数.時間:分:秒) です。この値の既定の設定は 24 時間です。この値に設定できる最大値は 7 日です。設定できる最小値は 0 秒です。ただし、この値に 0 秒を設定しても、ログの再生処理の既定の遅延 (50 のログ ファイル) には影響しません。設定すると、SCR を無効化して再度有効化しない限り、このパラメータの値を変更することはできません。
- -TruncationLagTime SCR ターゲット コンピュータにコピーされて再生されデータベースのコピーに反映されたログ ファイルを切り詰める前に Microsoft Exchange レプリケーション サービスが待つ時間の長さを指定します。この時間のカウントは、ログが再生されてデータベースのコピーに正常に反映されたときから開始します。このパラメータの形式は、(日数.時間:分:秒) です。この値に設定できる最大値は 7 日です。設定可能な最小値は 0 秒ですが、この値を 0 秒に設定すると、実質的にログ切り詰め処理における遅延はなくなります。設定すると、SCR を無効化して再度有効化しない限り、このパラメータの値を変更することはできません。
- -SeedingPostponed このパラメータは、SCR ターゲットの最初のシードを省略する際に使用できます。このパラメータを使用する場合、管理者は Update-StorageGroupCopy コマンドレットを使用して SCR ターゲットを手動でシードする必要があります。このパラメータは、Enable-StorageGroupCopy コマンドレットでのみ使用できます。この時点ではソース データベースが存在しないので、New-StorageGroup コマンドレットでは使用できません。
.gif "important")
重要 :再生またはトランザクションの遅延の設定を変更するには、まず SCR を無効にしてから、これらの設定の新しい値を使用して SCR を有効にする必要があります。
ReplayLagTime パラメータを使用して管理者が構成する再生の遅延のほかに、Exchange では、ReplayLagTime の値にかかわらず、特定の数のログ ファイルが SCR ターゲットに再生されるのを防ぐこともできます。次の数式を使用します。
Maximum of ("ReplayLagTime の値" または "X ログ ファイル")
ここで、X は 50 です。これにより、ローカル連続レプリケーション (LCR) またはクラスタ連続レプリケーション (CCR) などの連続レプリケーション環境内の SCR ソースで損失の大きいフェールオーバーが発生し、Restore-StorageGroupCopy コマンドレットを使用してオンラインになるような場合に、ストレージ グループを再シードせずに済みます。SCR ターゲットでの再生処理を遅延させることにより、SCR ソースで損失の大きいフェールオーバーが発生した場合に、SCR のコピーを再シードする必要が生じる可能性を最小限に抑えることができます。これは、SCR ソースにおけるデータ損失の性質により、2 つのコピーの時間が近くなるからです。
| 重要 : |
|---|
| 組み込みのラグ タイムである 50 のログ ファイルと、ReplayLagTime パラメータの値は、最初の SCR ターゲット データベースの作成に影響します。50 のトランザクション ログ ファイルが SCR ターゲット コンピュータにレプリケートされ、ReplayLagTime で指定された時間 (または ReplayLagTime の既定値の 24 時間) が経過するまで、SCR ターゲット データベースは作成されません。 |
ストレージ グループで SCR を有効にすると、SCR ソース上のストレージ グループと同じパスを使用して、SCR ターゲット コンピュータ上でストレージ グループのコピー (システム ファイル、ログ ファイル、およびデータベース ファイル) が自動的に作成および保持されます。
SCR を有効にした後は、Test-ReplicationHealth コマンドレットを使用して、各ストレージ グループの稼働状態を監視することをお勧めします。SCR を有効にする手順の詳細については、「既存のストレージ グループのスタンバイ連続レプリケーションを有効にする方法」および「新しいストレージ グループのスタンバイ連続レプリケーションを有効にする方法」を参照してください。
SCR およびログの切り詰め
SCR ターゲット データベースのバックアップを作成することはできないので、SCR ログの切り詰めはバックアップ時刻に基づいていません。代わりに、ログの切り詰めは、SCR ソースのチェックポイントおよび TruncationLagTime の値によって決まります。
SCR ソースが CCR 環境内のクラスタ化メールボックス サーバー (CMS) である場合、ログの切り詰めのロジックには、すべての SCR ターゲットによるログ ファイルの正常なコピーおよび検査が含まれます。これは、SCR ターゲットが使用できない場合、バックアップが作成されていても、SCR ソースでログの切り詰めは行われないことを意味します。
SCR 環境では、以下に基づいて、必要なすべてのログ ファイルを使用できる場合に、無効化されてから再度有効化された SCR ターゲットを再シードする必要はありません。
- ストレージ グループで循環ログが有効になっている場合、ログを削除すると、ログ シーケンス内に時間差が生じるため、有効化された SCR ターゲットを再シードする必要があります。
- ログ ファイルの切り詰めを含むバックアップを作成してある場合、ログを削除すると、ログ シーケンス内に時間差が生じるため、有効化された SCR ターゲットを再シードする必要があります。
上記のいずれの方法でもログ ファイルを切り詰められない場合は、無効化してから有効化する SCR を再シードする必要はありません。この場合、SCR ターゲットのログ ファイルを削除する必要がありますが、それらは SCR ソースから再度レプリケートされます。
無効化した SCR ターゲットを有効化する予定の場合は、SCR ターゲットが有効化され、有効化が必要な構成の変更が Active Directory 全体にレプリケートされるまで、ログ切り詰め操作 (循環ログの有効化、ログ切り詰めのバックアップの実行など) を実行しないことをお勧めします。
スタンバイ連続レプリケーションの無効化
SCR を無効にするには、Disable-StorageGroupCopy コマンドレットおよび StandbyMachine パラメータを使用します。SCR を無効にする場合は、StandbyMachine パラメータに適切な値を含めることが重要です。SCR ソースのストレージ グループでも LCR が有効になっていても、このコマンドの一部として StandbyMachine パラメータを含めなければ、ストレージ グループで LCR は無効になります。
ReplayLagTime または TruncationLogDelay パラメータの値を変更するには、SCR を無効にする必要があります。これらの値は、SCR が有効になっている間は変更できません。したがって、再生または切り詰めの遅延の設定を変更するには、まず SCR を無効化し、これらの設定に新しい値を使用して SCR を再度有効化する必要があります。
ストレージ グループの SCR を無効にするための詳細な手順については、「ストレージ グループのスタンバイ連続レプリケーションを無効にする方法」を参照してください。
レプリケーション処理の監視
SCR では特別な監視は必要ありませんが、ログ ファイルが正しくレプリケートされていることを確認するために、各ストレージ グループを定期的に監視することをお勧めします。Microsoft Operations Manager 2005 用 Microsoft Exchange Server 2007 管理パックには、次のような SCR 環境に関連したいくつかの重要な問題の警告が含まれています。
- Microsoft Exchange Replication Service が実行されていません。サービスを停止するとこのアラートを生成するイベントが繰り返し表示されなくなるため、この問題が解消されたかのように、関連付けられているアラートが表示されなくなることに注意してください。
- SCR ターゲットのコピーが失敗の状態にあります。
- SCR ターゲットのコピーは正常な状態であるが、ログのコピーまたは再生が遅れています。
Exchange 2007 Management Pack で生成された上記の警告は、できるだけ早く調査および解決してください。
Test-ReplicationHealth コマンドレット
Exchange 2007 SP1 には、Test-ReplicationHealth と呼ばれる新しいコマンドレットが導入されています。このコマンドレットは、連続レプリケーション (LCR、CCR、および SCR) および連続レプリケーション パイプラインの予防的な監視を行うように設計されています。Test-ReplicationHealth コマンドレットは、レプリケーション、クラスタ サービス、ストレージ グループのレプリケーション、および再生の状態のあらゆる点をチェックして、レプリケーション システム全体の概要を提供します。特に、Test-ReplicationHealth コマンドレットは次の表に示すテストを実行します。
Test-ReplicationHealth コマンドレットにより実行されるテスト
| Test | 説明 |
|---|---|
クラスタ ネットワークの状態 |
ローカル ノード上で検出された、クラスタにより管理されるすべてのネットワークが実行中であることを確認します。このテストは CCR 環境にのみ適用されます。 |
クォーラム グループの状態 |
クォーラム リソースを含むクラスタ グループが Healthy であることを確認します。このテストは CCR 環境にのみ適用されます。 |
ファイル共有クォーラムの状態 |
ファイル共有監視付きのマジョリティ ノード セット クォーラムにより使用されている FileSharePath の値が到達可能であることを確認します。このテストは CCR 環境にのみ適用されます。 |
クラスタ化メールボックス サーバー グループの状態 |
グループのすべてのリソースがオンラインであることを確認することにより、CMS が正常な状態であることを確認します。このテストは CCR 環境にのみ適用されます。 |
ノードの状態 |
クラスタ内のノードで一時停止状態のものがないことを確認します。このテストは CCR 環境にのみ適用されます。 |
DNS 登録の状態 |
[続行する場合は DNS 登録を要求する] 設定のあるすべてのクラスタ管理ネットワーク インターフェイスがドメイン ネーム システム (DNS) 登録を通過したことを確認します。このテストは CCR 環境にのみ適用されます。 |
レプリケーション サービスの状態 |
ローカル ノード上の Microsoft Exchange Replication Service が正常であることを確認します。 |
ストレージ グループのコピーの中断 |
任意のストレージ グループで連続レプリケーションが中断されているかどうかを調べます。 |
ストレージ グループのコピーの失敗 |
任意のストレージ グループのコピーが失敗の状態にあるかどうかを調べます。 |
ストレージ グループのレプリケーション キューの長さ |
任意のストレージ グループのレプリケーション コピー キューの長さが、ベスト プラクティスのしきい値より長いかどうかを調べます。現在、これらのしきい値は以下のとおりです。
|
フェールオーバー後にマウントが解除されたデータベース |
フェールオーバーの発生後に、任意のデータベースのマウントが解除されたか失敗したかどうかを調べます。このテストは、フェールオーバーの結果として障害が発生したデータベースのみをチェックします。 |
データベースのマウントとマウントの解除
SCR 環境では、データベースのマウントまたはマウント解除が必要になる場合があります。SCR ソースのストレージ グループまたはデータベースの再構成または保守が必要になった場合は、作業が行われている間、両方と通信するサービスをブロックする必要があります。この作業が必要になるのは、再構成を実行する場合や、サーバーやデータベースに関する問題を修正する場合です。マウントが解除されたデータベースへはアクセスできなくなります。
ストレージ グループとデータベース ファイルの場所の移動
SCR が有効なストレージ グループで、データベースの場所を変更することができます。SCR 環境では、各コピーに 1 つずつ、2 つのデータベース ファイルがあります。ストレージ グループ ファイルまたはデータベース ファイルを移動する際は、両方のコピーの場所をまとめて変更する必要があります。
.gif "note") 注 : |
|---|
| ストレージ グループ ファイルおよびデータベース ファイルへの完全なパスが、SCR ソースとすべての SCR ターゲットで一致している必要があります。 |
ストレージ グループ ログおよびシステム ファイルの場所の再構成と、SCR 環境でのデータベース ファイルの場所の再構成には、よく似た手順が使用されます。SCR が有効になっているストレージ グループでログ ファイルとシステム ファイルの場所を変更する方法の詳細については、「スタンバイ連続レプリケーション環境のストレージ グループを移動する方法」を参照してください。SCR 環境でのデータベース ファイルの場所を変更する方法の詳細については、「スタンバイ連続レプリケーション環境でデータベースを移動する方法」を参照してください。
| 重要 : |
|---|
| データベースをボリュームのルートに置くことはできません。 |
状態情報の表示
状態の監視はすべて、Exchange 管理シェルを使用して実行します。Exchange 管理コンソールでは、コピーの状態および SCR に関するその他の情報は表示されません。ストレージ グループの SCR を有効にした後は、Exchange 管理シェルを使用して、ストレージ グループおよびそのデータベースの SCR 固有の構成情報を表示することができます。
スタンバイ連続レプリケーションの状態情報
Exchange 2007 は、SCR コピーについてさまざまな状態情報を公開します。次の表は、SCR が有効になっているストレージ グループで使用できる状態情報を示しています。状態情報を取得する方法の詳細については、「スタンバイ連続レプリケーションの状態を表示する方法」を参照してください。
| 注 : |
|---|
| 次の表に、Get-StorageGroupCopyStatus コマンドレットの完全な出力を表示した場合のプロパティの一覧を表示される順序で示します。 |
SCR が有効なストレージ グループで使用できる状態情報
| プロパティ | 説明 |
|---|---|
Identity |
サーバーおよび照会するストレージ グループの名前です。 |
StorageGroupName |
クエリの対象となるストレージ グループの名前です。 |
SummaryCopyStatus |
SCR コピーの現在の全体的な状態です。使用可能な値は次のいずれかです。
|
Failed |
データベースまたはログの検証で、レプリケーションを妨げるような矛盾が識別されました。または、アクティブ コピーかパッシブ コピーに構成またはアクセスの問題があります。値は True または False です。 |
FailedMessage |
レプリケーションの失敗の原因となった状態を示すテキスト メッセージです。レプリケーションで問題のある部分は、このメッセージで示されたものだけとは限りません。 |
Seeding |
シードが進行中です。値は True または False です。 |
[中断] |
パッシブ コピーのレプリケーション (および中継) が停止されました。これは、データベースのアドバンスとログのコピーを妨げます。値は True または False です。 |
SuspendComment |
管理者による省略可能なコメントで、レプリケーション処理が停止された理由または注記を示します。 |
CopyQueueLength |
パッシブ コピー ログ ファイル フォルダにコピーされるのを待っているトランザクション ログ ファイルの数です。コピーは、破損のチェックが終了するまで完了したと見なされません。 |
ReplayQueueLength |
コピーされ、パッシブ コピーに再生されるのを待っているトランザクション ログ ファイルの数です。 |
LatestAvailableLogTime |
最後に検出された新しいトランザクション ログ ファイルのソース ストレージ グループのタイムスタンプです。 |
LastCopyNotificationedLogTime |
アクティブ ストレージ グループによって生成された最新のログに関連付けられており、コピーから認識されている日時です。 |
LastCopiedLogTime |
最後に正常にコピーされたトランザクション ログ ファイルのソース ストレージ グループのタイムスタンプです。 |
LastInspectedLogTime |
最後に正常に検査されたトランザクション ログ ファイルのターゲット ストレージ グループのタイムスタンプです。 |
LastReplayedLogTime |
最後に正常に再生されたトランザクション ログ ファイルのターゲット ストレージ グループのタイムスタンプです。 |
LastLogGenerated |
ストレージ グループのアクティブ コピーに生成されたことがわかっている最後のログ生成番号です。 |
LastLogCopied |
パッシブ コピー ログ フォルダに正常にコピーされた最後のログ生成番号です。 |
LastLogNotified |
アクティブ ストレージ グループによって生成され、コピーから認識されている最後のログ生成番号です。 |
LastLogInspected |
一貫性と破損について検査された最後のログ生成番号です。 |
LastLogReplayed |
ストレージ グループのパッシブ コピーに正常に再生された最後のログ生成番号です。 |
LatestFullBackupTime |
最後の完全バックアップの日時です。 |
LatestIncrementalBackupTime |
最後の増分バックアップの日時です。 |
SnapshotBackup |
バックアップは、従来のストリーミング API またはボリューム シャドウ コピー サービス (VSS) を使用して作成されています。値は True または False です。 |
SummaryCopyStatus、CopyQueueLength、ReplayQueueLength、および LastInspectedLogTime の値を調べると、SCR コピーが正常な状態にあるかどうかをすばやく評価できます。これらのプロパティは、SCR コピーが正常に機能しているかどうかと、SCR コピーがログのコピーと再生の両方において相対的に最新の状態にあるかどうかを示します。以下の条件が当てはまる場合は、問題の原因を特定して修正する必要があります。
- コピーが正常でない状態になったまま長時間が経過している。
- コピー キューの長さが 5 を超えている。
- 再生キューの長さが 20 を超えている。
- 最後に検査されたログ時刻が現在の時間を示していない。これを引き起こす原因として考えられるのは、ストレージ グループに多くの変更が加えられていないか、レプリケーション サービスが停止しているかの 2 つです。
再生キューの長さとコピー キューの長さの値は、パフォーマンス カウンタとして利用可能です。これらは、MSExchange Replication パフォーマンス オブジェクトの下にある、CopyQueueLength および ReplayQueueLength パフォーマンス カウンタです。
まれに、レプリケーションの状態によって、判断を誤りかねないような状況が生じることがあります。以下に、そのような状況を一覧で示します。
- アクティブでない (つまり、変更されていない) ストレージ グループが正常な状態ではない可能性があるときに、このストレージ グループが Healthy と報告されることがあります。この状況は、ログが再生されるまで、正常ではない状態にあることを検出できなかったために発生する場合があります。
- レプリケーションの初期化中は、レプリケーションの状態が評価されているために正確でないことがあります。初期化が完了すると、状態は更新されます。
- データベースのマウントが解除されている場合は、LastLogGenerated フィールドの値が間違っている可能性があります。ただし、ストレージ グループ コピーのレプリケーションが行われている場合は、エンド ユーザーのコンテンツがあるログはすべてレプリケートされます。
- ログ ストリームの途中に足りないログが 1 つ以上ある場合、パッシブ コピーは引き続き回復を試みます。その際に、レプリケーションの状態は Failed と Healthy の間で切り替わります。再生とコピーのキューは拡大し続けます。
- ごくまれに、ログの検証が正常に行われても、再生に失敗することがあります。この場合、システムは回復を試みるときに、状態を Failed と Healthy の間で切り替えます。再生とコピーのキューは拡大し続けます。
SCR ターゲットの整合性の検証
SCR を使用する場合は、データベース ファイルおよびトランザクション ログ ファイルに対して物理的な整合性チェックを実行することにより、定期的に各 SCR ターゲットのコピーの整合性を検証することをお勧めします。物理的な整合性チェックでは、トランザクション ログ ファイルおよびデータベース ファイルが破損しているかどうかを検査します。チェックを実行するには、コマンドライン バージョンの Microsoft ボリューム シャドウ コピー サービス ツール (VSSAdmin.exe) および Exchange Server データベース ユーティリティ (Eseutil.exe) を使用します。VSSAdmin および Eseutil を使用して、トランザクション ログ ファイルおよびデータベース ファイルの物理的な破損をチェックする方法の詳細については、「スタンバイ連続レプリケーション コピーを検証する方法」を参照してください。
| 注 : |
|---|
| データベースに対して物理的な整合性チェックを実行する前に、ストレージ グループに対するすべてのレプリケーション処理を一時的に中断する必要があります。レプリケーション処理を中断するには、Exchange 管理シェルで Suspend-StorageGroupCopy コマンドレットを使用します。整合性チェックが完了したら、Resume-StorageGroupCopy コマンドレットを使用してトランザクション ログの再生処理を再開できます。検証は運用時間外に実行し、再生処理を中断する時間は可能な限り短くすることをお勧めします。これは、ストレージ グループのコピーを中断すると SCR コピーへのすべての更新が中断され、一部のコンテンツが障害に対して脆弱になるためです。 |
レプリケーションと再生の管理
SCR 環境でのログ ファイルのレプリケーションと再生の管理には、主に以下の作業が含まれます。
- ストレージ グループ コピーへのレプリケーションの中断
- ストレージ グループ コピーへのレプリケーションの再開
- ストレージ グループの再シード
ストレージ グループ コピーとそのデータベースに対する変更の中断と再開
さまざまな理由から、トランザクション ログのレプリケーション処理の中断と再開を行う必要が生じる場合があります。トランザクション ログのレプリケーションは、Microsoft Exchange Replication Service が実行されており、ストレージ グループで SCR が有効になっており、SCR ソースと SCR ターゲットの両方が稼働している場合に発生します。ソースまたはターゲットのいずれかが利用できなくなった場合、レプリケーションを停止する必要があります。また、シードなどの一部の管理作業を行うには、SCR が有効になっているストレージ グループのレプリケーションを中断する必要があります。ターゲットのデータ ファイルへのすべてのアクセスを停止する必要がある場合は、レプリケーションを中断する必要があります。
SCR ターゲットの利用を制御する必要が生じることもあります。この作業が必要になるのは、再構成を実行する場合や、サーバーやデータベースに関する問題を修正する場合です。SCR ターゲットの物理的な整合性チェックを実行するには、ログ再生の中断も必要です。データベース コピーの更新を制御する必要がある場合は、SCR ターゲットのレプリケーションを中断する必要があります。SCR ターゲット ログをなんらかの理由で操作している場合にも、レプリケーションを中断する必要があります。
SCR コピーに対する変更のレプリケーションを中断する方法の詳細については、「スタンバイ連続レプリケーションの対象への変更を中断する方法」を参照してください。SCR コピーに対する変更のレプリケーションを再開する方法の詳細については、「スタンバイ連続レプリケーション ターゲットへのレプリケーションを再開する方法」を参照してください。パッシブ コピーのトランザクション ログ ファイルおよびデータベース ファイルに整合性チェックを実行する方法の詳細については、「スタンバイ連続レプリケーション コピーを検証する方法」を参照してください。
ストレージ グループ コピーのシードと再シード
SCR 環境でのストレージ グループ コピーのシードおよび再シードは、Update-StorageGroupCopy コマンドレットを StandbyMachine パラメータ (Exchange 2007 SP1 で追加された新しいパラメータ) と共に使用して実行します。
SCR ターゲットをシードまたは再シードする手順の詳細については、「タンバイ連続レプリケーションの対象をシードする方法」を参照してください。
破損時のレプリケーション状態の評価による破損からの回復
データベース コピーに障害または破損が発生した後は、SCR ターゲットを使用して直ちに運用を続行するかどうかを評価する必要があります。SCR は、この決定を支援するための以下の重要情報を提供します。
- エラー発生時のコピーの状態
- エラー発生時の再生キューおよびコピー キュー
- エラー発生時点で検査された最後のログ時刻
情報は、Get-StorageGroupCopyStatus コマンドレットを使用して取得できます。この情報を取得する方法の詳細については、「スタンバイ連続レプリケーションの状態を表示する方法」を参照してください。
| 注 : |
|---|
| ログが最後に検査された時刻は、SCR ソースの最も最近に行われた変更に関する情報を提供します。これは、Microsoft Exchange Replication Service の停止時にキューの長さが正確でないために Microsoft Exchange Replication Service が開始しなかった場合に、発生したエラーの検出を支援します。 |
コピー キューの長さには、エラー発生時の SCR ソースについて取得可能な最も優れた情報が含まれます。この情報とエラーの発生したデータベースの回復時間の評価に基づいて、利用可能な SCR ターゲットを有効化するかどうかを以下のように決定する必要があります。
再生キューの長さが大きい場合は、回復に時間がかかる可能性がありますが、重大なデータ損失が発生するという意味ではありません。
コピー キューの長さが大きい場合は、多くのログが失われています。データベースが有効化されている場合は、ほぼ最後にログがコピーされたときの状態にまで復元されます (Get-StorageGroupCopyStatus コマンドレットにより提供されます)。
検査された最後のログ時刻がエラーが発生した時刻よりかなり前の場合、Microsoft Exchange Replication Service が停止しており、その他のキュー情報が不正確であると考えられます。
注 :アクティブ コピーの現在の状態は最新の状態と同期が取れていないため、SCR の性質や外部遅延と通信エラーが原因で、コピー キューの長さが正確でなくなる可能性があります。一般に、不正確さはエラーの発生前後の約 1 分間の処理に限定されます。 注 :エラーの発生したデータベースは、SCR ターゲットのシードに使用できません。
参照している情報が最新であることを確認したり、他の Exchange Server 2007 ドキュメントを見つけたりするには、Exchange Server TechCenter を参照してください。