Binlog 簡介
MySQL中通常有如下幾種日誌：mysql
| 日誌類型 | 寫入日誌的信息 |
|---|---|
| 錯誤日誌 | 記錄在啓動，運行或中止mysqld時遇到的問題 |
| 通用查詢日誌 | 記錄創建的客戶端鏈接和執行的語句 |
| 二進制日誌 | 記錄更改數據的語句 |
| 中繼日誌 | 從複製主服務器接收的數據更改 |
| 慢查詢日誌 | 記錄全部執行時間超過 long_query_time 秒的全部查詢或不使用索引的查詢 |
| DDL日誌（元數據日誌） | 元數據操做由DDL語句執行 |
本文主要介紹二進制日誌 binlog。sql
MySQL 的二進制日誌 binlog 能夠說是 MySQL 最重要的日誌，它記錄了全部的 DDL 和 DML 語句（除了數據查詢語句select、show等），以事件形式記錄，還包含語句所執行的消耗的時間，MySQL的二進制日誌是事務安全型的。binlog 的主要目的是複製和恢復。shell
Binlog日誌的兩個最重要的使用場景
MySQL主從複製：MySQL Replication在Master端開啓binlog，Master把它的二進制日誌傳遞給slaves來達到master-slave數據一致的目的數據庫
數據恢復：經過使用 mysqlbinlog工具來使恢復數據緩存
啓用 Binlog
注：筆者實驗的MySQL版本爲：5.7.22安全
通常來講開啓binlog日誌大概會有1%的性能損耗。ruby
啓用binlog，經過配置 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf 配置文件的 log-bin 選項：bash
在配置文件中加入 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時是下面這樣，能夠發現又有一些不一樣
關於Event的分析，有須要能夠查看參考文檔進行推算。
參考文檔
MySQL 5.7參考手冊.二進制日誌
MySQL Internals Manual.The Binary Log
朱小廝.MySQL Binlog解析
七把刀.MySQL binlog格式解析
散盡浮華.Mysql之binlog日誌說明及利用binlog日誌恢復數據操做記錄
MySql Binlog 初識
MySQL5.7殺手級新特性：GTID原理與實戰
MySQL 5.7 基於 GTID 的主從複製實踐
本文分享自微信公衆號 - 小旋鋒（whirlysBigData）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。