High Availability

Alwayson Availability Group Replica is Not Synchronizing (Error: 976, Severity: 14, State: 1.)

tech-coffee-sql-server2
For some reason you can lose communication between the primary and secondary replicas.

As known, there is a policy on SQL Server to check the data synchronization state of the database replica. The policy is in an unhealthy state when the data synchronization state is NOT SYNCHRONIZING or the state is not SYNCHRONIZED for the synchronous-commit database replica.

After investigating the sql server errorlog, I got the following msg:

The target database, ‘YourDatabase’, is participating in an availability group and is currently not accessible for queries. Either data movement is suspended or the availability replica is not enabled for read access. To allow read-only access to this and other databases in the availability group, enable read access to one or more secondary availability replicas in the group.  For more information, see the ALTER AVAILABILITY GROUP statement in SQL Server Books Online. (Microsoft SQL Server, Error: 976)

According to Technet, this issue can be caused by the following:

  • The availability replica might be disconnected.
  • The data movement might be suspended.
  • The database might not be accessible.
  • There might be a temporary delay issue due to network latency or the load on the primary or secondary replica.

Further information: https://technet.microsoft.com/en-us/library/hh245199.aspx

Resolution:
You can fix it, using the following T-SQL command to force the resume synchronization:

ALTER DATABASE YourDatabase SET HADR RESUME;

 

You can also follow the link: How to resume an AG database.

Check out these related tips:

How to monitor Timeout and Changes Roles from Availability Groups with Alerts
How to Monitor AlwaysON – Primary / Secondary Replicas

Advertisements

Introducing Cloud Witness – [SQL Server]

We know that when we create a Cluster environment between two sites, we must take care about Quorum Witness.
If you need automatic failover SLA in your company, the best way is to separate the (Quorum) FileShare Quitness at a third site. So it is not lost if one of the other two sites has problems.

But, What if you dont have the third site?

Now, It’s possible using Cloud Witness. A new type of Failover Cluster quorum witness with Windows Server 2012 R2.
Follow the link below to an article with steps required to configure it.

http://blogs.msdn.com/b/clustering/archive/2014/11/14/10572766.aspx

How to validate Quorum Vote from Windows server Failover Cluster (AlwaysOn)

If you have configured a Windows server Failover Cluster with more than two Nodes, you must care about the “votes” in each Node.

Let’s imagine the following environment:

You have two Nodes configured in Automatic Failover/Synchronous mode with AlwaysOn Availability Group.
Another Node in Manual Failover/Asynchronous as a Reporting Service.

So, you have 3 Nodes where each one is counting one vote, and another one as a FileShare. (Quorum configured during the Alwayson installation).

You should always have an odd number of quorum votes in a WSFC cluster. For the purposes of quorum voting, SQL Server does not have to be installed on all nodes in the cluster. An additional server can act as a quorum member, or the WSFC quorum model can be configured to use a remote file share as a tie-breaker.

For more information, see: WSFC Quorum Modes and Voting Configuration (SQL Server)

In other words, if your FileShare and Reporting Service are not available, your production environment will goes down. It’s not a good ideia, right?

To fix it, you must Install the hotfix KB2494036 in each Node.
This hotfix is available to allow you to configure a cluster node that does not have quorum vote in Windows Server 2008 and 2008 R2.

Now, you are able to remove the quorum vote from Reporting Services environment with the script below on cmd:

Cluster.exe . node SERVERNAME /prop NodeWeight=0

To validate Quorum vote, take a look at the following scripts

Managment Studio

SELECT  member_name, member_state_desc, number_of_quorum_votes
 FROM   sys.dm_hadr_cluster_members;

PowerShell

Import-Module FailoverClusters
$cluster = "CLUSTERNAME"
$nodes = Get-ClusterNode -Cluster $cluster
$nodes | Format-Table -property NodeName, State, NodeWeight

I hope this information can help you.

High Availability and Disaster Recover – Syncronize logins [SQL Server]

Often I connect in new environments and I see solutions of High Availability and Disaster Recovery. But just the simple solution is sufficient for your applications?
I’m saying that because in many cases a just simple detail is forgotten. Many professionals forget to create a option to syncronize logins and when you need to use the otherside, application not run and your solution of High Availability failed.

Follow below one example of script to syncronize your environment.

You need to create one LINKEDSERVER between instances and run one job for a specific times or a trigger to execute this jobs when you have a new user or when the user has been modified.

After you need to create a procedure hexadecimal according with your version. Look that and create in both instances: http://support.microsoft.com/kb/918992

And finaly, create the procedure below. Don’t forget to change the name of LINKEDSERVER

This script is simple and just create login without administratives privileges and with the same SID and when password has been modified. If you need sysadmin for example, you will need input manually. I think is better because sometimes you have a diferent instance and maybe you can’t grant acess in a especific server.

BEGIN
SET NOCOUNT ON

	CREATE TABLE #Logins
	(
		loginId int IDENTITY(1, 1) NOT NULL,
		loginName nvarchar(128) NOT NULL,
		passwordHash varbinary(256) NULL,
		default_database_name nvarchar(128) NULL,
		sid varbinary(85) NOT NULL
	)

	INSERT INTO #Logins(loginName, passwordHash, sid, default_database_name)
	SELECT *
	FROM OPENQUERY([INSTANCE], '
	SELECT name, CONVERT(varbinary(256), LOGINPROPERTY(name, ''PasswordHash'')), sid, default_database_name
	FROM master.sys.server_principals
	WHERE
		type = ''S'' AND 
		name NOT IN (''sa'', ''guest'',''##MS_PolicyEventProcessingLogin##'',''usr_alwayson'') AND
		create_date >= ''01/05/2014''
	ORDER BY name')

	DECLARE 
		@count int, @loginId int, @loginName nvarchar(128), 
		@passwordHashOld varbinary(256), @passwordHashNew varbinary(256), 
		@SID_varbinary varbinary(85), @sql nvarchar(4000), @password varchar(514), @default_database_name nvarchar(128), @SID_string varchar (514)

	SELECT @loginId = 1, @count = COUNT(*)
	FROM #Logins

	WHILE @loginId <= @count
	BEGIN
		SELECT @loginName = loginName, @passwordHashNew = passwordHash, @SID_varbinary = sid, @default_database_name = default_database_name
		FROM #Logins
		WHERE loginId = @loginId

		IF NOT EXISTS (SELECT * FROM master.sys.server_principals WHERE name = @loginName)
		BEGIN
			EXEC master.dbo.sp_hexadecimal @passwordHashNew, @password OUTPUT
			EXEC master.dbo.sp_hexadecimal @SID_varbinary,@SID_string OUT

			SET @sql = 'CREATE LOGIN ' + @loginName + ' WITH PASSWORD = '
			SET @sql = @sql + CONVERT(nvarchar(512), COALESCE(@password, 'NULL')) 
			SET @sql = @sql + ' HASHED , SID = ' + CONVERT(nvarchar(512), @SID_string)
			SET @sql = @sql + ' , DEFAULT_DATABASE = [' + @default_database_name + ']'
			SET @sql = @sql + ' , CHECK_POLICY = OFF' 
			PRINT @sql
			EXEC (@sql)

			PRINT 'login created'
		END
		ELSE
		BEGIN
			SELECT @passwordHashOld = CONVERT(varbinary(256), LOGINPROPERTY(@loginName, 'PasswordHash'))

			-- only bother updating if the password has changed since the last sync
			IF @passwordHashOld <> @passwordHashNew
			BEGIN
				EXEC master.dbo.sp_hexadecimal @passwordHashNew, @password OUTPUT

				--SET @sql = 'DROP LOGIN ' + @loginName
				--PRINT @sql
				--EXEC (@sql)

				SET @sql = 'ALTER LOGIN ' + @loginName + ' WITH PASSWORD = '
				SET @sql = @sql + CONVERT(nvarchar(512), COALESCE(@password, 'NULL'))
				SET @sql = @sql + ' HASHED, CHECK_POLICY = OFF' 
				PRINT @sql
				EXEC (@sql)

				PRINT 'login "altered"'
			END
		END

		SET @loginId = @loginId + 1
	END

	DROP TABLE #Logins

END

Availability Groups Setup and Configuration from A to Z

AlwaysOn Availability Groups was introduced in SQL Server 2012, and it’s one of the most important features in the history of SQL Server.
The link provided below, as far as I’m concerned, it’s a complete step by step on how to configure a high availability solution with the Availability Groups.
There are points that you must consider before installation, as well as installing the hotfix KB2494036.
  • A hotfix is available to let you configure a cluster node that does not have quorum votes in Windows Server 2008 and in Windows Server 2008 R2

http://blogs.lessthandot.com/index.php/architect/availability-groups-setup-and-configuration-from-a-to-z/

Enjoy it!