Red Hat DIRECTORY SERVER 8.0, Руководство администратора

Страница: 316 / 552

Chapter 8. Managing Replication
298
Table Description
doing an update while the others can't acquire
the busy replica.
8.18. Solving Common Replication Conflicts
Multi-master replication uses a loose consistency replication model. This means that the same entries
can be changed on different servers. When replication occurs between the two servers, the conflicting
changes need to be resolved. Mostly, resolution occurs automatically, based on the timestamp
associated with the change on each server. The most recent change takes precedence.
However, there are some cases where change conflicts require manual intervention in order to reach a
resolution. Entries that have a change conflict that cannot be resolved automatically by the replication
process contain a conflict marker attribute
nsds5ReplConflict
. The
nsds5ReplConflict
attribute is an operational attribute which is indexed for presence and equality, so it is simple to search
for entries that contain this attribute. For example:
ldapsearch -D adminDN -w password
-b "dc=example,dc=com" "nsds5ReplConflict=*" \* nsds5ReplConflict
The
nsds5ReplConflict
attribute is already indexed for presence and equality, but for performance
reasons, if there are many conflicting entries every day, index the
nsds5ReplConflict
attribute in
other indexes. For information on indexing, see
Chapter 10, Managing Indexes
.
This section contains the procedures for the following conflict resolution procedures:
•
Section 8.18.1, “Solving Naming Conflicts”
•
Section 8.18.2, “Solving Orphan Entry Conflicts”
•
Section 8.18.3, “Solving Potential Interoperability Problems”
8.18.1. Solving Naming Conflicts
When two entries are created with the same DN on different servers, the automatic conflict resolution
procedure during replication renames the last entry created, including the entry's unique identifier
in the DN. Every directory entry includes a unique identifier given by the operational attribute
nsuniqueid
. When a naming conflict occurs, this unique ID is appended to the non-unique DN.
For example, the entry
uid=adamss,ou=people,dc=example,dc=com
is created on Server A at
time
t1
and on Server B at time
t2
, where
t2
is greater (or later) than
t1
. After replication, Server A
and Server B both hold the following entries:
•
uid=adamss,ou=people,dc=example,dc=com
(created at time
t1
)
•
nsuniqueid=66446001-1uid=adamss,dc=example,dc=com
(created at time
t2
)
The second entry needs to be renamed in such a way that it has a unique DN. The renaming
procedure depends on whether the naming attribute is single-valued or multi-valued.
8.18.1.1. Renaming an Entry with a Multi-Valued Naming Attribute
To rename an entry that has a multi-valued naming attribute, do the following: