locked
placing a witness on a different subnet RRS feed

  • Question

  • I have sql 2012 server configured for mirror and had to place the witness server on a different location/subnet.  its seems to be working but does anyone know if thats a supported configuration?

    Tuesday, March 24, 2015 7:15 PM

Answers

  • It's a supported configuration, but think of a scenario where you decide to put your mirror and principal in Datacentre1 (DC1) and your witness in Datacentre2 (DC2). You will have limited bandwidth between the two locations.
    A sysadmin needs to copy an ISO from DC1 to DC2, he starts this copy and consumes all of the bandwidth.
    As a result of this your witness loses connectivity from your mirror and principal - resulting in an inability to initiate automatic failover.

    If your witness is on a different subnet within the same datacentre it should be fine, if you're relying on connectivity to a remote site I'd be very cautious about implementing this configuration.
    Thursday, March 26, 2015 5:34 AM

All replies

  • On SQL 2012 Mirroring feature will be deprecated going forward though it's a supported feature I would recommend to avoid this design and think of implementing AlwaysOn.

    --Prashanth

    Tuesday, March 24, 2015 7:59 PM
  • I have sql 2012 server configured for mirror and had to place the witness server on a different location/subnet.  its seems to be working but does anyone know if thats a supported configuration?

    Technically this should be possible so long as you can get a route  to your mirror and principal, but there's a couple of things to consider.

    • The witness needs to be in constant contact with your principal and mirror in order to initiate failover. High network latency could potentially result in losing quorum if the mirror (or principal) was to become unavailable and the witness was not reachable. You should have a reliable/fast link in place between the servers if you're using high safety mode.
    • Ideally when setting up mirroring you'd use a fully qualified domain name. Will this be possible in your circumstances? Using IP address can result in issues and having to find work-arounds

    Hope that helps

    Wednesday, March 25, 2015 12:10 AM
  • On SQL 2012 Mirroring feature will be deprecated going forward though it's a supported feature I would recommend to avoid this design and think of implementing AlwaysOn.

    --Prashanth

    Totally agree with this, although unfortunately not an option on anything other than Enterprise edition
    Wednesday, March 25, 2015 12:14 AM
  • Yes, I am using fqdn.  Not sure about network latency.
    Thursday, March 26, 2015 12:00 AM
  • Is it supported configuration though?
    Thursday, March 26, 2015 12:08 AM
  • Hi Hulkster2004,

    It is a supported  configuration that place the witness server on a different location/subnet.

    However, we make no recommendations about whether the configuration is reliable enough for database mirroring in high-safety mode. If you decide to use high-safety mode, be cautious about how you add a witness to the session, because unwanted automatic failovers can occur.

    For more information, please review the following link.
    https://technet.microsoft.com/en-us/library/ms366349.aspx

    Thanks,
    Lydia Zhang


    Lydia Zhang
    TechNet Community Support



    Thursday, March 26, 2015 3:35 AM
  • It's a supported configuration, but think of a scenario where you decide to put your mirror and principal in Datacentre1 (DC1) and your witness in Datacentre2 (DC2). You will have limited bandwidth between the two locations.
    A sysadmin needs to copy an ISO from DC1 to DC2, he starts this copy and consumes all of the bandwidth.
    As a result of this your witness loses connectivity from your mirror and principal - resulting in an inability to initiate automatic failover.

    If your witness is on a different subnet within the same datacentre it should be fine, if you're relying on connectivity to a remote site I'd be very cautious about implementing this configuration.
    Thursday, March 26, 2015 5:34 AM