|
|
Our Hot Pick: Rising Antivirus 2006 - Certified by TUV & Checkmark! Get 10% discount by entering this coupon code: ONDISCOUNT10
We are attempting to set up multiple replica sets or groups where each
group replicates among itself, but not with each other. It's not
working.
This is how we have attempted to set it up. A single master database
is placed in its designated group (see Replica Master folder at link
below). That master is Recovered in its designated folder using Access
2K. Next, the replica hubs are created from their designated master
using the replication manager. The client replica sets are then
created from each hub (see Client Store at link below) using Access 2K.
The clients are partial replicas. The hubs are managed by the
replication manager, but the masters are not managed. The hubs
replicate with their clients in the field just fine. They also
replicate with each other, which is not okay.
As soon as the second hub is managed by the replication manager it
replicates with the first. That is not what we want. We only want the
hubs to replicate with their replica sets - not with each other.
Any suggestions on solving this would sure be appreciated.
http://mynet11.tripod.com/replication.htm
|
|
"icclearly[ at ]mindspring.com" <icclearly[ at ]mindspring.com> wrote in
news:1138746486.368377.247870[ at ]g49g2000cwa.googlegroups.com:
[Quoted Text] > We are attempting to set up multiple replica sets or groups where
> each group replicates among itself, but not with each other. It's
> not working.
>
> This is how we have attempted to set it up. A single master
> database is placed in its designated group (see Replica Master
> folder at link below). That master is Recovered in its designated
> folder using Access 2K. Next, the replica hubs are created from
> their designated master using the replication manager. The client
> replica sets are then created from each hub (see Client Store at
> link below) using Access 2K.
> The clients are partial replicas. The hubs are managed by the
> replication manager, but the masters are not managed. The hubs
> replicate with their clients in the field just fine. They also
> replicate with each other, which is not okay.
Replicas that are part of the same replica set and managed by the
same synchronizer will always replicate with each other.
You need to do one of three things:
1. investigate partial replication (I wouldn't recommend this)
2. break your replica set into multiple replica sets (this will
require creating new replica sets).
3. manage the distinct replicas on different synchronizers (i.e.,
different machines).
The last is the easiest from a replication standpoint, but not the
easiest if you need the hub replicas to be on a central server, of
which you may have only one.
The 2nd is the long-term best solution from my point of view, as I
think partial replication is mostly a bad idea (I don't think it
serves any real purpose, except for the empty partial replica, which
is very small and can be used to convey information about a replica
set to a remote machine without large bandwidth requirements).
But many would advocated #1.
To me, #1 is wrong for another reason. It seems to me that if the
replicas should never synch with each other, then they really
oughtn't be members of the same replica set at all, partial or full.
That's another reason why I consider #2 to be better.
But both 1 and 2 are not so easy. I can't explain much about #1 as
it's not something I do. The second choice, though, seems pretty
straightforward to me, though it's a lot of work, as you have to
unreplicate and re-replicate.
> As soon as the second hub is managed by the replication manager it
> replicates with the first. That is not what we want. We only
> want the hubs to replicate with their replica sets - not with each
> other.
They may be independent replica sets from *your* point of view, but
because of the way you've created them, it's all one big replica set
from Jet's point of view. There is no getting around that, except to
start over, seems to me.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
|
[Quoted Text] >2. break your replica set into multiple replica sets (this will
>require creating new replica sets).
David,
Thanks for getting back.
Actually, I thought we were creating new sets for each group. By
placing the master in a unique folder and recovering it and then
creating a hub for the specific group from that design master and then
creating client replicas for that specific group from that hub, I
thought we had a unique set. We repeat that process for each group.
>From your perspective what do we need to do to create a new replica
set?
Thanks.
IC
|
|
"icclearly[ at ]mindspring.com" <icclearly[ at ]mindspring.com> wrote in
news:1138809662.177973.243260[ at ]g14g2000cwa.googlegroups.com:
[Quoted Text] >>2. break your replica set into multiple replica sets (this will
>>require creating new replica sets).
>
> David,
>
> Thanks for getting back.
>
> Actually, I thought we were creating new sets for each group. By
> placing the master in a unique folder and recovering it and then
> creating a hub for the specific group from that design master and
> then creating client replicas for that specific group from that
> hub, I thought we had a unique set. We repeat that process for
> each group.
>
>>From your perspective what do we need to do to create a new
>>replica
> set?
It's not *my* perspective, it's Jet's -- you sart with a
non-replicated MDB file and then replicate it.
Once you've done that, any replicas created from there, whatever the
DM, are still part of the same replica set and always will be.
That's just the way Jet replication works.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
Davide,
Thanks! That solved the problem. It was not as much effort as I
expected. I simply created a blank database and imported the tables
from the design master. I then set up the new database for replication
and created my hubs and clients from that new database. I now have
four different groups on the same server with expectation of adding
more real soon.
Thanks again.
IC
|
|
|