Hi,
Had merge replication set up between two servers. with push subscription.
For various reasons the replication stopped running for a few days and now
we have different data at both sites.
Does anybody have a series of steps to get this back up and running other
than the following.
1. Create new db at subscriber.
2. Publish to this new sunscriber from existing publication.
3. Piece in missing data from offline subscriber.(data inserted at
subscriber since merge stopped).
Any other suggestions?
You should be able to synchronize to get things back up, provided you
haven't exceeded the retention period - the publication retention value is
used to determine when subscriptions that have not synchronized within the
retention period should expire and it is set to 14 days by default. If this
is not an option, then I'd use Redgate'd DataCompare to generate the change
script to be applied at the publisher then reinitialize the subscriber.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com/default.asp
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||run a validation to determine how out of sync you are. Run the merge agent
until it completes. Chances are you will be in sync after it runs.
The problem with trying to enter the data manually or through applets like
DataCompare is that when you enter this data on the subscriber to try to
sync it
it will raise all sorts of conflicts when you run the merge agent, and
they will be kicked back and you will be returned the state you where in
before.
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
|||Fair point, but I was recommending using the RedGate change script at the
publisher and subsequently reinitializing the subscriber. It's not very
sophisticated and the data size might make it unattractive, but it should
work.
Rgds,
Paul
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:opso0n92xurj9kur@.hcottter-lap.ap.org...
> run a validation to determine how out of sync you are. Run the merge agent
> until it completes. Chances are you will be in sync after it runs.
> The problem with trying to enter the data manually or through applets like
> DataCompare is that when you enter this data on the subscriber to try to
> sync it
> it will raise all sorts of conflicts when you run the merge agent, and
> they will be kicked back and you will be returned the state you where in
> before.
> --
> 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
|||Thanks for all the suggestions guys. The replicationanswers website is very
informative. Just a quick question Hilary you mentioned run a validation,
what exactly did you mean by that? write my own routine.
Just for info we did get the snapshot reapplied to the subscription but the
data changes at the subscriber did not get applied, despite being well
within the retention period so we had to maunally rebuild the data.
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:eh4LsOdPFHA.2748@.TK2MSFTNGP09.phx.gbl...
> Fair point, but I was recommending using the RedGate change script at the
> publisher and subsequently reinitializing the subscriber. It's not very
> sophisticated and the data size might make it unattractive, but it should
> work.
> Rgds,
> Paul
>
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:opso0n92xurj9kur@.hcottter-lap.ap.org...
>
|||if your subscription is a global subscription you should be able to
synchronize!
MB wrote:
> Thanks for all the suggestions guys. The replicationanswers website
is very
> informative. Just a quick question Hilary you mentioned run a
validation,
> what exactly did you mean by that? write my own routine.
> Just for info we did get the snapshot reapplied to the subscription
but the
> data changes at the subscriber did not get applied, despite being
well[vbcol=seagreen]
> within the retention period so we had to maunally rebuild the data.
>
> "Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
> news:eh4LsOdPFHA.2748@.TK2MSFTNGP09.phx.gbl...
at the[vbcol=seagreen]
very[vbcol=seagreen]
should[vbcol=seagreen]
merge[vbcol=seagreen]
runs.[vbcol=seagreen]
applets[vbcol=seagreen]
subscriber to[vbcol=seagreen]
and[vbcol=seagreen]
where in[vbcol=seagreen]
Showing posts with label recovery. Show all posts
Showing posts with label recovery. Show all posts
Friday, March 23, 2012
Merge Replication Recovery
Saturday, February 25, 2012
merge replication and simple recovery model
Hi All,
Is it possible or okay for setting the publishing DB in a merge
replication setup to Simple recovery model instead of the current
Bulk-logged model?
Will this have an impact to the subscribers?
Thanks.
Aramid
Merge doesn't use the transaction log in the same way as transactional, but
even in this case it is a common misconception that FULL recovery mode is
necessary, so to answer your question 'Yes' - it has no effect as far as the
correct workings of replication are concerned.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
Is it possible or okay for setting the publishing DB in a merge
replication setup to Simple recovery model instead of the current
Bulk-logged model?
Will this have an impact to the subscribers?
Thanks.
Aramid
Merge doesn't use the transaction log in the same way as transactional, but
even in this case it is a common misconception that FULL recovery mode is
necessary, so to answer your question 'Yes' - it has no effect as far as the
correct workings of replication are concerned.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
Labels:
currentbulk-logged,
database,
instead,
merge,
mergereplication,
microsoft,
model,
mysql,
oracle,
publishing,
recovery,
replication,
server,
setting,
setup,
sql
Monday, February 20, 2012
merge replication and disaster recovery (SQL 2005)
Once a merge relationship is established, what happens when either the
publisher restores a previous backup, or the subscriber restores a previous
backup? How is this handled? Will the latest data will be restored from
the database that didn't crash?
--Troy
If a publisher is restored to an earlier state, data which is in the
subscriber is detected as new (even if it came from the publisher originally
before the crash) and fills in the publisher. If the subscriber is restored
to a previous state, data flows from the publisher back to the subscriber to
sync it up.
This process will continue as long as you are within your retention
settings.
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
"Troy Wolbrink" <wolbrink@.ccci.org> wrote in message
news:%23UjcBWJ9FHA.1020@.TK2MSFTNGP15.phx.gbl...
> Once a merge relationship is established, what happens when either the
> publisher restores a previous backup, or the subscriber restores a
> previous backup? How is this handled? Will the latest data will be
> restored from the database that didn't crash?
> --Troy
>
|||As long as your within your retention settings, would new deletes be
included? Or would the restored record be seen as a new record and then
reinserted?
--Troy
> If a publisher is restored to an earlier state, data which is in the
> subscriber is detected as new (even if it came from the publisher
> originally before the crash) and fills in the publisher. If the subscriber
> is restored to a previous state, data flows from the publisher back to the
> subscriber to sync it up.
> This process will continue as long as you are within your retention
> settings.
[vbcol=seagreen]
publisher restores a previous backup, or the subscriber restores a previous
backup? How is this handled? Will the latest data will be restored from
the database that didn't crash?
--Troy
If a publisher is restored to an earlier state, data which is in the
subscriber is detected as new (even if it came from the publisher originally
before the crash) and fills in the publisher. If the subscriber is restored
to a previous state, data flows from the publisher back to the subscriber to
sync it up.
This process will continue as long as you are within your retention
settings.
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
"Troy Wolbrink" <wolbrink@.ccci.org> wrote in message
news:%23UjcBWJ9FHA.1020@.TK2MSFTNGP15.phx.gbl...
> Once a merge relationship is established, what happens when either the
> publisher restores a previous backup, or the subscriber restores a
> previous backup? How is this handled? Will the latest data will be
> restored from the database that didn't crash?
> --Troy
>
|||As long as your within your retention settings, would new deletes be
included? Or would the restored record be seen as a new record and then
reinserted?
--Troy
> If a publisher is restored to an earlier state, data which is in the
> subscriber is detected as new (even if it came from the publisher
> originally before the crash) and fills in the publisher. If the subscriber
> is restored to a previous state, data flows from the publisher back to the
> subscriber to sync it up.
> This process will continue as long as you are within your retention
> settings.
[vbcol=seagreen]
Labels:
backup,
database,
disaster,
established,
merge,
microsoft,
mysql,
oracle,
previous,
recovery,
relationship,
replication,
restores,
server,
sql,
subscriber,
thepublisher
Subscribe to:
Posts (Atom)