Submit a ticketCall us

WebinarUpcoming Webinar: Should I Move My Database to the Cloud?

So you’ve been running an on-premises SQL Server® for a while now. Maybe you’ve moved it from bare metal to a VM, and have seen some positive benefits. But, do you want to see more? If you said “YES!”, then this session is for you, as James Serra will review the many benefits that can be gained by moving your on-prem SQL Server to an Azure® VM (IaaS). He’ll also talk about the many hybrid approaches, so you can gradually move to the cloud. If you are interested in cost savings, additional features, ease of use, quick scaling, improved reliability, and ending the days of upgrading hardware, this is the session for you.

Register now.

Home > Success Center > Netflow Traffic Analyzer (NTA) > NTA Documentation > NTA 4.4 Administrator Guide > High Availability in SolarWinds products > How failovers work

How failovers work

Updated: September 13, 2017

This Orion Platform topic applies to the highlighted products:

DPAIMEOCETSIPAMLMNCMNPMNTASAMSRMUDTVMANVNQMWPM

After High Availability is enabled and you have set up a pool, each pool monitors itself for failover conditions such as:

  • Inability to connect to the network
  • Stopped SolarWinds services

    Stopped Agent services is not a failover condition.

  • Power loss
  • Network connection loss to the primary server

When a monitored service is down, the Orion server tries to allow the service to recover before failing over to the secondary server. If the same service fails within the default self-recovery period, a failover occurs.

When a failover condition is met and failover occurs in a pool, a failover event is logged and can be viewed in the Event Summary resource or the Events view. An email is also sent to your default recipients.

For example, if the job engine service is down, the High Availability software attempts to start it. If the job engine fails again within 1 hour, then a failover occurs and the event is logged. If the job engine fails in 61 minutes, a failover does not occur.

Failovers with virtual hostnames

When your HA pool uses a virtual hostname, failovers may not appear to work due to caching issues.  The client DNS cache can take up to one minute to redirect traffic to the new active pool member.

However, your browser's DNS cache does not respect the DNS Time to Live (TTL) value, and the DNS cache retention varies between browsers from 60 seconds to 24 hours. You must flush your browser's cache be successfully redirected to the new active pool member.

 
Last modified

Tags

Classifications

Public