Adding a Second Log Shipping Secondary Instance
Hi All,
I already log ship my main databases to another local server and now I need to also log ship to another physical DR location via a slower WAN connection.
My plan was to bring over the full backup of these databases ( which are quite large) and restore with standby in preparation to start log shipping to the DR site.
My question is this: how do I handle the incremental transaction log changes? Normally when doing this for the first secondary instance I restore a full backup and then a current trans log backup before starting log shipping, I imagine doing that for a second instance will create an LSN problem for the existing log shipping instance? Do I do a differential instead?
Thanks for the help.
I already log ship my main databases to another local server and now I need to also log ship to another physical DR location via a slower WAN connection.
My plan was to bring over the full backup of these databases ( which are quite large) and restore with standby in preparation to start log shipping to the DR site.
My question is this: how do I handle the incremental transaction log changes? Normally when doing this for the first secondary instance I restore a full backup and then a current trans log backup before starting log shipping, I imagine doing that for a second instance will create an LSN problem for the existing log shipping instance? Do I do a differential instead?
Thanks for the help.
ASKER
Hmm, never thought of that. Is that something which is commonly done? You can log ship from a database which is in standby as these will be?
I'll test right now the copy only backup on 2008 R2 Standby database.
Please see more details about different ways to "log ship" as highlighted in the picture/notes at the end of the article - I know is slightly different chain with Transactional Replication first but that one is just another Log Shipping method.
http://sqlmag.com/database-high-availability/3-log-shipping-techniques
Other options would be to use Transactional Replication with Pull Subscribers so the slow one will not affect the Publisher and the fast Subscriber which is not the StandBy Log Shipoped database(s).
Also check out the last solution just before last posting in this article and see if that helps.
http://www.sql-server-performance.com/forum/threads/backing-up-a-log-shipping-destination-database.17746/
Please see more details about different ways to "log ship" as highlighted in the picture/notes at the end of the article - I know is slightly different chain with Transactional Replication first but that one is just another Log Shipping method.
http://sqlmag.com/database-high-availability/3-log-shipping-techniques
Other options would be to use Transactional Replication with Pull Subscribers so the slow one will not affect the Publisher and the fast Subscriber which is not the StandBy Log Shipoped database(s).
Also check out the last solution just before last posting in this article and see if that helps.
http://www.sql-server-performance.com/forum/threads/backing-up-a-log-shipping-destination-database.17746/
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Wow, thanks for the validation. Will try this afternoon.
ASKER
A little confused. On the secondary do I do a full backup and then a trans backup to restore on the third server to get the database in place to start log shipping.
ASKER
No provision for backing up. Hmm take offline and move files?
Not sure what the purpose is for the secondary database in your existing Log Shipping but I think by creating a chain rather than log ship from one single source would alleviate the problems may be caused on the primary source database.