MySQL Shell 8.0 Release Notes
Table of Contents
- 9.1 Deploying InnoDB ReplicaSet
- 9.2 Configuring InnoDB ReplicaSet Instances
- 9.3 Creating an InnoDB ReplicaSet
- 9.4 Adding Instances to a ReplicaSet
- 9.5 Adopting an Existing Replication Setup
- 9.6 Changing the Primary Instance
- 9.7 Forcing a New Primary Instance
- 9.8 InnoDB ReplicaSet Locking
- 9.9 Tagging ReplicaSets
- 9.10 Checking the Status of InnoDB ReplicaSet
- 9.11 Upgrade InnoDB ReplicaSet
The AdminAPI includes support for InnoDB ReplicaSet, which enables you to administer a set of MySQL instances similarly running asynchronous GTID-based replication, which is completely transaction-based, to InnoDB Cluster. An InnoDB ReplicaSet consists of single primary and multiple secondaries (traditionally referred to as the MySQL replication source and replicas).
You administer your ReplicaSets using a
ReplicaSet object and the AdminAPI operations,
for example, to check the status of the InnoDB ReplicaSet, and
manually failover to a new primary in the event of a failure.
Similar to InnoDB Cluster, MySQL Router supports bootstrapping against
InnoDB ReplicaSet, which means you can automatically configure
MySQL Router to use your InnoDB ReplicaSet without manually
configuring it. This automatic configuration makes
InnoDB ReplicaSet a quick and easy way to get MySQL replication
and MySQL Router up and running. It makes it suited to scaling out
reads and providing manual failover capabilities
in use cases that do not require the high availability offered by
InnoDB Cluster.
In addition to deploying an InnoDB ReplicaSet using AdminAPI, you can adopt an existing replication setup. AdminAPI configures the InnoDB ReplicaSet based on the topology of the replication setup. Once you have completed the replication setup, you administer it the same way as an InnoDB ReplicaSet deployed from scratch. You can take advantage of AdminAPI and MySQL Router without creating a new ReplicaSet. For more information see Section 9.5, “Adopting an Existing Replication Setup”.
You can use InnoDB ReplicaSet over a Wide Area Network (WAN) with no impact on write performance, as the server instances are connected by asynchronous replication channels and do not need consensus on transactions. However, replication lag is larger over a WAN. This lag causes the secondary servers in the InnoDB ReplicaSet to be further behind the primary server.
InnoDB ReplicaSet Limitations. An InnoDB ReplicaSet has several limitations compared to an InnoDB Cluster. It is recommended that you deploy InnoDB Cluster wherever possible. Generally, an InnoDB ReplicaSet on its own does not provide high availability. Among the limitations of InnoDB ReplicaSet are:
No automatic failover. In events where the primary becomes unavailable, a failover needs to be triggered manually using AdminAPI before any changes are possible again. However, secondary instances remain available for reads.
No protection from partial data loss due to an unexpected halt or unavailability: Transactions that are not complete at the time of the unexpected halt could be lost.
No protection against inconsistencies after an unexpected exit or unavailability. If a manual failover promotes a secondary instance while the former primary is still available, for example, due to a network partition, the split-brain situation could introduce data inconsistencies.
InnoDB ReplicaSet does not support a multi-primary mode. Data consistency cannot be guaranteed with classic replication topologies that allow writes to all members.
Read scale-out is limited. InnoDB ReplicaSet is based on asynchronous replication, and therefore there is no possible tuning of flow control as there is with Group Replication.
All secondary members replicate from a single source. For some particular use-cases, this could impact the single source, for example, numerous small updates.
Only instances running MySQL version 8.0 and later are supported.
Only GTID-based replication is supported, Binary log file position replication is incompatible with InnoDB ReplicaSet.
Only Row-Based Replication (RBR) is supported, Statement-Based Replication (SBR) is unsupported.
Replication filters are not supported.
Unmanaged replication channels are not allowed on any instance.
A ReplicaSet consists of a maximum of one primary instance. One or multiple secondaries are supported. Although there is no limit to the number of secondaries you can add to a ReplicaSet, each MySQL Router connected to a ReplicaSet has to monitor each instance. Therefore, the more instances added to a ReplicaSet, the more monitoring there is.
The ReplicaSet must be managed by MySQL Shell. For example, the replication account is created and managed by MySQL Shell. Making configuration changes to the instance outside MySQL Shell, for example, using SQL statements directly to change the primary instance, is not supported. Always use MySQL Shell to work with InnoDB ReplicaSet.
The main reason to use InnoDB ReplicaSets is you have better write performance. Another reason to use InnoDB ReplicaSets is that they allows deployment on unstable or slow networks, while InnoDB Cluster does not.