2-Binlog Event Header

All the binlog events stored in a binary log file have a common structure:

  • an event header
  • event data

Event Header Structure, 19 Bytes

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).

Encrypted Binlog Events

For encrypted binlog events, only the event length is in plaintext and everything else is encrypted.

To decrypt the binlog event:

  • Store the event length in memory
  • Move the timestamp into the event length position
  • Decrypt the whole payload except the first four bytes
  • Move the timestamp back to its original position
  • Copy the original event length back to its position

Regardless of the cipher used to encrypt the binlogs, the encrypted data will be the same size as the original unencrypted event. For events that are encrypted in CBC mode and whose length is not a multiple of the cipher block size, the final partial block is encrypted using a form of residual block termination:

  • Encrypt the current IV of the binlog file in ECB mode
  • XOR the remaining bytes with the encrypted IV

Event Type

Fake Events

These are generated on the fly, never written.

Event Flag

HexEvent flag description

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.


If the query depends on the thread (for example: TEMPORARY TABLE)

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


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.

Events with this flag set are created by slave IO thread and written to relay log

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.

(no description yet)

(no description yet)

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 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.