Table of Contents
- 7.1 InnoDB Cluster Requirements
- 7.2 InnoDB Cluster Limitations
- 7.3 User Accounts for InnoDB Cluster
- 7.4 Deploying a Production InnoDB Cluster
- 7.4.1 Pre-Checking Instance Configuration for InnoDB Cluster Usage
- 7.4.2 Configuring Production Instances for InnoDB Cluster Usage
- 7.4.3 Creating an InnoDB Cluster
- 7.4.4 Adding Instances to an InnoDB Cluster
- 7.4.5 Configuring InnoDB Cluster Ports
- 7.4.6 Using MySQL Clone with InnoDB Cluster
- 7.4.7 Adopting a Group Replication Deployment
- 7.5 Configuring InnoDB Cluster
- 7.5.1 Setting Options for InnoDB Cluster
- 7.5.2 Customizing InnoDB Cluster Member Servers
- 7.5.3 Configuring the Election Process
- 7.5.4 Configuring Failover Consistency
- 7.5.5 Configuring Automatic Rejoin of Instances
- 7.5.6 Configuring the Parallel Replication Applier
- 7.5.7 InnoDB Cluster and Auto-increment
- 7.5.8 InnoDB Cluster and Binary Log Purging
- 7.5.9 Configuring the Group Replication Communication Stack
- 7.6 Securing InnoDB Cluster
- 7.7 Monitoring InnoDB Cluster
- 7.8 Restoring and Rebooting an InnoDB Cluster
- 7.9 Modifying or Dissolving an InnoDB Cluster
- 7.10 Upgrade InnoDB Cluster
- 7.11 MySQL InnoDB Cluster Read Replicas
MySQL InnoDB Cluster provides a complete high availability solution for MySQL. By using AdminAPI, which is included with MySQL Shell, you can easily configure and administer a group of at least three MySQL server instances to function as an InnoDB Cluster.
Each MySQL server instance in an InnoDB Cluster runs MySQL Group Replication, which provides the mechanism to replicate data within an InnoDB Cluster, with built-in failover. AdminAPI removes the need to work directly with Group Replication in an InnoDB Cluster, but for more information see Group Replication which explains the details. You can also configure InnoDB ClusterSet (see Chapter 8, MySQL InnoDB ClusterSet) to provide disaster tolerance for InnoDB Cluster deployments by linking a primary InnoDB Cluster with one or more replicas of itself in alternate locations, such as different datacenters.
MySQL Router can automatically configure itself based on the cluster you deploy, connecting client applications transparently to the server instances. In the event of an unexpected failure of a server instance the cluster reconfigures automatically. In the default single-primary mode, an InnoDB Cluster has a single read-write server instance - the primary. Multiple secondary server instances are replicas of the primary. If the primary fails, a secondary is automatically promoted to the role of primary. MySQL Router detects this and forwards client applications to the new primary. Advanced users can also configure a cluster to have multiple primaries.
The following diagram shows an overview of how the technologies work together:
InnoDB Cluster does not provide support for MySQL NDB Cluster. NDB Cluster
depends on the NDB
storage
engine as well as a number of programs specific to NDB Cluster which
are not furnished with MySQL Server 9.0;
NDB
is available only as part of the MySQL
NDB Cluster distribution. In addition, the MySQL server binary
(mysqld) that is supplied with MySQL Server
9.0 cannot be used with NDB Cluster. For more information
about MySQL NDB Cluster, see MySQL NDB Cluster 9.0.
MySQL Server Using InnoDB Compared with NDB Cluster, provides information
about the differences between the InnoDB
and
NDB
storage engines.