(Be sure to checkout the FREE SQLpassion Performance Tuning Training Plan - you get a weekly email packed with all the essential knowledge you need to know about performance tuning on SQL Server.)
Last week I have blogged about how you can run the Availability Group traffic through a different network card. In today’s blog posting I want to talk about some side effects of this approach when you want to add a new Replica into an existing Availability Group.
Add new Replicas
SQL Server Management Studio is great and awesome, but you really have to be very careful how you use it, because there are so many different side effects that you have to be aware of. Imagine you are routing your Availability Group traffic through a dedicated network card as I have described in my last blog posting. My lab environment consists of 3 VMs, which are using the following private IP addresses for the Availability Group traffic:
- 10.10.1.1
- 10.10.1.2
- 10.10.1.3
Summary
When you route your Availability Group traffic through a dedicated network card, you have to be aware of this problem. Otherwise your newly added Replica will not be part of your Availability Group (it can’t be joined), and you have to troubleshoot the underlying root cause of the problem.
So please check the IP address accordingly, when you add the next time a new Replica into an Availability Group. In another upcoming blog posting I will also show you how easy it is to completely crash SQL Server Management Studio when you add a previous removed Replica back into an Availability Group – but this is a topic for another day… 
Thanks for your time,
-Klaus
