MISP high availability

A database replica protects one layer of a MISP instance, and it is the layer that is easiest to plan for. The harder question is what else must be running, present and consistent on the server that takes over. MISP is built on PHP with CakePHP, MySQL or MariaDB and Redis, so a failover plan that only promotes a replica leaves several components behind. Before any design is approved, the team should write down each stateful dependency, who owns it, and what happens to it during a switch.

Redis is the first gap. It holds queued background jobs and cached state, and neither is captured by a MySQL or MariaDB replica. If the standby starts with an empty or stale Redis, work that was queued on the failed node may be lost or silently skipped, and cached data may be served from a state that no longer matches the database. The team should confirm how the chosen MISP version handles queue recovery after an unplanned loss of Redis, and whether Redis itself is replicated, clustered or rebuilt from scratch on failover. Those are separate decisions with separate risks.

Background workers and file storage are the next two gaps. Workers that process jobs such as imports, exports, correlation and sync must be running on whichever instance accepts traffic, and their configuration must match the primary. Attachments and other stored files live on the filesystem, not in the database, so a standby without a synchronized copy will show events whose attachments are broken or missing. Cron-driven tasks add a further risk: after a switch, a scheduled job may run on both nodes during a split or may not run at all until someone notices. The runbook should name each scheduled task, state where it runs, and define how duplicate or missed runs are detected.

Splitting ingestion from analyst instances changes where data arrives and where it is read. If feeds and submissions land on an ingestion node and analysts query a separate instance, that analyst instance is only as current as the synchronization between them. Analysts may see events that are minutes or hours behind, and a failure in sync can look like an empty or outdated threat picture rather than an outage. This makes sync a continuity mechanism in its own right, with its own health checks: last successful run, lag between instances, rejected or failed items, and whether restored data matches what was published. Confirm with your team which instance is the system of record for each type of data before any failover is tested.

Do not let analysts rely on a MISP high availability design until the team has proven that a failure produces a controlled stop, not silent data loss. The first test is a backup restore. Take the most recent database backup, restore it to a clean host that has no sync connections and no live feeds, and compare event and attribute counts against the production instance at the time the backup was taken. Check the counts per organization and per distribution level as well as the totals. A matching total can hide a restore that dropped the attributes of one partner. Record the backup timestamp, the source host, the MISP version on both sides, and the exact queries used, so the comparison can be repeated after every upgrade.

The second test promotes the database replica and confirms that the application connects to it. Stop writes on the primary, promote the replica, point the application's database settings at the new primary, and then create a test event, an attribute and a tag from the web interface and from the API key of a test user. Confirm that reads and writes succeed and that the old primary cannot accept writes if it comes back. Also confirm that replication lag was zero or near zero before promotion. Any event written to the primary after the replica last received it is lost in this switch, so the team must agree in advance how that gap will be recovered, usually from sync partners or from the feed sources.

The third test covers Redis and the background workers. Queue several jobs, such as a feed pull, a sync push and a bulk attribute import, then stop the worker service during processing and restart it. Confirm that each queued job either completes once or is reported as failed, and that restarting does not repeat an import. Check the event count and the feed item count after the restart against the expected values from a control run. Duplicated events or attributes are a data quality problem that analysts will not notice quickly, so this check needs explicit numbers rather than a visual review.

The fourth test confirms that sharing groups and distribution levels survived the switch. Pick a sample of events that use each distribution level, including sharing group distribution, and verify their settings on the new primary and on the restored host. Confirm that sharing group membership, the organizations inside each group and the sync filtering rules match the pre-test export. Then confirm that a failed sync does not silently drop events: force a sync to a partner that is unreachable, and check that the failure appears in the sync and job logs and that no events are marked as pushed. A failed sync should leave events pending, not removed. Ask your implementation partner or the MISP documentation to confirm exactly which logs and job states record these outcomes in your release.

Safe failure means the service stops accepting writes rather than corrupting data. Define this as a written acceptance criterion before testing. When the database is unavailable, the application should return errors on writes, the workers should stop claiming new jobs, and no partial event should be committed. Record every test in a results log with the date, the tester, the scenario, the expected result, the observed result and the evidence reference, such as a log extract, a count export or a screenshot with a hash. Keep the log with the change record so that auditors and your own compliance team can see that failover was tested, not assumed.

The first duty after launch is watching the components that make the standby useful when the primary fails. Monitor the web tier for response times and error rates on the event, attribute and API endpoints, since analysts, automation and sync partners all reach MISP through them. Track database replication lag between primary and standby, because a standby that is far behind is not a safe promotion target. Watch Redis memory use and queue depth, and confirm that background worker processes are running and draining jobs, since stalled workers can leave sync and feed jobs silently behind. Alert on free disk space for attachments, and on failed sync and feed ingestion jobs. Agree alert thresholds with your operations team and write them into the promotion runbook so on-call staff know what a warning means.

Backups should cover the database, the attachment store, the configuration files, and the keys and certificates that live outside the database. Agree the backup schedule and retention period with your legal, privacy and incident response teams, because retention decides how far back an investigation can reach and what must be deleted under your own policies. Do not treat the standby as a backup. Replication copies mistakes such as an accidental deletion of events or a bad sharing change, so keep separate database backups. Restore tests are what prove the backups work. Choose a cadence your team can sustain, restore into an isolated host, and confirm that the instance starts, that event and attribute counts match expectations, and that sharing groups and user roles came back intact. Record every test in the restore test log.

Upgrades need coordination across three parties: the primary, the standby and the sync partners. MISP 2.5 is the recommended line for new deployments, and releases arrive often. MISP 2.5.47, released on 17 September 2026, introduced a new database migration system with PostgreSQL support, and MISP 2.5.50 followed on 9 October 2026. Read the release notes before each change and confirm whether a migration is involved. Upgrade a staging copy or the standby first, verify migrations and replication, then move the primary in a maintenance window you have announced to partners. Confirm with each sync partner which version they run before the primary changes, because sync between mismatched versions can behave differently. Keep the standby on a compatible version so that a failover does not land on different code.

Five documents need to stay current. The architecture diagram should show the primary, standby, worker and Redis roles, the sync links, and the network paths between them, and it should be redrawn after every structural change. The promotion runbook must name who may promote the standby, the checks to run before and after promotion, and how users and sync partners are redirected. The restore test log records the date, scope, operator and outcome of each test. The contact lists for sync partners should name a technical contact and an out-of-hours contact for each partner, and be checked on a fixed schedule. Each upgrade needs a change record covering the versions involved, the release notes reviewed, test results and rollback steps. Store these documents where the on-call team can reach them during an outage, not only on the primary that may have failed.