It scales to several thousand subscribers, but it is normally implemented as
a hierarchy. IE you have a head office replicating to branch offices and the
subscribers hang off the branch offices as opposed to the head office. You
can have several levels of hierarchies.
The information about the sync is held for the most part in MSmerge_replinfo
table on the subscriber. The history of the sync is held in the distribution
database. Some data is held in the publisher, for instance with the minimize
network data option in horizontal filtering data is stored in the
msmerge_contents and tombstone where the data went.

Signature
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
> I'm wondering how well merge replication scales to a large number of
> subscribers. Where is the state of the merge sync relationship between
[quoted text clipped - 3 lines]
> Thanks,
> Troy
Troy Wolbrink - 30 Nov 2005 03:08 GMT
Thanks for the information. I'm definitely going to have to buy your merge
replication book when it comes out. Will this book stand on its own? Or
will your book on transaction replication be required reading first?
--Troy
> It scales to several thousand subscribers, but it is normally implemented
> as a hierarchy. IE you have a head office replicating to branch offices
[quoted text clipped - 6 lines]
> instance with the minimize network data option in horizontal filtering
> data is stored in the msmerge_contents and tombstone where the data went.
>> I'm wondering how well merge replication scales to a large number of
>> subscribers. Where is the state of the merge sync relationship between
>> the publisher and subscriber stored? Is it in the subscriber database,
>> distributor database, or in the publisher database?