转载自：http://teamapproach.ca/trouble/Replication.htmWindows Server Troubleshooting - Replication
Replicating directory information in Windows NT servers is simple because only the PDC Primary Domain Controller can accept updates and these updates are sent directly from the primary to the BDC Backup Domain Controllers. The problem with this simple scheme is that no updates can be accepted if the Primary Domain Controller fails.
NT Domain AD Multimaster Replication
ïð óó
BDC PDC BCD DC DC DC
Only PDC accept updates Any DC can accept updates
To provide better fault tolerance, the Active Directory supports multimaster replication. With multimaster replication, any domain controller can accept updates. All updates must then be replicated to all other domain controllers to try to achieve a consistent database. When network links and servers go down, the consistency between the distributed database cannot be guaranteed at any point in time. Because of this situation, the Active Directory is said to be loosely consistent. The Active Directory is designed to cope with loose consistency by continuously trying to get the databases to converge. Eventually updates will replicate to all Domain Controllers and then the Active Directory has convergence.
If every server had to replicate changes to every other server, there would be an excessive number of server connections.
To simplify the replication topology and to reduce the network traffic, the Active Directory uses a store-and-forward replication model as shown in the following diagram.
| ó ô õö ô ÷ø óExcessive connections |
ÄÊ Ç ÃStore-and-Forward Replication |
The store-and-forward model has a reduced number of replication partners with whom domain controllers exchange information.
Each domain controller stores three NC naming contexts, schema, configuration, and domain, each of which is replicated separately.
|
|
|
| ||
| All servers replicate the configuration and schema NCs | ||||
A service called the KCC Knowledge Consistency Checker determines which servers are replication partners. It starts by forming a replication ring and then adds connections that divide the ring until there is no more that 3 hops between servers. In the following diagram, 3 connections must be added to divide the 10-server ring to ensure no more than 3 hops.
|
óóó |
|
| ô ô |
ó |
ô ô |
|
óóó |
|
| Replication Ring |
Update Sequence Numbers
Any change to any object attribute in the Active Directory must be replicated to all other domain controllers. To keep track of changes, every attribute update is assigned a 64-bit sequence number called the USN update sequence number. The following diagram is a simplified view of his this works and shows how each attribute update is assigned a simple update sequence number.
| USN | Attribute | |
| 1238 | AttributeQ | |
| 1237 | AttributeX | |
| 1236 | AttributeB | |
| 1234 | AttributeZ | |
| 1234 | AttributeN | |
| ... | ... |
In the following example, if Server2 is a new domain controller then all attributes from Server1 are replicated to Server2. Server2 maintains its own independent USN update sequence numbers. Server2 must record the highest USN from Server1. This highest USN is know as the high-watermark vector. The next time replication occurs, only attributes with a higher USN need be copied
| Existing directory on Server1 | New directory on Server2 | ||||
| USN | Attribute | USN | Attribute | ||
| 1238 | AttributeQ | Replicatedè |
325 | AttributeQ | |
| 1237 | AttributeX | 324 | AttributeX | ||
| 1236 | AttributeB | 323 | AttributeB | ||
| 1234 | AttributeZ |
|
322 | AttributeZ | |
| 1234 | AttributeN | 321 | AttributeN | ||
| ... | ... | ... | ... | ||
| High-watermark for Server1 = 1238 | |||||
Domain Controllers must also record for every attribute update,
- Is this an originating update that was made on this server? or
- Is this a replicated update and on which server did it originate?
| USN | Attribute | Originated where? | |
| 9880 | AttributeY |  Replicated from Server2 |
|
| 9879 | AttributeC | Replicated from Server3 | |
| 9878 | AttributeF |  Originated here | |
| 9877 | AttributeW | Replicated from Server2 |
|
| 9876 | AttributeP | Originated here |
|
| ... | ... | ... |
To understand how the USN is used to notify domain controller replication partners, consider the following example. The diagram shows the state of the attribute updates before and after a replication cycle. The italics text represents the new information after the replication cycle. Initially, Server1 is updated to USN 1241. Its replication partners Server2 and Server3 have a high-watermark for Server1 of 1238 and 1240 respectively, set from the previous replication cycle. Only attribute updates with a USN higher than the high-watermark need to be replicated and are represented by the text in italics with the gray background. After the replication cycle, both servers will update their high-watermark to Server1's USN of 1241.
When attribute changes occur, domain controllers delay the notification of replication partners for 5 minutes in an attempt to accumulate multiple changes. Sending multiple changes together will result in less network traffic than sending each update separately.
| Existing directory on Server1 | Directory on Server2 | ||||
| USN | Attribute | USN | Attribute | ||
| 1241 | AttributeM | Replicatedè |
325 | AttributeM | |
| 1240 | AttributeG | 324 | AttributeG | ||
| 1239 | AttributeV | 323 | AttributeV | ||
| 1238 | AttributeQ |
|
325 | AttributeQ | |
| 1237 | AttributeX | 324 | AttributeX | ||
| ... | ... | ... | ... | ||
| Replicated | High-watermark for Server1 = 1238 | ||||
| î | High-watermark for Server1 = 1241 | ||||
| Directory on Server3 | |||||
| USN | Attribute | ||||
| 9881 | AttributeM | | |||
| 9880 | AttributeY | ||||
| 9879 | AttributeC | ||||
|
|
9878 | AttributeF | |||
| 9877 | AttributeW | ||||
| ... | ... | ||||
| High-watermark for Server1 = 1240 | |||||
| High-watermark for Server1 = 1241 | |||||
If a domain controller is offline for an extended period of time, its high-watermark vectors will not be updated. When it does come back online, it will then receive all updates without any loss of information.
Up-to-dateness Vector
Although we see that changes get replicated even when servers fail, we do not yet have the complete story of how replication works. Based on what has been described above, there is a problem if Server2 and Server3 replicate to each other. Because their USNs have now increased, they would replicated these changes to each other. But Server2 and Server3 already got these changes from Server1. They would also try to replicate these changes back to Server1. Server1's USN would increase again and it would replicate these same changes back to Server2 and Server3, thus creating a vicious replication loop. To prevent this, the domain controllers need to have another mechanism to represent how up-to-date they are with the source of the attribute updates. The Active Directory has an up-to-dateness vector to record the highest USN for updates that originate from each domain controller and have been received. The following table provides a summary.
| Vector | Description | For which DCs |
| High-watermark | Highest USN received from | Replication Partners |
| Up-to-dateness | Highest USN originating from | All DCs with same name context |
The up-to-dateness vector prevents changes from replicating when they have already been received from a different source. The up-to-dateness vector ensures that a domain controller knows how up to date it is with changes that originated on a particular domain controller.
| Server1 | Server2 | My information with respect to Server1 is up-to-date to USN 1240 so only send me changes that originate at Server1 with a USN greater than 1240. | |||
| USN | Attribute | î |
|||
| 1241 | AttributeM | Server4 | |||
| 1240 | AttributeG | ì | __ | ||
| 1239 | AttributeV | î | ì |
||
| 1238 | AttributeQ | Up-to-dateness of Server1 = 1240 | |||
| 1237 | AttributeX | ||||
| ... | ... | Server3 |
Resolving Conflicts
What happens if the same attribute is changed independently on two different domain controllers? The conflict needs to be resolved as the change replicates between the domain controllers. In the end the attribute change must converge to a consistent value. For each attribute, the Active Directory stores its value, but also
- an incrementing version number
- the time that the change was originated
- the server where the change originated
| Attribute | Value | Version | Originating time | Originating server |
|
incremented |
Conflicts are resolved by examining this additional information in the following sequence. Normally the last value that is written is used.
- the highest version number is used
- the latest originating time is used
- the originating server is identified by a GUID number, if the version and time are the same then the value of the GUID is arbitrarily used to break the tie.
There is a problem to resolve in the case of an object being added or moved to a container on one domain controller and that same container is deleted on another domain controller. In such cases, the objects are placed in the LostAndFound container.
| Server1 |
Server2 |
 è Add user to container |
 Delete container |
| To resolve the conflict AD stores the user in the LostAndFound container | |
Another problem occurs if objects are added to two different domain controllers with the same object name. In this case, the first added object keeps its name, but the second object gets a name in the format RDN*CNF:<GUID> where <GUID> is the globally unique identifying number for the object which is guaranteed to be unique. RDN stands for Relative Distinguished Name, CNF stand for Conflict, and * is a reserved character.
 |
I want to be called Bob Added 09:30 |
|
I want to be called Bob Added 09:31 |
 |
The 1st object will be named Bob |
 |
The 2nd object will be named RDN*CNF:1234567890 |
REPADMIN /SHOWMETA
To see the USNs, originating time, and version numbers for each attribute, use the REPADMIN command as shown below.
C:\>repadmin /showmeta cn=administrator,cn=users,dc=newdomain,dc=com
33 entries.
Loc.USN Originating DC Org.USN Org.Time/Date Ver Attribute
======= =============== ========= ============= === =========
8194 Default-First-Site-Name\WIN2003 8194 2003-02-11 11:31:37 1 objectClass
8194 Default-First-Site-Name\WIN2003 8194 2003-02-11 11:31:37 1 cn
16429 Default-First-Site-Name\WIN2003 16429 2003-04-23 19:45:04 3 description
16427 Default-First-Site-Name\WIN2003 16427 2003-04-23 19:44:14 1 physicalDeliveryOfficeName
8194 Default-First-Site-Name\WIN2003 8194 2003-02-11 11:31:37 1 instanceType
8194 Default-First-Site-Name\WIN2003 8194 2003-02-11 11:31:37 1 whenCreated
16432 Default-First-Site-Name\WIN2003 16432 2003-04-23 19:45:53 4 displayName
13893 Default-First-Site-Name\WIN2003 13893 2003-02-11 12:00:00 2 nTSecurityDescriptor