マルチマスターレプリケーションでは、疎整合型レプリケーションモデル (Loose Consistency Replication Model) を使用します。つまり、同一のエントリを別々のサーバーから同時に変更できます。2 つのサーバー間で更新が送信された場合、更新の競合を解決する必要があります。たいていは自動的に解決されます。たとえば、各サーバーの変更に関するタイムスタンプは、優先される最近の変更によって解決されます。しかし、一部の更新の競合では、解決に至るまでに、手動の調整が必要になることもあります。
この節の内容は、次のとおりです。
レプリケーションの競合を解決するもっとも簡単な方法は、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 内に含めることで名前を変更します。
たとえば、2 つのマスターで uid=bjensen,ou=People,dc=example,dc=com というエントリが同時に作成されると、レプリケーション後の 2 つのエントリは、次のようになります。
uid=bjensen,ou=People,dc=example,dc=com
nsuniqueid=66446001-1dd211b2-66225011-2ee211db+uid=bjensen,dc=example,dc=com
2 つ目のエントリには、有効な DN を指定する必要があります。競合しているエントリを削除し、競合しない名前で追加し直すことができます。ただし、エントリの名前を変更しても、その内容は変更されていません。名前変更の手順は、ネーミング属性が 1 つの値を持つか複数の値を持つかによって異なります。そのための手順は次のとおりです。
このタスクは 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 (ドメインコンポーネント) など、重複したエントリのネーミング属性が 1 つの値の場合は、エントリの名前を単に同じ属性の別の値に変更することはできません。代わりに一時的な名前を付ける必要があります。
このタスクは 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+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 属性を持つエントリが保持されます。