Novell Home

My Favorites

Close

Please to see your favorites.

Implications of running "Repair Timestamps and Declare a new epoch"

(Last modified: 25Aug2006)

This document (10073685) is provided subject to the disclaimer at the end of this document.

goal

Implications of running "Repair Timestamps and Declare a new epoch"

fact

Novell Directory Services

Novell NetWare 4.2

Novell NetWare 5.1

Novell NetWare 6.0

fix

An epoch is an instant in time that is arbitrarily selected as a point of reference.  It is used here to mean a new version.  An epoch controls replica synchronization.  When a new epoch is declared, it begins on the master replica.  Other replicas cannot send updates to to a replica with a new epoch, but they will receive updates from the master replica until they become fully synchronized with it.  When this process completes, all replicas have the same epoch, and can synchronize with other again.

This operation provides a new point of reference to the master replica, so that all replicas of the selected partition are updated.  This operation is always performed on the master replica, which does not need to be the local replica on the current server (meaning you can declare a new epoch from a Read/Write replica, but it is still issued from the Master replica).  In this operation all time stamps in the master replica are examined.  If any time stamps are ahead of the current time, they are replaced with the current one that is unique and will not be reissued.  After the time stamps have been made consistent in time, a new epoch is declared.

Below is a list of facts regarding the Declare a new epoch option:

-  A new epoch is declared on the master replica, possibly affecting all objects in the replica.

-  All time stamps are examined and repaired as required.

-  Updates are not accepted from replicas with post-dated time stamps (epochs) until the replicas are synchronized

-  A replica receives a copy of all objects in a master replica or any other replica that has received a new epoch

-  The replica becomes the same epoch as the master replica

-  Any modifications from a previous epoch are lost

-  The master replica does not need to reside on the current server, but you must have the Supervisor right to the master replica to perform the repair operation

-  The other replicas are put in a new state

CONSIDERATIONS:

NOTE:  Declaring a new epoch is a very expensive operation, and should not be used regularly.

The most important item to check when considering this option is to make sure that all servers in the replica ring are communicating properly.  When you declare a new epoch, it will put all Read/Write and S/R replicas in a new state simultaneously and the master will simultaneously synchronize ALL objects in the given partition to ALL replicas.  This can cause considerable network traffic depending on the size of the partition and the speed of the LAN/WAN links between the servers in the replica ring.  

One way to cut down on the amount of LAN/WAN traffic this will cause is to remove all RW replicas except one.  So the replica ring will have only one Master and one Read Write replica.  This is the preferrable state of the replica ring prior to declaring an epoch for the best results.

MINIMUM DS.NLM VERSIONS

You must be at the following versions (or greater) in order to avoide database corruption when using repair timestamps and declare a new epoch.  Although all servers in the replica ring should be running the versions listed below, only the server with the master replica must be updated to avoid replica ring corruption.

* All versions of NDS 6.x or 7.x
* DS version 8.80d or greater with NetWare 5.x
* DS version 85.26a or greater for eDirectory 8.5 
* eDirectory 8.6.2 (default DS for NetWare 6 Support Pack 1)

If you do run Repair timestamps and Declare a new epoch on an older version than listed above and the replica rings become corrupt, see TID #10063273  - Declaring an epoch destroys all replica ring attributes on servers holding copies, except for the Master.  




   

.

disclaimer

The Origin of this information may be internal or external to Novell. Novell makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Novell makes no explicit or implied claims to the validity of this information.
Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.

  • Document ID:
  • 10073685
  • Solution ID: NOVL81569
  • Creation Date: 20Aug2002
  • Modified Date: 25Aug2006
    • NovellNetWare

      eDirectory

Did this document solve your problem? Provide Feedback