15.25. 一般的なレプリケーションの競合の解決
マルチサプライヤーレプリケーションは、最終的に調整されたレプリケーションモデルを使用します。つまり、同じエントリーを別のサーバーで変更できることを意味します。この 2 つのサーバー間でレプリケーションが発生した場合は、競合する変更を解決する必要があります。多くの場合は、各サーバーでの変更に関連するタイムスタンプに基づいて解決が自動的に行われます。最新の変更が優先されます。
ただし、解像度に到達するには、競合を手動で介入する必要があるケースがあります。変更の競合のあるエントリーは、レプリケーションプロセスで自動的に解決できません。
競合エントリーをリスト表示するには、次のコマンドを実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com repl-conflict list dc=example,dc=com
15.25.1. ネーミングの競合の解決
異なるサーバーの同じ DN で 2 つのエントリーを作成すると、レプリケーション中に自動的に競合解決が行われ、DN のエントリーの一意識別子を含む、最後に作成されたエントリーの名前が変更します。すべてのディレクトリーエントリーには、操作属性
nsuniqueid
に保存されている一意の識別子が含まれます。命名の競合が発生すると、この一意の ID が一意でない DN に追加されます。
たとえば、2 つの異なるサーバーに uid=user_name,ou=People,dc=example,dc=com エントリーが作成された場合、レプリケーションは一意の ID を、作成した最後のエントリーの DN に追加します。つまり、以下のエントリーが存在します。
- uid=user_name,ou=People,dc=example,dc=com
- nsuniqueid=66446001-1dd211b2+uid=user_name,ou=People,dc=example,dc=com
レプリケーションの競合を解決するには、以下の手順を手動で決定する必要があります。
- 有効なエントリー (uid=user_name,ou=People,dc=example,dc=com) を維持し、競合エントリーを削除するには、次のコマンドを実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com repl-conflict delete nsuniqueid=66446001-1dd211b2+uid=user_name,ou=People,dc=example,dc=com
- 競合エントリー (nsuniqueid=66446001-1dd211b2+uid=user_name,ou=People,dc=example,dc=com) のみを維持するには、次のコマンドを実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com repl-conflict swap nsuniqueid=66446001-1dd211b2+uid=user_name,ou=People,dc=example,dc=com
- 両方のエントリーを保持するには、次のコマンドを実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com repl-conflict convert --new-rdn=uid=user_name_NEW nsuniqueid=66446001-1dd211b2+uid=user_name,ou=People,dc=example,dc=com
競合エントリーを保持するには、--new-rdn
オプションで新しい Relative Distinguished Name (RDN) を指定して競合エントリーの名前を変更する必要があります。上記のコマンドは、競合エントリーの名前を uid=user_name_NEW,ou=People,dc=example,dc=com に変更します。
15.25.2. 孤立エントリーの競合の解決
削除操作が複製され、コンシューマーサーバーが、削除されるエントリーに子エントリーがあることを検出すると、競合解決の手順により、ディレクトリーに孤立したエントリーが存在しないように、glue エントリーが作成されます。
同様に、追加操作が複製され、コンシューマーサーバーが親エントリーを検出できない場合は、競合解決の手順により、新しいエントリーが孤立エントリーではないように、親を表す glue エントリーが作成されます。
glue エントリー は、オブジェクトクラス glue および extensibleObject を含む一時エントリーです。チャンネルエントリーは、複数の方法で作成できます。
- 競合解決手続で、一致する一意の識別子を持つ削除されたエントリーが見つかった場合、glue エントリーは、そのエントリーの再生であり、glue のオブジェクトクラスと
nsds5ReplConflict
の属性が追加されます。このような場合は、glue エントリーを変更して glue オブジェクトクラスとnsds5ReplConflict
属性を削除して、エントリーを通常のエントリーとして維持するか、その子エントリーを削除します。 - サーバーは glue および extensibleObject オブジェクトクラスを使用して最小のエントリーを作成します。
このような場合は、エントリーを変更して意味のあるエントリーに変換するか、そのすべての子エントリーを削除します。
すべての glue エントリーをリスト表示するには、次のコマンドを実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com repl-conflict list-glue suffix
glue エントリーおよびその子エントリーを削除するには、次のコマンドを実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com repl-conflict delete-glue DN_of_glue_entry
glue エントリーを通常のエントリーに変換するには、次のコマンドを実行します。
# dsconf -D "cn=Directory Manager" ldap://server.example.com repl-conflict convert-glue DN_of_glue_entry
15.25.3. 廃止または不明なエラーの解決
レプリケーショントポロジーに関する情報、つまり、相互に、および同じレプリケーショングループ内の他のレプリカに更新を提供するすべてのサプライヤーは、レプリカ更新ベクトル (RUV) と呼ばれるメタデータのセットに含まれています。RUV には、ID と URL、ローカルサーバー上の最新の変更状態番号 (CSN)、最初の変更の CSN などのサプライヤーに関する情報が含まれています。サプライヤーとコンシューマーはいずれも RUV 情報を保存し、これを使用してレプリケーションの更新を制御します。
あるサプライヤーがレプリケーショントポロジーから削除されると、別のレプリカの RUV に残っている場合があります。他のレプリカが再起動すると、ログにエラーを記録し、レプリケーションプラグインが削除されたサプライヤーを認識しないことを警告します。エラーは以下の例のようになります。
[22/Jan/2021:17:16:01 -0500] NSMMReplicationPlugin - ruv_compare_ruv: RUV [changelog max RUV] does not contain element [{replica 8 ldap://m2.example.com:389} 4aac3e59000000080000 4c6f2a02000000080000] which is present in RUV [database RUV] <...several more samples...> [22/Jan/2021:17:16:01 -0500] NSMMReplicationPlugin - replica_check_for_data_reload: Warning: for replica dc=example,dc=com there were some differences between the changelog max RUV and the database RUV. If there are obsolete elements in the database RUV, you should remove them using the CLEANALLRUV task. If they are not obsolete, you should check their status to see why there are no changes from those servers in the changelog.
レプリカとその ID (この場合はレプリカ
8
を書き留めます。
サプライヤーがトポロジーから永久に削除されると、そのサプライヤーに関する残存するメタデータは、他のすべてのサプライヤーの RUV エントリーから消去されるはずです。
cleanallruv
ディレクトリータスクを使用して、トポロジー内のすべてのサプライヤーから RUV エントリーを削除します。
注記
cleanallruv
タスクが複製されます。そのため、1 つのサプライヤーでのみ実行する必要があります。
手順15.1 cleanallruv タスク操作を使用した、廃止または欠落したサプライヤーの削除
- 削除されたサプライヤーが他のサプライヤーにメタデータを残す可能性があるため、有効無効を問わず、すべての RUV レコードとレプリカ ID をリスト表示します。
# ldapsearch -o ldif-wrap=no -xLLL -H m1.example.com -D "cn=Directory Manager" -W -b dc=example,dc=com '(&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectclass=nstombstone))' nsDS5ReplicaId nsDS5ReplicaType nsds50ruv dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config nsDS5ReplicaId: 1 nsDS5ReplicaType: 3 nsds50ruv: {replicageneration} 55d5093a000000010000 nsds50ruv: {replica 1 ldap://m1.example.com:389} 55d57026000000010000 55d57275000000010000 nsds50ruv: {replica 20 ldap://m2.example.com:389} 55e74b8c000000140000 55e74bf7000000140000 nsds50ruv: {replica 9 ldap://m2.example.com:389} nsds50ruv: {replica 8 ldap://m2.example.com:389} 506f921f000000080000 50774211000500080000
返されたレプリカ ID1
、20
、9
、および8
を書き留めます。 cn=config
接尾辞のレプリカ設定エントリー DNcn=replica
を検索して、データベースを複製するすべてのサプライヤーに現在定義され、有効なレプリカ ID を一覧表示します。注記コンシューマーおよび読み取り専用ノードには、レプリカ ID が65535
に常に設定され、nsDS5ReplicaType: 3
はサプライヤーを署名します。# ldapsearch -o ldif-wrap=no -xLLL -H m1.example.com m2.example.com -D "cn=Directory Manager" -W -b cn=config cn=replica nsDS5ReplicaId nsDS5ReplicaType dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config nsDS5ReplicaId: 1 nsDS5ReplicaType: 3 dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config nsDS5ReplicaId: 20 nsDS5ReplicaType: 3
最初のステップで返されるすべての URI を検索すると (この手順ではm1.example.com
およびm2.example.com
) 、返されたサプライヤーのリスト (nsDS5ReplicaType: 3
があるもの) を直前の手順の RUV の一覧と比較します。上記の例では、この検索で ID1
と20
のみが返されますが、以前の検索では URIm2.example.com
で9
および8
も返されます。これは、後者の 2 つが削除済みで、その RUV を消去する必要があることを意味します。- クリーニングが必要な RUV を判別した後に、新しい
cn=cleanallruv,cn=tasks,cn=config
エントリーを作成し、レプリケーション設定に関する以下の情報を提供します。- 複製されたデータベースのベース DN (
replica-base-dn
) - レプリカ ID (
replica-id
) - 欠落しているサプライヤーからの最大変更状態番号 (CSN) に追いつくか、あるいはすべての RUV エントリーを削除して更新を見逃すか (
replica-force-cleaning
)。この属性をno
に設定すると、タスクは設定されているすべてのレプリカが、まず削除されたレプリカからのすべての変更に追いつくのを待ってから、RUV を削除することになります。
# dsconf -D "cn=Directory Manager" ldap://m2.example.com repl-tasks \ cleanallruv --suffix="dc=example,dc=com" --replica-id=8
注記cleanallruv
タスクが複製されます。そのため、1 つのサプライヤーでのみ実行する必要があります。整理したい各 RUV に同じことを繰り返す (この手順では ID9
)。 - 先に確認したすべてのレプリカの RUV をクリーンアップした後、最初の手順からの検索を再度使用して、追加の RUV がすべて削除されていることを確認します。
# ldapsearch -o ldif-wrap=no -xLLL -H m1.example.com -D "cn=Directory Manager" -W -b dc=example,dc=com '(&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectclass=nstombstone))' nsDS5ReplicaId nsDS5ReplicaType nsds50ruv dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config nsDS5ReplicaId: 1 nsDS5ReplicaType: 3 nsds50ruv: {replicageneration} 55d5093a000000010000 nsds50ruv: {replica 1 ldap://m1.example.com:389} 55d57026000000010000 55d57275000000010000 nsds50ruv: {replica 20 ldap://m2.example.com:389} 55e74b8c000000140000 55e74bf7000000140000
上記の出力でわかるように、レプリカ ID8
および9
は存在しなくなり、RUV が正常に消去されていることを示しています。