Export (0) Print
Expand All
This topic has not yet been rated - Rate this topic

3.1.1.11 Version Vector Object

The version vector is a vector of tuples. Each tuple consists of an originator GUID and a Volume Sequence Number (VSN). There is one tuple for each member of the replica set. Each replica tree has its own version vector.

The originator GUID MUST be a unique identifier for each member of the Replica Set. The VSN MUST be the VSN of the last change order received from the member identified by the originator GUID except when the change orders are received out of order. If change orders are received out of order, the VSN in the version vector MUST be the VSN of the most recent change order received that was not out of order.

Each member has its own originator GUID in its version vector. The VSN associated with a member's own originator GUID MUST be the VSN of the last change order that the member generated.

When a member initializes itself, it MUST set its own VSN to the current time (FILETIME). Using the current time ensures that all VSNs generated from the time of initialization forward will be greater than any VSN previously generated on the system. This is critical to ensure that replication continues to work properly across restarts of FRS on a system. Each time a change order is generated, the VSN MUST be incremented, and the new VSN is assigned to the new change order.

The version vector is persistent. If FRS stops running, the stored version vector can be used to determine what files need to be replicated onto the Partner to bring it back up to date. This is accomplished by a VVJoin process. In a VVJoin, the downstream partner establishes a connection with an upstream partner. Once the connection is established, the downstream partner's version vector MUST be sent to the Upstream Partner. The Upstream Partner compares the downstream partner's version vector to its own version vector. Any entries in the downstream partner's version vector that are older than the Upstream Partner's version vector entries cause the Upstream Partner to scan its IDTable to determine what files and folders must be replicated to bring the downstream partner up to date.

Once the upstream partner determines what files and folders must be replicated to the downstream partner, change orders MUST be generated and sent to the downstream partner. Once the downstream partner receives a change order from the Upstream Partner, it determines if a staging file is needed for this change order. If a staging file is needed, the downstream partner MUST request the staging file from the Upstream Partner. Once the downstream partner receives all parts of the staging file, or if a staging file is not needed, the downstream partner MUST apply the change order on the file system and MUST update IDTable and version vector objects based on the change order. The downstream partner MUST then forward the same change order to its downstream partners.

A VVJoin MUST take place when a schedule initially comes online.

On receipt of a change order, the originator GUID and the VSN of the change order MUST be checked against the version vector. This check (called version dampening) allows a member to recognize change orders for files or folders that have already been applied in the local replica tree.

Show:
© 2014 Microsoft. All rights reserved.