The following examples illustrate how mysqlbinlog displays row
events that specify data modifications. These correspond to
events with the WRITE_ROWS_EVENT, UPDATE_ROWS_EVENT, and
DELETE_ROWS_EVENT type codes. The --base64-output=DECODE-ROWS and
--verbose options may be used to affect row event output.
Suppose that the server is using row-based binary logging and
that you execute the following sequence of statements:
CREATE TABLE t
(
id INT NOT NULL,
name VARCHAR(20) NOT NULL,
date DATE NULL
) ENGINE = InnoDB;
START TRANSACTION;
INSERT INTO t VALUES(1, ´apple´, NULL);
UPDATE t SET name = ´pear´, date = ´2009-01-01´ WHERE id = 1;
DELETE FROM t WHERE id = 1;
COMMIT;
By default, mysqlbinlog displays row events encoded as base-64
strings using BINLOG statements. Omitting extraneous lines, the
output for the row events produced by the preceding statement
sequence looks like this:
shell> mysqlbinlog log_file
...
# at 218
#080828 15:03:08 server id 1 end_log_pos 258 Write_rows: table id 17 flags: STMT_END_F
BINLOG ´
fAS3SBMBAAAALAAAANoAAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBcBAAAAKAAAAAIBAAAQABEAAAAAAAEAA//8AQAAAAVhcHBsZQ==
´/*!*/;
...
# at 302
#080828 15:03:08 server id 1 end_log_pos 356 Update_rows: table id 17 flags: STMT_END_F
BINLOG ´
fAS3SBMBAAAALAAAAC4BAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBgBAAAANgAAAGQBAAAQABEAAAAAAAEAA////AEAAAAFYXBwbGX4AQAAAARwZWFyIbIP
´/*!*/;
...
# at 400
#080828 15:03:08 server id 1 end_log_pos 442 Delete_rows: table id 17 flags: STMT_END_F
BINLOG ´
fAS3SBMBAAAALAAAAJABAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBkBAAAAKgAAALoBAAAQABEAAAAAAAEAA//4AQAAAARwZWFyIbIP
´/*!*/;
To see the row events as comments in the form of 'pseudo-SQL'
statements, run mysqlbinlog with the --verbose or -v option. The
output will contain lines beginning with ###:
shell> mysqlbinlog -v log_file
...
# at 218
#080828 15:03:08 server id 1 end_log_pos 258 Write_rows: table id 17 flags: STMT_END_F
BINLOG ´
fAS3SBMBAAAALAAAANoAAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBcBAAAAKAAAAAIBAAAQABEAAAAAAAEAA//8AQAAAAVhcHBsZQ==
´/*!*/;
### INSERT INTO test.t
### SET
### @1=1
### @2=´apple´
### @3=NULL
...
# at 302
#080828 15:03:08 server id 1 end_log_pos 356 Update_rows: table id 17 flags: STMT_END_F
BINLOG ´
fAS3SBMBAAAALAAAAC4BAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBgBAAAANgAAAGQBAAAQABEAAAAAAAEAA////AEAAAAFYXBwbGX4AQAAAARwZWFyIbIP
´/*!*/;
### UPDATE test.t
### WHERE
### @1=1
### @2=´apple´
### @3=NULL
### SET
### @1=1
### @2=´pear´
### @3=´2009:01:01´
...
# at 400
#080828 15:03:08 server id 1 end_log_pos 442 Delete_rows: table id 17 flags: STMT_END_F
BINLOG ´
fAS3SBMBAAAALAAAAJABAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBkBAAAAKgAAALoBAAAQABEAAAAAAAEAA//4AQAAAARwZWFyIbIP
´/*!*/;
### DELETE FROM test.t
### WHERE
### @1=1
### @2=´pear´
### @3=´2009:01:01´
Specify --verbose or -v twice to also display data types and some
metadata for each column. The output will contain an additional
comment following each column change:
shell> mysqlbinlog -vv log_file
...
# at 218
#080828 15:03:08 server id 1 end_log_pos 258 Write_rows: table id 17 flags: STMT_END_F
BINLOG ´
fAS3SBMBAAAALAAAANoAAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBcBAAAAKAAAAAIBAAAQABEAAAAAAAEAA//8AQAAAAVhcHBsZQ==
´/*!*/;
### INSERT INTO test.t
### SET
### @1=1 /* INT meta=0 nullable=0 is_null=0 */
### @2=´apple´ /* VARSTRING(20) meta=20 nullable=0 is_null=0 */
### @3=NULL /* VARSTRING(20) meta=0 nullable=1 is_null=1 */
...
# at 302
#080828 15:03:08 server id 1 end_log_pos 356 Update_rows: table id 17 flags: STMT_END_F
BINLOG ´
fAS3SBMBAAAALAAAAC4BAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBgBAAAANgAAAGQBAAAQABEAAAAAAAEAA////AEAAAAFYXBwbGX4AQAAAARwZWFyIbIP
´/*!*/;
### UPDATE test.t
### WHERE
### @1=1 /* INT meta=0 nullable=0 is_null=0 */
### @2=´apple´ /* VARSTRING(20) meta=20 nullable=0 is_null=0 */
### @3=NULL /* VARSTRING(20) meta=0 nullable=1 is_null=1 */
### SET
### @1=1 /* INT meta=0 nullable=0 is_null=0 */
### @2=´pear´ /* VARSTRING(20) meta=20 nullable=0 is_null=0 */
### @3=´2009:01:01´ /* DATE meta=0 nullable=1 is_null=0 */
...
# at 400
#080828 15:03:08 server id 1 end_log_pos 442 Delete_rows: table id 17 flags: STMT_END_F
BINLOG ´
fAS3SBMBAAAALAAAAJABAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBkBAAAAKgAAALoBAAAQABEAAAAAAAEAA//4AQAAAARwZWFyIbIP
´/*!*/;
### DELETE FROM test.t
### WHERE
### @1=1 /* INT meta=0 nullable=0 is_null=0 */
### @2=´pear´ /* VARSTRING(20) meta=20 nullable=0 is_null=0 */
### @3=´2009:01:01´ /* DATE meta=0 nullable=1 is_null=0 */
You can tell mysqlbinlog to suppress the BINLOG statements for
row events by using the --base64-output=DECODE-ROWS option. This
is similar to --base64-output=NEVER but does not exit with an
error if a row event is found. The combination of
--base64-output=DECODE-ROWS and --verbose provides a convenient
way to see row events only as SQL statements:
shell> mysqlbinlog -v --base64-output=DECODE-ROWS log_file
...
# at 218
#080828 15:03:08 server id 1 end_log_pos 258 Write_rows: table id 17 flags: STMT_END_F
### INSERT INTO test.t
### SET
### @1=1
### @2=´apple´
### @3=NULL
...
# at 302
#080828 15:03:08 server id 1 end_log_pos 356 Update_rows: table id 17 flags: STMT_END_F
### UPDATE test.t
### WHERE
### @1=1
### @2=´apple´
### @3=NULL
### SET
### @1=1
### @2=´pear´
### @3=´2009:01:01´
...
# at 400
#080828 15:03:08 server id 1 end_log_pos 442 Delete_rows: table id 17 flags: STMT_END_F
### DELETE FROM test.t
### WHERE
### @1=1
### @2=´pear´
### @3=´2009:01:01´
Note
You should not suppress BINLOG statements if you intend to
re-execute mysqlbinlog output.
The SQL statements produced by --verbose for row events are much
more readable than the corresponding BINLOG statements. However,
they do not correspond exactly to the original SQL statements
that generated the events. The following limitations apply:
• The original column names are lost and replaced by @N, where
N is a column number.
• Character set information is not available in the binary log,
which affects string column display:
• There is no distinction made between corresponding binary
and nonbinary string types (BINARY and CHAR, VARBINARY
and VARCHAR, BLOB and TEXT). The output uses a data type
of STRING for fixed-length strings and VARSTRING for
variable-length strings.
• For multi-byte character sets, the maximum number of
bytes per character is not present in the binary log, so
the length for string types is displayed in bytes rather
than in characters. For example, STRING(4) will be used
as the data type for values from either of these column
types:
CHAR(4) CHARACTER SET latin1
CHAR(2) CHARACTER SET ucs2
• Due to the storage format for events of type
UPDATE_ROWS_EVENT, UPDATE statements are displayed with
the WHERE clause preceding the SET clause.
Proper interpretation of row events requires the information from
the format description event at the beginning of the binary log.
Because mysqlbinlog does not know in advance whether the rest of
the log contains row events, by default it displays the format
description event using a BINLOG statement in the initial part of
the output.
If the binary log is known not to contain any events requiring a
BINLOG statement (that is, no row events), the
--base64-output=NEVER option can be used to prevent this header
from being written.
