|
One option to fix synthetic time is to just wait. If the synthetic time is not too far into the future, the problem will resolve itself. If the timestamp is more than a few days in the future, then you may need to declare a new epoch.
Question: What is declare a new epoch doing?
Answer: A new epoch causes the Master replica to re-set the modification time stamp of all objects in the partition and then send every object in that partition to all the other servers in the replica ring. All replicas except the Master will be put into a New state. This causes a lot of network traffic and can it take a long time for all the replicas to progress to an On state again. The speed of the links between servers and the number of servers in the replica ring will effect how long this process takes.
Using DSRepair loaded with -a switch - Repair Time Stamps and Declare a New Epoch as described:
CAUTION: DO NOT DO THIS UNTIL you have ensured that the master replica correctly reflects the actual state of the NDS AND that all the servers in the tree are communicating with each other AND there is no other partition operation pending). ALL OF THE ABOVE CONDITIONS MUST BE MET BEFORE YOU DO THIS!
Load DSREPAIR -A | Advanced options menu | Replica and partition operations | select the partition of which this server holds the Master replica | Repair time stamps and declare new epoch. Note that this must be done on the Master of each partition that is reporting synthetic time.
This option causes the Master replica to re-set the modification time stamp of all objects in the partition and then send every object in that partition to all the other servers in the replica ring. This option thus creates a lot of network traffic. You would only want to do this if the time difference is very large (e.g greater than 1 week) and you should do it either after business hours or during off-peak periods because of the high volume of network traffic. You must also ensure that your transport (LAN/WAN) is reliable, especially if you have replicas across WAN links. Make sure that the WAN links are not congested. You can verify the LAN/WAN links by doing a "Report Synchronization" in DSREPAIR. If you do not get any -625 errors, then the links are fine. The next question is then:
How do I ensure that the master replica correctly reflects the actual state of the NDS?
Login to the tree with the following username: {name of server holding Master replica}/{complete name of admin user} Use NDS Manager (WIN95& WINNT); Partition Manager (either in NWADMIN for Windows or in DOS) to make sure that the replica being read is the master replica. Then use NWADMIN or netadmin to browse through the tree. If NDS Manager or Partition Manager shows that the replica being read is NOT the master replica, then you can force the master replica to be read by locking the DS on all the servers with R/W replicas. To lock the DS, load DSREPAIR and do a "Repair local database on those servers". Do the above login while the other servers are performing the DSREPAIR.
After declaring a new epoch on a partition, servers that do not hold a replica of that partition may still report future timestamps for objects in that partition. After you have declared a new epoch and all replicas are back to an On state, if you have a server that is reporting future timestamps for an object in that partition and it does not hold a Master, Read Write or Read Only copy of that partition, you will need to load DSREPAIR -xk3, go to the advanced options menu, and run a repair on the local DS database. Once the repair completes, save the repaired database and exit out of DSREPAIR. As soon as you have exited DSREPAIR, execute the following commands at the console prompt: SET DSTRACE=+BLINK and SET DSTRACE=*B. You can look at the DSTRACE screen to see the backlinks processing. There will be a message like "Finished Checking Backlinks Succeeded" when the backlink process finishes. You should then no longer see future timestamps on that server.
|
