1 of 71

Client/Server Protocol

Understand the MariaDB client/server protocol. This section details how clients communicate with the server, including connection, authentication, query execution, and result set handling.

Client/Server Protocol Overview

Protocol Data Types MariaDB Protocol Differences with MySQL

Client/Server Protocol Documentation

0 - Packet 1 - Connecting 2 - Text Protocol 3 - Binary Protocol (Prepared Statements)4 - Server Response Packets

Replication Protocol Documentation

Protocol Data Types

This page defines the fundamental data types used in the MariaDB client/server protocol, including integers, strings, and binary representations.

List of Possible Types

Unknown type:

0 - Packet

Understand the standard packet structure in the MariaDB protocol, including the packet header, length, sequence number, and payload handling.

Client/server exchanges are done using the following format:

Standard packet

The standard MySQL/MariaDB packet has a 4-byte header and a packet body:

int<3> packet length;
sequence number;
packet body.

Packet length is the length of the packet body. Packet length size cannot be more than 3 bytes length value. The actual length of the packet is calculated as from the 3 bytes as length:

The maximum size of a packet (with all 3 bytes 0xff) is 16777215 , or 2^24-1 or 0xffffff, or 16MB-1 byte.

The sequence number indicates the exchange number when an exchange demands different exchanges. Whenever the client sends a query, the sequence number is set to 0 initially, and is incremented if clients need to split packets.

In more complex situations, when the client and server exchange several packets, for instance, authentication handshake, the rule of thumb for clients is to set sequence number = (last seq.number from received server packet + 1).

Example: Sending a packet COM_PING body has only one byte (0x10):

The server will then return an response with a sequence number of 1.

Packet Splitting

The packet length is 3 bytes, making a maximum size of (2^24 -1) bytes or 16Mbytes-1 byte. But the protocol allows sending and receiving larger data. For those cases, the client can send many packets for the same data, incrementing the sequence number for each packet.

The principle is to split data by chunks of 16M bytes. When the server receives a packet with 0xffffff length, it will continue to read the next packet. In case of a length of exactly 16M bytes, an empty packet must terminate the sequence.

Example: max_allowed_packet is set to a value > to 40M bytes. Sending a 40M bytes packet body: \

First packet:

Second packet:

Third packet:

The client must be aware of the variable value. The server has a buffer to store the body with a maximum size corresponding to this max_allowed_packet value. If the client sends more data than max_allowed_packet size, the socket will be closed.

Note that data of exact size 2^24 -1 byte must be sent in 2 packets, the first one with length prefix 0xffffff, and the second one with length 0 (length byte 0x000000, seqno incremented). Generally, if data length is an exact multiple of 2^24-1, it must always be followed by an empty packet.

Compressed Packet

For slow connections, the packet can be compressed. This is activated after the when the client indicates [[1-connecting-connecting#capabilities|COMPRESS] capability with the server having this functionality, too.

When activated, packets are composed of 7 bytes, a compress header and data. The compression algorithm used is ZLIB, widely available and supported by many languages and runtimes.

compressed packet length;
compression protocol sequence number;
uncompress body length;
compressed body;

Since compress body can contain many "standard packets", compress sequence number is incremented separately from sequence number. If the length of the uncompressed payload exceeds 0xffffff bytes, the uncompressed payload must be sent in several compressed protocol packets.

For small packets, using compression won't be efficient, so the client can choose to send uncompressed data. That is done by setting the compressed packet length to the real length and the uncompressed packet length to 0. (Data must then be uncompressed).

Example: Sending a packet COM_PING body when COMPRESS is enabled. This is 1 byte of data that has then no reason to be compressed, so:

The server returns an response with a compress sequence number of 1, and a sequence number of 1.

Compression Packet Splitting

The server uncompresses data, and then must have the same packet as if there was no compression. If data size needs splitting, it's better to separate compress packet.

_{This page is licensed: CC BY-SA / Gnu FDL}

1 - Connecting

Learn about the connection phase in the client/server protocol. This section details how clients establish initial communication with the server, including handshaking and authentication processes.

Connecting Connecting via caching_sha2_password Connecting via sha256_password

Connecting via caching_sha2_password

This plugin implements the caching_sha2_password authentication method, using an in-memory cache for fast authentication or RSA encryption for full verification.

Overview

Caching SHA256 first sends an SHA256-encrypted password. MySQL server has an in-memory cache of SHA256 key for successful authentication. When a cache hit occurs, the connection is validated, if not, using some more steps to a process similar to .

Caching SHA256 authentication possible exchanges:

Connecting via sha256_password

The sha256_password plugin manages authentication using SHA-256 encryption, supporting both clear text passwords over SSL and RSA encrypted password exchange.

Overview

SHA256 authentication possible exchanges:

if connection use SSL (SSLRequest Packet sent):

2 - Text Protocol

Understand the text protocol in the Server's client/server communication. This section details how SQL commands and results are exchanged as plain text, including command types and packet structures.

COM_DEBUG

This command forces the server to dump debug information to the standard output or log, requiring the SUPER privilege.

The COM_DEBUG command forces the server to dump debug information to stdout. It requires the privilege.

Fields

0xOD : COM_DEBUG

COM_DROP_DB

This command drops an existing database from the server, functionally equivalent to the SQL statement DROP DATABASE.

This command is deprecated and not used by MariaDB connectors any more. Use the SQL statements or instead.

_{This page is licensed: CC BY-SA / Gnu FDL}

COM_FIELD_LIST

This command retrieves a list of fields (columns) for a specified table, similar to the SHOW COLUMNS SQL statement.

This command is deprecated and not used by MariaDB connectors any more. Use the SQL statements SHOW COLUMNS or SELECT FROM INFORMATION_SCHEMA.COLUMNS instead.

Fields

0x04 : COM_FIELD_LIST header.
Table name.
Optional field list.

Response

zero or more .
.

_{This page is licensed: CC BY-SA / Gnu FDL}

COM_INIT_DB

This command selects the default database for the current connection, functionally equivalent to the USE statement.

COM_INIT_DB is used to specify the default schema for the connection.

Fields

0x02 : COM_INIT_DB

COM_PING

This command checks if the server is alive and reachable, the server responds with an OK packet if it is running.

COM_PING permits sending a packet containing one byte to check that the connection is active.

Fields

0x0e : COM_PING header.

COM_PROCESS_KILL

This command asks the server to terminate a specific connection thread, functionally equivalent to the KILL statement.

Forces the server to terminate a specified connection.

Fields

0xC COM_PROCESS_KILL.

COM_PROCESSLIST

This command retrieves a list of active threads and their current status, similar to the SHOW PROCESSLIST statement.

This command is deprecated and not used by MariaDB connectors any more. Use the SQL statement SHOW PROCESSLIST instead.

_{This page is licensed: CC BY-SA / Gnu FDL}

COM_QUIT

This command instructs the server to close the connection and release associated resources.

Using the COM_QUIT command, the client tells the server that the connection should be terminated.

Fields

0x01 : COM_QUIT

COM_SET_OPTION

This command configures client-specific options for the current connection, such as enabling or disabling multi-statements.

Enables or disables server option.

Fields

0x1B COM_SET_OPTION .

COM_SLEEP

This is an internal command used to represent a sleeping connection that is waiting for a new command from the client.

This command is used inside the server only.

Direction

Used inside server only.

COM_STATISTICS

This command retrieves a human-readable string containing internal server statistics like uptime and thread counts.

Get internal server statistics.

Fields

0x09 : COM_STATISTICS header.

COM_STMT_CLOSE

This command deallocates a prepared statement on the server, freeing up associated resources.

Closes a previously prepared statement.

Direction

Client to server.

Implemented by

Fields

0x19 COM_STMT_CLOSE header.
statement id.

Example

05 00 00 00 19 04 00 00 00

Response

No response from server.

_{This page is licensed: CC BY-SA / Gnu FDL}

COM_STMT_FETCH

This command fetches rows from an existing result set of a prepared statement that was executed with a cursor.

Fetch rows from a prepared statement.

A with a non-zero cursor flag must have been successfully executed before any COM_STMT_FETCH commands can be executed.

Fields

0x1C COM_STMT_FETCH header.

COM_STMT_RESET

This command resets the data of a prepared statement on the server, clearing any buffers or previous parameter values.

Resets a prepared statement on the client and server to state after preparing.

Fields

int<1> 0x1A COM_STMT_RESET header.
Statement ID.

Response

or .

Example

_{This page is licensed: CC BY-SA / Gnu FDL}

COM_STMT_SEND_LONG_DATA

This command sends long data, such as BLOB or TEXT values, in chunks for a specific parameter of a prepared statement.

When data for a specific column is large, it can be sent separately to avoid the limitation of max_allowed_packet (see ).

Multiple COM_STMT_SEND_LONG_DATA commands with the same column ID append the data. COM_STMT_SEND_LONG_DATA is sent before .

Fields

Server Response Packets (Binary Protocol)

This section details the structure of response packets sent by the server when using the binary protocol, particularly for result sets.

4 - Server Response Packets

Understand server response packets in MariaDB's client/server protocol. This section details the various types of packets sent by the server, including OK, Error, and Result Set packets.

EOF_Packet

The EOF_Packet marks the end of a result set or a sequence of packets, containing warning counts and server status flags.

The EOF_Packet marks the end of a result set, and returns status and warnings.

When testing for an EOF packet, the packet size must be less than 9 bytes in length. The result set can send data that begin with a 0xfe byte, but then the packet length will be greater than 9.

Fields

ERR_Packet

The ERR_Packet is sent by the server to report an error, containing a numeric error code, SQL state marker, and a human-readable error message.

ERR_Packet indicates that an error occurred.

Fields

int<1> ERR_Packet header = 0xFF.
error code. see .
If (error code == 0xFFFF) /* progress reporting */:
- stage.
- max_stage.
- progress.
Else:
- If (next byte = '#'):
  - sql state marker '#'.
  - sql state.

Note that the ERR_Packet is supposed to send a server error to the client. In particular, all error codes in the range 2000 to 2999 and 5000 to 5999 (inclusive) are reserved for client errors and an ERR packet with such an error code will be considered malformed.

LOCAL_INFILE_Packet

The LOCAL_INFILE_Packet is sent by the server to request a file from the client during the execution of a LOAD DATA LOCAL INFILE statement.

If the client sends a LOAD DATA LOCAL INFILE statement via , the server responds with LOCAL_INFILE_Packet to tell the client to send a specified file to the server.

Fields

Replication Protocol

Understand the replication protocol. This section details how primary and replica servers communicate, exchanging binary log events to ensure data consistency and enable high availability.

ANNOTATE_ROWS_EVENT

This event accompanies row-based events to provide the original SQL query text, which is useful for auditing and debugging replication.

ANNOTATE_ROWS_EVENT events accompany row events and describe the query which caused the row event.

You can enable this with --binlog-annotate-row-events (default on).

In the binary log, each ANNOTATE_ROWS event precedes the corresponding Table map event.

For additional information refer to the annotate_rows_log_event documentation.

The master server sends ANNOTATE_ROWS_EVENT events only if the replica server connects with the BINLOG_SEND_ANNOTATE_ROWS_EVENT flag (value is 2) in the COM_BINLOG_DUMP replica registration phase.

Header

Event Type is 160 (0xa0).

Fields

The SQL statement (not null-terminated).

Complete Example with CRC32

_{This page is licensed: CC BY-SA / Gnu FDL}

BEGIN_LOAD_QUERY_EVENT

Used during LOAD DATA INFILE operations, this event marks the beginning of the data load and contains the initial query information.

This event is written to the binary log file for events if the server variable binlog_mode is set to "STATEMENT".

Header

Event Type = 0x11.

BINLOG_CHECKPOINT_EVENT

A marker event indicating a checkpoint in the binary log, used to ensure consistency and safe rotation of log files.

Binlog Checkpoint Event, Event Type is 161 (0xa1). This event specifies a binlog file such that XA crash recovery can start from that file.

There can be more than one event in a binlog file.

Header

COM_BINLOG_DUMP

This command is sent by a replica to the primary server to request the start of the binary log event stream from a specific file and position.

This is a command the replica sends to the master after .

The master server sends the from the requested file and position, or if GTID registration is in use, from the GTID value set in the earlier registration phase.

The payload is:

command (COM_BINLOG_DUMP = 0x12).
The requested binlog position.

Fake GTID_LIST event

A synthetic event sent by the master after the initial handshake to inform the replica of its current GTID state, it is not written to the binary log.

This event is sent by master server to the registering replica. It is sent only once, after the .

The fake GTID_LIST event is not written in the binlog file. It's created by the master and sent to newly connected replica before any "real" binlog event.

Fake ROTATE_EVENT

An artificial event sent to the replica to indicate the name of the binary log file on the master, ensuring the replica knows which file is being read.

When a slave server connects to a MariaDB master server, the first binlog event sent is Fake ROTATE_EVENT. This event is similar to , but it's artificial and its purpose is to tell the replica server which the binlog file name of the master is.

This matters when the replica connects with the GTID option (no filename is given) or when using file and pos with empty file name (usually file='' and pos = 4).

The Event Type is ROTATE_EVENT (0x4).

The fake

HEARTBEAT_LOG_EVENT

A heartbeat event sent over the network by the master when there are no binlog events, ensuring the replica knows the connection is still active.

This event does not appear in the . It's only sent over the network by a master to a replica server to let it know that the master is still alive, and is only sent when the master has no binlog events to send to replica servers.

This event is never written to the binary log file.

Header

INTVAR_EVENT

This event records integer values for auto-increment columns or the LAST_INSERT_ID function, ensuring that these values are replicated deterministically.

An INTVAR_EVENT is written every time a statement uses an auto increment column or the LAST_INSERT_ID() function.

Header

Event Type is 5

ROWS_EVENT_V1/V2, ROWS_COMPRESSED_EVENT_V1

These events record row-level changes (WRITE, UPDATE, DELETE) for replication, with versions supporting different column counts and compression.

A ROWS_EVENT_V1 is written for row-based replication if data is inserted, deleted or updated.

A ROWS_EVENT (version 2) is written for row based replication if data is inserted, deleted or updated. MariaDB Server doesn't send version 2 row events.

Event types

Event

Details

Header

WRITE_ROWS_EVENT_V1: Event Type is 23 (0x17).
UPDATE_ROWS_EVENT_V1: Event Type is 24 (0x18).
DELETE_ROWS_EVENT_V1: Event Type is 25 (0x19).

Fields

The table id.
Flags.
If rows_event is version 2:
- Extra data length.

Table id

Table id refers to a table defined by . The special value 0xFFFFFF should have "end of statement flag" (0x0001) set and indicates that table maps can be freed.

Flags

Flag

Details

Extra data length (version 2)

The length of extra data.

Extra data (version 2)

Extra data, length is extra data length -2.

Column Data Formats

The row data is stored in a packed format where each field is encoded in a particular format. The encoding is almost identical to the binary protocol but there are a few differences.

The field metadata is stored in the metadata block of the . The metadata is required to decode the events. The following list shows number of bytes a field uses from the metadata block.

2 bytes
- MYSQL_TYPE_BIT
- MYSQL_TYPE_ENUM
- MYSQL_TYPE_SET

The types that aren't listed here do not store data in the metadata block.

Simple Types

Type

Details

`MYSQL_TYPE_BLOB` and other blob types

Stored as a length-encoded string where the string is preceded by a variable-sized integer that stores the length of the blob. The size of the preceding integer in bytes is stored as a one byte integer in the table metadata that is a part of the table map event.

For example, if the value 4 is stored in the table metadata, the length is stored as a 4 byte integer (for instance, uint32_t) followed by the data.

The exact column_type can be determined by the metadata length:

Length

Type

`MYSQL_TYPE_STRING`, `MYSQL_TYPE_SET` and `MYSQL_TYPE_ENUM`

Stored as a fixed-length string with the length of the string stored in the second byte of the table metadata. All three of these types are stored as MYSQL_TYPE_STRING in the binlog and the real type of the field is stored in the first byte of the metadata.

`MYSQL_TYPE_VARCHAR` and other variable length string types

Stored as a length-encoded string where the string is preceded by a variable-sized integer that stores the length of the string. The field length is stored as a two byte integer in the table metadata.

If the field length is larger than 255, the string length is stored as a two byte integer. If the value is equal to or less than 255, the string length is stored as a one byte integer.

`MYSQL_TYPE_DATETIME`

This field type is only used in MariaDB if the global variable mysql56_temporal_format is set to OFF. Stored as an 8 byte value with the values stored as multiples of 100. This means that the stored value is in the format YYYYMMDDHHMMSS , and can be extracted by repeatedly calculating the remainder of dividing the value by 100 and dividing the value by 100. The following pseudo-code demonstrates extracting the value.

`MYSQL_TYPE_TIME`

This field type is only used in MariaDB if the global variable mysql56_temporal_format is set to OFF. Stored as a 3 byte value with the values stored as multiples of 100. This means that the stored value is in the format HHMMSS and can be extracted in the same way a MYSQL_TYPE_DATETIME is extracted. The following pseudo-code demonstrates extracting the value.

`MYSQL_TYPE_DATETIME2`

Stored as 4-byte value The number of decimals for the fractional part is stored in the table metadata as a one byte value. The number of bytes that follow the 5 byte datetime value can be calculated with the following formula: (decimals + 1) / 2 .

`MYSQL_TYPE_TIME2`

Stored as 3-byte value. The number of decimals for the fractional part is stored in the table metadata as a one byte value. The number of bytes that follow the 3 byte time value can be calculated with the following formula: (decimals + 1) / 2 .

`MYSQL_TYPE_TIMESTAMP2`

Stored as a 4 byte UNIX timestamp (number of seconds since 00:00, Jan 1 1970 UTC) followed by the fractional second parts. The number of decimals for the fractional part is stored in the table metadata as a one byte value. The number of bytes that follow the 4 byte timestamp can be calculated with the following formula: (decimals + 1) / 2

Microseconds for MYSQL_TYPE_DATETIME2, MYSQL_TYPE_TIME2 , and MYSQL_TYPE_TIMESTAMP .

`MYSQL_TYPE_DATE`

Stored as a 3 byte value where bits 1 to 5 store the day, bits 6 to 9 store the month and the remaining bits store the year.

`MYSQL_TYPE_TIMESTAMP`

Stored as a 4 byte UNIX timestamp (number of seconds since 00:00, Jan 1 1970 UTC).

Example From mysqlbinlog Utility, CRC32

Example Event as Written to the Binlog File

_{This page is licensed: CC BY-SA / Gnu FDL}

Connecting

The connection phase involves an initial handshake where the client and server exchange capabilities, default settings, and authentication data to establish a session.

Overview

Connection is done by many exchanges:

(Create socket)
If first byte from server is 0xFF:
- Packet is an , socket has to be closed.
Else:
- Packet is an .
- If SSL/TLS connection:
  - Client sends and switches to SSL mode for sending and receiving the following messages:

Initial Handshake Packet

protocol version.
server version
- MariaDB Server 10.X versions are by default prefixed "5.5.5-".
- and later versions do not have a "5.5.5-" default prefix.

Client Handshake Response

If the client requests a TLS/SSL connection, the first response is an SSL connection request packet, followed by a handshake response packet. If no TLS is required, client directly sends a handshake response packet.

SSLRequest Packet

client capabilities.
max packet size.
client's default character set and collation.
reserved.

Zero-Configuration SSL Encryption

Automatic Encrypted Connections (+):

Previously, failed SSL connections due to self-signed certificates prevented communication. + introduces a secondary validation method that works for all servers.

What Happens When SSL Validation Fails?

Even without a valid SSL certificate, the connector can still authenticate by remembering the server's fingerprint (unique identifier). However, it needs to confirm the connection is secure.

Verifying a Secure Connection:

The confirmation method depends on the connection type. When using secure MitM-proof methods, like Unix sockets, connector can automatically validate the connection. Otherwise, a shared secret is used.

Shared Secret for Secure Connection:

The shared secret is only used if the authentication plugin password is hashable (for instance, mysql_native_password , client_ed25519, or parsec) and not empty.

It's calculated by hashing the user's hash password with the authentication seed and the server fingerprint.

Password hash is generated depending on authentication plugin:

ed25519 : identical to password encryption.
mysql_native_password : identical to password encryption.
parsec: ext-salt + raw ed25519 public key.

Server 11.4+ Confirmation Details:

For servers running or later, the final confirmation packet contains:

encryption (actually only 0x01 = SHA256 encryption)
shared secret.

Matching the Shared Secret

If the calculated shared secret matches the received one, the SSL connection is considered valid (host validation is not needed). Otherwise, the connection must be closed for security reasons.

Handshake Response Packet

client capabilities.
max packet size.
client's default character set and collation.
reserved.

Server Response to Handshake Response Packet

If the authentication plugin needs further rounds of data exchange (like parsec), the server sends additional plugin authentication data (optionally prefixed with 0x01) to which the client sends an additional response. This can be repeated in multiple rounds. It ends with one of the following:

The server responds with an , an , or an Authentication Switch Request packet.

Authentication Switch Request

(If client and server support CLIENT_AUTH capability):

0xFE : Authentication switch request header.
authentication plugin name.
authentication plugin data.

Plugin List

mysql_old_password Plugin

deprecated — send an 8 byte encrypted password.

Authentication plugin data format:

8-byte seed.

Client response:

old format encrypted password.

mysql_clear_password Plugin

Since password is transmitted in clear, this has been used only when using SSL connection

Send clear password to server.

Client response:

password without encryption.

mysql_native_password Plugin

SHA-1 encrypted password with server seed.

Authentication plugin data format:

seed.

Client response:

SHA1-encrypted password.

The password is encrypted with: SHA1( password ) ^ SHA1( seed + SHA1( SHA1( password ) ) ) .

dialog Plugin (PAM)

Interactive exchanges to permit fill passwords — for example for 2-step authentication.

Authentication plugin data format:

password type.
prompt message.

The server can send one or many requests. For each of them, the client must display this prompt message to the user, to permit the user to type requested information, then send it to the server in format. Password type indicates the answer format (2 means "read the input with the echo enabled", 4 means "password-like input, echo disabled")

First authentication format (from authentication switch packet) can be empty.

This end when the server sends an , or .

auth_gssapi_client Plugin

GSSAPI implementation.

Authentication plugin data format:

serverPrincipalName (UTF-8 format).
mechanisms (UTF-8 format).

Client must exchange packet with server until having a mutual authentication. The only difference compared to standard client-server GSSAPI authentication is that exchanges contain standard protocol with packet headers.

client_ed25519 Plugin

The ed25519 plugin uses the Elliptic Curve Digital Signature Algorithm to securely store users' passwords and to authenticate users.

See .

The server sends a random nonce that the client signs.

authentication plugin data format:

seed.

Client response:

ed25519 encrypted password.

parsec Plugin

Authentication plugin data format:

server nonce.

Client has to send an empty packet to request "ext-salt".

Format of ext-salt is:

'P' (denotes KDF algorithm = PBKDF2).
iteration factor. number of iterations correspond to 1024 << iteration factor (0x0 means 1024, 0x1 means 2048, etc.).
salt.

The client must then:

Generate derived key = hash password with PBKDF2 (sha512 digest) with iteration number and salt from ext-salt.
Generate a client 32 bytes nonce.
Generate the signature with ed25519 of an array concatenation of server nonce + client nonce with the generated derived key as private key.

Client response:

client nonce.
signature.

Capabilities

Server and Client have different capabilities, here is the possibles values. client with capabilities CLIENT_MYSQL + CONNECT_WITH_DB will have a value of 9 (1 + 8).

Capability

Value

Details

Native Password Authentication

The 20-byte string 'seed' is calculated by concatenating scramble first part (8 bytes) and scramble second part from . After that, the client calculates a password hash using the password and seed by using ^ (bitwise xor), + (string concatenation) and SHA1 as follows:

_{This page is licensed: CC BY-SA / Gnu FDL}

Client/Server Protocol

Client/Server Protocol Overview

Client/Server Protocol Documentation

Replication Protocol Documentation

Protocol Data Types

List of Possible Types

0 - Packet

Standard packet

Packet Splitting

Compressed Packet

Compression Packet Splitting

1 - Connecting

Connecting via caching_sha2_password

Overview

Connecting via sha256_password

Overview

2 - Text Protocol

COM_DEBUG

Fields

COM_DROP_DB

COM_FIELD_LIST

Fields

Response

COM_INIT_DB

Fields

COM_PING

Fields

COM_PROCESS_KILL

Fields

COM_PROCESSLIST

COM_QUIT

Fields

COM_SET_OPTION

Fields

COM_SLEEP

Direction

COM_STATISTICS

Fields

COM_STMT_CLOSE

Direction

Implemented by

Fields

Example

Response

COM_STMT_FETCH

Fields

COM_STMT_RESET

Fields

Response

Example

COM_STMT_SEND_LONG_DATA

Fields

Server Response Packets (Binary Protocol)

4 - Server Response Packets

EOF_Packet

Fields

ERR_Packet

Fields

See also

LOCAL_INFILE_Packet

Fields

Replication Protocol

ANNOTATE_ROWS_EVENT

Header

Fields

Complete Example with CRC32

BEGIN_LOAD_QUERY_EVENT

Header

BINLOG_CHECKPOINT_EVENT

Header

COM_BINLOG_DUMP

Fake GTID_LIST event

Fake ROTATE_EVENT

HEARTBEAT_LOG_EVENT

Header

INTVAR_EVENT

Header

Client/Server Protocol

Client/Server Protocol Overview

Client/Server Protocol Documentation