How does failover work?
Here is the breakdown of how failover works across the infrastructure:
The Load Balancer is your first line of defense. It constantly performs Health Checks on your backend servers.
Detection: If a server stops responding to a ping (e.g., the application crashes or the VM hangs), the Load Balancer detects this within seconds.
Redirection: It immediately stops sending new requests to the "unhealthy" server and redirects traffic to the remaining "healthy" ones.
Self-Healing Infrastructure: Even the Load Balancer itself has failover. In a multi-AD region, OCI runs a "Primary" load balancer in one data center and a "Standby" in another. If the first data center loses power, the Standby takes over the IP address instantly.
For databases, failover is about data integrity. OCI uses Autonomous Data Guard to handle this.
Local Failover: If your primary database fails, OCI automatically promotes a "standby" database in a different Fault Domain. This typically has an RTO (Recovery Time Objective) of about 2 minutes.
Zero Data Loss: In local configurations, OCI guarantees zero data loss (RPO 0) because the data is written to both the primary and standby simultaneously.
Cross-Region Failover: If a whole region goes dark, you can trigger a failover to a remote region. This is often a manual "one-click" process to prevent "split-brain" scenarios where two regions think they are the leader.
If the physical hardware "underneath" your rented server fails, OCI has two ways to handle it:
Infrastructure Monitoring: OCI monitors the health of the physical host. If it detects a hardware failure, it will automatically attempt to reboot your VM on a different, healthy physical host.
Instance Pools: For web servers, you can use Instance Pools with an Autoscaling Configuration. If one server dies, the pool sees that the "actual count" is lower than the "desired count" and automatically spins up a brand-new server to replace the dead one.
Newer for the 2025/2026 era, the OCI Full Stack Disaster Recovery Service orchestrates the failover of everything at once.
Orchestration: Instead of failing over the database, then the servers, then the DNS, this service runs a "DR Plan."
One-Click Recovery: It handles the correct order of operations: it stops the primary, switches the database role, mounts the storage volumes in the new region, boots the servers, and updates the Load Balancer.
| Service Component | Failover Trigger | Recovery Time (RTO) | Data Loss (RPO) |
| Load Balancer | Health Check Failure | Seconds | None |
| Autonomous DB | Instance/Node Failure | ~2 Minutes | Zero (Local) |
| Compute VM | Host Hardware Failure | 5-10 Minutes (Reboot) | Last Backup / Disk Sync |
| Full Application | Regional Outage | Variable (Orchestrated) | Dependent on Sync |
To failover between entire cloud regions, OCI uses DNS Traffic Management steering policies.
It pings your primary region's public endpoint.
If it fails, the DNS record is automatically updated to point to the "Standby" region.
Because it's at the DNS level, this works even if an entire part of the world experiences a major internet outage.
In the OCI console, you will see both terms.
Switchover: A "planned" event (like maintenance). It’s graceful, ensures all data is synced, and has zero risk of data loss.
Failover: An "unplanned" event (emergency). It prioritizes speed to get the app back online, sometimes accepting a few seconds of data loss to ensure availability.