December 13, 2016 at 11:21 am
We have a clustered environment where we employ Availability Groups within SQL 2014. We then have a completely different server we want to log ship certain databases in a DR scenario.
The Availability Groups work as they should. The issue is coming into play when we attempt to log ship the databases over. Configuring LS as normal, from a fresh full backup, setting up the times for the LSBackup, LSCopy, and LSRestore jobs (we have Log shipping set up a lot of other places and rarely have issues), nothing new here.
LS configured successfully, 1st run after is successful, and then we get nothing but failures afterwards. The error is the following:
"The log in this backup set begins at LSN 2864000003254400001, which is too recent to apply to the database. An earlier log backup that includes LSN 2864000003253800001 can be restored."
We have attempted to troubleshoot this every way we have thought of. Every time this error pops up, restoring from a fresh backup fixes this.
We have looked into the first and last LSN's by reading the HeaderOnly on the transaction log backups and there is always one file that does not follow suit. But then after that one tran log file, all of the rest of the LSN's follow suit.
Is Availability Groups somehow messing up the LSN? Its almost as if there is another job somewhere that is running a tran log backup and placing the files somewhere is. We have explored this, there is nothing. We have compared backup times between the msdb.dbo.backupsets and the msdb.dbo.log_shipping_primary_databases to see if something is sneaking in and running a backup at a weird time and there is nothing.
Has anyone seen an issue like this before? Is AG causing issues?
Any and all help will be greatly appreciated.
Thank You
December 14, 2016 at 6:00 am
This was removed by the editor as SPAM
December 14, 2016 at 7:46 am
You're obviously missing some log backups.
What is the current config for your Ag backups?
Secondary?
Primary?
Any Replica?
Are the backup files being stored centrally?
When the primary changes the backup location, if local, will be moot. Any previous log backups will now be missed by the LS plan
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
December 14, 2016 at 8:12 am
@jason, thanks for the reply, but that is information that I am already aware of and tried to state that in my original post.
@perry, I agree with the missing tlog backup. AG is set to backup the Primary. The backups are being stored on the network and then being copied locally to the secondary server to be restored. What's weird is that this has been working for almost a year in this environment and we have the exact same set up for another customer in a completely separate environment and we have no issues there.
There is no other job on the primary server (where AG is) that would be performing a tlog backup. Perry, are you insinuating that AG is as well performing a tlog backup on the primary?
Thanks again to both of you for the reply!!!
December 14, 2016 at 8:56 am
GBeezy (12/14/2016)
AG is set to backup the Primary.
Ok, so this will change with a failover as the Primary obviously changes.
GBeezy (12/14/2016)
The backups are being stored on the network
Ok this negates the above then
GBeezy (12/14/2016)
and then being copied locally to the secondary server to be restored.
What do you mean copied locally?
The log shipping copy job on the secondary should just hook into the network backup location and then copy the files locally, or this what you mean it is doing?
GBeezy (12/14/2016)
What's weird is that this has been working for almost a year in this environment
Whats changed then
GBeezy (12/14/2016)
There is no other job on the primary server (where AG is) that would be performing a tlog backup. Perry, are you insinuating that AG is as well performing a tlog backup on the primary?Thanks again to both of you for the reply!!!
The only the primary would take a log backup is if there is a job running to do this.
Have you queried the backup tables in the primary to what backup files are there and who took them
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
December 14, 2016 at 11:07 am
The LSBackup job places the file on a network share and the LSCopy job copies that tlog backup from the network share locally to the secondary server where the LSRestore job restores said file.
It does appear something has changed, but this change appears to be within SQL. I dont think a Group Policy change or a server level change would affect the LSN associated with backup files. We have looked at this as well and have come up with nothing.
We have queried the backupsets table as well as the log shipping tables and everything checks out there.
Thank you for the reply and if anything comes to mind that we are missing to do, please throw out that suggestion.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply