High availability for MySQL usually comes down to two mainstream options: MySQL InnoDB Cluster and Galera-based clusters (e.g. Percona XtraDB Cluster, MariaDB Galera Cluster). Both offer multi-node, synchronous (or “virtually” synchronous) replication and automatic failover, but they differ in architecture, tooling and operational trade-offs.

This article compares them from a practical DBA perspective, focusing on behaviour, operations and when to choose which.

1. Architectural overview

1.1 MySQL InnoDB Cluster (Group Replication)

InnoDB Cluster is Oracle MySQL’s integrated HA stack built around Group Replication plus MySQL Router and MySQL Shell.

┌───────────────────────────┐
│       Application         │
│  (uses MySQL Router)     │
└────────────┬─────────────┘
             │
      ┌──────┴──────┐
      │ MySQL Router│
      └──────┬──────┘
             │ RW/RO routing
 ┌───────────┼───────────┐
 │           │           │
▼▼▼         ▼▼▼         ▼▼▼
MySQL       MySQL       MySQL
Instance A  Instance B  Instance C
(Group Replication, InnoDB)

• Core: MySQL Server with InnoDB and Group Replication plugin.
• Topology: Typically 3+ primaries (multi-primary) or 1 primary + 2+ secondaries (single-primary).
• Coordination: Group membership protocol, global transaction identifiers (GTIDs) and consensus for writes.
• Access: MySQL Router handles read/write split and failover transparency.

1.2 Galera Cluster

Galera is a replication library integrated into patched MySQL forks (e.g. Percona XtraDB Cluster, MariaDB with Galera). It provides virtually synchronous multi-primary replication.

┌───────────────────────────┐
│       Application         │
│ (connects via HAProxy /  │
│  ProxySQL / direct)      │
└────────────┬─────────────┘
             │
   ┌─────────┼─────────┐
   │         │         │
 ▼▼▼       ▼▼▼       ▼▼▼
MySQL     MySQL     MySQL
Node 1    Node 2    Node 3
(Galera   (Galera   (Galera
 provider) provider) provider)

• Core: MySQL fork with Galera provider plugin.
• Topology: Multi-primary by default, single-writer enforced via application or proxy if desired.
• Coordination: Certification-based replication; writes are replicated and certified before commit.
• Access: Typically via HAProxy, ProxySQL or application-side logic.

2. Consistency and replication behaviour

2.1 Write consistency

• InnoDB Cluster: Group Replication uses consensus. In single-primary mode, only one node accepts writes, simplifying conflict handling. In multi-primary, conflicts are detected and resolved based on deterministic rules (e.g. primary key conflicts cause errors).
• Galera: All nodes can accept writes. Transactions are replicated and then certified. Conflicting writes are rolled back on commit, so the application must handle deadlocks and certification failures robustly.

Best practice: for both technologies, prefer a single-writer topology for OLTP systems unless you have a very strong reason and well-tested logic for multi-writer patterns.

2.2 Read consistency

• InnoDB Cluster: Secondary nodes may lag slightly. You can control consistency guarantees using group_replication_consistency (e.g. EVENTUAL, BEFORE_ON_PRIMARY_FAILOVER, etc.).
• Galera: Reads are local, but you can enforce causal reads using wsrep_sync_wait and related settings to ensure a node has applied all writes up to a point.

Best practice: for read-after-write critical paths (e.g. authentication), route those queries to the writer or enable strict consistency options and test the performance impact.

3. Failover and topology management

3.1 Automatic failover

• InnoDB Cluster:
  • Group Replication detects failures and elects a new primary in single-primary mode.
  • MySQL Router updates routing automatically using metadata from the cluster.
  • MySQL Shell’s AdminAPI provides commands like dba.createCluster(), cluster.status(), cluster.rejoinInstance().
• Galera:
  • Cluster itself provides membership and flow control, but not external routing.
  • Failover is usually handled by HAProxy/ProxySQL health checks or orchestrators.
  • Manual control is often required for writer election if you enforce single-writer semantics.

Operationally, InnoDB Cluster offers a more integrated stack; Galera offers flexibility at the cost of assembling your own HA tooling.

3.2 Split-brain and quorum

• Both use quorum-based membership and are designed to avoid split-brain by refusing to operate without majority.
• Network partitions can still produce complex scenarios; always plan for how applications behave if a site loses quorum.

Best practice: deploy an odd number of voting nodes (typically 3 or 5) and avoid two-node clusters without an external arbitrator or tie-breaker.

4. Installation and configuration: step-by-step view

4.1 InnoDB Cluster high-level steps

1. Install Oracle MySQL Server, MySQL Shell and MySQL Router on RHEL/Rocky Linux.
2. Configure basic MySQL settings on each node:

   [mysqld]
   server_id               = 1               # unique per node
   log_bin                 = mysql-bin
   binlog_format           = ROW
   gtid_mode               = ON
   enforce_gtid_consistency= ON
   transaction_write_set_extraction = XXHASH64
   loose-group_replication_group_name = "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"
   loose-group_replication_start_on_boot = OFF
   loose-group_replication_local_address = "10.0.0.1:33061"
   loose-group_replication_group_seeds  = "10.0.0.1:33061,10.0.0.2:33061,10.0.0.3:33061"

3. Use MySQL Shell AdminAPI to bootstrap the cluster from one node:

   // In MySQL Shell (JS mode)
   var dba = require('dba');
   var cluster = dba.createCluster('prodCluster');
   cluster.addInstance('root@db2:3306');
   cluster.addInstance('root@db3:3306');
   cluster.switchToSinglePrimaryMode();

4. Deploy MySQL Router pointing at the cluster metadata and use its endpoints for applications.

Note: the above is conceptual; adapt names, users and addresses for your environment and follow vendor documentation for exact commands.

4.2 Galera Cluster high-level steps

1. Install a Galera-enabled MySQL variant (e.g. Percona XtraDB Cluster) on each RHEL/Rocky Linux node.
2. Configure Galera settings in my.cnf:

[mysqld]
server_id       = 1                # unique per node
binlog_format   = ROW
default_storage_engine = InnoDB
innodb_autoinc_lock_mode = 2

wsrep_on        = ON
wsrep_cluster_name = "prodCluster"
wsrep_cluster_address = "gcomm://10.0.0.1,10.0.0.2,10.0.0.3"
wsrep_node_address   = "10.0.0.1"
wsrep_node_name      = "db1"
wsrep_sst_method     = xtrabackup-v2
wsrep_sst_auth       = "sstuser:secret"

3. Bootstrap the first node with a special command (varies by distribution, e.g. systemctl start [email protected]), then start the remaining nodes normally.
4. Place a proxy (HAProxy, ProxySQL) in front of the nodes for health checks, routing and optional single-writer enforcement.

Best practice: always test SST (State Snapshot Transfer) and IST (Incremental State Transfer) paths in a staging environment to ensure backups, firewalls and credentials are correct.

5. Operational characteristics and performance

5.1 Latency and throughput

• Both technologies are sensitive to network latency between nodes; inter-node round trips are on the commit path.
• InnoDB Cluster: consensus-based; single-primary mode often behaves similarly to a well-tuned semi-sync replication but with tighter guarantees.
• Galera: certification overhead and flow control can impact performance under heavy write contention.

Best practice: keep nodes in the same low-latency LAN or availability zone for the main cluster. Use asynchronous replicas for cross-region DR.

5.2 Schema changes and heavy operations

• Online DDL can be expensive in any cluster. Avoid large blocking changes during peak hours.
• Galera historically had more restrictions around some DDL patterns; always check your specific vendor documentation.
• For both, consider rolling schema changes with tools like pt-online-schema-change or application-level migrations.

6. Backups and disaster recovery

• Logical backups (e.g. mysqldump, mysqlpump): usable but slow for large datasets. Run against a non-critical node.
• Physical backups (e.g. Percona XtraBackup, MySQL Enterprise Backup): preferred for large clusters.
  • InnoDB Cluster: treat a node like a normal InnoDB instance for backup; ensure Group Replication is healthy before/after.
  • Galera: often integrated with SST method; you can reuse that tooling for regular backups.
• DR replicas:
  • InnoDB Cluster: common pattern is a separate asynchronous replica or another cluster in a remote site.
  • Galera: same pattern; avoid stretching a single Galera cluster across high-latency WAN links.

7. Choosing between InnoDB Cluster and Galera

7.1 When InnoDB Cluster fits better

• You standardise on Oracle MySQL and want an officially supported, integrated HA stack.
• You prefer single-vendor tooling (Router, Shell, Group Replication) and tighter integration.
• You are comfortable with single-primary semantics and using Router for routing.

7.2 When Galera Cluster fits better

• You already use Percona or MariaDB ecosystems and rely on their tooling.
• You want deep control over proxies (ProxySQL/HAProxy) and are happy composing your own HA stack.
• You have workloads that benefit from multi-primary writes within a low-latency LAN and can handle certification conflicts.

8. Practical best practices for both

• Use 3–5 nodes for quorum; avoid 2-node clusters without an external arbitrator.
• Keep nodes in the same region/zone; use async replicas for geo-distribution.
• Enforce a single writer unless you have a strong, tested reason not to.
• Implement strict health checks in your proxies or Router configuration.
• Monitor replication lag, flow control, conflict/rollback counts and cluster membership.
• Test node failure, network partition and recovery scenarios regularly.
• Automate node provisioning and configuration with configuration management (e.g. Ansible) for repeatability.

Conclusion

InnoDB Cluster and Galera both deliver highly available MySQL, but with different philosophies. InnoDB Cluster focuses on an integrated, Oracle-supported stack with strong single-primary semantics. Galera emphasises multi-primary flexibility and ecosystem diversity, at the cost of more integration work and careful handling of conflicts. Start from your operational constraints, support model and team skills, then prototype both in realistic conditions before standardising on one.

This article offers general technical guidance. Validate all configurations in a safe environment before applying them to production.