AG error while trying to perform Join-only
-
Hi Experts,
I have a doubt on Always on Availability groups. While trying to add(i.e. JOIN only) a database to AG. It was throwing below error.
I tried to check the backup history of that database. There were 10 log backups taken to a network share since last FULL backup. Full backup was already restored with no recovery on secondary.
Now, instead of copying those 10 log backups , I took a fresh local differential backup and tried to restore it with no recovery option. restore was successful. However, when I tried to add the database to AG from Primary replica , it again throws the same above error message. I took another differential backup, and tried restoring with no recovery and it back to AG. Still same error message.. yes I do agree there are some incoming connections to the database on Primary (even before adding to AG). Finally, I tried to take a fresh log backup on primary, restored with no recovery on secondary. now performed the JOIN only to AG. This way, I was able to add the database AG.
Now, my question is, Is there any difference in restoring Differential and log backup in this scenario ?
I just went for differential to avoid copying/restoring so many log backups. I have observed this in more than 2 times in our environment and that is the main reason why I want to know more about this. LOG BACKUP restore always worked.
Thank you
Sam
-
Yes, differentials are not logs. You still need the log backups.
Differentials are closer to partial full backups. Logs are transaction lists. They work together, but one does not eliminate the other.
-
The problem is the transaction log backups on the primary. Between the time you performed the diff and restored to the secondary there was at least one tlog backup on the primary.
You can stop the tlog backups, perform the diff, restore on secondary...
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs -
As mentioned, the Log backups are stopped. Looks like some connections are active on primary replica. This is what causing the log gap.
-
I have performed this same operation multiple times - and the only time I have ever had any issues is when a transaction log backup was performed after the full or differential backup.
I just completed a migration to a new cluster and performed this same process with no issues. Restored full backups to both primary and secondary, restored differentials to both primary and secondary - and joined and the secondary started synchronizing.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
Viewing 5 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply