Comparing Oracle RAC and MySQL MHA: High‑Availability Architectures Explained

High‑Availability Overview

Oracle has a mature high‑availability solution called MAA, evolving since 9i, while MySQL offers many open‑source options such as MHA, Percona XtraDB Cluster, Galera, and the newer MySQL Group Replication (MGR). The article outlines the basic characteristics of each.

Oracle RAC vs MySQL MHA

Oracle RAC uses expensive commercial storage, multiple network interfaces, and licenses, representing a classic IOE architecture. It requires at least two physical NICs, three IPs per server (public, private, VIP), and shared storage. MySQL MHA, by contrast, runs on commodity hardware, scales horizontally with many nodes, and relies on a manager node to monitor cluster state.

Network Requirements and Failover

Oracle enforces strict network settings, including SCAN IPs (up to three) and Transparent Application Failover (TAF). Failover methods include preconnect (resource‑intensive but smoother) and basic (resource‑light but with brief pause). Failover types can be select (continue query) or session (force reconnect).

racdb=
(DESCRIPTION =
  (ADDRESS = (PROTOCOL=TCP)(HOST=192.168.3.101)(PORT=1521))
  (ADDRESS = (PROTOCOL=TCP)(HOST=192.168.3.201)(PORT=1521))
  (LOAD_BALANCE = yes)
  (FAILOVER = ON)
  (CONNECT_DATA =
    (SERVER=DEDICATED)
    (SERVICE_NAME=racdb)
    (FAILOVER_MODE =
      (TYPE=SELECT)
      (METHOD=BASIC)
      (RETRIES=30)
      (DELAY=5))))

For 11g SCAN‑IP configurations, a simpler description is used:

RACDB =
(DESCRIPTION =
  (ADDRESS = (PROTOCOL=TCP)(HOST=rac-scan)(PORT=1521))
  (CONNECT_DATA =
    (SERVER=DEDICATED)
    (SERVICE_NAME=RACDB)))

MySQL MHA Architecture

MySQL typically requires four IPs for a master‑slave‑VIP‑manager setup (five if a second slave is added). It does not enforce load‑balancing at the database layer; external proxies or application logic handle traffic distribution. Replication is logical, allowing many slaves, but strong consistency is not guaranteed.

Failover in MHA can be triggered by network interruptions, latency spikes, or heartbeat failures. MHA can optionally use binlog servers and integrate with proxies, ZooKeeper, or keepalive for more sophisticated failover handling.

Oracle Data Guard vs MySQL Disaster Recovery

Oracle Data Guard (DG) uses physical standby databases with clear roles (primary/standby) and supports failover and switchover operations. Features like Active Data Guard allow read‑only access on the standby and fast‑switching. MySQL’s disaster recovery relies on asynchronous binlog‑based replication; point‑in‑time recovery is possible via binlog extraction, while true physical standby equivalents are limited.

DG provides a validate command to check switchover readiness, and can preserve active sessions during a switchover. MySQL lacks comparable session‑preserving capabilities.

Performance and Scalability Considerations

Oracle’s shared‑storage architecture incurs higher network and storage costs, and latency can cause split‑brain scenarios. MySQL’s distributed design offers lower inter‑node communication overhead and easier horizontal scaling, though logical replication introduces some delay and potential data loss.

Parallel replication improvements in MySQL 5.7 (table‑level) reduce bottlenecks compared to MySQL 5.6’s database‑level replication.

Outlook and Future Work

Both platforms face common scaling challenges: single‑server limits, large table sizes, read/write imbalance, and complex application changes during scaling. Middleware, sharding, and read‑write splitting are typical remedies.

Conclusion

High‑availability solutions are abundant; Oracle offers a feature‑rich, enterprise‑grade stack with strong consistency, while MySQL provides flexible, open‑source options that excel in scalability and cost‑effectiveness. The optimal choice depends on specific business requirements, budget, and tolerance for complexity.