Next is the interesting part. First we need to add the cluster nodes that will be serving this Availability Group. Select “Add Replica…”:
When nodes are added, we also need to configure Replicas according to our needs [picture above]:
Initial Role – this is how I want my roles to be initiated after this wizard is completed. Later roles can be changed.
Automatic Failover – by selecting this I’m making sure that in case of a Primary node failure the other will take the role automatically.
Synchronous Commit – by selecting this I’m making synchronization type “Synchronous Commit”.
Readable Secondary – I want to be able to perform database read operations from the instance that is performing a Secondary role, therefore “Yes” is specified
Next tab is called “Endpoints”, and it’s going to be populated automatically:
A server instance uses an endpoint to listen for the AlwaysOn Availability Groups messages sent from availability replicas hosted by other server instances. In other words, an endpoint is used to communicate between the primary and the secondary replicas of the availability group. I think of them as an internal intercommunication. You might want to change the port number if the suggested are not good because of the firewall or some other considerations. By the way, this is not something new, mirroring also uses same type of endpoints.
Next tab is called “Backup Preferences”:
Prefer Secondary – Specifies that backups should occur on a secondary replica except when the primary replica is the only replica online. In that case, the backup should occur on the primary replica. This is the default option.
Secondary only – Specifies that backups should never be performed on the primary replica. If the primary replica is the only replica online, the backup should not occur.
Primary – Specifies that the backups should always occur on the primary replica. This option is useful if you need backup features, such as creating differential backups, that are not supported when backup is run on a secondary replica.
Any Replica – Specifies that you prefer that backup jobs ignore the role of the availability replicas when choosing the replica to perform backups. Note backup jobs might evaluate other factors such as backup priority of each availability replica in combination with its operational state and connected state.
Next tab is called “Listener” and this is the most important component in my opinion:
If the Endpoints are used to intercommunicate between cluster nodes, Listener on the other hand allows clients to automatically find the primary node, a node that is currently serving the Availability Group read/write database replica. Even more, if you specify a special parameter you can say that you actual want to access a database in a secondary replica. Listener is also a virtual network name (VNN) and it will be created as an AD object.
We can use port 1433 again because it will be attached to the listener dedicated IP addresses. So, no collision with the SQL Server main IP/port.
As you can see from the screenshot above, having a Listener is not a mandatory thing. Why? Because database users can still connect to the Primary database replica [read/write replica] directly by specifying a name of a server that is holding it. But if the Primary replica moves to another node then your users must change the connection address on their end manually. With the Listener all this redirection magic happens automatically.
By the way, remember IP addresses that I have allowed in Amazon on the secondary NICs:
Next step in the Wizard is asking us how we want to synchronize our Availability Group nodes. Remember a share that we have created in the Part 3 – “\\WIN2012DC\Replica”: And that is it. If everything was prepared correctly we should see this nice list of successful results: