Structure of the MySQL binary log

MySQL5.0 introduces a new binlog format, binlog format 4,,binlog format 4 is designed specifically for extensions. The Binlog event is made up of 4 parts

1 General Purpose head

Contains basic information about the event, the most important of which is the event type and time size

2 Submission Header

The submission header is related to a specific event type, the field stores information differently for different types, but as with the generic header, the size of the commit header is the same in the given Binlog file, and the size of the event type is given by the Foramat_description event

3 Event Body

The event header is followed by the event body, which is variable in size, and the general header of the event lists the size and end of the event body. The event body stores the primary data for the event, which varies depending on the event type, for example, the event body of the query event stores the query, while the User_var

User variables and their values that store a statement

4 Checksum

Starting from 5.6, if the server settings produce a test and a precondition, the end of the event is one more test and a field, is a 32-bit integer, to check whether there is corruption after the time write

To ensure the integrity of each event, MySQL5.6 introduces the validation of replicated events. At the time of writing the event, add a check and then, while reading these events, calculate the checksum and the value that was written before

For comparison. If it does not match, the slave stops execution when the event is applied. MySQL5.6 is turned on by default. You can also disable

Control replication event validation and by three options

Binlog-checksum=type

means to enable inspection and, and tell the server in which way to calculate the test and, there are two, 1 CRC32 2 None close the test and, that is, the default generated inspection and

Master-verify-checksum=boolean

Indicates whether Master wants to verify the checksum when reading the binary, that is, after the dump thread reads the event from the binary log, verifies that it is checksums, and sends it to slave after error. The same is true with the show BINLOG events command.

If there are any corruption events, an error is thrown. Default off state

Slave-verify-checksum=boolean

Indicates whether the slave verifies the checksum of the event before the event is applied on the slave database in the read trunk log. Default off state

$ client/mysqlbinlog--verify-binlog-checksum master-bin.000001
# at 261
#110406 8:35:28 Server ID 1 end_log_pos 333 CRC32 0xed927ef2 ...
SET timestamp=1302071728/*!*/;
BEGIN
/*!*/;
# at 333
#110406 8:35:28 Server ID 1 end_log_pos 365 CRC32 0x01ed254d Intvar
SET insert_id=1/*!*/;
Error:error in Log_event::read_log_event (): ' Event CRC check failed!...
DELIMITER;
# End of log file
ROLLBACK/* Added by Mysqlbinlog */;
/*!50003 SET [email protected]_completion_type*/;

More content: http://www.wangzhanjianshegs.com/ website Construction

Structure of the MySQL binary log