Quantcast
Channel: SQL Server High Availability and Disaster Recovery forum
Viewing all articles
Browse latest Browse all 4532

Have to remove DB and join DB back to AG to fix out of sync issue

$
0
0

Hello Masters,

I found several times, I cannot fix the AlwaysON issue then I have to delete database and join it back to fix.

This is usually how I fix alwayson issue:

1. Firstly, try resume the database.

ALTER DATABASE [DBName] SET HADR RESUME;

2. If item 1 doesn't work, set the ag from sync mode to async mode, then change it back

USE [master]
GO
ALTER AVAILABILITY GROUP [AGName]
MODIFY REPLICA ON N'A\INSTANCE3' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
GO

USE [master]
GO
ALTER AVAILABILITY GROUP [AGName]
MODIFY REPLICA ON N'A\INSTANCE3' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
GO

3. If item 2 doesn't work, on the secondary replica, remove db from ag then add it back

ALTER DATABASE [DBName] SET HADR OFF;
GO

alter database [DBName] set HADR AVAILABILITY GROUP = [AGName]
go

4. If 3 doesn't work,

on primary, make full backup and log backup if you don't have recent backups,

on secondary,

ALTER DATABASE [DBName] SET HADR OFF;

Restore database to latest log backup.

on primary,

ALTER AVAILABILITY GROUP [AGName]
REMOVE DATABASE [DBName];

Join the database in wizard.

Usually, item 1-3 are enough to fix not syncing issue, but sometimes, there is no luck, no matter how you play the not syncing database, there is just no luck, for example:

0. Two nodes are both on latest version.

Microsoft SQL Server 2014 - 12.0.4416.0 (X64) 
Jun 11 2015 19:18:41 
Copyright (c) Microsoft Corporation
Enterprise Edition (64-bit) on Windows NT 6.3 <X64> (Build 9600: )

Two databases in AG, and both sync mode for two nodes, set to automatic failover mode.

1. I was advised there is a maintenance work on server, the AG is automatically failedover, now found one database is not syncing on secondary.

2. Tried step 1-3 all didn't work, at step 3, keep failing by "The connection to the primary replica is not active.  The command cannot be processed."

Server Name: A\INSTANC3
Error Number: 35250
Severity: 16
State: 7

Checked the event log, not useful information provided:

-

Nonqualified transactions are being rolled back in database DBNamefor an AlwaysOn Availability Groups state change. Estimated rollback completion: 100%. This is an informational message only. No user action is required.

-

The database 'DBName' is marked RESTORING and is in a state that does not allow recovery to be run.

-

Starting up database 'DBName'.

-

State information for database 'DBName' - Hardended Lsn: '(268:12520:1)'    Commit LSN: '(0:0:0)'    Commit Time: 'Jan  1 1900 12:00AM'


GOOGLED, all pointed to the endpoint, firewall etc, which is not helpful at all, since there is another database working fine in same availability group... I have crosschecked, firewall is configured, port is open, the endpoint url status is connected on all nodes.

A bit sad... thus have to try solution 4 --- which fixed the issue in 1 minute.

So, does anyone knows why "The connection to the primary replica is not active.  The command cannot be processed." pops up even the connection is super good?

Regards,

Albert





Viewing all articles
Browse latest Browse all 4532

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>