I am wondering specifically when the changes on the Publisher are cleaned
up. I have implemented merge replication with each publication having a
retention time (set in sp_addmergepublication) of 18 months and a
@.max_disretention (set in sp_adddistributiondb) also at 18 months. Also I
have a system where there is 1 Subscription PER Publication. The
Subscribers can be disconnected for long periods of time (I'm hoping for
less than 18 months). Now the changes on the Publisher will be stored on
the Distributor and will wait until a PULL Subscriber connects to Merge the
changes (changes made on both sides). From what I understand the merge
agent controls the meta data and will clean up the stored changes on the
distributor depending on the Retention period of the publication. So at
each merge agent run, anything older than 18 months that whether or not it
has been merged will be cleaned up (the max_disretention gets rid of changes
that have not been applied to subscribers too). Is this basically how the
cleanup of changes works?
When a connection is made I have a script that can be run to reinitialize a
subscription. It basically runs the merge agent, starts the snapshot agent,
sets the subscription to be reinitialized, and then runs the merge agent
again to apply the snapshot. Will Reinitializing a subscription clean up
the changes for a publication, kind of override the retention period?
Any ideas as to when the Change log (change info stored for a merge) is
cleaned up?
thanks,
Nate
Oops, the Distribution DB doesn't do anything during merge replication so
min_distretention and max_distretention don't apply. Just the Retention
period of the Publications. Can anyone confirm that the MetaData is only
cleaned up by the merge agent using the Retention period? And, that the
data is not cleaned up when a subscription is reinitialized?
thanks,
nate
Wednesday, March 7, 2012
Meta Data Cleanup For Merge Repl.
Labels:
cleanedup,
cleanup,
database,
implemented,
merge,
meta,
microsoft,
mysql,
oracle,
publication,
publisher,
repl,
replication,
server,
specifically,
sql
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment