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
Related
I want a solution that match the below scenario:
We have 2 databases with 1 being the main DB and the other being the secondary DB. I want a process (executable, powershell, anything...) that can update the changes that I make in Stored Procedures in the main DB. the main DB is the database that we will make the changes then I want a process that update (simple delete and create) the older SP in the secondary DB.
How I can make this possible in the most simply way? If you will say software to work with please take in account that I only want freeware.
It seemed like you are defining something called Mirroring if I didn't assume wrong.
Database mirroring maintains two copies of a single database that must reside on different server instances of SQL Server Database Engine. Typically, these server instances reside on computers in different locations. Starting database mirroring on a database, initiates a relationship, known as a database mirroring session, between these server instances.
One server instance serves the database to clients (the principal server). The other instance acts as a hot or warm standby server (the mirror server), depending on the configuration and state of the mirroring session. When a database mirroring session is synchronized, database mirroring provides a hot standby server that supports rapid failover without a loss of data from committed transactions. When the session is not synchronized, the mirror server is typically available as a warm standby server (with possible data loss).
https://learn.microsoft.com/en-us/sql/database-engine/database-mirroring/database-mirroring-sql-server?view=sql-server-2017
Hope it helps
I have a SQL server 2012 database on a server, which is a development database.
I want to create an another database on other machine which will be exact replica of the original one and as soon as any changes occur in schema and data it should get migrated to this second database.
I tried the log shipping method but in that case secondary database goes in Restoring mode whereas I want both the database active and functioning at the same time.
Performance or locks doesn't matter.
Any other easy way to do this? a utility that runs periodically automatically would also be great.
With log shipping the databases may be in readonly state most of the time, unless the periods when you run scheduled restore job.
Other options to consider - transactional replication, mirroring with readonly via snapshot or AlwaysOn Avalaibility groups with readable replicas, backup/restore (initial full backup/restore, then differential + trans logs) - but the last option is not for large databases.
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 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
What is transaction replication used? I seemed to create transaction replication following this tutorial:
http://www.sql-server-performance.com/2010/transactional-replication-2008-r2/
And I know when I change some objects i.e any DML or DDL statement, those changes will be reflected to the other server where I did replication. But it's not clear to me why should we use transaction replication. Does SQL server automatically start using the 2nd server where replication was done when the main instance fails? or do we have to manually restore the database from the server where replication was done in case of failure of 1st instance?
Thanks in advance :)
You can use transactional replication to maintain a warm standby SQL server. Transactional replication replicates the data on one server (the publisher) to another server (the subscriber) with less latency than log shipping.
You can implement transactional replication at the database object level such as the table level. Therefore, Microsoft recommends that you use transactional replication when you have less data to protect, and you must have a fast data recovery plan.
This solution is vulnerable to the failure of the publisher and the subscriber at the same time. In such a scenario, you cannot protect your data. In all other scenarios such as the failure of a distributor or a subscriber, it is best to resynchronize the data in the subscriber with the data in the publisher.
You should use transactional replication to maintain a warm standby SQL server only when you do not implement schema changes or you do not implement other changes to your database such as security changes that replication does not support.
Note Replication is not designed for the maintenance of warm standby servers. With replication, you can use replicated data at the subscriber to generate reports. You can also use replication for other general uses without having to perform processing on your relatively busy publisher.
Disadvantages
Schema changes or security changes that are performed at the
publisher after establishing replication will not be available at
the subscriber. The distributor in transactional replication uses an
Open Database Connectivity (ODBC) connection or an OLE Database
(OLEDB) connection to distribute data. However, log shipping uses
the RESTORE TRANSACTION low-level Transact-SQL statement to
distribute the transaction logs. A RESTORE TRANSACTION statement is
much faster than an ODBC connection or an OLEDB connection.
Typically, switching servers erases replication configurations.
Therefore, you have to configure replication two times:
a. When you switch to the subscriber.
b. When you switch back to the publisher.
If a disaster occurs, you must manually switch servers by
redirecting all the applications to the subscriber.
Read more here http://sqlserverdatarecovery.com/transactional_replication.html