Подключаемый модуль протокола MySQL X не прослушивается (все маршрутизаторы не работают)

410
Neon

Я пытаюсь настроить и протестировать протокол MySQL X (связанные ключевые слова: MySQLX, X Plugin, XDevAPI, Connector / Node.js), и он почему-то не работает должным образом.

Я использую 64-битную Windows 7 со службой MySQL 5.7. Я убедился, что протокол X запущен и прослушивается, выполнив следующие команды (после установки MySQL Shell ).

mysqlsh.exe -u root -h localhost --classic --dba enableXProtocol Creating a Classic Session to 'root@localhost' Enter password: ************************ Your MySQL connection id is 14 Server version: 5.7.19-log MySQL Community Server (GPL) No default schema selected; type \use <schema> to set one. enableXProtocol: X Protocol plugin is already enabled and listening for connections on port 33060 
mysqlsh.exe -u root --sqlc -e "show plugins" Enter password: ************************ +----------------------------+----------+--------------------+---------+---------+ | Name | Status | Type | Library | License | +----------------------------+----------+--------------------+---------+---------+ | binlog | ACTIVE | STORAGE ENGINE | null | GPL | | mysql_native_password | ACTIVE | AUTHENTICATION | null | GPL | | sha256_password | ACTIVE | AUTHENTICATION | null | GPL | | CSV | ACTIVE | STORAGE ENGINE | null | GPL | | MEMORY | ACTIVE | STORAGE ENGINE | null | GPL | | InnoDB | ACTIVE | STORAGE ENGINE | null | GPL | | INNODB_TRX | ACTIVE | INFORMATION SCHEMA | null | GPL | | INNODB_LOCKS | ACTIVE | INFORMATION SCHEMA | null | GPL | | INNODB_LOCK_WAITS | ACTIVE | INFORMATION SCHEMA | null | GPL | | INNODB_CMP | ACTIVE | INFORMATION SCHEMA | null | GPL | | INNODB_CMP_RESET | ACTIVE | INFORMATION SCHEMA | null | GPL | | INNODB_CMPMEM | ACTIVE | INFORMATION SCHEMA | null | GPL | | INNODB_CMPMEM_RESET | ACTIVE | INFORMATION SCHEMA | null | GPL | | INNODB_CMP_PER_INDEX | ACTIVE | INFORMATION SCHEMA | null | GPL | | INNODB_CMP_PER_INDEX_RESET | ACTIVE | INFORMATION SCHEMA | null | GPL | | INNODB_BUFFER_PAGE | ACTIVE | INFORMATION SCHEMA | null | GPL | | INNODB_BUFFER_PAGE_LRU | ACTIVE | INFORMATION SCHEMA | null | GPL | | INNODB_BUFFER_POOL_STATS | ACTIVE | INFORMATION SCHEMA | null | GPL | | INNODB_TEMP_TABLE_INFO | ACTIVE | INFORMATION SCHEMA | null | GPL | | INNODB_METRICS | ACTIVE | INFORMATION SCHEMA | null | GPL | | INNODB_FT_DEFAULT_STOPWORD | ACTIVE | INFORMATION SCHEMA | null | GPL | | INNODB_FT_DELETED | ACTIVE | INFORMATION SCHEMA | null | GPL | | INNODB_FT_BEING_DELETED | ACTIVE | INFORMATION SCHEMA | null | GPL | | INNODB_FT_CONFIG | ACTIVE | INFORMATION SCHEMA | null | GPL | | INNODB_FT_INDEX_CACHE | ACTIVE | INFORMATION SCHEMA | null | GPL | | INNODB_FT_INDEX_TABLE | ACTIVE | INFORMATION SCHEMA | null | GPL | | INNODB_SYS_TABLES | ACTIVE | INFORMATION SCHEMA | null | GPL | | INNODB_SYS_TABLESTATS | ACTIVE | INFORMATION SCHEMA | null | GPL | | INNODB_SYS_INDEXES | ACTIVE | INFORMATION SCHEMA | null | GPL | | INNODB_SYS_COLUMNS | ACTIVE | INFORMATION SCHEMA | null | GPL | | INNODB_SYS_FIELDS | ACTIVE | INFORMATION SCHEMA | null | GPL | | INNODB_SYS_FOREIGN | ACTIVE | INFORMATION SCHEMA | null | GPL | | INNODB_SYS_FOREIGN_COLS | ACTIVE | INFORMATION SCHEMA | null | GPL | | INNODB_SYS_TABLESPACES | ACTIVE | INFORMATION SCHEMA | null | GPL | | INNODB_SYS_DATAFILES | ACTIVE | INFORMATION SCHEMA | null | GPL | | INNODB_SYS_VIRTUAL | ACTIVE | INFORMATION SCHEMA | null | GPL | | MyISAM | ACTIVE | STORAGE ENGINE | null | GPL | | MRG_MYISAM | ACTIVE | STORAGE ENGINE | null | GPL | | PERFORMANCE_SCHEMA | ACTIVE | STORAGE ENGINE | null | GPL | | ARCHIVE | ACTIVE | STORAGE ENGINE | null | GPL | | BLACKHOLE | ACTIVE | STORAGE ENGINE | null | GPL | | FEDERATED | DISABLED | STORAGE ENGINE | null | GPL | | partition | ACTIVE | STORAGE ENGINE | null | GPL | | ngram | ACTIVE | FTPARSER | null | GPL | | mysqlx | ACTIVE | DAEMON | mysqlx | GPL | +----------------------------+----------+--------------------+---------+---------+

Однако следующая команда ничего не выводит (я также проверил вывод вручную без grep):

E:\>netstat -a -b | grep 33060

Который является основной причиной, почему я публикую это на SuperUser, а не на StackOverflow. Я думаю, что это не ошибка программирования. Для полноты картины я включу небольшой Javascript, который я использовал для проверки моего соединения из Node.js, вдохновленного официальным примером соединения с базой данных .

const mysqlx = require('@mysql/xdevapi');  async function main() { const session = await mysqlx.getSession({ host: 'localhost', port: 33060, dbUser: 'test', dbPassword: 'test', }); console.log(session); }  main().catch(function (error) { console.log("error caught in main routine\n", error); });

Вывод следующий:

$ node db.js error caught in main routine { Error: All routers failed. at Session._failover (E:\temporary\xdevapi\node_modules\@mysql\xdevapi\lib\DevAPI\Session.js:231:23) at _properties.socketFactory.createSocket.then.then.then.then.catch.err (E:\temporary\xdevapi\node_modules\@mysql\xdevapi\lib\DevAPI\Session.js:271:27) at <anonymous> at process._tickCallback (internal/process/next_tick.js:169:7) errno: 4001 }

Сервер MySQL работает как служба на моем компьютере. База данных работает нормально. Есть идеи, почему MySQL думает, что плагин слушает, а на самом деле это не так? Или netstatкоманда, которую я запускаю, не подходит для этой работы? Как я могу исправить эту проблему?

0

1 ответ на вопрос

0
Neon

netstat на самом деле работал нормально.

Способ проверки, прослушивает ли плагин Mysqlx порт, который он должен прослушивать, - это проверка переменных состояния MySQL.

SHOW GLOBAL STATUS

Согласно официальной ссылке на MySQL 5.7 должна быть переменная с именем, Mysqlx_portустановленной для соответствующего порта. Если он установлен UNDEFINEDна привязку не удалось. Это был случай для меня.

Короче говоря, после экспорта моих данных я удалил все с именем MySQL и переустановил его. После этого я убедился, что сервер vanilla теперь будет слушать 33060, и он это сделал.

Однако после копирования моей Dataпапки в каталог данных нового сервера ( C:/ProgramData/MySQL Server 5.7/) он снова перестал работать. Я снова сбросил базу данных и импортировал данные, используя дамп SQL. Проблема вернулась снова.

Мне нужно было восстановить свою старую базу данных, а затем экспортировать только свои базы данных (без mysql, sys, performance_schemaи information_schema) и импортировать их в новую базу данных, чтобы он работать должным образом. Похоже, что в базах данных сервера есть некоторые настройки или данные, которые мешают Mysqlx работать должным образом.

Профессиональный совет для экспорта всех данных: используйте

mysqldump -u root -p --routines --triggers --databases <database>... > dump.sql

Так что он будет экспортировать процедуры и триггеры, а также. Пользователи также будут потеряны, но в Интернете есть темы с объяснениями, как это сделать . Команда запросит пароль.

Используйте это, чтобы повторно импортировать:

mysql -u root -p < dump.sql

Похожие вопросы