I have an issue where there was a merge replication between 2 instances for around 10 articles that has now been dropped. I want to recreate the merge replication - I am looking for inputs on the steps/ different options to set it up again and synchronize.
The subscriber is remote and not a part of the LAN. Please note that I have the scripts to create the replication.
This is what I am thinking of doing:
backup current publisher and restore it to the subscriber instance in a different name
restore a copy of the subscriber in a different name
run compare using a tool that generates scripts, like those from red gate
apply the script generated on the restored subscriber db.
After this, what do you think is the best way to set the replication back to running?
Any advise appreciated. thankyou
There is two thing to check before you backup and restore.
Make sure that you have all data from publisher and subscriber in one database. It could be publisher. If you hadve ETLs which loading you publisher and subscribers database from diffeent source this point is pretty important.
run http://technet.microsoft.com/en-us/library/ms188734%28v=sql.105%29.aspx on both publisher and subscriber
Script out all your indexes if you need reduce backup file. You can create them l8r once you will be in sync.
backup db on publisher and restore it pn subscriber
Next
create publication
create snapshot
add login to the access list of your publication
add articles for publication
create script drop/create indexes. Create scrip to drop/create indexes on tables classified as “big data” to prevent snapshotting indexes.
Do this for constraints, too. They slow up your action..
Just drop them all. From step 9
Snapshot your stuff.
Now subscriber
add pull subscription. You have two steps. Script on publisher and script on subscriber.
stop agents on subscriber and change GENERATION_LEVELING_THRESHOLD if you need or change subscriber agent profile.
You can now start pull agents.
Remember about replication index maintenance
Hope that help
Related
Currently working on customer releases for our product. First step is to compare the customer database with our current dev db. Apparently we need to shut off cdc to do this, which drops all of the system cdc tables. Is there any way to backup and restore these tables for after we've finished comparing the two db's?
Apparently we need to shut off cdc to do this.
Completely agree with #DavidBrown that it isn't necessary to disable CDC for comparing the databases.
CDC enabled database simply means that your database captures the data change automatically. It manages that changed data in a separate table therefore you can still compare your database with different database without disabling CDC.
In case if required, you can restore the CDC enabled database by referring this third-party tutorial.
Restoring a SQL Server database that uses Change Data Capture
After configuring replication all the data from tables has replicated from publisher to subscriber. Now my requirement is whenever I insert new record in publisher only that record should replicate rather than reinitialize all the records to subscriber because my table is having millions of records.
Rather than drop and reinitialize snapshot cont we store earlier sync data of table in subscriber and only sync the new record.
Is there any way to do this?
If you're using transactional replication (as you say above in your comments), something is configured incorrectly. Transactional replication is supposed to work as you describe (i.e. a one row change gets pushed over and applied as a one row change). I'd guess that you have the immediate_sync property turned on at the publisher and are running the snapshot agent on a schedule. At the very least, turn off the schedule for the snapshot agent and I think you'll see your problem go away.
I have a windows server 2012 with SQL Server 2012 configured with Merge replication with three subscribers.
I want to take a full back up the merge replication in case of total sql server crush. I am not sure how to take it or which databases to take a back up? for how long? so that if some thing happens then I will just restore all the configuration back.
any idea?
thanks
You should take backups of these databases
The publication database at the Publisher
The distribution database at the Distributor
The subscription database at each Subscriber
The master and msdb system databases at the Publisher, Distributor and all Subscribers. These databases should be backed up
at the same time as each other and the relevant replication database.
For example, back up the master and msdb databases at the Publisher
at the same time you back up the publication database. If the
publication database is restored, ensure that the master and msdb
database are consistent with the publication database in terms of
replication configuration and settings.
For more information, refer msdn
To add to what ughai posted, all replication components should be scripted out as a part of a disaster recovery plan. They should also be rescripted if any publication and/or subscription property changes are made.
This is covered in the section Script the replication topology in Best Practicies for Replication Administration and in Scripting Replication.
It does seem like a need of a proper disaster recovery plan, from what you describe. You can create your own or maybe use a third party vendor in order to do that. We worked with cloudendure back at the time, I'm not sure as for their costs right now, maybe it's worth a look. What happens is that you've got a replica being formed and updated in 1 sec time intervals, replication of the data goes right onto the target location (the cloud), and we're aiming for near zero downtime so for whenever that happens, your replica will be loaded automatically onto your site.
I have a local SQL Server database that I copy large amounts of data from and into a remote SQL Server database. Local version is 2008 and remote version is 2012.
The remote DB has transactional replication set-up to one local DB and another remote DB. This all works perfectly.
I have created an SSIS package that empties the destination tables (the remote DB) and then uses a Data Flow object to add the data from the source. For flexibility, I have each table in it's own Sequence Container (this allows me to run one or many tables at a time). The data flow settings are set to Keep Identity.
Currently, prior to running the SSIS package, I drop the replication settings and then run the package. Once the package completes, I then re-create the replication settings and reinitialise the subscribers.
I do it this way (deleting the replication and then re-creating) for fear of overloading the server with replication commands. Although most tables are between 10s and 1000s of rows, a couple of them are in excess of 35 million.
Is there a recommended way of emptying and re-loading the data of a large replicated database?
I don't want to replicate my local DB to the remote DB as that would not always be appropriate and doing a back and restore of the local DB would also not work due to the nature of the more complex permissions, etc. on the remote DB.
It's not the end of the world to drop and re-create the replication settings each time as I have it all scripted. I'm just sure that there must be a recommended way of managing this...
Not doing it. Empty / Reload is bad. Try to update the table via merge - this way you can avoid the drop and recreate, which also will result in 2 replicated operations. Load the new data into temp tables on the other server (not replicated), then merge them into the replicated tables. If a lot of data is unchanged, this will seriously reduce the replication load.
SQL Server 2008R2 Transactional Replication - Move SubscriberDB - Push Subscription
I have a requirement to move a subscriber database to a new server outside of a system outage i.e. I cannot stop new transaction from loading into the publisher database.
So far I have attempted to stop the distribution agent and let all un-replicated commands replicate to the subscriber database at Server1. Then backup and restore the subscriber database to Server2. I have then created a new subscription from Server2 to the existing publication.
This works but only transactions created from that point forward are replicated to the Server2 subscriber database. I also require all the old transactions built up at the distributor database destined to only go to Server1.
Is there a replication command available to update the destination of existing transactions at the distributer to the new subscriber.subscriber_DB?
There is 1 publication with multiple articles. The publication is currently only subscribed to by one database at Server1.
You're working too hard. Create a subscription on the new server as though you didn't have an existing subscription at all. There are many ways to do this; pick your favorite. I see in your response to another answer that snapshots are a no-go. I have had a lot of success using the "initialize from backup" option (here, "backup" refers to a backup of the publisher). Once the subscriber is in sync after initialization, you're done. You're now clear to "migrate" to the new server.
Due to the distribution agent being specific to each subscribing server, you can't really have a new subscriber take over where an existing subscriber left off. The only way this would work is if you backup/restore to Server2, temporarily stopped transactions on the publisher, backup/restore log to Server2, create subscriptions with "replication support only", and then re-enable transactions.
Can you not just add subscriptions to the same publication for the new subscriber and kick off the snapshot agent? That will independently sync Server2 while Server1 continues to stay in sync. You should then be able to switch to Server2 seamlessly and remove the subscriptions to Server1.
One note of warning though. I would check the sync_method in syspublications table (or run sp_helppublications) of your publication database to make sure snapshots won't lock the tables in your publisher (by default with SQL Server 2005+, this shouldn't be an issue). Otherwise, what I just suggested will cause blocking on the publisher until the snapshot finishes.
Also, this is a good reference to understanding how to do snapshots one at a time if you setup replication through the GUI using default settings. This will be useful for distributing the snapshots over a larger period of time to reduce publisher server load if you have a lot of data to replicate (gigabytes rather than megabytes).
http://www.replicationanswers.com/TransactionalOptimisation.asp