JavaScriptが検索に必要です。
ナビゲーション・リンクをスキップ
印刷ビューの終了
Oracle Directory Server Enterprise Edition管理ガイド 11gリリース1(11.1.1.5.0)
検索フィルタ・アイコン
検索アイコン

ドキュメント情報

はじめに

第1部 Directory Serverの管理

1.  Directory Serverのツール

2.  Directory Serverのインスタンスと接尾辞

3.  Directory Serverの構成

4.  Directory Serverのエントリ

5.  Directory Serverのセキュリティ

6.  Directory Serverのアクセス制御

7.  Directory Serverのパスワード・ポリシー

8.  Directory Serverのバックアップとリストア

バイナリ・バックアップ

ディレクトリ・データのみのバックアップ

ディレクトリ・データをバックアップするには:

dse.ldifファイルをバックアップするには:

ファイル・システムのバックアップ

ファイル・システムをバックアップするには:

ファイル・システムをリストアするには:

LDIFへのバックアップ

LDIFへのエクスポート

接尾辞をLDIFにエクスポートするには:

バイナリ・リストア

サーバーをリストアするには:

レプリケートされた接尾辞のリストア

シングルマスター・シナリオでのサプライヤのリストア

マルチマスター・シナリオでのサプライヤのリストア

ハブのリストア

専用コンシューマのリストア

マルチマスター・シナリオでのマスターのリストア

コマンドラインによる更新の受付けを開始するには:

障害時リカバリ

障害時リカバリ用のバックアップを作成するには:

障害時リカバリ用にリストアするには:

9.  Directory Serverのグループ、ロールおよびCoS

10.  Directory Serverのレプリケーション

11.  Directory Serverのスキーマ

12.  Directory Serverの索引作成

13.  Directory Serverの属性値の一意性

14.  Directory Serverのロギング

15.  Directory Serverの監視

第2部 Directory Proxy Serverの管理

16.  Directory Proxy Serverのツール

17.  Directory Proxy Serverのインスタンス

18.  LDAPデータ・ビュー

19.  Directory Proxy Serverの証明書

20.  Directory Proxy Serverのロード・バランシングとクライアント・アフィニティ

21.  Directory Proxy Serverの配布

22.  Directory Proxy Serverによる仮想化

23.  仮想データ変換

24.  Directory Proxy ServerとバックエンドLDAPサーバーの接続

25.  クライアントとDirectory Proxy Serverの接続

26.  Directory Proxy Serverのクライアント認証

27.  Directory Proxy Serverのロギング

28.  Directory Proxy Serverの監視とアラート

第3部 Directory Service Control Centerの管理

29.  Directory Service Control Centerの構成

索引

レプリケートされた接尾辞のリストア

サプライヤ・サーバーとコンシューマ・サーバー間でレプリケートされた接尾辞では、リストアする前に特別な考慮が必要です。可能な場合、バックアップからのリストアではなく、レプリケーション・メカニズムにより接尾辞を更新するようにしてください。

サプライヤまたはハブ・インスタンスをリストアする際は、サーバーの構成をバックアップを実行したときと同じにする必要があります。これを確実に行うには、Directory Serverデータのリストア前にdse.ldifファイルをリストアします。サーバーの起動中に、--safeオプションを使用します。詳細は、「Directory Serverを起動、停止および再起動するには:」を参照してください。

この項では、レプリカをリストアする場合とその方法、およびその操作後に他のレプリカとの同期を確保する方法について説明します。レプリカを初期化するには「レプリカの初期化」を参照してください。

レプリケートされた大規模な接尾辞に多くのエントリを追加して、レプリケーションの更新が正常に追加されるようにするには、「大規模なレプリケートされた接尾辞への多数のエントリの増分追加」を参照してください。

この項の内容は、次のとおりです。

シングルマスター・シナリオでのサプライヤのリストア

シングルマスター・サプライヤである接尾辞には、レプリケーション・トポロジ全体に対して信頼できるデータが含まれます。したがって、接尾辞のリストアはトポロジ全体のデータすべてを初期化すしなおすことに相当します。シングルマスターをリストアするのは、リストアするバックアップの内容で全データを初期化しなおす場合のみとします。

エラーによりシングルマスター・データのリカバリが不可能な場合、コンシューマにはバックアップよりも新しい更新を含まれていることがあるので、いずれかのコンシューマのデータを使用することを検討してください。この場合、データをコンシューマ・レプリカからLDIFファイルにエクスポートしてから、そのLDIFファイルよりマスターを初期化しなおす必要があります。

バックアップのリストアでも、マスター・レプリカでのLDIFファイルのインポートでも、後でこのレプリカから更新を受信するすべてのハブおよびコンシューマ・レプリカを初期化しなおす必要があります。サプライヤ・サーバーのログ・ファイルには、コンシューマの再初期化が必要であることを示すメッセージが記録されます。

マルチマスター・シナリオでのサプライヤのリストア

マルチマスターのレプリケーションでは、他の各マスターにはレプリケートされたデータの信頼できるコピーが含まれています。古いバックアップでは、最新のレプリカの内容より古い場合があるので、リストアできません。可能であれば、レプリケーション・メカニズムにより、他のマスターの内容を使用してマスターを最新にするようにしてください。

それが不可能な場合、次のいずれかの方法でマルチマスターをリストアします。

リストアまたは再初期化の方法にかかわらず、マスター・レプリカでは初期化後も読取り専用モードが維持されます。この動作により、レプリカの他のマスターとの同期が可能になり、これ以後は、「マルチマスター・シナリオでのマスターのリストア」の説明どおりに、書込み操作を行うこともできます。

リストアまたは再初期化したマスターでの書込み操作を許可する前に、すべてのレプリカを収束させることの利点は、ハブまたはコンシューマ・サーバーを初期化しなおす必要がなくなることです。

ハブのリストア

この項は、レプリケーション・メカニズムでハブ・レプリカを自動的に最新の状態にできない状況でのみ適用されます。このような状況には、データベース・ファイルの破損、または長期にわたるレプリケーションの中断が含まれます。これらの場合、次の方法のいずれかによりハブ・レプリカをリストアまたは初期化しなおす必要があります。


注意: ハブ・レプリカのリストアまたは初期化の方法にかかわらず、他のあらゆるレベルのハブを含め、このハブのコンシューマをすべて初期化しなおす必要があります


専用コンシューマのリストア

この項は、レプリケーション・メカニズムで専用コンシューマ・レプリカを自動的に最新の状態にできない状況でのみ適用されます。このような状況には、データベース・ファイルの破損、または長期にわたるレプリケーションの中断が含まれます。これらの場合、次の方法のいずれかによりコンシューマをリストアまたは初期化しなおす必要があります。

マルチマスター・シナリオでのマスターのリストア

マルチマスターのレプリケーションの場合、あるマスターのリストア中に、他のマスターが変更を処理することもあります。したがって、リストア完了時に、新しいマスターは、リストア・データには含まれていなかった新しい更新を受け取る必要があります。マスターのリストアには莫大に時間がかかる場合があるので、保留中の更新数もまた莫大になることがあります。

それらの保留中の更新を収束させるために、新たにリストアされたマスターはリストア後、クライアント操作に対して自動的に読取り専用モードに設定されます。これは、コマンドラインでLDIFファイルからデータをインポートするか、バックアップを使用してバイナリ・コピーを実行することでマスターをリストアする場合にのみ当てはまります。

したがってリストア後は、マルチマスター構成のマスターは、レプリケーション更新を処理して読取り操作を許可しますが、クライアントからの書込み操作すべてに対してはリフェラルを返します。

更新が許可される前に、新しいマスターが他のマスターと完全に同期していることを確認するには、初期化されたマスターで手動により更新を有効にします。


注意: この新しい動作によってリフェラルを送信するマスター・レプリカでは、書込み操作を実行するクライアントが構成されたホップ制限に達する場合があります。この場合、クライアントのホップ制限の構成を増やして、クライアントが使用可能なマスターへアクセスできるようにする必要があります。すべてのマスター・レプリカが初期化または再初期化されている場合、クライアント更新を受け付けるレプリカがないので、書込み操作はすべて失敗します。

いずれにしても、初期化されたマスターを注意して監視し、リフェラル属性を適切に設定してサーバーのレスポンスを最大にしてください。


コマンドラインによる更新の受付けを開始するには:

このタスクの実行には、DSCCが使用できます。詳細は、「Directory Service Control Centerのインタフェース」およびDSCCのオンライン・ヘルプを参照してください。

次のコマンドをマルチマスター・レプリカの初期化プロセスを自動化するスクリプトで使用できます。

  1. insyncツールを使用して、レプリカが他のすべてのマスターと一致したことを確認します。

    全サーバーにおける変更の遅延がゼロの場合、またはレプリカにレプリケートする変更がない場合(-1の遅延)、レプリカは同期状態にあります。詳細は、insync(1)のマニュアル・ページを参照してください。

  2. 更新の受付けを開始します。
    $ dsconf set-suffix-prop -h host -p port suffix-DN repl-accept-client-update-enabled:on

    このコマンドにより、読み書きモードが自動的に設定されます。