Introduction
Query Attributes are a relatively new feature of the MySQL Protocol. This is availble since MySQL 8.0.23.
Before Query Attributes were introduced there already was already another similar feature: Connetion Attributes, which provides per-connection metadata in the form of key/value pairs.
This is what connection attributes look like:
mysql> SELECT ATTR_NAME, ATTR_VALUE
-> FROM performance_schema.session_connect_attrs
-> WHERE PROCESSLIST_ID=64;Oracle Open World 2016 has just finished in San Francisco and we are now about to embark on Percona Live Europe in Amsterdam. I offered a presentation in San Francisco on the MySQL X protocol, the new protocol that Oracle is using to make the DocumentStore work. This new protocol also allow you to send … Continue reading OOW16 talk – MySQL X protocol – Talking to MySQL directly over the Wire
The post OOW16 talk – MySQL X protocol – Talking to MySQL directly over the Wire first appeared on Simon J Mudd's Blog.
The MySQL server supports a variety of client connection methods. To summarize: you have TCP/IP (v4 and v6) on all OSes (with or without TLS/SSL encryption), Unix Domain Sockets on Unix/Linux, and Named Pipes and/or Shared Memory on Windows.
Each of these connection methods has its own set of pros and cons: speed, security, portability, and ease-of-use.…
Today a little history lesson.
I was on a quest to find the origin of this line in include/mysql_com.h:
#define CLIENT_LONG_PASSWORD 1 /* new more secure passwords */
“new” ? “more secure” ?
These CLIENT_* flags are used between client and
server to negotiate what capabilities they support. It allows the
server to add new features to the protocol and let’s the client
add support for it along the way. MySQL 5.5.x has 21 of these
flags.
But back to CLIENT_LONG_PASSWORD and its wonderful
comment. What would one expect if someone reads “new” and “more
secure”?
new
Well, let’s check the file history:
$ bzr blame include/mysql_com.h
2 bk@work | #define CLIENT_LONG_PASSWORD 1 …I've just started learning MySQL's internals but I've got an idea which I want to convert to a question here, to ask people who are already deeper in it. Is it a bad idea to completeley avoid query parsing on the server side and use a binary protocol instead? This way the client parses the query and could cache the statement structure for further usage or another client API uses a NoSQL approach to send the request data to the server.
Mark Callaghan asks Can a protocol be GPL?, after finding a
disturbing comment in a source file: Any re-implementations of
this protocol must also be under GPL, unless one has got an
license from MySQL AB stating otherwise.
I recall talking with one of the company lawyers about this
matter, and he assured me that the GPL can't be used for a
protocol, and that's why this notice was dropped from MySQL.com
site a few years ago, even before the Sun acquisition.
This is thus an embarrassing piece of ancient history (which will
hopefully be removed soon) that has been in our files for
long time. For how long?
If we get the source trees from the public bazaar …
Wheel of protocol, turn turn turn.
Tell us the lesson that we should learn. (with apologies to
the original source)
Writing a book comes with many challenges. For me, writing a MySQL book for MySQL beginners, who may or may not be database beginners, has fed my compulsion to research and test bizarre interactions.
Today’s lesson is on what protocol is used when connecting to a
local mysqld instance on a non-Windows machine. The
TCP/IP protocol is used by default when connecting on a Windows
machine, and connecting from any operating system to a non-local
mysqld instance. I am assuming the connections are
being made by a command line client such as mysql,
mysqladmin or mysqldump. Connections
made via …