February 15, 2019 at 5:09 am
I have implemented TLOG shipping between 2 clusters. one of the Databases is very large. I have a couple of questions.
1. The cluster where the dbs are shipping from has the databases on multiple volumes. I believe the Log ship will utilize the default volumes specified on the replica. I was wondering if this is the case and or can I specify specific volumes to ship to?
2. The log shipping is in place what are the correct steps to failover to the replica?
3. Is there a command I can run to check that the databases are both in sync? ( I dont have access to the Transaction Log Replica Report)
February 15, 2019 at 7:14 am
Andrew.weckermann - Friday, February 15, 2019 5:09 AMI have implemented TLOG shipping between 2 clusters. one of the Databases is very large. I have a couple of questions.1. The cluster where the dbs are shipping from has the databases on multiple volumes. I believe the Log ship will utilize the default volumes specified on the replica. I was wondering if this is the case and or can I specify specific volumes to ship to?
2. The log shipping is in place what are the correct steps to failover to the replica?
3. Is there a command I can run to check that the databases are both in sync? ( I dont have access to the Transaction Log Replica Report)
1. The secondary doesn't care about the volumes on the primary. You are just restoring transactions logs, replaying transactions on the secondary.
2. To fail over to the secondary (it's not a replica in log shipping), you'd stop the jobs, do a log backup on the primary, apply any remaining logs on the secondary, and then switch roles between the primary and secondary. The process and details for the steps are listed in this documentation:
Change Roles Between Primary and Secondary Log Shipping Servers (SQL Server)
3. You can execute the same stored procedure the log shipping status report uses: sp_help_log_shipping_monitor
Sue
February 15, 2019 at 5:18 pm
Keep in mind with log shipping the databases aren't in sync unless there are no changes on the primary after the last log backups is sent to the secondary. When the log backup finishes, there is time involved in copying the log, waiting for the restore job to fire, then restoring the log. If anything on the primary changes, then you're out of sync.
This is why Database Mirroring and Availability Groups were created, to give more real time movement of data.
Viewing 3 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply