2-Binlog Event Header
You are viewing an old version of this article. View
the current version here.
All the binlog events stored into a binary log file have a common structure:
- an event header
- event data
Event Header structure, 19 bytes
- uint<4> Timestamp (creation time)
- uint<1> Event Type (type_code)
- uint<4> Server_id (server which created the event)
- uint<4> Event Length (header + data)
- uint<4> Next Event position
- uint<2> Event flags
Note: if CRC32 is in use, the Event Length is 4 bytes bigger in size.
The 4 bytes CRC32 are written at the end of the event (just after the last 'data' byte).
Event type
TO BE DONE
Hex | Event type | description |
---|
Event flag
Hex | Event flag | description |
---|---|---|
0x0001 | LOG_EVENT_BINLOG_IN_USE_F | This flag only makes sense for Format_description_log_event. It is set when the event is written, and *reset* when a binlog file is closed (yes, it's the only case when MySQL modifies already written part of binlog). Thus it is a reliable indicator that binlog was closed correctly. |
0x0002 | LOG_EVENT_FORCED_ROTATE_F | (unused) |
0x0004 | LOG_EVENT_THREAD_SPECIFIC_F | If the query depends on the thread (for example: TEMPORARY TABLE) |
0x0008 | LOG_EVENT_SUPPRESS_USE_F | Suppress the generation of 'USE' statements before the actual statement. This flag should be set for any events that does not need the current database set to function correctly. Most notable cases are 'CREATE DATABASE' and 'DROP DATABASE'. |
0x0010 | LOG_EVENT_UPDATE_TABLE_MAP_VERSION_F | (unused) |
0x0020 | LOG_EVENT_ARTIFICIAL_F | Artificial events are created arbitarily and not written to binary log. These events should not update the master log position when slave SQL thread executes them. |
0x0040 | LOG_EVENT_RELAY_LOG_F | Events with this flag set are created by slave IO thread and written to relay log |
0x0080 | LOG_EVENT_IGNORABLE_F | For an event, 'e', carrying a type code, that a slave, 's', does not recognize, 's' will check 'e' for LOG_EVENT_IGNORABLE_F, and if the flag is set, then 'e' is ignored. Otherwise, 's' acknowledges that it has found an unknown event in the relay log. |
0x0100 | LOG_EVENT_NO_FILTER_F | (no description yet) |
0x0200 | LOG_EVENT_MTS_ISOLATE_F | (no description yet) |
0x8000 | LOG_EVENT_SKIP_REPLICATION_F | Flag set by application creating the event (with @@skip_replication); the slave will skip replication of such events if --replicate-events-marked-for-skip is not set to REPLICATE. This is a MariaDB flag; we allocate it from the end of the available values to reduce risk of conflict with new MySQL flags. |
Event Header example of FORMAT_DESCRIPTION_EVENT
This is the first event in the binlog file at pos 4
a4 85 9e 59 0f 8c 27 00 00 f5 00 00 00 f9 00 00 ...Y..'......... 00 00 00 04 00 31 30 2e 31 2e 32 34 2d 4d 61 72 .....10.1.24-Mar 69 61 44 42 00 6c 6f 67 00 00 00 00 00 00 00 00 iaDB.log.... ... ...
Interpretation of first 19 bytes of the event (the event header)
- a4 85 9e 59 [4] Timestamp => 59 9e 85 a4 => 1503561124 = 2017-08-24 09:52:04
- 0f [1] Event Type = 0x0f = FORMAT_DESCRIPTION_EVENT
- 8c 27 00 00 [4] Server_id => 00 00 27 8c = 10124
- f5 00 00 00 [4] Event length => 00 00 00 f5 => 245
- f9 00 00 00 [4] Next Event pos => 00 00 00 f9 => 249 (pos 4 + event size)
- 00 00 [2] Event flags = 0
Comments
Comments loading...
Content reproduced on this site is the property of its respective owners,
and this content is not reviewed in advance by MariaDB. The views, information and opinions
expressed by this content do not necessarily represent those of MariaDB or any other party.