when can AG primary replica be a different host to WFC primary?












1















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?










share|improve this question
















bumped to the homepage by Community 5 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
















1















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?










share|improve this question
















bumped to the homepage by Community 5 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














1












1








1








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?










share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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 5 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 5 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



















  • 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










1 Answer
1






active

oldest

votes


















0














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.






share|improve this answer























    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
    });


    }
    });














    draft saved

    draft discarded


















    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









    0














    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.






    share|improve this answer




























      0














      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.






      share|improve this answer


























        0












        0








        0







        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.






        share|improve this answer













        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.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Jul 24 '15 at 11:05









        Brent OzarBrent Ozar

        34.9k19104235




        34.9k19104235






























            draft saved

            draft discarded




















































            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            SQL Server 17 - Attemping to backup to remote NAS but Access is denied

            Always On Availability groups resolving state after failover - Remote harden of transaction...

            Restoring from pg_dump with foreign key constraints