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
at www.example.com
, on port
3306
use the connection string:
myuser@www.example.com:3306
To use this connection string with an AdminAPI operation such
as 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. If you are using the JavaScript
implementation of AdminAPI issue:
MySQL JS > dba.configureInstance('myuser@www.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 Section 4.4, “Pluggable Password Store”, and once you store the password you used to connect to the instance you are no longer prompted for it.
MySQL Shell defaults to trying X Protocol first for a
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 will
briefly create a session for X Protocol, and then create 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 managed by MySQL Router, in which
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 the --mc
or
--mysql
option.
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 cluster.status()
command. The connection timeout may not provide enough time for
a response.
From MySQL Shell 8.0.28, you can use the MySQL Shell
configuration option dba.connectTimeout
to set the
default connection timeout in seconds for any session using
AdminAPI.