2. Directory Serverのインスタンスと接尾辞
7. Directory Serverのパスワード・ポリシー
8. Directory Serverのバックアップとリストア
9. Directory Serverのグループ、ロールおよびCoS
16. Directory Proxy Serverのツール
17. Directory Proxy Serverのインスタンス
19. Directory Proxy Serverの証明書
20. Directory Proxy Serverのロード・バランシングとクライアント・アフィニティ
22. Directory Proxy Serverによる仮想化
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の管理
レプリケーションの一環として更新が実行される際は、UID一意性プラグインでの属性値チェックは行われません。これはシングルマスター・レプリケーションには影響しませんが、プラグインではマルチマスター・レプリケーションに対して属性の一意性を自動的に適用できません。
クライアント・アプリケーションによる変更はすべてマスター・レプリカで実行されるため、マスター・サーバーでUID一意性プラグインを有効にする必要があります。レプリケートされた接尾辞内で一意性を適用するよう、プラグインを構成する必要があります。マスターでは目的の属性値についての一意性が保証されるので、コンシューマ・サーバーでこのプラグインを有効にする必要はありません。
シングルマスターのコンシューマでUID一意性プラグインを有効化しても、レプリケーションや通常のサーバー操作に支障はありません。ただし、パフォーマンスが若干低下する場合があります。
UID一意性プラグインは、マルチマスター・レプリケーション・シナリオに対応した設計にはなっていません。マルチマスター・レプリケーションでは、ゆるやかな一貫性を持つレプリケーション・モデルが使用されるので、両方のサーバーでプラグインが有効になっていても、同じ属性値が両方のサーバーに同時に追加された場合は検出されません。
ただし、一意性チェックの実行対象の属性がネーミング属性であり、かつ一意性プラグインをすべてのマスターの同じサブツリーの同じ属性に対して有効にする場合は、UID一意性プラグインを使用できます。
これらの条件が満たされている場合、レプリケーション時の名前の競合として一意性の競合が報告されます。名前の競合は手動で解決する必要があります。詳細は、「一般的なレプリケーション競合の解決」を参照してください。