☰

MySQL X Protocol Plugin hört nicht zu (Alle Router sind ausgefallen)

tag-icon • tag-icon windows-7 mysql javascript database node.js
MySQL X Protocol Plugin hört nicht zu (Alle Router sind ausgefallen)

Ich versuche, das MySQL X-Protokoll (verwandte Schlüsselwörter: MySQLX, X-Plugin, XDevAPI, Connector/Node.js) einzurichten und zu testen, und es läuft irgendwie nicht wie erwartet.

Ich verwende Windows 7 64 Bit mit einem MySQL 5.7-Dienst. Ich habe sichergestellt, dass das X-Protokoll ausgeführt wird und zuhört, indem ich die folgenden Befehle ausführte (nach der InstallationMySQL-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     |
+----------------------------+----------+--------------------+---------+---------+

Der folgende Befehl gibt jedoch nichts aus (ich habe die Ausgabe auch manuell ohne geprüft grep):

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

Das ist der Hauptgrund, warum ich dies auf SuperUser und nicht auf StackOverflow poste. Ich denke, es ist kein Programmierfehler. Der Vollständigkeit halber werde ich das kleine Javascript einschließen, das ich verwendet habe, um meine Verbindung von Node.js zu testen, inspiriert vondas offizielle Datenbankverbindungsbeispiel.

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

Die Ausgabe ist wie folgt:

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

Der MySQL-Server läuft als Dienst auf meinem Computer. Die Datenbank funktioniert einwandfrei. Irgendwelche Ideen, warum MySQL denkt, dass das Plugin zuhört, obwohl es das in Wirklichkeit nicht tut? Oder ist der netstatBefehl, den ich ausführe, nicht der richtige für diesen Job? Wie kann ich dieses Problem beheben?

Antwort1

netstathat eigentlich gut funktioniert.

Eine Möglichkeit zu prüfen, ob das Mysqlx-Plugin auf dem vorgesehenen Port lauscht, besteht in der Überprüfung der MySQL-Statusvariablen.

SHOW GLOBAL STATUS

Entsprechenddie offizielle MySQL 5.7-ReferenzEs sollte eine Variable namens „ Mysqlx_portset“ für den entsprechenden Port vorhanden sein. Wenn sie auf gesetzt ist, UNDEFINEDist die Bindung fehlgeschlagen. Das war bei mir der Fall.

Kurz gesagt, ich habe nach dem Exportieren meiner Daten alles deinstalliert, was MySQL im Namen hatte, und es dann neu installiert.Danach habe ich dafür gesorgt, dass dieVanilleDer Server würde jetzt auf 33060 hören, und das tat er.

Nachdem ich meinen Ordner jedoch Datain das Datenverzeichnis des neuen Servers ( C:/ProgramData/MySQL Server 5.7/) kopiert hatte, funktionierte es wieder nicht mehr. Ich setzte die Datenbank erneut zurück und importierte die Daten mithilfe eines SQL-Dumps. Das Problem trat erneut auf.

Ich musste meine alte Datenbank wiederherstellen, dann nur meine Datenbanken (ohne mysql, sys, performance_schemaund information_schema) exportieren und sie in die neue Datenbank importieren, damit sie richtig funktioniert. Es scheint, dass es in den Serverdatenbanken eine Einstellung oder Daten gibt, die verhindern, dass Mysqlx richtig funktioniert.

Profi-Tipp für den Export aller Daten: Verwenden Sie

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

Es werden also auch Routinen und Trigger exportiert. Benutzer gehen ebenfalls verloren, aber es gibtThreads im Internet mit Erklärungen, wie es gehtDer Befehl fordert zur Eingabe eines Passworts auf.

Zum erneuten Importieren verwenden Sie Folgendes:

mysql -u root -p < dump.sql

verwandte Informationen