MySQL 9.0.0
Source Code Documentation
|
The events contain the actual data that should be shipped from the master to the slave.
Depending on the use, different events are sent.
The first event is either a START_EVENT_V3 or a FORMAT_DESCRIPTION_EVENT while the last event is either a STOP_EVENT or ROTATE_EVENT.
Type | Name | Description |
---|---|---|
int<2> | binlog-version | Version of the binlog format. See Binlog Version |
string[50] | mysql-server version | version of the MySQL Server that created the binlog. The string is evaluated to apply workarounds on the slave. |
int<4> | create-timestamp | seconds since Unix epoch when the binlog was created |
A format description event is the first event of a binlog for binlog Version 4. It described how the other events are laid out.
Type | Name | Description |
---|---|---|
int<2> | binlog-version | Version of the binlog format. See Binlog Version |
string[50] | mysql-server version | version of the MySQL Server that created the binlog. The string is evaluated to apply workarounds on the slave. |
int<4> | create-timestamp | seconds since Unix epoch when the binlog was created |
event-header-length
Length of the Binlog Event Header of next events. Should always be 19.
event type header lengths
a array indexed by binlog-event-type - 1
to extract the length of the event specific header
For mysql-5.5.2-m2 the event specific header lengths are:
Event Name | Header Length | ||
---|---|---|---|
v4 | v3 | v1 | |
Binlog Event Header | 19 | 13 | |
START_EVENT_V3 | 56 | ||
QUERY_EVENT | 13 | 11 | |
STOP_EVENT | 0 | ||
ROTATE_EVENT | 8 | 0 | |
INTVAR_EVENT | 0 | ||
LOAD_EVENT | 18 | ||
SLAVE_EVENT | 0 | ||
CREATE_FILE_EVENT | 4 | ||
APPEND_BLOCK_EVENT | 4 | ||
EXEC_LOAD_EVENT | 4 | ||
DELETE_FILE_EVENT | 4 | ||
NEW_LOAD_EVENT | 18 | ||
RAND_EVENT | 0 | ||
USER_VAR_EVENT | 0 | ||
FORMAT_DESCRIPTION_EVENT | 84 | — | |
XID_EVENT | 0 | — | |
BEGIN_LOAD_QUERY_EVENT | 4 | — | |
EXECUTE_LOAD_QUERY_EVENT | 26 | — | |
TABLE_MAP_EVENT | 8 | — | |
DELETE_ROWS_EVENTv0 | 0 | — | |
UPDATE_ROWS_EVENTv0 | 0 | — | |
WRITE_ROWS_EVENTv0 | 0 | — | |
INCIDENT_EVENT | 2 | — | |
HEARTBEAT_EVENT | 0 | — | |
DELETE_ROWS_EVENTv2 | 10 | — | |
UPDATE_ROWS_EVENTv2 | 10 | — | |
WRITE_ROWS_EVENTv2 | 10 | — |
The event-size
of 0x67
(103
) minus the event-header
length of 0x13
(19
) should match the event type header length of the FORMAT_DESCRIPTION_EVENT 0x54
(84
).
The number of events understood by the master may differ from what the slave supports. It is calculated by:
For mysql-5.5.2-m2 it is 0x1b
(27
).
A STOP_EVENT has not payload or post-header
The rotate event is added to the binlog as last event to tell the reader what binlog to request next.
Type | Name | Description |
---|---|---|
if binlog-version > 1 { | ||
int<8> | position | |
} |
Type | Name | Description |
---|---|---|
string<EOF> | binlog | name of the next binlog |
Type | Name | Description | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
int<2> | type |
|
An artificial event generated by the master. It isn't written to the relay logs.
It is added by the master after the replication connection was idle for x
seconds to update the slave's Seconds_behind_source timestamp in the SHOW REPLICA STATUS output.
It has no payload nor post-header.
Statement Based Replication or SBR sends the SQL queries a client sent to the master AS IS to the slave. It needs extra events to mimic the client connection's state on the slave side.
The query event is used to send text queries through the binlod
Type | Name | Description |
---|---|---|
int<4> | slave_proxy_id | |
int<4> | execution time | |
int<1> | schema length | |
int<2> | error code | |
if binlog-version >= 4 { | ||
int<2> | status_vars length | Number of bytes in the following sequence of status_vars |
} |
Type | Name | Description | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
binary<var> | status-vars | A sequence of status key/value pairs. The key is 1-byte, while the value is dependent on the key
The value of the different status vars are: Bitmask of flags that are usually set with the SET command: SQL_AUTO_IS_NULL FOREIGN_KEY_CHECKS UNIQUE_CHECKS AUTOCOMMIT
Bitmask of flags that are usually set with SET sql_mode:
2 byte autoincrement-increment and 2 byte autoincrement-offset
1 byte length + <length> chars of the cataiog + ‘0‘-char
2 bytes character_set_client + 2 bytes collation_connection + 2 bytes collation_server See Character Set 1 byte length + <length> chars of the timezone. Timezone the master is in.
1 byte length + <length> chars of the catalog.
LC_TIME of the server. Defines how to parse week-, month and day-names in timestamps
character set and collation of the schema a 64bit field ... should only be used in Row Based Replication Events and multi-table updates 4 byte ... 1 byte length + <length> bytes username and 1 byte length + <length> bytes hostname 1 byte count + <count> \0 terminated string 3 byte microseconds | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
binary<var> | schema | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
binary<eof> | query | text of the query |
In Row Based replication the changed rows are sent to the slave which removes side-effects and makes it more reliable. Now all statements can be sent with RBR though. Most of the time you will see RBR and SBR side by side.
LOAD DATA|XML INFILE
is a special SQL statement as it has to ship the files over to the slave too to execute the statement.
A binlog event starts with Binlog Event Header and is followed by a event specific part.
The binlog event header starts each event and is either 13 or 19 bytes long, depending on the Binlog Version
Type | Name | Description |
---|---|---|
int<4> | timestamp | seconds since unix epoch |
int<1> | event_type | See mysql::binlog::event::Log_event_type |
int<4> | server-id | server-id of the originating mysql-server. Used to filter out events in circular replication |
int<4> | event-size | size of the event (header, post-header, body) |
if binlog-version > 1 { | ||
int<4> | log-pos | position of the next event |
int<2> | flags | See Binlog Event Header Flags |