The SHOW BINLOG EVENTS and SHOW RELAYLOG EVENTS statements read the binary log and relay log, respectively, and return the events matching the arguments. There are four arguments, of which one only applies to relay log events:
• IN: The name of the binary log or relay log file to read events from.
• FROM: The position in bytes to start reading from.
• LIMIT: The number of events to include with an optional offset. The syntax is the same as for SELECT statements: [offset], row_count.
• FOR CHANNEL: For relay logs, the replication channel to read events for.
141 All arguments are optional. If the IN argument is not given, events from the first log are returned. An example of using SHOW BINLOG EVENTS is shown in Listing 8-1. If you want to try the example, you will need to replace the binary log filename, position, and limit.
Listing 8-1. Using SHOW BINLOG EVENTS
mysql> SHOW BINLOG EVENTS IN 'binlog.000049' FROM 195 LIMIT 5\G
*************************** 1. row ***************************
Log_name: binlog.000049 Pos: 195
Event_type: Gtid Server_id: 1 End_log_pos: 274
Info: SET @@SESSION.GTID_NEXT= '4d22b3e5-a54f-11e9-8bdb-ace2d35785be:603'
*************************** 2. row ***************************
Log_name: binlog.000049 Pos: 274
Event_type: Query Server_id: 1 End_log_pos: 372 Info: BEGIN
*************************** 3. row ***************************
Log_name: binlog.000049 Pos: 372
Event_type: Table_map Server_id: 1
End_log_pos: 436
Info: table_id: 89 (world.city)
*************************** 4. row ***************************
Log_name: binlog.000049 Pos: 436
Event_type: Update_rows Server_id: 1
End_log_pos: 544
Info: table_id: 89 flags: STMT_END_F
ChaPTer 8 ShOW STaTemenTS
*************************** 5. row ***************************
Log_name: binlog.000049 Pos: 544
Event_type: Xid Server_id: 1 End_log_pos: 575
Info: COMMIT /* xid=44 */
5 rows in set (0.0632 sec)
The example illustrates some of the limitations of using SHOW statements to inspect binary and relay logs. The result is a normal result set from a query, and since the files typically are around 1 GiB in size, it means the result can be equally large. You can do as in the example where only specific events are chosen, but it is not always trivial to know where the interesting events start, and you cannot filter by the event types or which tables they affect. Finally, the default event format (the binlog_format option) is the row format, and as it can be seen from the third and fourth rows in the result, all you can see from SHOW BINGOG EVENTS is that the transaction updated the world.city table. You cannot see which rows were updated and what the values are.
In practice, if you have access to the file system, it is in most cases better to use the mysqlbinlog utility that is shipped with MySQL. (The SHOW BINLOG EVENTS and SHOW RELAYLOG EVENTS statements can still be useful in controlled testing or when replication stops and you quickly want to inspect the event that caused the error.) The equivalent command using the mysqlbinlog utility to the previous SHOW BINLOG EVENTS statement is shown in Listing 8-2. That example also uses the verbose flag to show the before and after images of the row-based event that updates the world.city table.
Listing 8-2. Inspecting the binary log using the mysqlbinlog utility
shell> mysqlbinlog -v --base64-output=decode-rows --start-position=195 --stop-position=575 binlog.000049
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 124
#190914 20:38:43 server id 1 end_log_pos 124 CRC32 0x751322a6 Start:
binlog v 4, server v 8.0.18 created 190914 20:38:43 at startup
143
# Warning: this binlog is either in use or was not closed properly.
ROLLBACK/*!*/;
# at 195
#190915 10:18:45 server id 1 end_log_pos 274 CRC32
0xe1b8b9a1 GTID last_committed=0 sequence_number=1 rbr_only=yes original_committed_timestamp=1568506725779031 immediate_commit_timestamp=1568506725779031 transaction_length=380 /*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=1568506725779031 (2019-09-15 10:18:45.779031 AUS Eastern Standard Time)
# immediate_commit_timestamp=1568506725779031 (2019-09-15 10:18:45.779031 AUS Eastern Standard Time)
/*!80001 SET @@session.original_commit_timestamp=1568506725779031*//*!*/;
/*!80014 SET @@session.original_server_version=80018*//*!*/;
/*!80014 SET @@session.immediate_server_version=80018*//*!*/;
SET @@SESSION.GTID_NEXT= '4d22b3e5-a54f-11e9-8bdb-ace2d35785be:603'/*!*/;
# at 274
#190915 10:18:45 server id 1 end_log_pos 372 CRC32 0x2d716bd5 Query thread_id=8 exec_time=0 error_code=0
SET TIMESTAMP=1568506725/*!*/;
SET @@session.pseudo_thread_id=8/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0,
@@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1168113696/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_
offset=1/*!*/;
/*!\C utf8mb4 *//*!*/;
SET @@session.character_set_client=45,@@session.collation_connection=45,
@@session.collation_server=255/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
/*!80011 SET @@session.default_collation_for_utf8mb4=255*//*!*/;
BEGIN /*!*/;
# at 372
ChaPTer 8 ShOW STaTemenTS
#190915 10:18:45 server id 1 end_log_pos 436 CRC32 0xb62c64d7 Table_map:
`world`.`city` mapped to number 89
# at 436
#190915 10:18:45 server id 1 end_log_pos 544 CRC32 0x62687b0b Update_rows: table id 89 flags: STMT_END_F
### UPDATE `world`.`city`
### WHERE
### @1=130
### @2='Sydney'
### @3='AUS'
### @4='New South Wales'
### @5=3276207
### SET
### @1=130
### @2='Sydney'
### @3='AUS'
### @4='New South Wales'
### @5=3276208
# at 544
#190915 10:18:45 server id 1 end_log_pos 575 CRC32 0x149e2b5c Xid = 44 COMMIT/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
The -v arguments request verbose mode and can be given up to two times to increase the amount of information included. A single -v is what generates the comment with the pseudo query in the event starting at position 436. The --base64- output=decode-rows argument tells mysqlbinlog not to include a base64 encoded version of the events in row format. The --start-position and --stop-position arguments specify the start and stop offsets in bytes.
145 The most interesting event in the transaction is the one starting with the comment
# at 436 which means the event starts at offset 436 (in bytes). It is written as a pseudo update statement with the WHERE part showing the values before the change and the SET part the values after the update. This is also known as the before and after images.