jspωiki
TransitiveVector

Overview#

TransitiveVector in eDirectory is a synchronizing multi-valued attributeTypes, where each attribute value represents the state in time that the specified eDirectory agent has received changes up to.

Background Information#

Novell Directory Services (eDirectory) was initially release in 1993. For instance, in NetWare 3.x, there were the enhancements to the SYSCON utility called NETCON, which used a form of forced synchronization of user and group objects between servers. In order to overcome the limitations of a patched solution such as NETCON, NDS was born to offer a complete Directory Service solution, designed from the ground up to fulfill that mission.

Initially, NDS was designed with a method of updating information on all servers in the NDS Tree-name. This was called synchronization. Recently synchronization has been improved to handle increased efficiency that were demanded by the current workforce. One of the updates to synchronization is called Transitive Synchronization. In order to understand Transitive Synchronization, it is important to understand the TransitiveVector.

The TransitiveVector#

In order to maintain the EDirectory Synchronization of replicas, NDS needs to keep track of the changes that have been made. This is done by placing a timestamp on a specific attribute of the Partition Root Entry. This timestamp indicates when the last update was made. By looking at the timestamp, NDS can evaluate whether the most current updates have been received by that replica.

EDirectory Versions before NetWare 5, an attribute called "Synchronized Up To" determined when the latest changes were made. The value of Synchronized Up To attribute is unique for each replica and is not synchronized to the other servers in the replica ring (NDS Tree-name).

TransitiveVector NetWare 5 and greater#

EDirectory Versions that shipped with NetWare 5 and greater, use TransitiveVector to track changes to a partition. The TransitiveVector holds Timestamps for all the replicas in the replica List from each NcpServer's perspective.

Each NcpServer in the replica List has a copy of its own TransitiveVector and every NcpServer also has copies of the TransitiveVector of the other NcpServers in the NDS Tree-name.

On each single NcpServer, these Timestamps are referred to as the TransitiveVector. The TransitiveVector tracks any changes that occur to the immediate partition.

TransitiveVector is a MULTI-VALUE attribute, the TransitiveVector is added to the Partition Root Entry for each NDS Partition in NDS (eDirectory). By synchronizing the TransitiveVector values, all of the replicas can synchronize without having every replica communicate with every other replica.

TransitiveVector Values#

Ldapwiki has not been able to find any detailed documentation on content of TransitiveVector and this is based on years of experience, research and theory and a few hints form here and there. Of course Ldapwiki is most interested in how to read the TransitiveVector from LDAP

Array of entries which each entry contains:

TransitiveVector and the Restore Verification Process#

NcpServers that hold replicas of the same partition communicate with each other to keep the replicas synchronized. Each time a server communicates with another server in the Replica List, it keeps a record of the TransitiveVector the other NcpServer had when they communicated. These TransitiveVector allow the servers in a Replica List to know what information needs to be sent to each replica in the ring to keep all the replicas synchronized. When a server goes down, it stops communicating, and the other servers do not send updates or change the TransitiveVector they have recorded for that NcpServer until the server starts communicating again.

When you restore eDirectory on a NcpServer, the restore verification process compares the TransitiveVector of the server being restored to the other NcpServers in the Replica List. This is done to make sure that the replicas being restored are in the same state that the other NcpServer expect.

If the TransitiveVector on the remote server is ahead of the local TransitiveVector, then data is missing from the restore, and the verification fails. For example, data might be missing because you did not turn on continuous Roll-Forward Logs before the last full or Incremental Backup, you did not include the roll-forward logs in the restore, or the set of Roll-Forward Logs you provided for the restore was not complete.

By default the restored eDirectory database is NOT opened if it is inconsistent with the other replicas.

TransitiveVector Example#

TransitiveVector is a time stamp for a replica.

TransitiveVector is made up of a representation of the number of seconds since a common specific point in history (UNIX epoch), the replica number, and the current event number. Here's an example:

s3D35F377 r02 e002

LDAP AttributeTypes Definition#

The TransitiveVector AttributeTypes is defined as:

More Information#

There might be more information for this subject on one of the following: