Behaviour of Merge Replication

I want to deepen the function of Merge Replication:
1) what's the main difference between a push subscription and a pull
subscription ?
2) if I have a subscriber node that for many time (4-5 months) is
disconnected from publisher, what will it do when it'll be re-connected
to the network ?
3) is there a method to force the re-synchronization of DB subscriber
in this case ?
4) instead if I have a failure of Publisher server, and I work only
with subscribers, what sould I do after the restart of Publisher to
load the changes made in subscribers DB ?
Hi Marco - answers inline:

> 1) what's the main difference between a push subscription and a pull
> subscription ?
Which box does the work. If I have the choice, I prefer to have the agents
centralised and use one set of alerts and notifications.
> 2) if I have a subscriber node that for many time (4-5 months) is
> disconnected from publisher, what will it do when it'll be re-connected
> to the network ?
It will error and require reinitialization.
> 3) is there a method to force the re-synchronization of DB subscriber
> in this case ?
The term we use is Reinitialization. sp_reinitmergesubscription and
sp_reinitmergepullsubscription can be used. Run the snapshot agent then the
merge agent.
> 4) instead if I have a failure of Publisher server, and I work only
> with subscribers, what sould I do after the restart of Publisher to
> load the changes made in subscribers DB ?
>
Restore an older version of the publisher's database and synchronize. This
is not foolproof (eg schema changes and download only articles will require
some thought) but it generally works.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com .
|||answers inline
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Marco" <peska78@.tin.it> wrote in message
news:1164723024.262636.185820@.h54g2000cwb.googlegr oups.com...
>I want to deepen the function of Merge Replication:
> 1) what's the main difference between a push subscription and a pull
> subscription ?
With a push the publisher initiates the sync, with a pull the subscriber
initiates it. Push is good for a small number of subscribers when you want
to centrally manage them. Pull is good for a large number of subscribers but
you don't have a central point of management.
> 2) if I have a subscriber node that for many time (4-5 months) is
> disconnected from publisher, what will it do when it'll be re-connected
> to the network ?
It will probably have expired so you will need to send a new snapshot down.
you can upload the subscriber changes before the snapshot is applied.
> 3) is there a method to force the re-synchronization of DB subscriber
> in this case ?
Its called a re-initialization. Expand your publication and right click on
your subscription and select reinitialize to reinitilize the problem
subscriber.
> 4) instead if I have a failure of Publisher server, and I work only
> with subscribers, what sould I do after the restart of Publisher to
> load the changes made in subscribers DB ?
>
Nothing. When the subscriber comes back on line it will synchronize changes
which have occurred with the subscribers. If the retention period has passed
most of your subscribers will probably have expired which means you will
have to reinitialize, run the snapshot agent and then run the merge agents.
|||Paul, Hilary
thanks for your answers.
|||Hi Josip
There is no hard rule defining small, or the cut off point going from push
to pull. I normally use pull for over 10 subscribers.
As you have some tables which are only one direction I would use
transactional replication. As you have some which are bi-directional I would
use merge for those.
For the merge publications use central publisher in your head office. For
the uni-directional publications it depends on the data flow, if they are
going to the central publisher make the branch offices the publishers, ie 14
publishers in the branch office going to the central publisher in the head
office. If they are going from the central publisher in the head office to
the subscribers branch office use the central publisher in the head office.
HTH
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Josep" <jmartinez@.autec.es> wrote in message
news:e4BsFn5FHHA.1912@.TK2MSFTNGP03.phx.gbl...
> Hi Hilary,
> I new in replications and I've just realised that I need Merge replication
> (after reading the first chapter of your book). So I started looking for
> information about Merge. But still I've things unclear. For example, I
> don't know if I should use push or pull subscriber. When you say:
>
> what's a small number of subscribers? Because I've 15 machines to be
> replicated, where one is a dedicated server, the Central Server. Some
> tables must be replicated to everywhere (using the Central Server?) and
> some other tables just replicated to the Central Server (so a filter
> should be applied?). It's like a star topology.
> And this goes to another question. What's better, to have the publication
> in the Central Server and push/pull subscription to the other computers or
> generate a publication on each server and make the Central Server a
> subscriber of all?
> I think that the first option is the best, at least for the tables that
> must be replicated to everywhere, but I'm not sure for the tables that
> must be filtered.
>
> Thank you,
> Josep Martnez
>
> "Hilary Cotter" <hilary.cotter@.gmail.com> escribi en el mensaje
> news:eNEH1zvEHHA.4132@.TK2MSFTNGP04.phx.gbl...
>