A brief introduction: we will continue to analyze binlog, but do not go into the code
Two versions 5.6
Format
Gtid and traditional formats
Traditional format
One binlog for specific transactions note-1
1 Update records the values of all columns before and after the change
2 Delete records the values of all columns before deletion
3 insert records the specific SQL that is inserted
4 DDL statements only record the statement itself and do not log affected rows
5 DCL statements are not logged
6 Special types
1 trigger 1 records the SQL statement that generated the data update. Data updates that occur after the trigger is called are not recorded in the Binlog
2 function If there are data changes in the function, the call statement (including the SELECT statement) of the functions will be recorded in the Binlog
3 The SQL statement that updates data will be credited to the Binlog,event feature is turned off by default after the event event is triggered. Once the event is defined on master, slave synchronizes the event and marks it as slaveside_disabled, paying special attention to
Summary: 1 record creation statement itself 2 records the statements generated during execution and does not record column all values
7 Special Statements
The CREATE table as SELECT * from is recorded according to the insert single record, but belongs to a transaction
Two Binlog for transaction record points-2
1 record table information
dbname,table_name,table_id
2 Transaction-related information
1 A complete transaction must begin with begin and end With end
2 Transaction Start-specific time of submission
3 start of transaction-position submitted
Three restores
1 Follow the site recovery, remember to choose a complete transaction for recovery, then how to determine a complete transaction site, the start of the transaction at the beginning of the site, the place under the point of the commit
Cond
MySQL principle ~ Binlog