Standby application host and takeover

What this page covers

The application and the database do not have to live on the same host. A production deployment can use external PostgreSQL, with a second application host pointing at the same database. A second instance that cannot take the single-instance lock does not exit. It waits on the takeover page for the lock to be released. An administrator can also confirm the old host is down on that page and take over, without editing a settings file.

Confirm the original host is down, then take over from standby4 / 4

After takeover and start, the standby becomes the host that serves traffic.

Guard stops itConfirm downNamed confirmationRestore service

PreviousNextStart over

1. At startup the standby does not get the single-instance lock, so it stays on the guard page and serves no traffic until takeover.
2. Operations first confirm the original host has stopped.
3. An administrator re-enters the confirmation code on the standby page and verifies credentials. The takeover is named and recorded.
4. After takeover and start, the standby becomes the host that serves traffic.

Deployment shape

Use docker-compose.external-database.yml so the application talks to external PostgreSQL. Quickstart on an external database does not invent DB_PASSWORD. It keeps the password already on the database. A missing value refuses to start.

When two application hosts point at the same database, only one holds the single-instance lock at a time. While the standby sits on the takeover page it does not run database migrations and it does not write.

The INSTANCE_GUARD_ACK environment-variable path still works for scripted takeover. Takeover from the page does not need a file edit.

How to take over from the page

Before the service is up, unseal and takeover are two columns: status and irreversible warnings on the left, numbered steps on the right. Cooldown or the last failure stays in the same place.

1. The standby sits on the takeover page and shows that it cannot take the lock.
2. Confirm the other application host is down.
3. Re-enter the acknowledgement code.
4. Sign in with a local administrator account.
5. The page finishes takeover. The container does not need a restart.

The action is named and recorded. The confirmation code and administrator check have to pass before it continues.

Where backup, restore, and key material live: Backup and restore, Key management. After a restart in delegated mode, custodian credentials are handed over again on the unseal page. See Key management.

What auditors can see

• Page takeover confirmation and administrator verification are named and recorded.
• While the standby is halted there is no migration and no write.