MySQL Shell позволяет работать с различными API и поддерживает указание подключений, как описано в . Вы можете указать подключения, используя строки, похожие на URI, или пары ключ-значение. В AdminAPI они не поддерживаются. В этом документе демонстрируется использование AdminAPI со строками подключения, похожими на URI.

Для операций AdminAPI вы можете подключаться только к экземплярам серверов в InnoDB Cluster с использованием TCP/IP-соединений и классического протокола MySQL. Использование сокетов Unix и именованных каналов не поддерживается для операций AdminAPI, а использование протокола X также не поддерживается для операций AdminAPI. Те же ограничения применяются к подключениям между самими экземплярами серверов.

Например, для подключения как пользователя myuser к экземпляру сервера MySQL по адресу www.example.com на порту 3306 используйте строку подключения:

myuser@www.example.com:3306

Чтобы использовать эту строку подключения с операцией AdminAPI, такой как dba.configureInstance(), необходимо убедиться, что строка подключения интерпретируется как строка. Например, заключив строку подключения в одинарные (') или двойные (") кавычки.

Если вы используете JavaScript-реализацию AdminAPI, то вызовите:

mysql-js> > dba.configureInstance('myuser@www.example.com:3306')

Если вы используете Python-реализацию AdminAPI, вызовите:

mysql-py> dba.configure_instance('myuser@www.example.com:3306')

При запуске MySQL Shell в режиме интерактивного взаимодействия вы будете запрошены о вашем пароле. AdminAPI поддерживает Раздел 4.4, «Подключаемый хранилище паролей» MySQL Shell, и после того, как вы сохраните пароль, который вы использовали для подключения к экземпляру, вам больше не придется его вводить.

MySQL Shell по умолчанию пытается использовать протокол X для подключения к экземпляру сервера. Если вы не указываете тип подключения при создании подключения для операции AdminAPI, MySQL Shell временно создает сеанс для протокола X перед созданием сеанса классического протокола MySQL.

Это поведение не оказывает влияния, если вы подключаетесь к InnoDB Cluster только с двумя вторичными (только для чтения) экземплярами через порт, которым управляет MySQL Router. В этом случае балансировка нагрузки не обрабатывается правильно между двумя экземплярами, и всегда используется один и тот же экземпляр. Чтобы избежать этого побочного эффекта, вы можете явно указать сеанс классического протокола MySQL, добавив опцию --mc или --mysql.

Некоторые операции, открывающие много подключений к серверам, могут выполняться долго, если один или несколько серверов недоступны, например, команда cluster.status(). Временного ограничения подключения может быть недостаточно для получения ответа.

Вы можете использовать параметр конфигурации MySQL Shell dba.connectTimeout для установки значения временного ограничения подключения по умолчанию в секундах для любого сеанса, использующего AdminAPI.