MySQL Shell enables you to work with various APIs, and supports specifying connections as explained in Connecting to the Server Using URI-Like Strings or Key-Value Pairs. You can specify connections using either URI-like strings, or key-value pairs. The Additional Connection parameters are not supported in AdminAPI. This documentation demonstrates AdminAPI using URI-like connection strings.
For AdminAPI operations, you can only connect to server instances in an InnoDB Cluster using TCP/IP connections and classic MySQL protocol. The use of Unix sockets and named pipes is not supported for AdminAPI operations, and the use of X Protocol is not supported for AdminAPI operations. The same limitations apply to connections between the server instances themselves.
Client applications can use X Protocol and Unix sockets and named pipes to connect to instances in an InnoDB Cluster. The limitations only apply to administration operations using AdminAPI commands, and to connections between the instances.
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 such
dba.configureInstance(), you need to
ensure the connection string is interpreted as a string. For
example, by surrounding the connection string with either single
(') or double (") quote marks.
mysql-js> > dba.configureInstance('email@example.com:3306')
If you are using the Python implementation of AdminAPI issue:
You are prompted for your password if you are running MySQL Shell in the default interactive mode. AdminAPI supports MySQL Shell's Section 4.4, “Pluggable Password Store”, and once you store the password you used to connect to the instance, you will no longer be prompted for it.
MySQL Shell defaults to trying X Protocol for connection to a server instance. If you do not specify the connection type when you make a connection for an AdminAPI operation, MySQL Shell's automatic protocol detection briefly creates a session for X Protocol, before it creates a classic MySQL protocol session.
The behavior has no effect unless you are connecting to an
InnoDB Cluster with only two secondary (read-only) instances
using a port that a MySQL Router is managing. In this case, load
balancing is not managed correctly between the two instances,
and the same instance is always used. To avoid this side-effect,
you can specify a classic MySQL protocol session explicitly by adding
Certain operations that open many connections to servers can
take a long time to execute when one or more servers are indeed
unreachable, for example, the
command. The connection timeout may not provide enough time for
From MySQL Shell 8.0.28, you can use the MySQL Shell
dba.connectTimeout to set the
default connection timeout in seconds for any session using