Indirect synch requires a replica hub?
bberkow
to a "public share", and that since if many staff are aaccessing the same
database it has to be on a share, that you therefore require a hub to take
partin the synch, that is not on a share and which then will synch (directly,
I suppose) to the database on the share. AM I making myself clear?
But I've been setting up a test replica to work out the kinks and it appears
that there is an indirect synch between two replicas, each on a share, since
each is the main database at each end of the office vpn (the main office and
the branch office). Also I have, I think, turned off the other possible kind
as of synch via the registry editor - setting their priority to zero. Is
what I am describing impossible and therefore I am mis-reading some of what
is going on?
Access 2002. Windows XP on the desktops. Windows Server 2003 R2 at both
ends. Drop boxes and databases are each in their own shares on their
respective servers. (I had the other question about whether you had to stay
logged on to keep Syncrhonizer running for indirect synchs that run on a
schedule overnight.)
Thank you.
Thank you in advance.
David W. Fenton
in news:8ACD0954-749E-408C...@microsoft.com:
> I thought I came across an explanation that you cannot do an
> indirect synch to a "public share", and that since if many staff
> are aaccessing the same database it has to be on a share, that you
> therefore require a hub to take partin the synch, that is not on a
> share and which then will synch (directly, I suppose) to the
> database on the share. AM I making myself clear?
I'm a little unclear on the circumstances under which an indirect
synch will take place to a replica in a public share. I know that
ReplMan could not do it, and the Access UI could not do it -- if you
requested an indirect synch to a replica that was visible through
the file system or over SMB networking, it would use direct
replication.
I am not certain on this, but it appears that if you use the TSI
Synchronizer or JRO to explicitly initiate an indirect synch, it
will succeed even when the remote replica is in a public share.
Now, I am not certain if I've indentified the exact parameters
involved here. It could be that there's some factor other than what
tools you use to initiate the indirect synch that controls whether
or not it will work.
> But I've been setting up a test replica to work out the kinks and
> it appears that there is an indirect synch between two replicas,
> each on a share,
You can confirm this by looking in the MSysExchangeLog table and
seeing what kind of exchange it was. The ActualTransport column will
have DIRECT for direct synchs and FS for a synch that uses the
synchronizer (I don't know if there's a distinction between indirect
and Internet synch as I've never done the latter).
> since
> each is the main database at each end of the office vpn (the main
> office and the branch office).
I'd advise against this topology. It's best to insulate your
production replica from the risks of replication. For instance, if
the synch accidentally falls over to a direct synch, the production
replica is then at risk of corruption (or at the least, loss of
replicability). Thus, it's better in my opinion, to have a hub
replica with which all the remote computers synchronize, and then
synch the hub with the production replica on a schedule (a direct
synch, which in most cases will be on the same machine, i.e., your
server).
This adds to the complexity and adds a bit of latency, but it also
adds safety both by providing a buffer between your production
replica and the synch process, but also by being a de facto "replica
farm." If either the production replica or the hub replica is lost,
you can create a replacement replica from the one that survives. If
you have only one replica, you're lost if it gets corrupted.
So I just think it's much safer to never synch the remote users with
the production replica.
> Also I have, I think, turned off the other possible kind
> as of synch via the registry editor - setting their priority to
> zero. Is what I am describing impossible and therefore I am
> mis-reading some of what is going on?
I don't know anything about the registry setting you describe.
I would avoid the question entirely by using a topology with a hub
replica that is not in a public share. If you end up setting up a
replica farm, you need to do this anyway.
Also, another thought: if you use your production replica for remote
synchs, it has to be managed, which means it's always open (by the
synchronizer), with the result that you can't run overnight
maintenance (e.g., backup and compact).
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
bberkow
If I can trouble you a little bit more, I am still trying to get this
straight.
With a hub do I need to have a hub at either then of our vpn? These then
would be replicas that synch to the replicas which are actually edited by
staff (production replicas) also at each end? These production replicas
could be on the same server as the hub replicas at either end of the vpn, but
would only replicate to their respective hub replica? And the hub replicas
would synchronize over the vpn?
So then there were would be mutliple replica sets? One between the hubs over
the vpn and others to synch between the "local" hub and production replica at
each end?
I hope to be still using Replication Manager (sorry) and will it allow
mutiple replica sets (one for the vpn synch and another for the
hub-production synch)?
Hope this is clear.
Thank you in advance.
"David W. Fenton" wrote:
> .
>
David W. Fenton
in news:24B90433-643C-4612...@microsoft.com:
> With a hub do I need to have a hub at either then of our vpn?
> These then would be replicas that synch to the replicas which are
> actually edited by staff (production replicas) also at each end?
Yes. The purpose of the replication hub on each server is as a
conduit between the remote replicas to the production replicas. It
has no other purpose than to serve as a buffer to protect the
production replicas from the dangers of remote synchronization.
> These production replicas
> could be on the same server as the hub replicas
Not could be, but SHOULD be, and, perhaps, MUST BE.
> at either end of the vpn, but
> would only replicate to their respective hub replica? And the hub
> replicas would synchronize over the vpn?
The hub replicas would synchronize (direct replication) with the
production replica on a schedule, chosen appropriately to provide
manageable latency.
In indirect replication, you don't synchronize between replicas, but
between synchronizers. A synchronizer manages replicas, and the
synchronizer will choose the first available managed replica (this
is all discussed in Michael Kaplan's article on replica farms). In
the simplest scenario, each synchronizer manages only the hub
replica on the server where the synchronizer is running, so that you
do know that when you are synching from a remote replica, it's
synching with the hub replica (as that's the only managed replica).
> So then there were would be mutliple replica sets?
There's only one replica set -- you can't synch replicas from
different replica sets.
> One between the hubs over
> the vpn and others to synch between the "local" hub and production
> replica at each end?
There is a (scheduled) direct synch between the hub replica and the
production replica.
The indirect synch between synchronizers is done as requested from
the remote replicas.
> I hope to be still using Replication Manager (sorry) and will it
> allow mutiple replica sets (one for the vpn synch and another for
> the hub-production synch)?
You're mis-using replication terminology. There are not different
"replica sets" involved here at all.