I bet a lot of IT professionals who are really serious about their work are like me. When they see an error or warning message like this, their first instinct is to find out what the problem is and fix it. That’s what I did when I saw this error while configuring a SQL Server 2012 Always On Availability Group. I searched blog posts, forum posts, mailing lists, KB articles, and everything I can think of. I’ve seen this error message before and I know exactly what to do. I’ve done this many times. Except this time, I didn’t do what I knew I needed to do.
Understanding the underlying architecture design is key to addressing warning and/or error messages like this. Microsoft KB article 2833122 outlines the different causes of this warning message when you are working with SQL Server 2012 Always On Availability Groups. I knew causes #1 and #2 do not apply to me because I’m already running on Windows Server 2012 with SQL Server 2012 with Service Pack 1. In the past, I had to install the required hotfix for Windows Server 2008/R2 to get this to work. But check this out. If you look closely at causes #3 and #4, and you understand the underlying architecture design, you might miss out the last phrase (emphasis mine.)
…you can safely ignore the warning message.
That’s it. No panicking, no pressing of the emergency button, no dialing 911. Again, the key thing here is “understanding the architecture design.” In my case, it is a SQL Server failover clustered instance configured with an Always On Availability Group whose standby replica is on a different network subnet. I had to explicitly configure the node weight of the secondary replica to zero (0) because it is on a different network subnet. I do not want that node to affect the SQL Server failover clustered instance that is running in my primary data center. Ironically, I was the one who designed the architecture but was the very first one who panicked. 🙂
So, the next time you see an error message like this, ask yourself these questions:
- Do I know what caused it?
- Do I understand the underlying architecture design?
- Do I need to resolve it?
- Did I have enough sleep last night?
Feeling helpless and confused when dealing with Windows Server Failover Clustering (WSFC) for your SQL Server databases?
You’re not alone. I’ve heard the same thing from thousands of SQL Server administrators throughout my entire career. These are just a few of them.
“How do I properly size the server, storage, network and all the AD settings which we do not have any control over?”
“I don’t quite understand how the Windows portion of the cluster operates and interacts with what SQL controls.”
“I’m unfamiliar with multi-site clustering.”
“Our servers are setup and configured by our parent company, so we don’t really get much experience with setting up Failover Clusters.“
If you feel the same way, then, this course is for you. It’s a simple and easy-to-understand way for you to learn and master how Windows Server Failover Clusters can keep your SQL Server databases highly available. Be confident in designing, building and managing SQL Server databases running on Windows Server Failover Clusters.
But don’t take my word for it. Here’s what my students have to say about the course.
“The techniques presented were very valuable, and used them the following week when I was paged on an issue.”
“Thanks again for giving me confidence and teaching all this stuff about failover clusters.”
“I’m so gladdddddd that I took this course!!”
“Now I got better knowledge to setup the Windows FC ENVIRONMENT (DC) for SQL Server FCI and AlwaysON.”
Please note: I reserve the right to delete comments that are offensive or off-topic.