Path: utzoo!attcan!uunet!clyde.concordia.ca!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!rpi!zaphod.mps.ohio-state.edu!usc!ucsd!ucsdhub!hp-sdd!apollo!mk
From: mk@apollo.HP.COM (Mike Kong)
Newsgroups: comp.sys.apollo
Subject: Re: Apollo prmgr troubles
Summary: keep your clocks synched
Message-ID: <493156dd.20b6d@apollo.HP.COM>
Date: 14 Mar 90 18:05:00 GMT
References: <9003081502.AA02337@richter.mit.edu>
Sender: root@apollo.HP.COM
Reply-To: mk@apollo.HP.COM (Mike Kong)
Organization: Hewlett-Packard Apollo Division - Chelmsford, MA
Lines: 40

In article <9003081502.AA02337@richter.mit.edu>
krowitz%richter@UMIX.CC.UMICH.EDU (David Krowitz) writes:
>...
>I recently started running multiple global location brokers on my network.
>...
>After starting up two addition copies of /etc/ncs/glbd (for a total of 3
>global location brokers) in order to make certain that the whole net would
>be able to continue operating if my master node went down, I found that the
>various components of the SR10 printing system could not talk to each other
>unless they were running on the same node.
>...
>When I ran /etc/ncs/drm_admin to check the state of the glbd databases, I
>found that not all of the replicas were known to each other, so I used the
>"addrep" command to add the replicas to the list, and then the "merge_all"
>command to merge the replicated databases. 
>...
>One interesting note ... the "merge_all" command only worked when I used
>the "set" command to operating on the original glbd node. When I tried to
>use one of the other nodes as the hub for the merge, drm_admin refused to
>do the merge because the system clocks on the three nodes were out of sync

If the clocks at the existing glb site and the new glb site are in synch
(differing by 10 minutes or less), you should not have to add replicas or
merge databases with drm_admin.  If the clocks are out of synch (differing
by more than 10 minutes), the replica creation should fail cleanly.

However, it's possible to create a set of replicas in which sites A and B
are in synch and sites B and C are in synch, but sites A and C are out of
synch.  In this case, database inconsistencies can arise, and a global merge
can work with one site as the hub but not with another site as the hub.  To
avoid these problems, keep the clocks at all sites within 10 minutes of each
other.

At SR10.x, if you have one of the UNIX environments installed, setting
clocks is fairly painless; use the /bin/date utility.  At SR10.2, the
time server daemon /etc/timed is available, but I haven't tried it.

Mike Kong
Apollo Computer
mk@apollo.hp.com