Failover

infrastructure

Failover

Definition

Failover is the automated process by which a redundant or standby system component takes over the responsibilities of a primary component when the primary fails, becomes unreachable, or degrades below acceptable thresholds. The transfer is initiated by a health-detection mechanism (heartbeat, quorum vote, external probe) and must be transparent to clients — meaning that requests in flight are either completed by the standby or retried without manual intervention. Failover is typically characterized by Recovery Time Objective (RTO — how long the switchover takes) and Recovery Point Objective (RPO — how much data may be lost).

Manažerské shrnutí

Failover je v platformě Prismatic přítomen v každé vrstvě, která může spadnout: PostgreSQL (streaming replication s automatickým promote přes Patroni), Meilisearch (active-active cluster), KuzuDB (read-replica fallback), MCP servery (AutoBootOrchestrator restart-on-crash), a samotné BEAM uzly (OTP supervision tree). Manažersky podstatné: failover není záloha — chrání před technickým výpadkem, ale ne před logickou chybou nebo škodlivým úmyslem (ty se replikují do standby i s daty). Pravidelné failover-drills jsou součástí compliance kalendáře (NIS2 vyžaduje testovaný DR plán). Reálná RTO platformy: <30s pro databázové komponenty, <5s pro stateless služby, <100ms pro BEAM supervisor restart.

Operational Context

Architektonické vzory failoveru:

  • Active-passive: primární uzel obsluhuje, sekundární čeká s replikovanou daty. Jednoduché, ale plýtvá kapacitou.
  • Active-active: oba uzly obsluhují, navzájem se zálohují. Vyžaduje konfliktní řešení (CRDT, last-write-wins, consensus).
  • N+1 / N+M: pool standby pro skupinu primárů.

Detekce selhání: heartbeat (TCP keepalive, gRPC health check), quorum vote (Raft, Paxos), external prober (Consul, etcd). Hlavní past je split-brain — síťový partition způsobí, že obě části clusteru se prohlásí za primární. Prevence: fencing (STONITH — Shoot The Other Node In The Head), quorum requirement (kvórum musí mít absolutní většinu, ne jen relativní).

Practical Application

  1. Storage layer: PostgreSQL primary failure → Patroni promotuje synchronní replika za <15s, aplikace přes pgBouncer transparentně reconnectne.
  2. API gateway: prismatic_api stateless instance — load balancer detekuje 5xx burst nebo health-check fail a vyřadí instanci z pool, traffic přechází na zbylé. RTO ~3s.
  3. MCP server pool: AutoBootOrchestrator monitoruje 21 stdio MCP serverů, při crash spustí restart s exponential backoff, dokud server nezačne odpovídat.
  4. BEAM supervisor: každý OTP supervisor implementuje implicitní failover skrze restart strategii (:one_for_one, :rest_for_one, :one_for_all).

References

  • Tanenbaum, A. S. & Van Steen, M. Distributed Systems (3rd ed., 2017)
  • Kleppmann, M. Designing Data-Intensive Applications (O'Reilly, 2017), ch. 5 Replication
  • Patroni Documentation — PostgreSQL High Availability
  • Lamport, L. The Part-Time Parliament (ACM Trans. Comput. Syst., 1998) — Paxos foundational paper

Built with precision. Optimized for AI consumption.

Back to Glossary