Failover
Failover is the transfer of service or workload from a failed or unavailable component to a functioning alternate or standby component.
100 SQL Server Mistakes and How to Avoid Them
Failover is the transfer of service from a failed or inactive primary system to a secondary system.
- How it is used
- Supports continuous database service during outages and controlled maintenance by moving workloads between replicas or cluster nodes.
- How deep it goes
- Explains operational trade-offs, failure causes, permissions, encryption, and testing rather than implementation commands or configuration steps.
- Examples
- Uses rolling patching, an overnight ETL workload, and a remote secondary replica that becomes unusably slow after failover.
- What you can do after
- Diagnose/debug with it by testing failover regularly and checking secondary performance, SYSTEM permissions, and encryption compatibility.
Read how 100 SQL Server Mistakes and How to Avoid Them explains failover →
Amazon Web Services in Action, Third Edition: An in-depth guide to AWS
Failover is the process of transferring service responsibility from a failed or unavailable primary component to an available replacement.
- How it is used
- Protects web applications and data services from component, network, or Availability Zone failures.
- How deep it goes
- Explains automatic promotion, DNS redirection, topology election, timing, cost, and cross-zone limitations.
- Examples
- Uses RDS primary-standby databases, Redis clusters, load-balanced virtual machines, and cross-Availability-Zone recovery.
- What you can do after
- Operate/configure AWS architectures that redirect service to healthy replacements after failures.
Read how Amazon Web Services in Action, Third Edition: An in-depth guide to AWS explains failover →
Microsoft Azure in Action
Automatic failover is the automatic transfer of service operation to another region or component when the primary one becomes unavailable.
- How it is used
- Protects database and globally distributed applications from regional outages while reducing downtime and manual intervention.
- How deep it goes
- Explains replication, automatic and manual policies, listeners, graceful switching, and regional priority, but does not detail application retry behavior.
- Examples
- Uses Banning Books database replicas, an Azure SQL failover-group command, and Alpaca-Ma-Bags Cosmos DB regions.
- What you can do after
- Operate/configure replicated Azure databases and Cosmos DB accounts with automatic or prioritized regional failover.
Infrastructure as Code, Patterns and Practices: With examples in Python and Terraform
Failover is the transfer of service traffic or operation from a failing component or environment to a standby replacement.
- How it is used
- Protects business-critical services from infrastructure-change failures by providing a standby environment for traffic cutover.
- How deep it goes
- Defines failover and implements regional traffic weighting, but defers active-active operation to future refactoring.
- Examples
- Uses the sundew deployment, us-central1 and us-west1 environments, Python configuration files, and weighted load-balancer services.
- What you can do after
- Operate/configure a standby environment and redirect production traffic when the active environment fails.
Acing the CCNA Exam: Volume 1 Fundamentals and Protocols
Failover is the transfer of an active network service or role to a standby device after the active device fails.
- How it is used
- Maintains first-hop gateway availability when an active router fails.
- How deep it goes
- Explains takeover, GARP signaling, switch relearning, and host transparency, but not configuration commands.
- Examples
- Uses an R1 hardware failure, R2 takeover, GARP broadcasts, switch-table updates, and gateway 10.0.0.1.
- What you can do after
- Evaluate how FHRP failover preserves host gateway operation and updates switched forwarding paths.
Read how Acing the CCNA Exam: Volume 1 Fundamentals and Protocols explains failover →
PostgreSQL Mistakes and How to Avoid Them
Failover is the transition of service from a failed or unavailable primary system to a replica or alternate system.
- How it is used
- Protects PostgreSQL availability by transferring service from a failed primary to a replicated standby or alternate system.
- How deep it goes
- Explains promotion consequences through replication lag, WAL omission, timeline divergence, rewinding, and network partitions.
- Examples
- Uses a lagging standby, divergent timelines, rewound WAL, and a partitioned primary to illustrate unsafe promotion.
- What you can do after
- Evaluate failover designs and select proven tooling instead of trusting untested manual procedures or custom scripts.
Read how PostgreSQL Mistakes and How to Avoid Them explains failover →
Related concepts
- active-passive configurationused by · An active-passive configuration is an architecture in which one environment serves traffic while a separate environment remains ready to take over after failure or for fallback.
- disaster recoveryused by · Disaster recovery is the planning and execution of processes and capabilities for restoring systems, data, and services after a disruptive event.
- standby taskaddressed by · A standby task is an inactive Kafka Streams task that maintains a replicated state-store copy for faster failover when an active task is reassigned.
- uptimeused by · Uptime is the duration or proportion of a specified period during which a system or service is operational and available to provide its intended function.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.