An account of setting up a replicated system

From: Neil Sargent (neil_at_sargent.nospam.demon.co.uk)
Date: 02/20/04 

Date: Fri, 20 Feb 2004 23:56:56 -0000

There follows an account of my deployment of my replication system. I have
dispersed a number of questions and all comments would be appreciated.

I know that this post is long. However if the experts who monitor the group
(in particular Michka and Jack MacDonald) will correct or endorse it, it
might become a useful resource for future developers who, like me, find this
whole subject rather daunting.

>>>>>>>>>>>

The head office has about six users. I created a DM and EF (Empty Full
replica) from the original database backend. I then created a HUB replica
from the DM.

I then created two replicas from the HUB, named SPARE and BACKUP. I used the
TSISync MakeReplica function here, which appears to assign a fixed priority
of 90 by default if the priority parameter is not specified (rather than DAO
3.60 which assigns 90% of the source replica).

I then managed the HUB, SPARE and BACKUP replicas using Replication Manager
(RM) and locally synched all three. Inspecting the synchronizer log file, I
determined that RM had allocated SPARE as the base replica, which was not my
intention. I wanted to know when I indirect sync to the farm, which replica
is going to be synched so I can synch the local working replica to it
without wating for the servers RM schedule to bring the rest of the farm up
to date.

So using RM's MoveReplica function, I renamed the SPARE to TEMP, HUB to
SPARE and TEMP to HUB so that HUB is my base replica.

(I know that the base replica for a managed set of full replicas will be
that with the lowest replica ID. However, it appears that GUIDs are not
ascending, even when generated on the same machine, in sequence. This does
not particularly surprise me. Is there a way of predicting which replica
will be the base without the above "suck it and see" approach?)

I then MoveReplica'd the BACKUP replica to a second, always-on machine on
the LAN. I now had my head office farm of three
replicas, with HUB known to be the base replica and set an every 30mins RM
schedule from 3:00am to 9:30pm.

I created a new replica from the HUB and called this WORKING. I did not
manage the WORKING replica. Instead, I set RM to synch it with the farm
every 30 mins from 3:15am to 9:45pm. This replica is the shared backend for
the six head office users.

The server backup runs at 10pm so by ensuring no updates occur within the
farm I have a complete set of replicas saved for off-site backup to cover
total loss of the server and BACKUP machines (e.g. office fire, flood,
theft). In the case of server disk failure, I have BACKUP on a second
machine which is at most 30 mins out of date.

I then created a new, full replica for one of the office users' laptop
called PC. This laptop docks with the LAN when it is in the office and
connects through RAS dial-up when in the field. I created a public root
share dropbox on the server and another on the laptop. I created a group for
the server call HUBUSERS and put each of the local database users in the
group except for the laptop user. I set the permissions for the hub folder
so only the HUBUSERS group could access it (with Change permissions). This
means that the folder could not be opened by the laptop user so it must
always use indirect synchs over LAN or dial-up.

I created the laptop's full replica from the HUB and then MoveReplica'd it
into the laptop's dropbox. I then used RM on the laptop to MoveReplica it
into a private folder (C:\PCHub) on the laptop so that the servers RM could
not see it. I repeated the procedure to create a second replica on the
laptop (PCSPARE) and then set up RM to manage the two replicas on an hourly
schedule. I then set up the application to use the PC replica as the working
replica on the laptop.

The laptop now has two replicas managed by RM, one of which is used as the
backend for the application. The application uses the SyncIndirect2 method
of TSISync to synchronise, the laptop to the HUB replica. Replication
Manager is just used in the background as a sort of hourly backup.

(Does this meet the requirements of a farm? I am assuming that if a couple
of indirect synchs fail and the PC replica goes into the "Unknown
synchronizer" state, that the PCSPARE replica will refresh it and recover
the situation. Is this correct?)

I then repeated the whole laptop setup for a second satellite office's PC.
We physically transported the satellite office's PC to head office so that
it could be set up with a LAN connection, rather than moving a 30Mbyte
replica across the 33kbaud dial-up link (the baud rate is limited by the low
quality of the land-line rather than the modem!) Since I had a LAN
connection, I moved both replicas across the link. Had I been limited to
dial-up, I would have moved one across the connection and created the spare
replica from it.

Finally I created a number of single partial replicas for use by field
workers who will connect by dial-up only. Eventually I decided that the
partials weren't worth farming. They are only about 5Mbytes for which an
initial move may over the dial-up is practical. I have any lost replica
problems I will be able to fix them with my EF replica (or in fact a working
EF replica derived from it).

I'm not out of the woods yet. I have discovered that my application is
generating conflicts (formerly data errors) because one of its functions
modifies a record's primary key. Sorting that one is my immediate task in
hand. It seemed like a good idea, pre-replication because it saved me
deleting/inserting a record. What else have I in store in the next couple of
weeks????

Best Regards

Neil
--------------------------------------------------------
  Neil Sargent
  Smart IT
  Email: neil@sargent.nospam.demon.co.uk
--------------------------------------------------------

Relevant Pages

  • Re: Replication to laptops - how do you do this?
    ... We have a main office which has the server. ... out in the field gathering information into the replica. ... So I don't know which is the best synchronization method to use. ... each laptop needs to have a replica of the data file. ...
    (microsoft.public.access.replication)
  • Re: Replication to laptops - how do you do this?
    ... We have a main office which has the server. ... out in the field gathering information into the replica. ... need those 4 to connect and synch up to the version onthe branch office PC ... each laptop needs to have a replica of the data file. ...
    (microsoft.public.access.replication)
  • Re: Replication to laptops - how do you do this?
    ... synched back up to the server in the main office where we print the reports ... reading for days and was convienced I need to use indirect synch. ... just create one replica and then use the "move replica" tool? ... each laptop needs to have a replica of the data file. ...
    (microsoft.public.access.replication)
  • Re: Newbie Questions
    ... The reason for running the dm as the lan copy was then I could tell ... It is no good telling them to sync it every 6 months as ... dont anticipate any replica design conflict issues but then again one ... One reason for having the laptop Dropboxes on the lan would be ...
    (microsoft.public.access.replication)
  • Re: UNKNOWN REASON (-1017)
    ... replica before it lost replicability, however, to get anything you ... > laptop so I was spared manual data merging. ... > source of the corruption, my client could only tell me that he was ...
    (microsoft.public.access.replication)
Loading