Wtyczka protokołu MySQL X nie nasłuchuje (wszystkie routery uległy awarii)

Próbuję skonfigurować i przetestować protokół MySQL X (powiązane słowa kluczowe: MySQLX, X Plugin, XDevAPI, Connector / Node.js) i jakoś nie działa zgodnie z oczekiwaniami.

Używam 64-bitowego systemu Windows 7 z usługą MySQL 5.7. Upewniłem się, że protokół X działa i nasłuchuje, wykonując następujące polecenia (po zainstalowaniu powłoki MySQL ).

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     |
+----------------------------+----------+--------------------+---------+---------+

Jednak następujące polecenie nic nie wypisuje (sprawdziłem też dane wyjściowe ręcznie bez grep):

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

To jest główny powód, dla którego publikuję to na SuperUser, a nie StackOverflow. Myślę, że to nie błąd programistyczny. Dla kompletności dołączę mały skrypt JavaScript, którego użyłem do przetestowania mojego połączenia z Node.js, zainspirowanego oficjalnym przykładem połączenia z bazą danych .

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); });

Dane wyjściowe są następujące:

$ 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 }

Serwer MySQL działa jako usługa na moim komputerze. Baza danych działa poprawnie. Wszelkie pomysły, dlaczego MySQL uważa, że wtyczka nasłuchuje, a tak naprawdę nie jest? A może netstatpolecenie, które wykonuję, nie jest odpowiednie dla tego zadania? Jak mogę rozwiązać ten problem?

— Neon
źródło

netstat działało dobrze.

Sposobem sprawdzenia, czy wtyczka Mysqlx nasłuchuje na porcie, na którym ma nasłuchiwać, jest sprawdzenie zmiennych stanu MySQL.

SHOW GLOBAL STATUS

Zgodnie z oficjalnym odniesieniem do MySQL 5.7 powinna istnieć zmienna o nazwie Mysqlx_portset dla odpowiedniego portu. Jeśli jest ustawiony, UNDEFINEDwiązanie nie powiodło się. Tak było w moim przypadku.

Krótko mówiąc, odinstalowałem wszystko z MySQL w nazwie po wyeksportowaniu moich danych i ponownej instalacji. Potem upewniłem się, że serwer waniliowy będzie teraz słuchał 33060 i tak też było.

Jednak po skopiowaniu mojego Datafolderu do katalogu danych nowego serwera ( C:/ProgramData/MySQL Server 5.7/) przestał on działać. Ponownie zresetowałem bazę danych i zaimportowałem dane za pomocą zrzutu SQL. Problem wrócił ponownie.

Musiałem przywrócić moją starą bazę danych, a następnie wyeksportować tylko moich baz danych (bez mysql, sys, performance_schemai information_schema) i importować je do nowej bazy danych, aby działać poprawnie. Wygląda na to, że w bazach danych serwera są jakieś ustawienia lub dane, które uniemożliwiają prawidłowe działanie Mysqlx.

Pro wskazówka dotycząca eksportowania wszystkich danych: użyj

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

Więc eksportuje również procedury i wyzwalacze. Użytkownicy również zostaną utraceni, ale w Internecie są wątki z wyjaśnieniami, jak to zrobić . Polecenie wyświetli monit o podanie hasła.

Użyj tego, aby ponownie zaimportować:

mysql -u root -p < dump.sql

— Neon
źródło