Analysis and Fix for MySQL Mixed Binlog Format Event Creation Bug

Problem background : In MySQL versions prior to 5.6.29, setting binlog_format=mixed and creating an event that contains sysdate() leads to replication breakage.

Reproduction steps : Using MySQL 5.6.23, the article shows how the issue appears under statement , row , and mixed formats, with screenshots of the STARTS timestamps and binlog files.

Analysis : SystemTap probes were used to trace the calls to Events::create_event , Event_db_repository::create_event , and Event_queue::create_event . The call chain reveals that when sysdate() (a non‑replication‑safe function) is encountered, MySQL invokes set_current_stmt_binlog_format_row_if_mixed() , which switches the statement to row format.

inline void set_current_stmt_binlog_format_row_if_mixed() {
  if ((variables.binlog_format == BINLOG_FORMAT_MIXED) && (in_sub_stmt == 0))
    set_current_stmt_binlog_format_row();
}

The function set_current_stmt_binlog_format_row() simply sets current_stmt_binlog_format = BINLOG_FORMAT_ROW , causing the event creation to generate an extra row‑based entry in mysql.event .

Proposed fix : Modify the event creation code to temporarily set binlog_format to STATEMENT before calling Event_db_repository::create_event , then restore the original format after the operation.

@@ -308,6 +308,7 @@ Events::create_event(THD *thd, Event_parse_data *parse_data, ...)
  ulong save_binlog_format = thd->variables.binlog_format;
  ...
+  thd->variables.binlog_format = BINLOG_FORMAT_STMT;
  if (lock_object_name(...)) {
    ret = true;
    goto err;
  }
  ...
+err:
+  thd->variables.binlog_format = save_binlog_format;

Conclusion : Upgrading to MySQL 5.6.29 or using row binlog format avoids the issue. In mixed mode, non‑safe functions like sysdate() automatically switch to row mode, preventing data inconsistency. Additionally, when enabling event_scheduler on a replica, ensure the slave’s SLAVESIDE_DISABLED setting is considered to avoid unintended writes.