Network Management

SQL DR - Mirroring - Clustering - Log Shipping - SQL AlwaysOn

Implementing SolarWinds Platform on SQL Cluster is supported. It is a great method to provide redundancy for the SQL Server while high availability will provide redundancy for Pollers.

First published date

10/24/2018 9:16 PM

Last published date

4/13/2026 8:39 PM

Overview

SQL Server Clustering & Netperfmon

Implementing SolarWinds Platform on SQL Cluster is supported.
It is a great method to provide redundancy for the SQL Server while FoE will provide redundancy for Pollers.
SolarWinds Platform does not care if the DB is on a Cluster or not. This is the beauty of a SQL always on Cluster.
Make sure that SolarWinds Platform is set to the cluster name and not to a cluster node.
- Otherwise if a failover occurs SolarWinds Platform will lose the connection.
SolarWinds Technical Support supports any DB Connections issues from SolarWinds Platform to the SolarWinds Platform DB, same as a non clustered configuration, but we do not support assisting with Cluster Configuration, etc… That is for the Server\DB Admins responsibility.
Most issues we might see are due to SolarWinds Platform not being pointed to the Cluster name or the Storage behind the Cluster is causing issue, not clustering itself, SANs etc….

SQL Replication:

SQL Replication is supported, but our database does not support GUID columns (common with DB mirroring) with our tables.
SQL HA will typically require Replication and FULL Recovery Mode.
- Please see our SQL best practices Guide for further details about configuration requirements when using SolarWinds Database in a Full Recovery Mode: https://documentation.solarwinds.com/en/Success_Center/orionplatform/Content/Core-SQL-Server-Configuration-Best-Practices-sw1430.htm

Product section

Network Performance Monitor

Resolution

SQL Replication Made Simple

Q: Will SolarWinds Platform work with SQL replication?
A: Yes, SolarWinds Platform supports SQL replication. It is highly dependent on the performance of the SQL server for it to be stable.

Q: What are the different type of SQL replication that we work with?
A: There are various types of common Cluster SQL server where the replication is transparent to NPM.
There is: log shipping, Snapshot Replication, and Merge replication.

Our database works with Log Shipping.
Snapshot and Merge replication may also work but there are many configuration,
it all depends whether the configuration is transparent to us meaning no modification to our db and creating indexes or consider modifying the DB. (We cannot test snapshot and merge replication as there are many different configuration scenarios)
As long as your clustering configuration requires no modification of the SolarWinds Database it should work. If your configuration requires modification of the SolarWinds Database this is something that is not supported by SolarWinds Technical Support.

Q: What recovery mode does Log Shipping need to be on?
A: The DB needs to be in Full Recovery mode for Log Shipping.

Q: Do SolarWinds support DB to full recovery mode.
A: We do not recommend FULL Recovery due to overhead it causes, but we do support it as long the SQL server performance is not effected. Setting the recovery mode to Full requires the SQL server to keep up with the added burden of setting it to this mode. Please see this LINK to our SQL best practices guide for some guidelines on how to compensate for the Full recovery overhead.

Q: When I set to Full recovery mode I see the transaction log grow very fast and the log files get very large very fast.
A: Yes this is normal behavior for a Full Recovery database. Let's understand what the transaction log is used for - it is a temp. bucket for data to be put into the database. So if the DB cannot keep up, the trans log grows quickly. This is related to the speed of the disk system (IOPS) and how many resource is available to the SQL server/database.

Official SolarWinds Documentation

SQL DISASTER RECOVERY SOLUTION OVER WAN

https://thwack.solarwinds.com/discussion/68115/sql-disaster-recovery-solution-over-wan

SOLARWINDS PLATFORM AND SQL MIRRORING

https://thwack.solarwinds.com/discussion/comment/13400
SQL Mirroring is an ancient feature of MSSQL it is not recommend to be used by SolarWinds.
- Database mirroring is in maintenance mode for years and MS is warning its users that it would be removed soon (but it is still present)
- There is Always On Availability Groups instead of Mirroring
- We recommend Availability Groups and recommend avoid using SQL Mirroring
https://docs.microsoft.com/en-us/sql/database-engine/database-mirroring/database-mirroring-sql-server?view=sql-server-2017

Options for SQL Failover

Options below include both DR and HA

SQL Clustering
SQL Log Shipping
NeverFail for SQL (HA)
SQL High Availability Groups

SQL AlwaysOn

SQL AlwaysON is supported.
Multi-subnet failover is supported in OLE DB Driver version 17 and above. For more information, see https://learn.microsoft.com/en-us/sql/connect/oledb/features/oledb-driver-for-sql-server-support-for-high-availability-disaster-recovery?view=sql-server-ver17

Force-enable multi-subnet failover in Configuration Wizard

In earlier versions, the Configuration Wizard attempted to automatically detect whether the SolarWinds Platform database was hosted in a SQL Server Always On Availability Group and, if needed, injected MultiSubnetFailover=True into the SQL connection string. In some topologies, however, this automatic detection step might not run or might fail to recognize that multi-subnet failover support is required, which could result in intermittent connectivity issues for services connecting through a multi-subnet listener until MultiSubnetFailover=True was added manually.

Starting with SolarWinds Platform 2026.1, the Configuration Wizard includes a new Force-enable multi-subnet failover checkbox to give you explicit control over this behavior.

Use this option in environments that meet both of the following conditions:

You are using SQL Server Always On Availability Groups (AG), or a SQL Server listener that spans multiple subnets.
You want the connection string used by SolarWinds Platform services to include MultiSubnetFailover=True to improve connection reliability when failing over between replicas or subnets.

When you run the Configuration Wizard:

Proceed to the Database Settings step.
Select the Force-enable multi-subnet failover checkbox.
Complete the wizard as usual.

If the checkbox is selected or the wizard successfully detects SQL Server Always On, the wizard attempts to add MultiSubnetFailover=True to the connection string. If the connection test with this property succeeds, the setting is kept; if it fails, the connection string remains unchanged.

Your selection is saved and reused the next time you run the Configuration Wizard, so you do not need to re-enable the checkbox on every run once it has been set for your environment.

This option is especially important for environments where services such as the Certificate Management Service (CMS) connect through a multi-subnet listener, as it helps prevent scenarios where CMS can no longer connect to the database after maintenance unless MultiSubnetFailover=True is present in the connection string.

Disclaimer: Please note, any content posted herein is provided as a suggestion or recommendation to you for your internal use. This is not part of the SolarWinds software or documentation that you purchased from SolarWinds, and the information set forth herein may come from third parties. Your organization should internally review and assess to what extent, if any, such custom scripts or recommendations will be incorporated into your environment. You elect to use third-party content at your own risk, and you will be solely responsible for the incorporation of the same if any.