Error Method changeUser not available for MySQL server due to Bug #83472"

[drwharris]

I am calling the following Node code against a MariaDB v10.2 instance running under "Azure Database for MariaDB servers". I am using package version 2.1.5.

    connection.changeUser({ database: dbName }) `
        .catch((error) => {
            reject(`Couldn't switch to it: ${error}`);
        });

But when it executes I am getting the following error in the catch block.

Error: (conn=65412, no: 45003, SQLState: 0A000) method changeUser not available for MySQL server due to Bug #83472
code:"ER_MYSQL_CHANGE_USER_BUG"
errno:45003
fatal:false
message:"(conn=65412, no: 45003, SQLState: 0A000) method changeUser not available for MySQL server due to Bug #83472"
sqlState:"0A000"
stack:"Error: (conn=65412, no: 45003, SQLState: 0A000) method changeUser not available for MySQL server due to Bug #83472\n at Object.module.exports.createError (...\node_modules\mariadb\lib\misc\errors.js:55:10)\n at Connection.changeUser (...\node_modules\mariadb\lib\connection.js:101:16)\n at ...\dist\services\Database\MariaDb.js:89:41\n at processTicksAndRejections (internal/process/task_queues.js:89:5)"
proto:Error {constructor: }

Whats going on here? This works perfectly well when I use "mysql" package against MySQL 8.

EDIT: Interestingly connection.serverVersion() returns "5.6.42.0"
EDIT1: But SELECT VERSION(); return { 'VERSION()': '10.2.29-MariaDB-log' }

Regards

Andrew

[rusher]

Strange this "Azure Database for MariaDB servers" version. They probably force the version to '5.6.42.0'.

Whats going on here? This works perfectly well when I use "mysql" package against MySQL 8.

yes and no : When connecting, Server annonce to connector the capabilities of the server.
If server has the CONNECT_ATTRS capability , "mariadb" connector will enable this capability and send different information on server when creating connection.

This permits to fill performance schema informations and permit to identify clients from server for lots of use case like detect if some client use huge ressources

"mysql" package doesn't enable this capability, and doesn't send anything regarding to that to server.

The problem is that when this capability has been enable, mysql has an issue when changind user. An issue is open and verified MySQL side regarding this : https://bugs.mysql.com/bug.php?id=83472

MariaDB server doesn't have this issue.

That's why connector check if server is a MariaDB server before using changeUser.

Simple workaround If you have acces to server global variables, it would be nice to check that "server" variable and then add '-MariaDB' to it.

[rusher]

thinking more about that, even with wrong "server" version, connector detection must detect correctly mariadb server.

Could you send a connection logs with server
(Just connect to this azure server and close connection with the additionnal "debug: true" connection option)

This will permit to identify why server type identification doesn't works

[drwharris]

@rusher thanks for your response. As requested plus connection.info output.

One other thing to note, I tested this on Azure MySql and got a similar issue so went back to AWS and tested it and its all fine. Seems to be something Azure are doing but no idea what.

<== conn:-1 Handshake.parseHandshakeInit (0,76)
4C 00 00 00 0A 35 2E 36  2E 34 32 2E 30 00 82 FF     L....5.6.42.0...
00 00 FE FE FE FE FE FE  FE FE 00 0F AB 21 02 00     .............!..
3F 00 15 00 00 00 00 00  00 00 00 00 00 FE FE FE     ?...............
FE FE FE FE FE FE FE FE  FE 00 6D 79 73 71 6C 5F     ..........mysql_
6E 61 74 69 76 65 5F 70  61 73 73 77 6F 72 64 00     native_password.

==> conn:65410 Handshake(0,36)
20 00 00 01 02 AB AF 00  00 00 00 40 E0 00 00 00      ..........@....
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00     ................
00 00 00 00                                          ....

==> conn:65410 Handshake(0,100)
60 00 00 02 02 AB AF 00  00 00 00 40 E0 00 00 00     `..........@....
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00     ................
00 00 00 00 74 72 61 63  6B 65 72 5F 61 64 6D 69     ....tracker_admi
6E 40 79 65 6C 6C 6F 77  00 14 D6 97 42 F1 3C 24     n@yellow....B.<$
34 DD 55 89 29 6F 30 BF  3D 6D 93 AC 86 17 6D 79     4.U.)o0.=m....my
73 71 6C 5F 6E 61 74 69  76 65 5F 70 61 73 73 77     sql_native_passw
6F 72 64 00                                          ord.

<== conn:65410 Handshake.handshakeResult (0,44)
2C 00 00 03 FE 6D 79 73  71 6C 5F 6E 61 74 69 76     ,....mysql_nativ
65 5F 70 61 73 73 77 6F  72 64 00 1F 0B 13 56 3B     e_password....V;
60 4F 29 1A 36 02 50 4A  6A 7A 6C 4D 07 48 4E 00     `O).6.PJjzlM.HN.

==> conn:65410 NativePasswordAuth(0,24)
14 00 00 04 0B 8C 8E 5D  C0 61 E6 79 D4 10 C5 B7     .......].a.y....
02 45 00 01 51 A6 E2 AD                              .E..Q...

<== conn:65410 NativePasswordAuth.successSend (0,128)
80 00 00 05 00 00 00 02  00 00 00 78 4C 6F 63 61     ...........xLoca
74 69 6F 6E 3A 20 6D 79  73 71 6C 3A 2F 2F 65 63     tion: mysql://ec
63 32 37 65 34 65 65 61  62 33 2E 74 72 31 32 34     c27e4eeab3.tr124
30 2E 61 75 73 74 72 61  6C 69 61 65 61 73 74 31     0.australiaeast1
2D 61 2E 77 6F 72 6B 65  72 2E 64 61 74 61 62 61     -a.worker.databa
73 65 2E 77 69 6E 64 6F  77 73 2E 6E 65 74 3A 31     se.windows.net:1
36 30 32 33 2F 75 73 65  72 3D 74 72 61 63 6B 65     6023/user=tracke
72 5F 61 64 6D 69 6E 40  65 63 63 32 37 65 34 65     r_admin@ecc27e4e
65 61 62 33                                          eab3

==> conn:65410 Quit(0,5)
01 00 00 00 01                                       .....

ConnectionInformation {threadId: 65410, status: 2, serverVersion: Object, serverCapabilities: 4172559, seed: Buffer(20), …}
clientCapabilities: 11512578
defaultPluginName: "mysql_native_password"
eofDeprecated: false
seed: Buffer(20) [254, 254, 254, …]
serverCapabilities: 4172559
serverVersion: Object {raw: "5.6.42.0", mariaDb: false, major: 5, …}
major: 5
mariaDb: false
minor: 6
patch: 42
raw: "5.6.42.0"
proto: Object {constructor: , defineGetter: , defineSetter: , …}
status: 2
threadId: 65410
proto: Object {constructor: , addPacket: , getLastPackets: , …}

[drwharris]

Something else to add. Not sure if its relevant as its "After" connection is established.

https://docs.microsoft.com/en-us/azure/mariadb/concepts-limits#current-known-issues

MariaDB server instance displays the incorrect server version after connection is established. To get the correct server instance engine version, use the select version(); command.

[rusher]

This is very strange, because initial handshake packet :

<== conn:-1 Handshake.parseHandshakeInit (0,76)
4C 00 00 00 0A 35 2E 36  2E 34 32 2E 30 00 82 FF     L....5.6.42.0...
00 00 FE FE FE FE FE FE  FE FE 00 0F AB 21 02 00     .............!..
3F 00 15 00 00 00 00 00  00 00 00 00 00 FE FE FE     ?...............
FE FE FE FE FE FE FE FE  FE 00 6D 79 73 71 6C 5F     ..........mysql_
6E 61 74 69 76 65 5F 70  61 73 73 77 6F 72 64 00     native_password.

here "0F AB" indicate some server capability. Since 10.2, MariaDB has removed this capability, permitting to drivers to identify server has a mariadb server, and it is enable.

You confirm this debug logs comes from a MariaDB server ?

Connector identify server type properly : it does normally with Server version or capability, but here server version is 5.6.42.0 and capability is wrong ...

[rusher]

ahh, found this : https://docs.microsoft.com/en-us/azure/mariadb/concepts-supported-versions

Note

In the service, a gateway is used to redirect the connections to server instances. After the
connection is established, the MySQL client displays the version of MariaDB set in the gateway, not
the actual version running on your MariaDB server instance. To determine the version of your
MariaDB server instance, use the SELECT VERSION(); command.

So information that driver use are wrong
I've make an option to permit relying on SELECT VERSION(); command then

[drwharris]

@rusher Yes 100% it was a MariaDB. The issue is that SELECT VERSION() on a 10.3 version MariaDB instance returns 8.0.15. Nothing to do with MariaDB. Will that matter?

[rusher]

version 2.2.0 is release with a new option forceVersionCheck that - if enable - will issue a 'SELECT VERSION()' query on connection, not relying on initial handshake information.

This permit to avoid bad information that comes from proxy.

could you take a look and check if this completly solve azure issue ?

[rusher]

closing since issue fixed