MySQL InnoDB cluster provides a complete high availability solution for MySQL. MySQL Shell includes AdminAPI which enables you to easily configure and administer a group of at least three MySQL server instances to function as an InnoDB cluster. Each MySQL server instance runs MySQL Group Replication, which provides the mechanism to replicate data within InnoDB clusters, with built-in failover. AdminAPI removes the need to work directly with Group Replication in InnoDB clusters, but for more information see Chapter 18, Group Replication which explains the details. 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.
InnoDB cluster does not provide support for MySQL NDB Cluster.
NDB Cluster depends on the
engine as well as a number of programs specific to NDB Cluster which
are not furnished with MySQL Server 8.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
8.0 cannot be used with NDB Cluster. For more
information about MySQL NDB Cluster, see
Chapter 22, MySQL NDB Cluster 8.0.
Section 22.1.6, “MySQL Server Using InnoDB Compared with NDB Cluster”, provides information
about the differences between the
NDB storage engines.
The following diagram shows an overview of how these technologies work together:
MySQL Shell includes the AdminAPI, which is accessed
dba global variable and its
associated methods. The
methods enable you to deploy, configure, and administer InnoDB
clusters. For example, use the
dba.createCluster() method to create an
MySQL Shell enables you to connect to servers over a socket connection, but AdminAPI requires TCP connections to a server instance. Socket based connections are not supported in AdminAPI.
MySQL Shell provides online help for the AdminAPI. To
list all available
dba commands, use the
dba.help() method. For online help on a
specific method, use the general format
object.help('methodname'). For example:
mysql-js> dba.help('getCluster') Retrieves a cluster from the Metadata Store. SYNTAX dba.getCluster([name][, options]) WHERE name: Parameter to specify the name of the cluster to be returned. options: Dictionary with additional options. RETURNS The cluster object identified by the given name or the default cluster. DESCRIPTION If name is not specified or is null, the default cluster will be returned. If name is specified, and no cluster with the indicated name is found, an error will be raised. The options dictionary accepts the connectToPrimary option,which defaults to true and indicates the shell to automatically connect to the primary member of the cluster. EXCEPTIONS MetadataError in the following scenarios: - If the Metadata is inaccessible. - If the Metadata update operation failed. ArgumentError in the following scenarios: - If the Cluster name is empty. - If the Cluster name is invalid. - If the Cluster does not exist. RuntimeError in the following scenarios: - If the current connection cannot be used for Group Replication.
MySQL Shell can optionally log the SQL statements used by AdminAPI operations (with the exception of sandbox operations), and can also display them in the terminal as they are executed. To configure MySQL Shell to do this, see Logging AdminAPI Operations.
One of the core concepts of administering InnoDB cluster is understanding connections to the MySQL instances which make up your cluster. The requirements for connections to the instances when administering your InnoDB cluster, and for the connections between the instances themselves, are:
only TCP/IP connections are supported, using Unix sockets or named pipes is not supported. InnoDB cluster is intended to be used in a local area network, running a cluster of instances connected over a wide area network is not recommended.
only MySQL Classic protocol connections are supported, X Protocol is not supported.Tip
Your applications can use X Protocol, this requirement is for AdminAPI.
MySQL Shell enables you to work with various APIs, and
supports specifying connections as explained in
Section 4.2.5, “Connecting to the Server Using URI-Like Strings or Key-Value Pairs”. The
Additional Connection parameters are not
supported by InnoDB cluster. You can specify connections using
either URI-type strings, or key-value pairs. This documentation
demonstrates AdminAPI using URI-type connection strings.
For example, to connect as the user
myuser to the MySQL server instance
www.example.com, on port
3306 use the connection string:
To use this connection string with an AdminAPI operation
dba.configureInstance(), you need to
ensure the connection string is interpreted as a string, for
example by surrounding the connection string with either single
implementation of AdminAPI issue:
MySQL JS > dba.configureInstance('email@example.com:3306')
Assuming you are running MySQL Shell in the default interactive mode, you are prompted for your password. AdminAPI supports MySQL Shell's Pluggable Password Store, and once you store the password you used to connect to the instance you are no longer prompted for it.