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

510
Neon

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 läuft und abhört, indem ich die folgenden Befehle ausführt (nach der Installation von 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 | +----------------------------+----------+--------------------+---------+---------+

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

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

Dies ist der Hauptgrund, warum ich dies auf SuperUser und nicht auf StackOverflow poste. Ich denke es ist kein Programmierfehler. Der Vollständigkeit halber füge ich das kleine Javascript hinzu, das ich verwendet habe, um meine Verbindung von Node.js zu testen, das vom offiziellen Datenbankverbindungsbeispiel inspiriert wurde .

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 die folgende:

$ 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 eigentlich nicht der Fall ist? Oder ist der netstatBefehl, den ich ausführte, nicht der richtige für diesen Job? Wie kann ich dieses Problem beheben?

0

1 Antwort auf die Frage

0
Neon

netstat funktionierte eigentlich gut.

Eine Möglichkeit zur Überprüfung, ob das Mysqlx-Plugin den Port abhört, an dem es überwacht werden soll, ist die Überprüfung der MySQL-Statusvariablen.

SHOW GLOBAL STATUS

Gemäß der offiziellen MySQL 5.7-Referenz sollte es eine Variable geben, Mysqlx_portdie auf den jeweiligen Port festgelegt ist. Wenn es auf UNDEFINEDdie Bindung eingestellt ist, ist die Bindung fehlgeschlagen. Das war bei mir der Fall.

Um es kurz zu machen: Ich habe alles mit MySQL im Namen deinstalliert, nachdem ich meine Daten exportiert und neu installiert habe. Danach stellte ich sicher, dass der Vanilla- Server jetzt 33060 hört, und das tat er auch.

Nach dem Kopieren meines DataOrdners in das Datenverzeichnis des neuen Servers ( C:/ProgramData/MySQL Server 5.7/) funktionierte der Ordner jedoch nicht mehr. Ich setze die Datenbank erneut zurück und importierte die Daten mithilfe eines SQL-Dumps. Das Problem kam wieder zurück.

Ich brauchte meine alte Datenbank wiederherzustellen, dann exportieren nur meine Datenbanken (ohne mysql, sys, performance_schemaund information_schema) und sie in der neuen Datenbank zu importieren, um es richtig zu haben zu arbeiten. Anscheinend gibt es Einstellungen oder Daten in den Server-Datenbanken, die verhindern, dass Mysqlx ordnungsgemäß funktioniert.

Pro-Tipp für den Export aller Daten: Verwendung

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

Es werden also auch Routinen und Trigger exportiert. Die Benutzer werden ebenfalls verloren gehen, es gibt jedoch Threads im Internet mit Erklärungen, wie das geht . Der Befehl fordert zur Eingabe eines Kennworts auf.

Verwenden Sie dies zum erneuten Importieren:

mysql -u root -p < dump.sql

Verwandte Probleme