MySQL InnoDB Cluster Read Replicas: Adding, Configuring, and Managing Read‑Only Nodes

Introduction

MySQL 8.1.0, the first Innovation release, adds support for read‑only replicas in MySQL InnoDB Cluster. Replica (secondary) nodes provide high availability by taking over when the primary fails and can also offload read traffic from the primary.

Asynchronous replica nodes can be added to the topology for load‑balancing reads, dedicated reporting, or scaling beyond the capacity of existing replicas.

Creating a Read Replica

Adding a read replica uses the same Admin API as adding a regular member. Assuming a running cluster, the command is:

cluster.addReplicaInstance("rome4:3306")

The shell output shows the instance being set up, cloned, and finally added as a read replica of the cluster.

After creation, the replica can be inspected with:

cluster.status()

Operational Principle: Source Node Identification

By default a read replica synchronizes from the primary. If a primary failover occurs, the replica automatically reconnects to the new primary, tracking the primary via MySQL Group Replication (MGR) asynchronous failover mechanisms.

The replica maintains a list of potential source nodes; if the current source goes down, it selects a new one from the list.

Configuring the Read Replica

Replication sources can be customized when adding a replica or later via Cluster.setInstanceOption() . Example adding a replica with a predefined source list:

cluster.addReplicaInstance("rome5:3306", {replicationSources: ["rome2:3306", "rome3:3306"]})

Changing the source of an existing replica:

cluster.setInstanceOption("rome4:3306", "replicationSources", "secondary")

After changing options, the instance must be rejoined:

cluster.rejoinInstance("rome4:3306")

Routing Read Requests to Replicas

MySQL Router directs client traffic to the appropriate target. The read_only_targets option controls which members are used for read‑only traffic:

secondaries : use secondary members only (default)

read_replicas : use only read‑replica members

all : use both secondaries and read replicas

Configuration is done via cluster.setRoutingOption("read_only_targets", "all") or at the Router/ClusterSet level.

Health Checks and Isolation

Router is stateless and relies on InnoDB Cluster metadata. When a replica is part of the cluster, its status may not be visible to Router, so an isolation mechanism is used: after a failed connection attempt, the target is isolated and periodically health‑checked until it can be re‑added.

Replication Lag

Significant lag can be hidden from applications by using Router tags to exclude lagging replicas, allowing upgrades, maintenance, or backup operations without affecting traffic.

Hiding Replicas

Instances can be hidden from Router traffic by setting the built‑in _hidden tag:

cluster.setInstanceOption("rome5:3306", "tag:_hidden", true)

Conclusion

Read‑only replicas extend the scalability of read‑intensive workloads, reduce load on primary nodes, and increase data redundancy while offering flexible configuration and routing options.