☰

El complemento del protocolo MySQL X no escucha (todos los enrutadores fallaron)

tag-icon • tag-icon windows-7 mysql javascript database node.js
El complemento del protocolo MySQL X no escucha (todos los enrutadores fallaron)

Estoy intentando configurar y probar el protocolo MySQL X (palabras clave relacionadas: MySQLX, X Plugin, XDevAPI, Connector/Node.js) y de alguna manera no funciona como se esperaba.

Estoy ejecutando Windows 7 de 64 bits con un servicio MySQL 5.7. Me aseguré de que el Protocolo X se esté ejecutando y escuchando ejecutando los siguientes comandos (después de instalarShell de 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     |
+----------------------------+----------+--------------------+---------+---------+

Sin embargo, el siguiente comando no genera nada (también verifiqué el resultado manualmente sin grep):

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

Esta es la razón principal por la que publico esto en SuperUser y no en StackOverflow. Creo que no es un error de programación. Para completar, incluiré el pequeño Javascript que he usado para probar mi conexión desde Node.js inspirado enel ejemplo de conexión de base de datos oficial.

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

El resultado es el siguiente:

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

El servidor MySQL se ejecuta como un servicio en mi computadora. La base de datos está funcionando bien. ¿Alguna idea de por qué MySQL cree que el complemento está escuchando, cuando en realidad no es así? ¿O el netstatcomando que ejecuto no es el adecuado para este trabajo? ¿Como puedo solucionar este problema?

Respuesta1

netstaten realidad estaba funcionando bien.

Una forma de comprobar si el complemento Mysqlx estaba escuchando en el puerto en el que se supone que debe escuchar es comprobar las variables de estado de MySQL.

SHOW GLOBAL STATUS

De acuerdo ala referencia oficial de MySQL 5.7Debería haber una variable denominada Mysqlx_portconfigurada en el puerto respectivo. Si está configurado para que UNDEFINEDel enlace haya fallado. Este fue mi caso.

En pocas palabras, desinstalé todo lo que tenía MySQL en su nombre después de exportar mis datos y lo reinstalé.Después de eso me aseguré de quevainillaEl servidor escucharía 33060 ahora y lo hizo.

Sin embargo, después de copiar mi Datacarpeta al directorio de datos del nuevo servidor ( C:/ProgramData/MySQL Server 5.7/), dejó de funcionar nuevamente. Restablecí la base de datos nuevamente e importé los datos usando un volcado de SQL. El problema volvió a aparecer.

Necesitaba restaurar mi base de datos anterior, luego exportar solo mis bases de datos (sin , y mysql) syse importarlas en la nueva base de datos para que funcionara correctamente. Parece que hay alguna configuración o datos en las bases de datos del servidor que impiden que Mysqlx funcione correctamente.performance_schemainformation_schema

Consejo profesional para exportar todos los datos: utilice

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

Por lo tanto, también exportará rutinas y desencadenantes. Los usuarios también se perderán, pero hayhilos en internet con explicaciones de como hacerlo. El comando solicitará una contraseña.

Utilice esto para volver a importar:

mysql -u root -p < dump.sql

información relacionada