Failover to the warm standby

Failing over to the warm standby is a manual process.

• You can failover to the warm standby in the event of a systems failure with the primary instance of .
• You may wish to failover even if the primary instance of is healthy in order to perform system maintenance or upgrades without significant downtime.

Failover procedure

Do these steps as the phantom user.

1. If the primary instance of is online, you must stop all services. The warm standby will not take over if it detects that the primary instance is still operating.
   /<PHANTOM_HOME>/bin/stop_phantom.sh
2. SSH to your warm standby instance.
   SSH <username>@<warm_standby_phantom_hostname>
3. Run the setup_warm_standby.pyc script to convert the standby to the primary.
   On instances version 4.6.19142 or newer:
   phenv python /<PHANTOM_HOME>/bin/setup_warm_standby.pyc --standby-mode --convert-to-primary --ignore-package-updates
   On instances version 4.6.18265 or earlier:
   phenv python /<PHANTOM_HOME>/bin/setup_warm_standby.pyc --standby-mode --convert-to-primary
4. Update DNS to resolve the hostname of your instance to the IP address of the new primary.
5. If you are ingesting from external services, you will need to update their configurations to use the new primary. Elasticsearch users will need to manually reindex in Main Menu > Administration > Administration Settings > Search Settings.

After the failover procedure, the warm standby is now the primary instance of . The previous primary should be offline.

Do not reboot or restart Splunk SOAR (On-premises) services on the decommissioned primary. It can lead to two standalone instances of Splunk SOAR (On-premises) polling the same assets, and lead to data loss or other unwanted behavior.