20.7.2.1 Event Flags

Event headers for v3 format and up contain event flags in the two flag bytes at position FLAGS_OFFSET = 17. There are comments about these flags in log_event.h, in addition to the remarks in this section.

Current event flags:

  • LOG_EVENT_BINLOG_IN_USE_F = 0x1 (New in 5.0.3)

    Used to indicate whether a binary log file was closed properly. This flag makes sense only for FORMAT_DESCRIPTION_EVENT. It is set when the event is written to the log file. When the log file is closed later, the flag is cleared. (This is the only case when MySQL modifies an already written part of a binary log file).

  • LOG_EVENT_THREAD_SPECIFIC_F = 0x4 (New in 4.1.0)

    Used only by mysqlbinlog (not by the replication code at all) to be able to deal properly with temporary tables. mysqlbinlog displays events from the binary log in printable format, so that you can feed the output into mysql (the command-line interpreter), to achieve incremental backup recovery. But suppose that the binary log is as follows, where two simultaneous threads used temporary tables with the same name (which is allowed because temporary tables are visible only in the thread which created them):

<thread id 1>
CREATE TEMPORARY TABLE t (a INT);
<thread id 2>
CREATE TEMPORARY TABLE t (a INT);

In this case, simply feeding this into mysql will lead to a "table t already exists" error. This is why events that use temporary tables are marked with the flag, so that mysqlbinlog knows it has to set the pseudo_thread_id system variable before, like this:

SET PSEUDO_THREAD_ID=1;
CREATE TEMPORARY TABLE t (a INT);
SET PSEUDO_THREAD_ID=2;
CREATE TEMPORARY TABLE t (a INT);

This way there is no confusion for the server that receives these statements. Always printing SET PSEUDO_THREAD_ID, even when temporary tables are not used, would cause no bug, it would just slow down.

  • LOG_EVENT_SUPPRESS_USE_F = 0x8 (New in 4.1.7)

    Suppresses generation of a USE statement before the actual statement to be logged. This flag should be set for any event that does not need to have the default database set to function correctly, such as CREATE DATABASE and DROP DATABASE. This flag should only be used in exceptional circumstances because it introduces a significant change in behavior regarding the replication logic together with the --binlog-do-db and --replicate-do-db options.

  • LOG_EVENT_UPDATE_TABLE_MAP_VERSION_F = 0x10 (New in 5.1.4)

    Causes the table map version internal to the binary log to be increased after the event has been written to the log.

Obsolete event flags:

  • LOG_EVENT_TIME_F (obsolete as of 4.1.1). This flag was never set.

  • LOG_EVENT_FORCED_ROTATE_F (obsolete as of 4.1.1). This flag was set in events of type ROTATE_EVENT on the master, but was not used for anything useful

They are now commented out in log_event.h and their values are available for reuse or have already been reused. (But see the associated comments in log_event.h for various cautions!)


User Comments
  Posted by Todd Eisenberger on August 29, 2013
There are two additional flags available in MySQL 5.5 (at least in 5.5.31):

/**
@def 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.
*/
#define LOG_EVENT_ARTIFICIAL_F 0x20

/**
@def LOG_EVENT_RELAY_LOG_F

Events with this flag set are created by slave IO thread and written
to relay log
*/
#define LOG_EVENT_RELAY_LOG_F 0x40
Sign Up Login You must be logged in to post a comment.