一般的なレプリケーション競合の解決

マルチマスター・レプリケーションでは、ゆるやかな一貫性を持つレプリケーション・モデルを使用します。これは同一エントリを別々のサーバーで同時に変更できることを意味します。2つのサーバー間で更新が送信された場合、変更の競合を解決する必要があります。ほとんどの場合、解決は自動で行われます。たとえば、各サーバーの変更に関連付けられたタイムスタンプは優先される直近の変更により解決されます。しかし、一部の変更の競合には、解決に至るまでに手動操作が必要になるものもあります。

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

DSCCの使用によるレプリケーション競合の解決
コマンドラインの使用によるレプリケーション競合の解決
名前の競合の解決
親のないエントリの競合の解決
潜在的な相互運用性の問題の解決

DSCCの使用によるレプリケーション競合の解決

レプリケーションの競合を解決する最も簡単な方法は、DSCCを使用することです。詳細は、DSCCのオンライン・ヘルプを参照してください。

コマンドラインの使用によるレプリケーション競合の解決

コマンドラインの使用により、レプリケーション競合を解決できます。レプリケーション・プロセスでの自動解決が不可能な変更の競合があるエントリには、競合マーカーとしての操作属性nsds5ReplConflictが含まれます。

競合するエントリを検出するには、定期的にこの属性を含むエントリを検索します。たとえば、次のldapsearchコマンドを使用して、競合のあるエントリを検索できます。

$ ldapsearch -h host2 -p 1389 -D cn=admin,cn=Administrators,cn=config \
 -w - -b "dc=example,dc=com" "(nsds5ReplConflict=*)"

nsds5ReplConflict属性はデフォルトで索引が付けられます。

名前の競合の解決

サーバー同士が互いの変更をレプリケートする前に、エントリが作成された場合、同じDNを持つエントリが別々のマスターで作成される場合があります。レプリケーションでは、競合解決のメカニズムにより2番目に作成されたエントリの名前が自動的に変更されます。

DNの名前が競合するエントリは、操作属性nsuniqueidにより指定される一意の識別子をDN内に含めることで名前を変更します。

たとえば、エントリuid=bjensen,ou=People,dc=example,dc=comが2つのマスターで同時に作成された場合、レプリケーション後の2つのエントリは次のようになります。

uid=bjensen,ou=People,dc=example,dc=com
nsuniqueid=66446001-1dd211b2-66225011-2ee211db+uid=bjensen,dc=example,dc=com

2番目のエントリには、実用的なDNを与える必要があります。競合するエントリを削除して、競合しない名前を付けて再度追加することもできます。ただし、エントリ名の変更により、内容まで変わってしまうことはありません。名前の変更手順は、ネーミング属性が単一値を持つか複数値を持つかかにより異なります。次の手順を参照してください。

複数値のネーミング属性を持つ競合エントリ名を変更するには:

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

古いRDN値を維持しながら、エントリ名を変更します。たとえば、次のようになります。
```
$ ldapmodify -h host2 -p 1389 -D cn=admin,cn=Administrators,cn=config -w -
Enter bind password:
dn: nsuniqueid=66446001-1dd211b2-66225011-2ee211db+uid=bjensen,dc=example,dc=com
changetype: modrdn
newrdn: uid=bj66446001
deleteoldrdn: 0
^D
```
この手順で古いRDN値は削除できません。これが削除できないnsuniqueidの操作属性を含むためです。

ネーミング属性の古いRDN値と競合マーカー属性を削除します。たとえば、次のようになります。

$ ldapmodify -h host2 -p 1389 -D cn=admin,cn=Administrators,cn=config -w -
Enter bind password:
dn: uid=bj66446001,dc=example,dc=com
changetype: modify
delete: uid
uid: bjensen
-
delete: nsds5ReplConflict
^D

単一値のネーミング属性を持つ競合エントリ名を変更するには:

dc(ドメイン・コンポーネント)など、重複エントリのネーミング属性が単一値の場合、エントリ名を単純に同じ属性の他の値に変更することはできません。かわりに、エントリには一時的な名前を付与する必要があります。

異なるネーミング属性を使用してエントリ名を変更し、古いRDN値は維持します。たとえば、次のようになります。
```
$ ldapmodify -h host2 -p 1389 -D cn=admin,cn=Administrators,cn=config -w -
Enter bind password:
dn: nsuniqueid=66446001-1dd211b2-66225011-2ee211db+dc=HR,dc=example,dc=com
changetype: modrdn
newrdn: o=TempHREntry
deleteoldrdn: 0
^D
```
この手順で古いRDN値は削除できません。これが削除できないnsuniqueidの操作属性を含むためです。

目的のネーミング属性を一意の値に変更して、競合マーカー属性を削除します。たとえば、次のようになります。

$ ldapmodify -h host2 -p 1389 -D cn=admin,cn=Administrators,cn=config -w -
Enter bind password:
dn: o=TempHREntry,dc=example,dc=com
changetype: modify
replace: dc
dc: NewHR
delete: nsds5ReplConflict
^D

エントリ名を変更して、目的のネーミング属性に戻します。たとえば、次のようになります。
```
$ ldapmodify -h host2 -p 1389 -D cn=admin,cn=Administrators,cn=config -w -
Enter bind password:
dn: dc=NewHR,dc=example,dc=com
changetype: modrdn
newrdn: dc=HR
deleteoldrdn: 1
^D
```
deleteoldrdn属性の値を1に設定することにより、一時的な属性と値のペアo=TempHREntryを削除します。この属性を維持する場合は、deleteoldrdn属性の値を0に設定します。

親のないエントリの競合の解決

削除操作がレプリケートされ、かつコンシューマ・サーバーで削除するエントリに子エントリがあることが判明した場合、競合解決プロシージャによってglueエントリが作成され、ディレクトリに親のないエントリが生じる事態を回避します。

同様に、追加操作がレプリケートされ、かつコンシューマ・サーバーで親エントリを検出できない場合も、競合解決プロシージャにより親を表すglueエントリが作成され、新しいエントリが親のないエントリとなる事態を回避します。

glueエントリは、オブジェクト・クラスglueおよびextensibleObjectを持つ一時的なエントリです。glueエントリは、次の様々な方法で作成できます。

競合解決プロシージャにより、一致する一意の識別子を持つ削除されたエントリが見つかった場合は、glueエントリはそのエントリの復元となります。これにはglueオブジェクト・クラスとnsds5ReplConflict属性も含まれます。

このような場合では、glueエントリを変更してglueオブジェクト・クラスとnsds5ReplConflict属性を削除し、通常のエントリとして維持するか、またはglueエントリとその子エントリを削除します。
サーバーにより、glueおよびextensibleObjectオブジェクト・クラスを持つ最小限のエントリが作成されます。

このような場合には、エントリを変更して意味のあるエントリとするか、またはエントリとそのすべての子エントリ削除します。

潜在的な相互運用性の問題の解決

メール・サーバーのように属性の一意性に依存するアプリケーションとの相互運用性のため、nsds5ReplConflict属性を持つエントリへのアクセス制限が必要となる場合があります。これらのエントリに対するアクセスを制限しない場合は、1つの属性のみを要求するアプリケーションが元のエントリとnsds5ReplConflictを含む競合解決エントリの両方を取得し、処理が失敗します。

アクセスを制限するには、次のコマンドを使用して、匿名の読取りアクセスを許可するデフォルトのACIを変更する必要があります。

$ ldapmodify -h host2 -p 1389 -D cn=admin,cn=Administrators,cn=config -w -
Enter bind password:
dn: dc=example,dc=com
changetype: modify
delete: aci
aci: (target ="ldap:///dc=example,dc=com")
 (targetattr !="userPassword"
 (version 3.0;acl "Anonymous read-search  access";
 allow (read, search, compare)(userdn = "ldap:///anyone");)
-
add: aci
aci: (target="ldap:///dc=example,dc=com")
 (targetattr!="userPassword")
 (targetfilter="(!(nsds5ReplConflict=*))")(version 3.0;acl
 "Anonymous read-search access";allow (read, search, compare)
 (userdn="ldap:///anyone");)
^D

新しいACIは、nsds5ReplConflict属性を含むエントリが検索結果として返されないようにします。

ナビゲーション・リンクをスキップ
印刷ビューの終了
	Oracle Directory Server Enterprise Edition管理ガイド 11gリリース1(11.1.1.5.0)