If I have one table in one publication in transactional replication
replication between primary and replicate is broken because subscription is marked as inactive.
If there are 3 rows on replicate and 5 rows on primary , out of which 2 are added after replication is broken
If I do
Reinitialize subscriptions
start the snapshot agent
start the distribution agent
Does this mean that it will only transfer the new 2 rows to replicate sites ? or will it drop everything from replicate site and apply all rows from primary site on to replicate.
Any help is appreciatedIt will drop every article the subscriber subscribes and refresh the DDL and data from the publication.
Showing posts with label replicate. Show all posts
Showing posts with label replicate. Show all posts
Tuesday, March 20, 2012
Reinitialize replication - Merge
I have a few databases that I replicate between NY and Greece. We utilize merge replication on all SQL 2000 servers. My question, is there a quick way to reinitialize replication besides pushing the initial snapshot? I would like to avoid the initial snapshot in the event of a failure due to the amount of time it takes to transfer over our 3mb ATM circuit.
Any help is greatly appreciated.
Thanks,
MichaelYou are kind of between a rock and a hard place (as you've probably noticed). The problem is that if you don't know what is "out of whack" in the replica, the only way to get it back in sync is to push a new snapshot. If you know what the problem is, replication prevents you from fixing it!
In the case where you don't know what is broken, the snapshot is your only safe answer. It may be ugly, but it saves everything that can be salvaged.
In the case where you know what needs to be fixed, you can drop the subscription, fix the problems, then resubscribe without pushing a new snapshot.
See the notes on this subject in MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/replsql/replimpl_7xbn.asp).
-PatP|||Usally you call ReinitializeSubscription when you want to recreate all the
tables on the subscriber and start from a "clean" state. Note that calling ReinitializeSubscription would not clean your subscribtion. This will happen on on the next sync.
Refer to books online for further information on merge replication topic.
Any help is greatly appreciated.
Thanks,
MichaelYou are kind of between a rock and a hard place (as you've probably noticed). The problem is that if you don't know what is "out of whack" in the replica, the only way to get it back in sync is to push a new snapshot. If you know what the problem is, replication prevents you from fixing it!
In the case where you don't know what is broken, the snapshot is your only safe answer. It may be ugly, but it saves everything that can be salvaged.
In the case where you know what needs to be fixed, you can drop the subscription, fix the problems, then resubscribe without pushing a new snapshot.
See the notes on this subject in MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/replsql/replimpl_7xbn.asp).
-PatP|||Usally you call ReinitializeSubscription when you want to recreate all the
tables on the subscriber and start from a "clean" state. Note that calling ReinitializeSubscription would not clean your subscribtion. This will happen on on the next sync.
Refer to books online for further information on merge replication topic.
Subscribe to:
Posts (Atom)