Plugin MySQL X Protocol não escutando (todos os roteadores falharam)

Question

Estou tentando configurar e testar o MySQL X Protocol (palavras-chave relacionadas: MySQLX, X Plugin, XDevAPI, Connector / Node.js) e, de alguma forma, ele não é executado como esperado.

Estou executando o Windows 7 64 Bit com um serviço MySQL 5.7. Certifiquei-me de que o X Protocol está sendo executado e escutando executando os seguintes comandos (depois de instalar o 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     |
+----------------------------+----------+--------------------+---------+---------+

No entanto, o comando a seguir não produz nada (também verifiquei a saída manualmente sem grep ):

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

Qual é a principal razão pela qual eu postei isso no SuperUser e não no StackOverflow. Eu acho que não é um erro de programação. Para completar, incluirei o pequeno Javascript que usei para testar minha conexão do Node.js inspirado em o exemplo de conexão oficial do banco de dados .

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

A saída é a seguinte:

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

O servidor MySQL está sendo executado como um serviço no meu computador. O banco de dados está funcionando bem. Alguma idéia porque o MySQL acha que o plugin está escutando, enquanto na verdade não é? Ou o comando netstat não é o correto para esse trabalho? Como posso resolver este problema?

    

Answer 1

netstat estava realmente funcionando bem.

Uma maneira de verificar se o plug-in Mysqlx estava escutando na porta que ele deveria ouvir é verificar as variáveis de status do MySQL.

SHOW GLOBAL STATUS

De acordo com a referência oficial do MySQL 5.7 deve haver uma variável chamada Mysqlx_port definida para a respectiva porta. Se estiver definido como UNDEFINED , a ligação falhou. Este foi o caso para mim.

Resumindo, desinstalei tudo com o MySQL em seu nome depois de exportar meus dados e os reinstalei. Depois disso, certifiquei-me de que o servidor vanilla ouvia o 33060 agora e aconteceu.

No entanto, depois de copiar minha pasta Data para o diretório de dados do novo servidor ( C:/ProgramData/MySQL Server 5.7/ ), ele parou de funcionar novamente. Eu reconfigurei o banco de dados novamente e importei os dados usando um dump SQL. O problema voltou novamente.

Eu precisava restaurar meu banco de dados antigo e exportar apenas meus bancos de dados (sem mysql , sys , performance_schema e information_schema ) e importá-los no novo banco de dados para que ele funcionasse corretamente. Parece que há alguma configuração ou dados nos bancos de dados do servidor que impedem que o Mysqlx funcione corretamente.

Pro dica para exportar todos os dados: use

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

Por isso, também exportará rotinas e acionadores. Os usuários também serão perdidos, mas há tópicos na internet com explicações sobre como fazer isso . O comando solicitará uma senha.

Use isso para reimportar:

mysql -u root -p < dump.sql