メールボックスデータベースコピーを管理

適用対象: yes-img-16 2016 yes-img-19 2019 yes-img-se Subscription Edition

Exchange Serverでは、Exchange 管理コンソール (EAC) または Exchange 管理シェルを使用して、データベース可用性グループ (DAG) の作成、構成、メールボックスサーバーメンバーの設定後にメールボックスデータベースのコピーを追加できます。

データベースコピーの管理

データベースの複数のコピーが作成されたら、EAC または Exchange 管理シェルを使用して、次のタスクを実行できます。

各コピーの正常性と状態を監視します。
データベースコピーに関連付けられている他の管理タスクを実行します。例:
- データベースのコピーを一時停止または再開します。
- データベースコピーをシードします。
- データベースのコピーを監視します。
- データベースコピー設定を構成する
- データベースコピーを削除します。

データベースコピーの中断と再開

計画メンテナンスの実行など、さまざまな理由で、データベースコピーの継続的なレプリケーションアクティビティを中断して再開することが必要になる場合があります。さらに、シード処理などのいくつかの管理タスクでは、先にデータベースコピーを中断する必要があります。データベースのパス、またはデータベースのログファイルを変更する場合には、すべてのレプリケーション活動を中断することをお勧めします。 EAC を使用するか、Exchange 管理シェルで Suspend-MailboxDatabaseCopy コマンドレットおよび Resume-MailboxDatabaseCopy コマンドレットを実行すると、データベースコピー活動を中断して再開できます。データベースコピーの連続レプリケーション活動の中断または再開に関する詳しい手順については、「メールボックスデータベースコピーを中断または再開する」を参照してください。

データベースコピーのシード

シード処理 ( 更新) は、空のデータベースまたは運用データベースのコピーが、アクティブなデータベースと同じ DAG 内の別のメールボックスサーバー上のターゲットコピーの場所に追加される場合です。このデータベースは、そのサーバーによって管理されるコピーのベースラインデータベースになります。

状況に応じて、自動プロセスを使用するか、または管理者が開始する手動プロセスを使用して、データベースをシード処理することができます。データベースコピーが追加されると、ターゲットサーバーとそのストレージが適切に構成されている場合、コピーは自動的にシードされます。データベースコピーを手動でシード処理し、コピーの作成時に自動シード処理を実行しないようにするには、Add-MailboxDatabaseCopy コマンドレットで SeedingPostponed パラメーターを使用します。

最初のシード処理の後に、データベースコピーを再シードする必要はほとんどありません。ただし、再シード処理が必要な場合や、システムがコピーを自動的にシード処理するのではなく、データベースコピーを手動でシードする場合は、次の 2 つのオプションがあります。

EAC でメールボックスデータベースコピーの更新ウィザードを使用します。
Exchange 管理シェルで Update-MailboxDatabaseCopy コマンドレットを使用します。

データベースコピーをシード処理する前に、先にメールボックスデータベースコピーを中断する必要があります。データベースコピーをシード処理する方法の詳しい手順については、「メールボックスデータベースコピーの更新」を参照してください。

手動シード操作が完了すると、シードされたメールボックスデータベースのコピーのレプリケーションが自動的に再開されます。レプリケーションを自動的に再開しない場合は、Update-MailboxDatabaseCopy コマンドレットで ManualResume パラメーターを使用できます。

シード対象の選択

シード操作を実行する場合は、次の操作を選択できます。

メールボックスデータベースのコピーをシードします。
メールボックスデータベースコピーのコンテンツインデックスカタログをシードします。
データベースコピーとコンテンツインデックスカタログコピーの両方をシードします。

メールボックスデータベースコピーの更新ウィザードと Update-MailboxDatabaseCopy コマンドレットの既定の動作では、メールボックスデータベースコピーとコンテンツインデックスカタログコピーの両方をシード処理します。

コンテンツインデックスカタログをシードせずにメールボックスデータベースのコピーだけをシードするには、Update-MailboxDatabaseCopy コマンドレットで DatabaseOnly パラメーターを使用します。

コンテンツインデックスカタログのコピーだけをシードするには、Update-MailboxDatabaseCopy コマンドレットで CatalogOnly パラメーターを使用します。

シード元の選択

正常なデータベースコピーは、そのデータベースの別のコピーのシードソースとして使用できます。このオプションは、複数の物理的な場所に DAG を拡張する場合に特に便利です。

たとえば、次の 4 メンバー DAG デプロイを考えてみましょう。

MBX1 と MBX2 はオレゴン州ポートランドにあります。
MBX3 と MBX4 は、ニューヨーク州ニューヨークにあります。
DB1 という名前のメールボックスデータベースが MBX1 でアクティブです。
MBX2 と MBX3 の DB1 のパッシブコピーがあります。

DB1 のコピーを MBX4 に追加する場合は、シード処理のソースとして MBX3 のコピーを使用できます。このオプションは、ポートランドとニューヨークの間のワイドエリアネットワーク (WAN) リンク経由でのシード処理を回避します。

新しいデータベースコピーを追加するときにシード処理のソースとして特定のコピーを使用するには、次の手順を実行します。

データベースコピーを追加するには、Add-MailboxDatabaseCopy コマンドレットの SeedingPostponed パラメーターを使用します。それ以外の場合、データベースコピーは、データベースのアクティブなコピーをソースとして使用して明示的にシード処理されます。
EAC のメールボックスデータベースコピーの更新ウィザードで使用するソースサーバーを指定することも、Update-MailboxDatabaseCopy コマンドレットの SourceServer パラメーターを使用してシード処理に必要なソースサーバーを指定することもできます。

前の例では、ソースサーバーとして MBX3 を指定しました。それ以外の場合、データベースのコピーは、データベースのアクティブなコピーから明示的にシード処理されます。

シードとネットワーク

メールボックスデータベースコピーをシード処理するための特定のシード元サーバーを選択することに加え、Exchange 管理シェルを使用して、使用する DAG ネットワークも指定できます。シード操作中に DAG ネットワークの圧縮と暗号化の設定をオーバーライドできます。

シード処理に使用するネットワークを指定するには、Update-MailboxDatabaseCopy コマンドレットの Network パラメーターを使用し、使用する DAG ネットワークを指定します。 Network パラメーターを使用しない場合、システムはシード処理に使用するネットワークを選択するために、次の既定の動作を使用します。

ソースサーバーとターゲットサーバーが同じサブネット上にあり、サブネットを含むレプリケーションネットワークが構成されている場合、レプリケーションネットワークが使用されます。
ソースサーバーとターゲットサーバーが異なるサブネット上にある場合、それらのサブネットを含むレプリケーションネットワークが構成されている場合でも、シード処理にはクライアント (MAPI) ネットワークが使用されます。
ソースサーバーとターゲットサーバーが異なるデータセンターにある場合は、シード処理にクライアント (MAPI) ネットワークが使用されます。

DAG レベルで暗号化と圧縮に関して DAG ネットワークが構成されます。既定の設定では、異なるサブネット上での通信にのみ、暗号化と圧縮が使用されます。ソースとターゲットが異なるサブネット上にあり、DAG が NetworkCompression と NetworkEncryption の既定値で構成されている場合は、Update-MailboxDatabaseCopy コマンドレットの NetworkCompressionOverride パラメーターと NetworkEncryptionOverride パラメーターを使用して、これらの値をオーバーライドできます。

シード処理

Add-MailboxDatabaseCopy または Update-MailboxDatabaseCopy コマンドレットを使用してシード処理を開始すると、以下のタスクが実行されます。

Active Directory のデータベースプロパティは、指定したデータベースとサーバーを検証し、ソースサーバーとターゲットサーバーがExchange Server実行されていることを確認するために読み取られます。これらはどちらも同じ DAG のメンバーであり、指定されたデータベースが復旧データベースではないことを確認します。データベースファイルのパスも読み取られます。
シード先サーバーの Microsoft Exchange レプリケーションサーバーから、再シードチェックの準備が行われます。
シード先サーバーの Microsoft Exchange レプリケーションサービスが、ステップ 1 で Active Directory チェックによって読み取られたファイルディレクトリにデータベースとトランザクションログファイルが存在することをチェックします。
Microsoft Exchange レプリケーションサービスが、コマンドレットが実行された管理インターフェイスに、シード先サーバーからの状態情報を返します。
すべての予備チェックに合格した場合は、続行する前に操作を確認するように求められます。操作を確認すると、処理が続行します。事前チェック中にエラーが発生すると、エラーが報告され、操作は異常終了します。
シード操作は、シード先サーバーの Microsoft Exchange レプリケーションサービスから開始します。
Microsoft Exchange レプリケーションサービスは、アクティブデータベースコピーのデータベースレプリケーションを中断します。
Microsoft Exchange レプリケーションサービスは、シード処理の状態を反映するようにデータベースの状態情報を更新します。
ターゲットサーバーにターゲットデータベースとログファイルのディレクトリがまだない場合は、作成されます。
データベースをシードする TCP 要求は、ターゲットサーバーの Microsoft Exchange レプリケーションサービスからソースサーバー上の Microsoft Exchange レプリケーションサービスに渡されます。この要求とそれに続くデータベースのシード処理に関する通信は、レプリケーションネットワークとして構成された DAG ネットワーク上で行われます。
シード先 Microsoft Exchange レプリケーションサービスが、Microsoft Exchange インフォメーションストアサービスインターフェイス経由で、Extensible Storage Engine (ESE) ストリーミングバックアップを開始します。
Microsoft Exchange インフォメーションストアサービスが、Microsoft Exchange レプリケーションサービスにデータベースデータをストリームします。
シード元サーバーの Microsoft Exchange レプリケーションサービスから、シード先サーバーの Microsoft Exchange レプリケーションサービスまで、データベースデータが移動します。
ターゲットサーバーの Microsoft Exchange レプリケーションサービスは、一 時シードと呼ばれるメインデータベースディレクトリにある一時ディレクトリにデータベースコピーを書き込みます。
データベースの最後に到達すると、シード元サーバー上のストリーミングバックアップ操作が終了します。
シード先サーバーの書き込み操作が完了し、temp-seeding ディレクトリから最終的な場所までデータベースが移動します。 temp-seeding ディレクトリが削除されます。
シード先サーバー上で Microsoft Exchange レプリケーションサービスが Microsoft Exchange 検索サービスに要求を転送し、データベースコピーのコンテンツインデックスカタログをマウントします (存在する場合)。データベースコピーの以前のインスタンスの最新ではないカタログファイルが存在する場合、マウント操作は失敗し、結果としてシード元サーバーからのカタログの複製が必要になります。同様に、シード先サーバーのデータベースコピーの新しいインスタンスにカタログが存在しない場合、カタログのコピーが必要になります。 Microsoft Exchange レプリケーションサービスが Microsoft Exchange 検索サービスを検出し、シード元から新しいカタログをコピーしている間、データベースコピーのインデックス処理を中断します。
シード先サーバーの Microsoft Exchange レプリケーションサービスがシード元サーバーの Microsoft Exchange レプリケーションサービスに、シードカタログ要求を送信します。
ソースサーバーでは、Microsoft Exchange レプリケーションサービスは、Microsoft Exchange Search Serviceからディレクトリ情報を要求し、インデックス作成の中断を要求します。
シード元サーバーの Microsoft Exchange 検索サービスが、Microsoft Exchange レプリケーションサービスに検索カタログディレクトリ情報を返します。
シード元サーバーの Microsoft Exchange レプリケーションサービスが、ディレクトリからのカタログファイルを読み取ります。
シード元サーバーの Microsoft Exchange レプリケーションサービスが、レプリケーションネットワークにわたる接続を使用して、シード先サーバーの Microsoft Exchange レプリケーションサービスにカタログデータを移動します。読み取りが完了すると、Microsoft Exchange レプリケーションサービスが Microsoft Exchange 検索サービスにシード元データベースのインデックス処理を再開する要求を送信します。
シード先サーバーのディレクトリに何らかの既存ファイルが存在する場合、シード先サーバーの Microsoft Exchange レプリケーションサービスがそれらのファイルを削除します。
ターゲットサーバーの Microsoft Exchange レプリケーションサービスは、データが完全に転送されるまで、カタログデータを CiSeed.Temp という一時ディレクトリに書き込みます。
Microsoft Exchange レプリケーションサービスが、最終的な場所にまで完全なカタログデータを移動します。
シード先サーバーの Microsoft Exchange レプリケーションサービスが、シード先データベースの検索インデックス処理を再開します。
シード先サーバーの Microsoft Exchange レプリケーションサービスが完了状態を返します。
オペレーションの最終結果が、コマンドレットの呼び出し元である管理インターフェイスに返されます。

データベースコピーの構成

データベースコピーが作成されると、必要なときにデータベースコピーの構成設定を表示して変更できるようになります。 EAC で、データベースコピーの [プロパティ] ページを確認すると、いくつかの構成情報を表示できます。 Exchange 管理シェルの Get-MailboxDatabase コマンドレットと Set-MailboxDatabaseCopy コマンドレットを使用して、データベースコピー設定を表示および構成することもできます。たとえば、再生ラグタイム、切り捨てラグタイム、アクティブ化優先順序などです。データベースコピー設定の表示と構成に関する詳しい手順については、「メールボックスデータベースのコピーのプロパティを構成する」を参照してください。

再生の時間差オプションと切り捨ての時間差オプションの使用

メールボックスデータベースコピーは、再生の時間差と切り捨ての時間差 (両者とも分単位で構成する) の使用をサポートします。再生の時間差を設定することで、データベースコピーを特定の時点にまで戻すことができるようになります。切り捨ての時間差を設定することで、パッシブデータベースコピーのログを使用して、アクティブデータベースコピーのログファイルの損失を復元できるようになります。どちらの機能でもログファイルが一時的に蓄積されるため、どちらかを使用するとストレージの設計に影響します。

再生の時間差

再生の時間差とは、メールボックスデータベースコピーのプロパティであり、データベースコピーのログ再生を遅らせる時間を分で指定します。リプレイラグタイマーは、ログファイルがパッシブコピーにレプリケートされ、正常に検査に合格すると開始されます。データベースコピーへのログの再生を遅らせて、データベースを過去の特定時点にまで復元できるようになります。再生ラグタイムが 0 より大きい状態で構成されたメールボックスデータベースのコピーは、 遅延メールボックスデータベースのコピー (単に 遅延コピー) と呼ばれます。

Exchange Serverでデータベースコピーと訴訟ホールド機能を使用する戦略では、通常、データ損失の原因となるさまざまな障害に対する保護を提供できます。ただし、これらの機能では、論理的な破損によるデータ損失から保護することはできません。論理的な破損はまれですが、データ損失を引き起こす可能性があります。遅延コピーは、論理的な破損によるデータの損失を防ぐために設計されています。一般的に、論理的な破損には以下の 2 種類が存在します。

データベースの論理的な破損: データベースページのチェックサムが一致しますが、ページ上のデータが論理的に間違っています。この状況は、ESE がデータベースページを書き込もうとしたときに発生します。オペレーティングシステムは成功メッセージを返しますが、データはディスクに書き込まれなかったり、間違った場所に書き込まれたりします。この条件は、 失われたフラッシュと呼ばれます。ロストフラッシュによりデータを失わないようにするため、ESE により、ページパッチ機能 (単一ページの復元) と一緒に、ロストフラッシュ検出機構がデータベースに組み込まれています。
ストアの論理的な破損: ユーザーが予期しない方法でデータを追加、削除、または操作します。一般に、Microsoft 以外のアプリケーションではこのようなケースが発生します。一般に、ユーザーが破損と見なすという意味では、破損と見なされます。 Exchange ストアは、論理的破損を引き起こすトランザクションを一連の有効な MAPI 操作として見なします。 Exchange Serverの訴訟ホールド機能は、ストアの論理的な破損からの保護を提供します (ユーザーまたはアプリケーションによってコンテンツが完全に削除されないようにするため)。ただし、ユーザーメールボックスが破損し、破損する前の特定の時点にデータベースを復元し、ユーザーメールボックスをエクスポートして、破損していないデータを取得する方が簡単になる場合があります。

データベースコピー、情報保留ポリシー、および ESE 単一ページ復元を組み合わせることで、まれに発生する壊滅的なストアの論理的破損以外の破損に対処できます。再生ラグ (遅延コピー) でデータベースコピーを使用するかどうかの決定は、使用する Microsoft 以外のアプリケーションと、ストアの論理的な破損を伴うorganizationの履歴によって異なります。

時間差コピーを使用する場合、以下の点に注意してください。

再生ラグタイムは、管理者が構成した値です。既定では、再生ラグタイムは無効になっています。
再生ラグタイム設定の既定の設定は 0 日で、最大設定は 14 日です。
時間差コピーは高可用コピーとは見なされません。代わりに、ストアの論理的な破損から保護するために、ディザスターリカバリーを目的として設計されています。
再生の時間差設定が大きくなればなるほど、データベースの復旧処理も長くなります。次の理由により、データベースの復旧に数時間かかる場合があります。
- 再生するログファイルの数。
- ハードウェアが再生できる速度。
全体的な障害復旧戦略にとって、時間差コピーが必要不可欠であるかどうかを判断することを推奨します。時間差コピーの使用が戦略上必要不可欠であれば、複数の時間差コピーを使用するか、複数の時間差コピーを使用しないのであれば RAID (Redundant Array of Independent Disks) を使用して単一の時間差コピーを保護することを推奨します。ディスクを失うか、破損が発生しても、すぐに時間差コピーを失うことはありません。
ESE シングルページ復元機能では、遅延コピーに修正プログラムを適用できません。遅延コピーでデータベースページの破損 (-1018 エラーなど) が発生した場合は、コピーを再シードする必要があります。再シード処理では、コピーの遅延の側面が失われます。

データベースですべてのログファイルを再生し、データベースのコピーを最新の状態にする場合は、遅延メールボックスデータベースのコピーをアクティブ化して回復するのが簡単なプロセスです。特定の時点までログファイルを再生する場合は、ログファイルを手動で操作し、データベースユーティリティ (Eseutil.exe) Exchange Server実行する必要があるため、プロセスはより困難になります。

遅延メールボックスデータベースのコピーをアクティブ化する方法の詳細な手順については、「ラグドメールボックスデータベースのコピーをアクティブ化する」を参照してください。

切り捨ての時間差

切り捨てラグタイムは、ログファイルがデータベースコピーに再生された後にデータベースコピーのログ削除を遅延させる時間を分単位で指定するメールボックスデータベースコピーのプロパティです。切り捨ての時間差タイマーは、ログファイルがパッシブコピーに複製され、検査に合格し、データベースのコピーに正常に再生された時点から開始します。データベースコピーからログファイルの切り捨てを遅らせることで、データベースのアクティブコピーのログファイルに影響を与える障害から復旧できるようになります。

データベースコピーとログの切り捨て

ログの切り捨ては、Exchange 2016 と Exchange 2019 では、Exchange 2010 と同じように機能します。切り捨て動作は、コピーの再生の時間差と切り捨ての時間差設定によって決定します。

時間差設定が既定値である 0 (無効) に設定されている場合、データベースコピーのログファイルが切り捨てられるには、以下の基準に一致する必要があります。

ログファイルが正常にバックアップされているか、循環ログが有効になっています。
ログファイルがデータベースのチェックポイント (復旧に必要な最小ログファイル) 未満である必要があります。
その他の遅延コピーはすべて、ログファイルを検査しました。
その他のすべてのコピー (遅延コピーを除く) は、ログファイルを再生しました。

時間差データベースコピーで切り捨てが行われるには、以下の基準に一致する必要があります。

ログファイルがデータベースのチェックポイント未満である必要があります。
ログファイルが ReplayLagTime + TruncationLagTime より古い必要があります。
ログファイルは、アクティブなコピーで切り捨てられます。

Exchange Serverでは、1 つ以上のパッシブコピーが中断されている場合、アクティブなメールボックスデータベースのコピーでログの切り捨てが行われません。計画メンテナンスアクティビティが長時間 (たとえば、数日) かかる場合は、かなりのログファイルのビルドアップが発生する可能性があります。ログドライブがトランザクションログで満杯になることを防止するには、影響を受けたパッシブデータベースコピーを中断するのではなく削除します。計画された保守が完了したら、パッシブデータベースコピーをもう一度追加できます。

Exchange Server、ルーズ切り捨てと呼ばれる機能が既定で無効になりました。通常の操作では、各データベースコピーは、データベースのすべてのコピーが確認されるまで、他のデータベースコピーに配布する必要があるログを保持します。

ログファイル (パッシブコピー) を再生しました。
ログファイル (遅延コピー) を受信しました。

この動作は、既定のログ切り捨て動作です。あるデータベースコピーが何らかの理由でオフラインになると、他のデータベースコピーで使用されるディスク上でログファイルが蓄積されていきます。当該データベースコピーが長期にわたってオフラインのままになると、他のデータベースコピーがディスク領域を使い尽くす可能性があります。

切り捨て動作は、緩やかな切り捨てと循環ログが有効になっている場合に異なります。各データベースコピーは、それ自身のディスク空き領域を追跡して、空き領域が少なくなった場合に緩やかな切り捨て動作を適用します。

アクティブコピーの場合は、最も古い残存コピー (ログ再生が最も後回しのパッシブデータベースコピー) が無視され、切り捨てで残りの最も古いパッシブコピーが尊重されます。アクティブデータベースコピーでは、グローバル切り捨てが計算されます。
パッシブコピーの場合、領域が不足すると、後のレジストリ値テーブルで後述する構成済みのパラメーターを使用して、ログファイルが個別に切り捨てられます。パッシブコピーは、アクティブコピーに対して行われた切り捨て決定を尊重しようとします。 MinCopiesToProtect という名前が影響を受けますが、切り捨てが実行された時点で、Exchange では最も古い既知のストラグラーのみが無視されます。

オフラインデータベースがオンラインに戻されると、不足しているログファイルが他の正常なコピーから削除され、データベースのコピー状態は FailedAndSuspended になります。この場合、Autoreseed が構成されている場合、影響を受けるコピーは自動的に再シードされます。 Autoreseed が構成されていない場合は、データベースコピーを管理者が手動でシード処理する必要があります。

循環ログが無効になっている場合、緩やかな切り捨ては、作成されたすべてのバックアップを考慮します。緩やかな切り捨てでは、バックアップされていないログファイルは削除されません。

切り捨ては、バックアップが使用されず、循環ログが有効になっている推奨アーキテクチャに推奨される機能です。

必要な正常コピーの数、空きディスクスペースのしきい値、保持されるログの数は、すべて構成可能パラメーターです。既定で、ディスクの空き領域のしきい値は 204800 MB (200 GB) で、保持されるログの数はパッシブコピーが 100,000 (100 GB)、アクティブコピーが 10,000 (10 GB) です。

緩やかな切り捨てを有効にし、緩やかな切り捨てパラメーターを構成するには、各 DAG メンバー上で Windows レジストリを編集します。構成できるレジストリ値は 3 つあり、すべて HKLM\Software\Microsoft\ExchangeServer\v15\BackupInformation の下に格納されています。 BackupInformation キーでは、次の DWORD 値は既定では存在しないため、手動で作成する必要があります。以下の表で、BackupInformation の下の DWORD レジストリ値について説明します。

レジストリ値	説明	既定値
LooseTruncation_MinCopiesToProtect	このキーは緩やかな切り捨てを有効にするために使用されます。データベースのアクティブコピーに対する緩やかな切り捨てから保護されるパッシブコピーの数を表しています。このキーの値を 0 に設定すると、緩やかな切り捨てが無効になります。	0
LooseTruncation_MinDiskFreeSpaceThresholdInMB	緩やかな切り捨てのトリガーに使用可能なディスク領域 (MB) のしきい値。空きディスクスペースがこの値より小さくなると、切り詰めがトリガーされます。	このレジストリ値が構成されていない場合、緩やかな切り捨てで使用される既定値は 200 GB です。
LooseTruncation_MinLogsToProtect	ログが切り捨てられる正常なコピーに関して保持されるログファイルの最小数。このレジストリ値が構成されている場合は、構成された値がアクティブコピーとパッシブコピーの両方に適用されます。	このレジストリ値が構成されていない場合、パッシブデータベースコピーの場合は既定値 100,000、アクティブなデータベースコピーの場合は 10,000 が使用されます。

LooseTruncation_MinLogsToProtectレジストリ値を使用する場合、アクティブデータベースコピーとパッシブデータベースコピーでは動作が異なります

アクティブ: 保護されたパッシブコピーとアクティブコピーの必要な範囲で必要なログの前に保持された追加のログの数。
パッシブ: 使用可能な最新のログから保持されるログの数。この数の 10 分の 1 は、このパッシブコピーの必要な範囲の前にログを保持するためにも使用されます。

必要な範囲は通常非常に大きいため、遅れたデータベースコピーが領域を占有しすぎないように、2 つの制限が設定されています。

データベースのアクティブ化ポリシー

メールボックスデータベースのコピーを作成し、システムがそのコピーを自動的にアクティブ化できないようにするシナリオがあります。たとえば、エラーが発生した後:

1 つ以上のメールボックスデータベースコピーを代替データセンターまたはスタンバイデータセンターに展開します。
復旧のために遅延データベースコピーを構成します。
メンテナンスまたはサーバーのアップグレードを行っています。

上記の各シナリオでは、データベースコピーを自動的にアクティブにすることはできません。メールボックスデータベースコピーが自動的にアクティブにならないようにするため、アクティベーションを禁止 (中断) するようにコピーを構成できます。

この構成により、システムはログ配布と再生を通じてデータベースの通貨を維持できますが、コピーを自動的にアクティブ化して使用することはできなくなります。管理者は、アクティブ化のためにブロックされたコピーを手動でアクティブ化する必要があります。

DatabaseCopyAutoActivationPolicy パラメーターを Blocked に設定できます。

Set-MailboxServer コマンドレットを使用したサーバー全体。
Set-MailboxDatabaseCopy コマンドレットを使用した個々のデータベースコピー。

データベースのアクティベーションポリシーの構成の詳細については、「メールボックスデータベースのコピーのライセンス認証ポリシーを構成する」を参照してください。

メールボックスの移動の連続レプリケーションへの影響

アクセス回数が非常に多く、ログ生成率の高いメールボックスデータベースでは、パッシブデータベースコピーのレプリケーションがログ生成に間に合わない場合に、データが損失する可能性が高くなります。ログ生成率が高くなるシナリオの 1 つにメールボックスの移動があります。 Exchange Serverには、システムまたは管理者によって設定された DataMoveReplicationConstraint パラメーターの値に基づいて、データベースコピーアーキテクチャの正常性をチェックするために Exchange メールボックスレプリケーションサービス (MRS) などのサービスによって使用されるデータ保証 API が含まれています。具体的には、データ保証 API を使用すると、以下のような作業が可能になります。

レプリケーションの正常性を確認する: データベースコピーの前提条件の数が使用可能であることを確認します。
レプリケーションフラッシュの確認: 必要なログファイルが、前提条件のデータベースコピー数に対して再生されることを確認します。

実行すると、API は呼び出し元のアプリケーションに次の状態情報を返します。

再試行: 条件がデータベースに対してチェックされるのを妨げる一時的なエラーがあることを示します。
満足: データベースが必要な条件を満たしているか、データベースがレプリケートされていないことを示します。
NotSatisfied: データベースが必要な条件を満たしていないことを示します。さらに、 NotSatisfied 応答が返された理由に関する情報を、呼び出し元のアプリケーションに提供します。

メールボックスデータベースの DataMoveReplicationConstraint パラメーターの値によって、要求の一部として評価する必要があるデータベースコピーの数が決まります。 DataMoveReplicationConstraint パラメーターには、次の可能な値があります。

None: メールボックスデータベースを作成する場合、この値は既定で設定されます。この値を設定すると、データ保証 API の条件は無視されます。この設定は、レプリケートされないメールボックスデータベースにのみ使用します。
SecondCopy: メールボックスデータベースの 2 番目のコピーを追加する場合の既定値です。この値を設定する場合、少なくとも 1 つのパッシブデータベースコピーがデータ保証 API の条件を満たしている必要があります。
SecondDatacenter: この値が設定されている場合、別の Active Directory サイト内の少なくとも 1 つのパッシブデータベースコピーが Data Guarantee API の条件を満たしている必要があります。
AllDatacenters: この値が設定されている場合、各 Active Directory サイト内の少なくとも 1 つのパッシブデータベースコピーが Data Guarantee API の条件を満たしている必要があります。
AllCopies: この値を設定すると、メールボックスデータベースのすべてのコピーが Data Guarantee API の条件を満たす必要があります。

レプリケーションの正常性の確認

データベースコピーのインフラストラクチャの正常性を評価するためにデータ保証 API が実行されると、いくつかのアイテムが評価されます。

すべてのシナリオで、パッシブデータベースコピーは次の条件を満たす必要があります。

正常である。
再生キューの再生ラグタイムが 10 分以内である。
コピーキューの長さが 10 ログ未満である。
コピーキューの平均の長さが 10 ログ未満である。コピーキューの平均長は、アプリケーションがデータベースの状態を照会した回数に基づいて計算されます。

DataMoveReplicationConstraint パラメーターがに設定されている場合。	次に、特定のデータベースに対して...
`SecondCopy`	レプリケートされたデータベースの少なくとも 1 つのパッシブデータベースコピーは、前に説明した条件を満たしている必要があります。
`SecondDatacenter`	別の Active Directory サイト内の少なくとも 1 つのパッシブデータベースコピーは、前に説明した条件を満たしている必要があります。
`AllDatacenters`	アクティブコピーをマウントする必要があり、各 Active Directory サイトのパッシブコピーは、前に説明した条件を満たす必要があります。
`AllCopies`	アクティブコピーをマウントし、すべてのパッシブデータベースコピーが前に説明した条件を満たしている必要があります。

レプリケーションフラッシュの確認

データ保証 API は、必要な数のデータベースコピーが必要なトランザクションログを再生したことを検証するためにも使用できます。これは、最後に再生されたログのタイムスタンプと呼び出し元サービスのコミットタイムスタンプのタイムスタンプ (ほとんどの場合、これは、必要なデータを含む最後のログファイルのタイムスタンプ) に加えて、5 秒 (システムタイムクロックスキューまたはドリフトに対処するため) を比較することによって検証されます。再生タイムスタンプがコミットタイムスタンプより大きい場合は、 DataMoveReplicationConstraint パラメーターが満たされます。再生タイムスタンプがコミットタイムスタンプより小さい場合、 DataMoveReplicationConstraint は満たされません。

DAG 内のレプリケーションデータベースとの間で多数のメールボックスを移動する前に、次の表に従って、各メールボックスデータベースで DataMoveReplicationConstraint パラメーターを構成することをお勧めします。

デプロイしている場合...	DataMoveReplicationConstraint を..に設定します。
データベースコピーを持たないメールボックスデータベース	`None`
1 つの Active Directory サイト内の DAG	`SecondCopy`
分散されている Active Directory サイトを使用する複数のデータセンター内の DAG	`SecondCopy`
2 つの Active Directory サイトにまたがる DAG で、各サイトに高可用性データベースコピーがある	`SecondDatacenter`
2 つの Active Directory サイトにまたがる DAG で、2 番目のサイトでデータベースのコピーが遅れているだけです	`SecondCopy` Data Guarantee API は、ログファイルがデータベースコピーに再生されるまで、データがコミットされることを保証しません。データベースコピーの遅延が原因で、遅延データベースコピーの ReplayLagTime 値が 30 分未満でない限り、この制約は移動要求に失敗します。
3 つ以上の Active Directory サイトにまたがり、各サイトに高可用性データベースコピーが含まれる DAG	`AllDatacenters`

データベースコピーのバランス維持

DAG の固有の性質により、データベースの切り替えとフェールオーバーの結果として、アクティブなメールボックスデータベースコピーは DAG の有効期間を通じてホストを数回変更します。この結果、アクティブなメールボックスデータベースコピー配布の点で DAG のバランスがくずれる可能性があります。次の表に、アクティブなデータベースコピーが不均等に配布された、それぞれに各データベースの 4 つのコピーを持つ 4 つのデータベースがある DAG (各サーバーに合計 16 個のデータベース) の例を示します。

サーバー	アクティブなデータベースの数	パッシブなデータベースの数	マウントされたデータベースの数	優先順位カウント一覧
EX1	5	11	5	4, 4, 3, 5
EX2	1	15	1	1, 8, 6, 1
EX3	12	4	12	13, 2, 1, 0
EX4	1	15	1	1, 1, 5, 9

前の例では、各データベースの 4 つのコピーがあるため、アクティブ化優先順位に指定できる値は 4 つ (1、2、3、または 4) しかありません。 「優先順位カウント一覧」 列は、アクティブ化優先順位の値ごとにデータベース数のカウントを示したものです。たとえば、EX3 には、アクティブ化優先順位が 1 のデータベースコピーが 13 個、アクティブ化優先順位が 2 のコピーが 2 個、アクティブ化優先順位が 3 のコピーが 1 個あり、アクティブ化優先順位が 4 のコピーはありません。

ご覧のとおり、この DAG は、各 DAG メンバーによってホストされているアクティブなデータベースの数、各 DAG メンバーによってホストされているパッシブなデータベースの数、またはホストされているデータベースのアクティブ化優先順位カウントの点でバランスがくずれています。

RedistributeActiveDatabases.ps1 スクリプトを使用すると、DAG 全体にわたってアクティブなメールボックスデータベースコピーのバランスを維持できます。このスクリプトは、DAG 内の各サーバーにマウントされているデータベースの数を均等にするために、データベースをコピー間で移動します。必要に応じて、サイト全体でアクティブなデータベースのバランスをとることも試行します。

このスクリプトには、DAG 内でアクティブなデータベースコピーのバランスをとるために、次の 2 つのオプションが用意されています。

BalanceDbsByActivationPreference: このオプションを指定すると、スクリプトは Active Directory サイトに関係なく(アクティブ化の優先に基づいて) 最も優先されるコピーにデータベースを移動しようとします。
BalanceDbsBySiteAndActivationPreference: このオプションを指定すると、スクリプトはアクティブなデータベースを最も優先されるコピーに移動しながら、各 Active Directory サイト内のアクティブなデータベースのバランスを取ろうとします。

最初のオプションでスクリプトを実行すると、次の表に示すように、前述のバランスがくずれた DAG のバランスが調整されます。

サーバー	アクティブなデータベースの数	パッシブなデータベースの数	マウントされたデータベースの数	優先順位カウント一覧
EX1	4	12	4	4, 4, 4, 4
EX2	4	12	4	4, 4, 4, 4
EX3	4	12	4	4, 4, 4, 4
EX4	4	12	4	4, 4, 4, 4

前の表に示したように、この DAG は、各サーバー上のアクティブとパッシブなデータベースの数、およびサーバー全体にわたるアクティブ化優先順位の点でバランスがとれた状態になりました。

次の表に、RedistributeActiveDatabases.ps1 スクリプトで使用可能なパラメーターを示します。

パラメーター	説明
DagName	再度バランスをとる DAG の名前を指定します。このパラメーターを省略すると、ローカルサーバーがメンバーになっている DAG が使用されます。
BalanceDbsByActivationPreference	Active Directory サイトを無視してデータベースをその最も優先されるコピーに移動するようにスクリプトに指定します。
BalanceDbsBySiteAndActivationPreference	Active Directory サイト内のアクティブなデータベースのバランスをとる一方で、アクティブなデータベースをその最も優先されるコピーに移動するようにスクリプトに指定します。
ShowFinalDatabaseDistribution	再配布が完了した後に、現在のデータベース配布のレポートを表示することを指定します。
AllowedDeviationFromMeanPercentage	サイト全体におけるアクティブなデータベースの許容変化量を割合で指定します。既定値は 20% です。たとえば、3 つのサイト間に 99 個のデータベースが配布されている場合、最適な配布は各サイトで 33 個のデータベースとなります。許容変化量が 20% の場合、各サイトでこの個数の上下 10% を超えないように、スクリプトはデータベースのバランスをとろうとします。 33 の 10% は 3.3 で、切り上げて 4 になります。したがって、スクリプトは各サイトでデータベースの数を 29 ～ 37 にしようとします。
ShowDatabaseCurrentActives	各データベースについて、データベースがどのように移動したか、データベースがその最も優先されるコピーでアクティブであるかどうかを詳細に示すレポートを生成するようにスクリプトに指定します。
ShowDatabaseDistributionByServer	各サーバーについて、そのデータベース配布を示すレポートを生成するようにスクリプトに指定します。
RunOnlyOnPAM	現在 PAM 役割を持つ DAG メンバー上でのみスクリプトを実行するように指定します。スクリプトは、PAM から実行されていることを確認します。 PAM から実行されていない場合、スクリプトは終了します。
LogEvents	アクションの概要を含むイベント (MsExchangeRepl イベント 4115) をログに記録するようにスクリプトに指定します。
IncludeNonReplicatedDatabases	アクティブなデータベースの再配布方法の決定時に、レプリケートされていないデータベース (コピーを持たないデータベース) を含めるようにスクリプトに指定します。レプリケートされていないデータベースは移動できませんが、レプリケートされたデータベースの分散に影響する可能性があります。
確認	Confirm スイッチは、このスクリプトの実行時に既定で表示される確認プロンプトの表示の抑制に使用できます。確認プロンプトの表示を抑制するには、syntax -Confirm:$False を使用します。構文にはコロン (:)を含める必要があります。

RedistributeActiveDatabases.ps1 の例

この例は、優先順位カウント一覧を含む DAG の現在のデータベース配布を示します。

RedistributeActiveDatabases.ps1 -DagName DAG1 -ShowDatabaseDistributionByServer | Format-Table

この例では、入力を促すメッセージを表示しないで、アクティブ化優先順位を使用して、DAG 内のアクティブなメールボックスデータベースコピーを再配布しバランスをとります。

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -Confirm:$False

この例では、アクティブ化優先順位を使用して、DAG 内のアクティブなメールボックスデータベースコピーを再配布しバランスをとり、配布の概要を生成します。

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -ShowFinalDatabaseDistribution

データベースコピーの監視

EAC でデータベースコピーの詳細を確認すると、コピーキューの長さ、再生キューの長さ、状態とコンテンツインデックス状態情報などのさまざまな情報を表示できます。さらに、 Get-MailboxDatabaseCopyStatus コマンドレットを Exchange 管理シェルで使用して、データベースコピーのさまざまな状態情報を表示することもできます。

注:

データベースコピーは、データベースのアクティブコピーに影響を与える障害が発生した場合の、第一の防御です。そのため、データベースコピーの正常性と状態を監視して、必要に応じて使用できることを確認することが重要です。

データベースコピーの監視の詳細については、「データベース可用性グループの監視」を参照してください。

データベースコピーの削除

EAC を使用するか、Exchange 管理シェルで Remove-MailboxDatabaseCopy コマンドレットを使用すれば、いつでもデータベースコピーを削除できます。データベースコピーを削除した後、データベースコピーを削除するサーバーからすべてのデータベースとトランザクションログファイルを手動で削除する必要があります。データベースコピーを削除する方法の詳しい手順については、「メールボックスデータベースコピーを削除する」を参照してください。

データベース切り替え

データベースのアクティブコピーをホストするメールボックスサーバーはメールボックスデータベースマスターと呼ばれます。パッシブデータベースコピーをアクティブにする処理により、データベースのメールボックスデータベースマスターが変更され、パッシブコピーが新しいアクティブコピーに変わります。この処理をデータベースの切り換えと呼びます。データベースの切り替えでは、1 つのメールボックスサーバー上のデータベースのアクティブコピーがマウント解除され、そのデータベースのパッシブコピーが別のメールボックスサーバー上で新しいアクティブメールボックスデータベースとしてマウントされます。切り替え実行時には、オプションで新しいメールボックスデータベースマスターのデータベースマウントダイヤル設定を上書きできます。

EAC の [データベースコピー] タブの下にある右側の列を確認すると、どのメールボックスサーバーが現在のメールボックスデータベースマスターであるかをすばやく特定することができます。 EAC で [アクティブにする] リンクを使用するか、 Move-ActiveMailboxDatabase で Exchange 管理シェルコマンドレットを使用すると、切り替えを実行できます。

パッシブコピーをアクティブ化する前に、いくつかの内部チェックが実行されます。場合によっては、データベースの切り替えは禁止またはキャンセルされます。その他の場合には、コマンドレットを使用して、いくつかのチェックを移動またはスキップすることができます。

データベースコピーの状態がチェックされます。データベースコピーが障害状態にあると、切り替えは禁止されます。 Move-ActiveMailboxDatabase コマンドレットの SkipHealthChecks パラメーターを使用して、この動作をオーバーライドし、正常性チェックをバイパスできます。このパラメーターを使用すると、障害状態にあるデータベースコピーにアクティブコピーを移動できます。
アクティブデータベースコピーが、現在、データベースのいずれかのパッシブコピーのシード元であるかどうかを確認するためにチェックされます。アクティブコピーが現在シード元として使用されている場合は、切り替えはブロックされます。 Move-ActiveMailboxDatabase コマンドレットの SkipActiveCopyChecks パラメーターを使用して、この動作をオーバーライドし、シードソースチェックをバイパスできます。このパラメーターを使用して、シード元として使用されているアクティブコピーを移動できます。このパラメーターを使用すると、シード処理操作が取り消され、失敗と見なされます。
データベースコピーのコピーキューと再生キューの長さがチェックされ、これらの値が構成された基準の範囲内にあることが確認されます。また、データベースコピーが確認され、現在シードのシード元として使用されていないことが確認されます。キューの長さの値が構成された範囲外にある場合、またはデータベースが現在シードのシード元として使用されている場合、切り替えは禁止されます。 Move-ActiveMailboxDatabase コマンドレットの SkipLagChecks パラメーターを使用して、この動作をオーバーライドし、これらのチェックをバイパスできます。このパラメーターは、アクティブ化され、再生とコピーのキューを持つコピーが、構成された条件外になることを許可します。
データベースコピーの検索カタログ (コンテンツインデックス) の状態がチェックされます。検索カタログが最新ではない場合、異常な状態にある場合、または破損している場合、切り替えは禁止されます。この動作をオーバーライドし、Move-ActiveMailboxDatabase コマンドレットの SkipClientExperienceChecks パラメーターを使用して、検索カタログのチェックをバイパスできます。このパラメーターを使用すると、この検索はカタログの正常性チェックをスキップします。アクティブ化するデータベースコピーの検索カタログが異常または使用できない状態にあり、このパラメーターを使用してカタログの正常性チェックをスキップし、データベースコピーをアクティブ化する場合は、検索カタログをもう一度クロールまたはシード処理する必要があります。

データベース切り替えを実行するとき、アクティブにするパッシブデータベースコピーをホストするサーバーに構成されているマウントダイヤル設定を上書きする方法もあります。 Move-ActiveMailboxDatabase コマンドレットの MountDialOverride パラメーターを使用すると、ターゲットサーバーに独自のマウントダイヤル設定をオーバーライドし、MountDialOverride パラメーターで指定された設定を使用するように指示します。

データベースコピーの切り替え方法の詳細な手順については、「メールボックスデータベースコピーをアクティブにする」を参照してください。

Last updated on 2025-05-09

次の方法で共有

メールボックス データベース コピーを管理

データベース コピーの管理

データベース コピーの中断と再開

データベース コピーのシード