About Me

My photo
I am an MCSE in Data Management and Analytics, specializing in MS SQL Server, and an MCP in Azure. With over 19+ years of experience in the IT industry, I bring expertise in data management, Azure Cloud, Data Center Migration, Infrastructure Architecture planning, as well as Virtualization and automation. I have a deep passion for driving innovation through infrastructure automation, particularly using Terraform for efficient provisioning. If you're looking for guidance on automating your infrastructure or have questions about Azure, SQL Server, or cloud migration, feel free to reach out. I often write to capture my own experiences and insights for future reference, but I hope that sharing these experiences through my blog will help others on their journey as well. Thank you for reading!

Violation of AlwaysOn constraint

================================

Rakesh configures WSFC cluster with two nodes, NODE01 and NODE02. He installs a SQL Server failover cluster instance, fciInstance1, on both NODE01 and NODE02 where NODE01 is the current owner for fciInstance1.

On NODE02, Rakesh installs another instance of SQL Server, Instance3, which is a stand-alone instance.
On NODE01,  Rakesh  enables fciInstance1 for AlwaysOn Availability Groups. On NODE02, he enables Instance3 for AlwaysOn Availability Groups. Then he sets up an availability group for which fciInstance1hosts the primary replica, and Instance3 hosts the secondary replica.
At some point fciInstance1 becomes unavailable on NODE01, and the WSFC cluster causes a failover of fciInstance1 to NODE02. After the failover, fciInstance1 is a AlwaysOn Availability Groups-enabled instance running under the primary role on NODE02. However, Instance3 now resides on the same WSFC node as fciInstance1. This violates the AlwaysOn Availability Groups constraint.





Detailed Explanation in this blog:-


http://blogs.msdn.com/b/arvindsh/archive/2012/09/26/failover-cluster-instance-alwayson-availability-group-dr-scenario.aspx

Labels: , ,