March 26, 2015 at 5:14 am
Hi Experts,
Our application team does upgrades and when they do the same they rename the primary database in Always On availability group , before that we disables the backup job in secondary
Below Commands are run on primary
ALTER AVAILABILITY GROUP [ABCHA] REMOVE DATABASE [ABC];
USE ABC
CHECKPOINT
GO
ALTER DATABASE ABC SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO
ALTER DATABASE ABC MODIFY NAME = ABC_UPGRADE
GO
ALTER DATABASE ABC_UPGRADE SET MULTI_USER
GO
CREATE DATABASE ABC_UPGRADE_SS ON
(NAME = ABC, FILENAME = 'X:\ABC_Data_SS.ss'),
(NAME = ABC_Data2, FILENAME = 'L:\ABC_Data2_SS.ss')
As SNAPSHOT OF ABC_UPGRADE
GO
Performs the installs and then run the below commands
Use Master
Go
DROP DATABASE ABC_UPGRADE_SS
Go
Use ABC_UPGRADE
Go
CHECKPOINT
GO
ALTER DATABASE ABC_UPGRADE SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO
ALTER DATABASE ABC_UPGRADE MODIFY NAME = ABC
GO
ALTER DATABASE ABC SET MULTI_USER
GO
USE MASTER
ALTER AVAILABILITY GROUP [ABCHA] ADD DATABASE [ABC];
On secondary run the below command.
ALTER DATABASE [ABC] SET HADR AVAILABILITY GROUP = [ABCHA];
Now the problem we are facing is when tried to add it back to AG its throwing below error(when running the above command).
Msg 1478, Level 16, State 101, Line 1
The mirror database, "ABC", has insufficient transaction log data to preserve the log backup chain of the principal database. This may happen if a log backup from the principal database has not been taken or has not been restored on the mirror database.
March 26, 2015 at 6:43 am
Ratheesh.K.Nair (3/26/2015)
Our application team does upgrades and when they do the same they rename the primary database in Always On availability group remove secondary from AG, before that we disables the backup job in secondary
One question, Why??
Shouldn't need to touch the AG
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
March 26, 2015 at 6:48 am
Thanks Perry for the reply.
In order to successfully upgrade the application they need to rename the Primary database as DB_Upgrade for that they need to take the DB out of AG.
March 26, 2015 at 6:50 am
We had issue in this environment as our snapshot was getting corrupted because of the limitation of windows. The file as getting fragmented because of high data change. Will that be a cause for this issue??
March 30, 2015 at 2:17 am
Anyone have any idea why this is happening. This happened again today..Not able to figure out the root cause.
April 17, 2015 at 8:17 am
The backup preference is set to secondary only
March 3, 2020 at 2:42 am
To work around this issue, create a transaction log backup on the primary replica or Primary Database, restore the log backup on the secondary replica with no recovery, and then rejoin the secondary replica to the AlwaysOn availability group. once you take out the Database from AAG the log chain always break no matter what. Because of the broken LSN when you try to add DB again in to AAG it won't match the LSN and it can't sync with Primary replica. So the only solution is what I mentioned in first two lines.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply