when can AG primary replica be a different host to WFC primary?
To set up an Availability Group with two servers, the servers both participate in a Windows Failover Cluster.
I've seen cases after certain failover modes where the primary IP address in the cluster (in Windows Server Manager -> Failover Cluster Manager -> Cluster Core Resources) can be the address associated with the secondary replica in the AG.
Is this a problem – does it matter at all?
More generally, is there any reference on how the WFC relates to the AG, and to the Availability Group Listener?
sql-server sql-server-2012 clustering availability-groups
bumped to the homepage by Community♦ 4 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
To set up an Availability Group with two servers, the servers both participate in a Windows Failover Cluster.
I've seen cases after certain failover modes where the primary IP address in the cluster (in Windows Server Manager -> Failover Cluster Manager -> Cluster Core Resources) can be the address associated with the secondary replica in the AG.
Is this a problem – does it matter at all?
More generally, is there any reference on how the WFC relates to the AG, and to the Availability Group Listener?
sql-server sql-server-2012 clustering availability-groups
bumped to the homepage by Community♦ 4 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
If your hardware failed and the Primary node failed over to a secondary node, the secondary becomes the primary. Same with the AG and it's replicas, only with the AG, your primary replica may be located on your secondary node. So the answer is no, it's not a problem, but it can get confusing. Typically, we would resolve the failover and manually fail back to the intended primary, just to mitigate confusion.
– Steve Mangiameli
Jan 16 '15 at 19:52
add a comment |
To set up an Availability Group with two servers, the servers both participate in a Windows Failover Cluster.
I've seen cases after certain failover modes where the primary IP address in the cluster (in Windows Server Manager -> Failover Cluster Manager -> Cluster Core Resources) can be the address associated with the secondary replica in the AG.
Is this a problem – does it matter at all?
More generally, is there any reference on how the WFC relates to the AG, and to the Availability Group Listener?
sql-server sql-server-2012 clustering availability-groups
To set up an Availability Group with two servers, the servers both participate in a Windows Failover Cluster.
I've seen cases after certain failover modes where the primary IP address in the cluster (in Windows Server Manager -> Failover Cluster Manager -> Cluster Core Resources) can be the address associated with the secondary replica in the AG.
Is this a problem – does it matter at all?
More generally, is there any reference on how the WFC relates to the AG, and to the Availability Group Listener?
sql-server sql-server-2012 clustering availability-groups
sql-server sql-server-2012 clustering availability-groups
edited Jan 30 '14 at 15:27
Aaron Bertrand♦
151k18288488
151k18288488
asked Jan 29 '13 at 16:06
Joe KearneyJoe Kearney
16326
16326
bumped to the homepage by Community♦ 4 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
bumped to the homepage by Community♦ 4 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
If your hardware failed and the Primary node failed over to a secondary node, the secondary becomes the primary. Same with the AG and it's replicas, only with the AG, your primary replica may be located on your secondary node. So the answer is no, it's not a problem, but it can get confusing. Typically, we would resolve the failover and manually fail back to the intended primary, just to mitigate confusion.
– Steve Mangiameli
Jan 16 '15 at 19:52
add a comment |
If your hardware failed and the Primary node failed over to a secondary node, the secondary becomes the primary. Same with the AG and it's replicas, only with the AG, your primary replica may be located on your secondary node. So the answer is no, it's not a problem, but it can get confusing. Typically, we would resolve the failover and manually fail back to the intended primary, just to mitigate confusion.
– Steve Mangiameli
Jan 16 '15 at 19:52
If your hardware failed and the Primary node failed over to a secondary node, the secondary becomes the primary. Same with the AG and it's replicas, only with the AG, your primary replica may be located on your secondary node. So the answer is no, it's not a problem, but it can get confusing. Typically, we would resolve the failover and manually fail back to the intended primary, just to mitigate confusion.
– Steve Mangiameli
Jan 16 '15 at 19:52
If your hardware failed and the Primary node failed over to a secondary node, the secondary becomes the primary. Same with the AG and it's replicas, only with the AG, your primary replica may be located on your secondary node. So the answer is no, it's not a problem, but it can get confusing. Typically, we would resolve the failover and manually fail back to the intended primary, just to mitigate confusion.
– Steve Mangiameli
Jan 16 '15 at 19:52
add a comment |
1 Answer
1
active
oldest
votes
This is easiest to explain if you think about having multiple Availability Groups in your environment rather than just one. Each AG listener would have its own name and IP, and it could be failed over independently to either physical node.
In that environment, there are a few different parts:
- The physical nodes - each of which has its own IP address
- Each Availability Group listener - each of which has its own virtual name and address, and fails over back and forth between the nodes depending on who owns that particular Availability Group at that moment in time
- The cluster's management point - which also has its own virtual name and address, and can be different than the AG listener.
See, one of the nodes has to own the cluster. This becomes more and more important as your cluster grows out - for example, to multiple physical nodes rather than just two. That cluster manager keeps control of the cluster's state, which nodes own which moving parts, and so on.
All Windows clusters - even a simple 2-node, 1-AG setup - have this separate name and IP address for management. Most of the time, it doesn't matter who owns the cluster, but in a multi-node cluster (say, 3 nodes in your primary data center and 2 nodes in your disaster recovery data center) where you want to get down to last-man-standing as things fail, then it does start to matter.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "182"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f33756%2fwhen-can-ag-primary-replica-be-a-different-host-to-wfc-primary%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
This is easiest to explain if you think about having multiple Availability Groups in your environment rather than just one. Each AG listener would have its own name and IP, and it could be failed over independently to either physical node.
In that environment, there are a few different parts:
- The physical nodes - each of which has its own IP address
- Each Availability Group listener - each of which has its own virtual name and address, and fails over back and forth between the nodes depending on who owns that particular Availability Group at that moment in time
- The cluster's management point - which also has its own virtual name and address, and can be different than the AG listener.
See, one of the nodes has to own the cluster. This becomes more and more important as your cluster grows out - for example, to multiple physical nodes rather than just two. That cluster manager keeps control of the cluster's state, which nodes own which moving parts, and so on.
All Windows clusters - even a simple 2-node, 1-AG setup - have this separate name and IP address for management. Most of the time, it doesn't matter who owns the cluster, but in a multi-node cluster (say, 3 nodes in your primary data center and 2 nodes in your disaster recovery data center) where you want to get down to last-man-standing as things fail, then it does start to matter.
add a comment |
This is easiest to explain if you think about having multiple Availability Groups in your environment rather than just one. Each AG listener would have its own name and IP, and it could be failed over independently to either physical node.
In that environment, there are a few different parts:
- The physical nodes - each of which has its own IP address
- Each Availability Group listener - each of which has its own virtual name and address, and fails over back and forth between the nodes depending on who owns that particular Availability Group at that moment in time
- The cluster's management point - which also has its own virtual name and address, and can be different than the AG listener.
See, one of the nodes has to own the cluster. This becomes more and more important as your cluster grows out - for example, to multiple physical nodes rather than just two. That cluster manager keeps control of the cluster's state, which nodes own which moving parts, and so on.
All Windows clusters - even a simple 2-node, 1-AG setup - have this separate name and IP address for management. Most of the time, it doesn't matter who owns the cluster, but in a multi-node cluster (say, 3 nodes in your primary data center and 2 nodes in your disaster recovery data center) where you want to get down to last-man-standing as things fail, then it does start to matter.
add a comment |
This is easiest to explain if you think about having multiple Availability Groups in your environment rather than just one. Each AG listener would have its own name and IP, and it could be failed over independently to either physical node.
In that environment, there are a few different parts:
- The physical nodes - each of which has its own IP address
- Each Availability Group listener - each of which has its own virtual name and address, and fails over back and forth between the nodes depending on who owns that particular Availability Group at that moment in time
- The cluster's management point - which also has its own virtual name and address, and can be different than the AG listener.
See, one of the nodes has to own the cluster. This becomes more and more important as your cluster grows out - for example, to multiple physical nodes rather than just two. That cluster manager keeps control of the cluster's state, which nodes own which moving parts, and so on.
All Windows clusters - even a simple 2-node, 1-AG setup - have this separate name and IP address for management. Most of the time, it doesn't matter who owns the cluster, but in a multi-node cluster (say, 3 nodes in your primary data center and 2 nodes in your disaster recovery data center) where you want to get down to last-man-standing as things fail, then it does start to matter.
This is easiest to explain if you think about having multiple Availability Groups in your environment rather than just one. Each AG listener would have its own name and IP, and it could be failed over independently to either physical node.
In that environment, there are a few different parts:
- The physical nodes - each of which has its own IP address
- Each Availability Group listener - each of which has its own virtual name and address, and fails over back and forth between the nodes depending on who owns that particular Availability Group at that moment in time
- The cluster's management point - which also has its own virtual name and address, and can be different than the AG listener.
See, one of the nodes has to own the cluster. This becomes more and more important as your cluster grows out - for example, to multiple physical nodes rather than just two. That cluster manager keeps control of the cluster's state, which nodes own which moving parts, and so on.
All Windows clusters - even a simple 2-node, 1-AG setup - have this separate name and IP address for management. Most of the time, it doesn't matter who owns the cluster, but in a multi-node cluster (say, 3 nodes in your primary data center and 2 nodes in your disaster recovery data center) where you want to get down to last-man-standing as things fail, then it does start to matter.
answered Jul 24 '15 at 11:05
Brent OzarBrent Ozar
34.9k19104235
34.9k19104235
add a comment |
add a comment |
Thanks for contributing an answer to Database Administrators Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f33756%2fwhen-can-ag-primary-replica-be-a-different-host-to-wfc-primary%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
If your hardware failed and the Primary node failed over to a secondary node, the secondary becomes the primary. Same with the AG and it's replicas, only with the AG, your primary replica may be located on your secondary node. So the answer is no, it's not a problem, but it can get confusing. Typically, we would resolve the failover and manually fail back to the intended primary, just to mitigate confusion.
– Steve Mangiameli
Jan 16 '15 at 19:52