> For the complete documentation index, see [llms.txt](https://help.security.gallagher.com/knowledge-hub/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.security.gallagher.com/knowledge-hub/products/cc-software/configure/command-centre-redundancy-and-failover.md).

# Redundancy and failover

Plan Command Centre failover while ensuring only one service instance uses SQL.

**Failover** is the automatic transition to a standby server when the primary fails.

**Switchover** is the same thing done manually. Controllers and doors keep operating and recording events independently when the Command Centre server is unavailable. Gallagher provides a Stratus redundancy solution and supports two DNS-based arrangements. The hard rule across every arrangement: only one Command Centre service instance may talk to the SQL instance at a time.

## Failover vs switchover

* **Failover** is the automatic transition to a redundant or standby server, system, hardware component, or network when the primary fails or terminates unexpectedly.
* **Switchover** performs the same function, but it is a **manual** process that requires human intervention and typically happens with prior notice.

Some sites implement third-party failover or redundancy solutions for their Command Centre servers. Gallagher does **not** provide support for configuring third-party failover software, but can assist with the setup and configuration of the Command Centre software itself.

{% hint style="warning" %}
When a Command Centre server becomes unavailable, controllers and doors continue to operate normally and still record events independently of the server. Loss of the server is loss of central management and live monitoring, not loss of access control at the door.
{% endhint %}

***

## Stratus (Penguin Solutions)

Gallagher provides **Stratus** redundancy solutions for Command Centre servers. The Stratus product line is owned by **Penguin Solutions**. For the specific fault-tolerant options (**ftServer** lockstep hardware, **everRun** and **everRun SplitSite** software fault-tolerance, and **ztC Edge** edge appliance), including part numbers and the ztC Edge support ceiling, see [Penguin Solutions Technologies (Stratus)](/knowledge-hub/products/cc-hardware/resilience-solutions/penguin-solutions-technologies-stratus.md).

***

## Other failover arrangements

### Single SQL server with DNS redirection

This arrangement uses:

* A single SQL server holding the Command Centre databases.
* Two servers with Command Centre services installed, both connected to that SQL database.
* **Only one of the two Command Centre servers may have its services running at a time.**
* DNS servers direct controller and workstation traffic to whichever Command Centre services are running.

How it behaves:

* There must be a mechanism to update the DNS server's records to point network traffic at the active Command Centre services. **This is the site's responsibility to arrange. Command Centre does not have this feature.**
* At no stage may more than one instance of Command Centre services communicate with the SQL instance.
* Controllers take a few minutes to update themselves from the DNS server, then come back online after a transfer between servers.

### Dual mirrored standalone servers

Essentially the same outcome as Stratus/everRun, but with considerably more setup and ongoing maintenance effort:

* Two servers run side by side. One has its Command Centre services **disabled**.
* The SQL databases are **mirrored** between the two servers.
* **At no stage should both servers have the Command Centre services running.**
* A DNS server is needed to control network traffic to the active server.

As above, there must be a site-provided mechanism to update the DNS records to point traffic at the active Command Centre services. Command Centre does not provide this.

***

## The invariant

Across every arrangement above, the single rule that must never be broken: **only one Command Centre service instance may be connected to and running against the SQL instance at any time.** Two live instances against one database is an unsupported and damaging state.

***

🔗 **Related**

* [Penguin Solutions Technologies (Stratus)](/knowledge-hub/products/cc-hardware/resilience-solutions/penguin-solutions-technologies-stratus.md). The supported fault-tolerant hardware and software options.
* [Controllers](/knowledge-hub/products/cc-hardware/controllers.md). Why controllers keep operating when the server is down.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://help.security.gallagher.com/knowledge-hub/products/cc-software/configure/command-centre-redundancy-and-failover.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.