vtgate does not implement COM_STATISTICS

[aquarapid]

Pretty minor, but logging in case it comes up:

With the result that you don't get server uptime and anything in server stats when executing "\s" via the mysql client.

E.g.: via "real" MySQL you get something like this (note the uptime and stats at the end):

mysql> \s
--------------
.
.
Connection id:          56
Current database:
Current user:           root@localhost
SSL:                    Not in use
Current pager:          stdout
Using outfile:          ''
Using delimiter:        ;
Server version:         5.7.28-log MySQL Community Server (GPL)
Protocol version:       10
Connection:             Localhost via UNIX socket
Server characterset:    utf8
Db     characterset:    utf8
Client characterset:    latin1
Conn.  characterset:    latin1
UNIX socket:            mysql.sock
Uptime:                 3 min 18 sec

Threads: 25  Questions: 157  Slow queries: 0  Opens: 119  Flush tables: 1  Open tables: 113  Que792

Via vtgate (note no uptime and stats at the end):

mysql> \s
--------------
mysql  Ver 8.0.18 for Linux on x86_64 (Source distribution)

Connection id:          5
Current database:       vt_main
Current user:           vt_app@localhost
SSL:                    Not in use
Current pager:          stdout
Using outfile:          ''
Using delimiter:        ;
Server version:         5.5.10-Vitess MySQL Community Server (GPL)
Protocol version:       10
Connection:             34.70.126.210 via TCP/IP
Server characterset:    utf8
Db     characterset:    utf8
Client characterset:    utf8mb4
Conn.  characterset:    utf8mb4
TCP port:               3306
--------------

If you trace the network, you'll see we just respond with an 1047 error "command handling not implemented yet: 9" to the COM_STATISTICS command.

[lishinho]

when you select user(), it always comes out 'vt_app'. Does it mean we connect to mysqld from using vt_app but not the real client conn name?

[aquarapid]

when you select user(), it always comes out 'vt_app'. Does it mean we connect to mysqld from using vt_app but not the real client conn name?

@lishinho I just saw this comment today; yes; since vttablet is doing connection pooling at the backend, the vtgate username/passwords are unrelated to the actual MySQL usernames/passwords vttablet are using.

[gsphanikumar]

@harshit-gangal Could you please assign this to me. Would like to get started on this.

[harshit-gangal]

@harshit-gangal Could you please assign this to me. Would like to get started on this.

Hi, have you made any progress on it? do you need information or help regarding progress? Or, have you dropped plan to support this?

[Maniktherana]

Hi @harshit-gangal I'm looking to contribute to Vitess. Can I pick this issue up? If so is there any other relevant info that would help?

[harshit-gangal]

You can take this up. Best places would we to understand the request and response for this https://dev.mysql.com/doc/dev/mysql-server/latest/page_protocol_com_statistics.html

and look at other implementation in go/mysql/conn.go:handleNextCommand method

[Maniktherana]

If you trace the network, you'll see we just respond with an 1047 error "command handling not implemented yet: 9" to the COM_STATISTICS command.

@harshit-gangal just to confirm, shouldn't the command be 8? The MySQL docs you referred to state that the associated constant for this command is 0x08

[systay]

Yeah, you would need to add the constant to go/mysql/constants.go, something like:

	ComStatistics = 0x08

[Maniktherana]

@systay figured as much but wouldn't that mean that the unimplemented command in the network trace should be 8?

Specifically referring to the quote in my previous comment

[systay]

Hmm... good point. I misunderstood your question.

If I were you, I would reproduce @aquarapid 's experiment and use wireshark or something like it to see what is going on.

The mysql client does a lot of extra stuff behind the scenes. /s does might not be just sending COM_STATISTICS 🤷

[harshit-gangal]

I agree with @systay, wireshark is best to understand the wire protocol