Binlog 簡介
MySQL中一般有以下幾種日誌：
| 日誌類型 | 寫入日誌的信息 |
|---|---|
| 錯誤日誌 | 記錄在啓動，運行或停止mysqld時遇到的問題 |
| 通用查詢日誌 | 記錄建立的客戶端連接和執行的語句 |
| 二進制日誌 | 記錄更改數據的語句 |
| 中繼日誌 | 從複製主服務器接收的數據更改 |
| 慢查詢日誌 | 記錄所有執行時間超過 long_query_time 秒的所有查詢或不使用索引的查詢 |
| DDL日誌（元數據日誌） | 元數據操作由DDL語句執行 |
本文主要介紹二進制日誌 binlog。
MySQL 的二進制日誌 binlog 可以說是 MySQL 最重要的日誌，它記錄了所有的 DDL 和 DML 語句（除了數據查詢語句select、show等），以事件形式記錄，還包含語句所執行的消耗的時間，MySQL的二進制日誌是事務安全型的。binlog 的主要目的是複製和恢復。
Binlog日誌的兩個最重要的使用場景
- MySQL主從複製：MySQL Replication在Master端開啓binlog，Master把它的二進制日誌傳遞給slaves來達到master-slave數據一致的目的
- 數據恢復：通過使用 mysqlbinlog工具來使恢復數據
啓用 Binlog
注：實驗的MySQL版本爲：5.7.22
一般來說開啓binlog日誌大概會有1%的性能損耗。
啓用binlog，通過配置 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf 配置文件的 log-bin 選項：
在配置文件中加入 log-bin 配置，表示啓用binlog，如果沒有給定值，寫成 log-bin=，則默認名稱爲主機名。（注：名稱若帶有小數點，則只取第一個小數點前的部分作爲名稱）
[mysqld]
log-bin=my-binlog-name也可以通過 SET SQL_LOG_BIN=1 命令來啓用 binlog，通過 SET SQL_LOG_BIN=0 命令停用 binlog。啓用 binlog 之後須重啓MySQL才能生效。
常用的Binlog操作命令
# 是否啓用binlog日誌
show variables like 'log_bin';
# 查看詳細的日誌配置信息
show global variables like '%log%';
# mysql數據存儲目錄
show variables like '%dir%';
# 查看binlog的目錄
show global variables like "%log_bin%";
# 查看當前服務器使用的biglog文件及大小
show binary logs;
# 查看主服務器使用的biglog文件及大小
# 查看最新一個binlog日誌文件名稱和Position
show master status;
# 事件查詢命令
# IN 'log_name' ：指定要查詢的binlog文件名(不指定就是第一個binlog文件)
# FROM pos ：指定從哪個pos起始點開始查起(不指定就是從整個文件首個pos點開始算)
# LIMIT [offset,] ：偏移量(不指定就是0)
# row_count ：查詢總條數(不指定就是所有行)
show binlog events [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count];
# 查看 binlog 內容
show binlog events;
# 查看具體一個binlog文件的內容 （in 後面爲binlog的文件名）
show binlog events in 'master.000003';
# 設置binlog文件保存事件，過期刪除，單位天
set global expire_log_days=3;
# 刪除當前的binlog文件
reset master;
# 刪除slave的中繼日誌
reset slave;
# 刪除指定日期前的日誌索引中binlog日誌文件
purge master logs before '2019-03-09 14:00:00';
# 刪除指定日誌文件
purge master logs to 'master.000003';寫 Binlog 的時機
對支持事務的引擎如InnoDB而言，必須要提交了事務纔會記錄binlog。binlog 什麼時候刷新到磁盤跟參數 sync_binlog 相關。
- 如果設置爲0，則表示MySQL不控制binlog的刷新，由文件系統去控制它緩存的刷新；
- 如果設置爲不爲0的值，則表示每
sync_binlog次事務，MySQL調用文件系統的刷新操作刷新binlog到磁盤中。 - 設爲1是最安全的，在系統故障時最多丟失一個事務的更新，但是會對性能有所影響。
如果 sync_binlog=0 或 sync_binlog大於1，當發生電源故障或操作系統崩潰時，可能有一部分已提交但其binlog未被同步到磁盤的事務會被丟失，恢復程序將無法恢復這部分事務。
在MySQL 5.7.7之前，默認值 sync_binlog 是0，MySQL 5.7.7和更高版本使用默認值1，這是最安全的選擇。一般情況下會設置爲100或者0，犧牲一定的一致性來獲取更好的性能。
Binlog 文件以及擴展
binlog日誌包括兩類文件:
- 二進制日誌索引文件（文件名後綴爲.index）用於記錄所有有效的的二進制文件
- 二進制日誌文件（文件名後綴爲.00000*）記錄數據庫所有的DDL和DML語句事件
binlog是一個二進制文件集合，每個binlog文件以一個4字節的魔數開頭，接着是一組Events:
- 魔數：0xfe62696e對應的是0xfebin；
- Event：每個Event包含header和data兩個部分；header提供了Event的創建時間，哪個服務器等信息，data部分提供的是針對該Event的具體信息，如具體數據的修改；
- 第一個Event用於描述binlog文件的格式版本，這個格式就是event寫入binlog文件的格式；
- 其餘的Event按照第一個Event的格式版本寫入；
- 最後一個Event用於說明下一個binlog文件；
- binlog的索引文件是一個文本文件，其中內容爲當前的binlog文件列表
當遇到以下3種情況時，MySQL會重新生成一個新的日誌文件，文件序號遞增：
- MySQL服務器停止或重啓時
- 使用
flush logs命令； - 當 binlog 文件大小超過
max_binlog_size變量的值時；
max_binlog_size的最小值是4096字節，最大值和默認值是 1GB (1073741824字節)。事務被寫入到binlog的一個塊中，所以它不會在幾個二進制日誌之間被拆分。因此，如果你有很大的事務，爲了保證事務的完整性，不可能做切換日誌的動作，只能將該事務的日誌都記錄到當前日誌文件中，直到事務結束，你可能會看到binlog文件大於 max_binlog_size 的情況。
Binlog 的日誌格式
記錄在二進制日誌中的事件的格式取決於二進制記錄格式。支持三種格式類型：
- STATEMENT：基於SQL語句的複製（statement-based replication, SBR）
- ROW：基於行的複製（row-based replication, RBR）
- MIXED：混合模式複製（mixed-based replication, MBR）
在 MySQL 5.7.7 之前，默認的格式是 STATEMENT，在 MySQL 5.7.7 及更高版本中，默認值是 ROW。日誌格式通過 binlog-format 指定，如 binlog-format=STATEMENT、binlog-format=ROW、binlog-format=MIXED。
Statement
每一條會修改數據的sql都會記錄在binlog中
優點：不需要記錄每一行的變化，減少了binlog日誌量，節約了IO, 提高了性能。
缺點：由於記錄的只是執行語句，爲了這些語句能在slave上正確運行，因此還必須記錄每條語句在執行的時候的一些相關信息，以保證所有語句能在slave得到和在master端執行的時候相同的結果。另外mysql的複製，像一些特定函數的功能，slave與master要保持一致會有很多相關問題。
Row
5.1.5版本的MySQL纔開始支持 row level 的複製,它不記錄sql語句上下文相關信息，僅保存哪條記錄被修改。
優點： binlog中可以不記錄執行的sql語句的上下文相關的信息，僅需要記錄那一條記錄被修改成什麼了。所以row的日誌內容會非常清楚的記錄下每一行數據修改的細節。而且不會出現某些特定情況下的存儲過程，或function，以及trigger的調用和觸發無法被正確複製的問題.
缺點:所有的執行的語句當記錄到日誌中的時候，都將以每行記錄的修改來記錄，這樣可能會產生大量的日誌內容。
注：將二進制日誌格式設置爲ROW時，有些更改仍然使用基於語句的格式，包括所有DDL語句，例如CREATE TABLE， ALTER TABLE，或 DROP TABLE。
Mixed
從5.1.8版本開始，MySQL提供了Mixed格式，實際上就是Statement與Row的結合。
在Mixed模式下，一般的語句修改使用statment格式保存binlog，如一些函數，statement無法完成主從複製的操作，則採用row格式保存binlog，MySQL會根據執行的每一條具體的sql語句來區分對待記錄的日誌形式，也就是在Statement和Row之間選擇一種。
mysqlbinlog 命令的使用
服務器以二進制格式將binlog日誌寫入binlog文件，如何要以文本格式顯示其內容，可以使用 mysqlbinlog 命令。
# mysqlbinlog 的執行格式
mysqlbinlog [options] log_file ...
# 查看bin-log二進制文件（shell方式）
mysqlbinlog -v --base64-output=decode-rows /var/lib/mysql/master.000003
# 查看bin-log二進制文件（帶查詢條件）
mysqlbinlog -v --base64-output=decode-rows /var/lib/mysql/master.000003 \
--start-datetime="2019-03-01 00:00:00" \
--stop-datetime="2019-03-10 00:00:00" \
--start-position="5000" \
--stop-position="20000"設置日誌格式爲ROW時，在我的機器上輸出了以下信息
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#190308 10:05:03 server id 1 end_log_pos 123 CRC32 0xff02e23d Start: binlog v 4, server v 5.7.22-log created 190308 10:05:03
# Warning: this binlog is either in use or was not closed properly.
# at 123
#190308 10:05:03 server id 1 end_log_pos 154 CRC32 0xb81da4c5 Previous-GTIDs
# [empty]
# at 154
#190308 10:05:09 server id 1 end_log_pos 219 CRC32 0xfb30d42c Anonymous_GTID last_committed=0 sequence_number=1 rbr_only=yes
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 219
...
...
# at 21019
#190308 10:10:09 server id 1 end_log_pos 21094 CRC32 0x7a405abc Query thread_id=113 exec_time=0 error_code=0
SET TIMESTAMP=1552011009/*!*/;
BEGIN
/*!*/;
# at 21094
#190308 10:10:09 server id 1 end_log_pos 21161 CRC32 0xdb7a2b35 Table_map: `maxwell`.`positions` mapped to number 110
# at 21161
#190308 10:10:09 server id 1 end_log_pos 21275 CRC32 0xec3be372 Update_rows: table id 110 flags: STMT_END_F
### UPDATE `maxwell`.`positions`
### WHERE
### @1=1
### @2='master.000003'
### @3=20262
### @4=NULL
### @5='maxwell'
### @6=NULL
### @7=1552011005707
### SET
### @1=1
### @2='master.000003'
### @3=20923
### @4=NULL
### @5='maxwell'
### @6=NULL
### @7=1552011009790
# at 21275
#190308 10:10:09 server id 1 end_log_pos 21306 CRC32 0xe6c4346d Xid = 13088
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*/;截取其中的一段進行分析：
# at 21019
#190308 10:10:09 server id 1 end_log_pos 21094 CRC32 0x7a405abc Query thread_id=113 exec_time=0 error_code=0
SET TIMESTAMP=1552011009/*!*/;
BEGIN
/*!*/;上面輸出包括信息：
- position: 位於文件中的位置，即第一行的（# at 21019）,說明該事件記錄從文件第21019個字節開始
- timestamp: 事件發生的時間戳，即第二行的（#190308 10:10:09）
- server id: 服務器標識（1）
- end_log_pos 表示下一個事件開始的位置（即當前事件的結束位置+1）
- thread_id: 執行該事件的線程id （thread_id=113）
- exec_time: 事件執行的花費時間
- error_code: 錯誤碼，0意味着沒有發生錯誤
- type:事件類型Query
Binlog 事件類型
binlog 事件的結構主要有3個版本：
- v1: 在 MySQL 3.23 中使用
- v3: 在 MySQL 4.0.2 到 4.1 中使用
- v4: 在 MySQL 5.0 及以上版本中使用
現在一般不會使用MySQL5.0以下版本，所以下面僅介紹v4版本的binlog事件類型。binlog 的事件類型較多，本文在此做一些簡單的彙總
| 事件類型 | 說明 |
|---|---|
| UNKNOWN_EVENT | 此事件從不會被觸發，也不會被寫入binlog中；發生在當讀取binlog時，不能被識別其他任何事件，那被視爲UNKNOWN_EVENT |
| START_EVENT_V3 | 每個binlog文件開始的時候寫入的事件，此事件被用在MySQL3.23 – 4.1，MYSQL5.0以後已經被 FORMAT_DESCRIPTION_EVENT 取代 |
| QUERY_EVENT | 執行更新語句時會生成此事件，包括：create，insert，update，delete； |
| STOP_EVENT | 當mysqld停止時生成此事件 |
| ROTATE_EVENT | 當mysqld切換到新的binlog文件生成此事件，切換到新的binlog文件可以通過執行flush logs命令或者binlog文件大於 max_binlog_size 參數配置的大小； |
| INTVAR_EVENT | 當sql語句中使用了AUTO_INCREMENT的字段或者LAST_INSERT_ID()函數；此事件沒有被用在binlog_format爲ROW模式的情況下 |
| LOAD_EVENT | 執行LOAD DATA INFILE 語句時產生此事件，在MySQL 3.23版本中使用 |
| SLAVE_EVENT | 未使用 |
| CREATE_FILE_EVENT | 執行LOAD DATA INFILE 語句時產生此事件，在MySQL4.0和4.1版本中使用 |
| APPEND_BLOCK_EVENT | 執行LOAD DATA INFILE 語句時產生此事件，在MySQL4.0版本中使用 |
| EXEC_LOAD_EVENT | 執行LOAD DATA INFILE 語句時產生此事件，在MySQL4.0和4.1版本中使用 |
| DELETE_FILE_EVENT | 執行LOAD DATA INFILE 語句時產生此事件，在MySQL4.0版本中使用 |
| NEW_LOAD_EVENT | 執行LOAD DATA INFILE 語句時產生此事件，在MySQL4.0和4.1版本中使用 |
| RAND_EVENT | 執行包含RAND()函數的語句產生此事件，此事件沒有被用在binlog_format爲ROW模式的情況下 |
| USER_VAR_EVENT | 執行包含了用戶變量的語句產生此事件，此事件沒有被用在binlog_format爲ROW模式的情況下 |
| FORMAT_DESCRIPTION_EVENT | 描述事件，被寫在每個binlog文件的開始位置，用在MySQL5.0以後的版本中，代替了START_EVENT_V3 |
| XID_EVENT | 支持XA的存儲引擎纔有，本地測試的數據庫存儲引擎是innodb，所有上面出現了XID_EVENT；innodb事務提交產生了QUERY_EVENT的BEGIN聲明，QUERY_EVENT以及COMMIT聲明，如果是myIsam存儲引擎也會有BEGIN和COMMIT聲明，只是COMMIT類型不是XID_EVENT |
| BEGIN_LOAD_QUERY_EVENT | 執行LOAD DATA INFILE 語句時產生此事件，在MySQL5.0版本中使用 |
| EXECUTE_LOAD_QUERY_EVENT | 執行LOAD DATA INFILE 語句時產生此事件，在MySQL5.0版本中使用 |
| TABLE_MAP_EVENT | 用在binlog_format爲ROW模式下，將表的定義映射到一個數字，在行操作事件之前記錄（包括：WRITE_ROWS_EVENT，UPDATE_ROWS_EVENT，DELETE_ROWS_EVENT） |
| PRE_GA_WRITE_ROWS_EVENT | 已過期，被 WRITE_ROWS_EVENT 代替 |
| PRE_GA_UPDATE_ROWS_EVENT | 已過期，被 UPDATE_ROWS_EVENT 代替 |
| PRE_GA_DELETE_ROWS_EVENT | 已過期，被 DELETE_ROWS_EVENT 代替 |
| WRITE_ROWS_EVENT | 用在binlog_format爲ROW模式下，對應 insert 操作 |
| UPDATE_ROWS_EVENT | 用在binlog_format爲ROW模式下，對應 update 操作 |
| DELETE_ROWS_EVENT | 用在binlog_format爲ROW模式下，對應 delete 操作 |
| INCIDENT_EVENT | 主服務器發生了不正常的事件，通知從服務器並告知可能會導致數據處於不一致的狀態 |
| HEARTBEAT_LOG_EVENT | 主服務器告訴從服務器，主服務器還活着，不寫入到日誌文件中 |
Binlog 事件的結構
一個事件對象分爲事件頭和事件體，事件的結構如下：
+=====================================+
| event | timestamp 0 : 4 |
| header +----------------------------+
| | type_code 4 : 1 |
| +----------------------------+
| | server_id 5 : 4 |
| +----------------------------+
| | event_length 9 : 4 |
| +----------------------------+
| | next_position 13 : 4 |
| +----------------------------+
| | flags 17 : 2 |
| +----------------------------+
| | extra_headers 19 : x-19 |
+=====================================+
| event | fixed part x : y |
| data +----------------------------+
| | variable part |
+=====================================+如果事件頭的長度是 x 字節，那麼事件體的長度爲 (event_length - x) 字節；設事件體中 fixed part 的長度爲 y 字節，那麼 variable part 的長度爲 (event_length - (x + y)) 字節
Binlog Event 簡要分析
從一個最簡單的實例來分析Event，包括創建表，插入數據，更新數據，刪除數據；
CREATE TABLE `test` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`age` int(11) DEFAULT NULL,
`name` varchar(255) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
insert into test values(1,22,"小旋鋒");
update test set name='whirly' where id=1;
delete from test where id=1;日誌格式爲STATEMENT，查看所有的Event
日誌格式爲ROW時是下面這樣，可以發現又有一些不同
