October 25, 2012 at 9:23 am
We have several large (approaching 1 TB) databases that we are mirroring between two servers (high safety, no witness) and transaction log shipping to a third. The primary server went down unexpectedly so we failed over using SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS. Once the primary came back online we successfully reestablished mirroring.
However, when attempting to apply the first transaction log backup created from when the mirror became primary to the third server we got the following error:
"This backup set cannot be applied because it is on a recovery path that is inconsistent with the database. The recovery path is the sequence of data and log backups that have brought the database to a particular recovery point. Find a compatible backup to restore, or restore the rest of the database to match a recovery point within this backup set, which will restore the database to a different point in time. For more information about recovery paths, see SQL Server Books Online."
Running a full backup/restore to the third database to reestablish the transaction log shipping is very difficult due to the size of the databases.
1) What went wrong, why are we getting that error?
2) Is there any way to get the third database in a state where it will accept new transaction logs without transferring over a copy of a full backup? After failing over with data loss the old primary database had also forked from the mirror, but it was still able to resume mirroring (I assume it first rolls back transactions from when it was exposed to bring it to the point when it sent the last transaction to the mirror server). Why can't the third database do the same thing?
3) If this is an expected issue that can't be recovered from, what can we do to avoid this situation? So that even if the primary database goes down unexpectedly and we have to fail over, we do not have to rebuild the third, TLOG database.
I posted this to the ask SSC section but maybe this forum is more appropriate.
Thanks, Nathan
October 25, 2012 at 5:10 pm
There is a recovery path that has occurred but not been synchronised by log shipping. What does the following return when run against the new mirror principal instance and the log ship secondary instance
Select differential_base_lsn from sys.master_files
Where database_id = db_id('yourdb')
Can you provide more detail about how you configured the mirroring and log shipping?
This link details how to set them both up together
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
October 26, 2012 at 1:48 pm
Are you running log shipping on the same database(s) that you also have mirroring on?
From the sounds of it you had a database setup for log shipping and mirroring, and that database changed so the mirror database then became the primary. Once that happened log shipping stopped and new transactions on the new primary were not being copied over and applied to the log shipping secondary.
If this is the case I wonder if you can gather the transaction log backup files from the instance the database went to when it failed over to the log shipping secondary and run the LSRestore jobs and see if they run. You will have to have all the logs though otherwise the log chain is broken and it will not find any logs to restore.
Joie Andrew
"Since 1982"
Viewing 3 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply