MySQL Binlog 介紹

時間  2021-08-15
標籤 html mysql linux sql shell 數據庫 緩存 安全 bash 服務器 欄目 MySQL 简体版
原文   原文鏈接

Binlog 簡介

MySQL Binlog 介紹html

MySQL中通常有如下幾種日誌：mysql

日誌類型 寫入日誌的信息
錯誤日誌 記錄在啓動，運行或中止mysqld時遇到的問題
通用查詢日誌 記錄創建的客戶端鏈接和執行的語句
二進制日誌 記錄更改數據的語句
中繼日誌 從複製主服務器接收的數據更改
慢查詢日誌 記錄全部執行時間超過 long_query_time 秒的全部查詢或不使用索引的查詢
DDL日誌（元數據日誌） 元數據操做由DDL語句執行

本文主要介紹二進制日誌 binlog。linux

MySQL 的二進制日誌 binlog 能夠說是 MySQL 最重要的日誌，它記錄了全部的 DDL 和 DML 語句（除了數據查詢語句select、show等），以事件形式記錄，還包含語句所執行的消耗的時間，MySQL的二進制日誌是事務安全型的。binlog 的主要目的是複製和恢復。sql

Binlog日誌的兩個最重要的使用場景

  • MySQL主從複製：MySQL Replication在Master端開啓binlog，Master把它的二進制日誌傳遞給slaves來達到master-slave數據一致的目的
  • 數據恢復：經過使用 mysqlbinlog工具來使恢復數據

啓用 Binlog

注：筆者實驗的MySQL版本爲：5.7.22shell

通常來講開啓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才能生效。bash

經常使用的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的字段或者1436753函數；此事件沒有被用在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

STATEMENT格式下create、insert、update、delete操做產生的binlog事件

日誌格式爲ROW時是下面這樣，能夠發現又有一些不一樣

ROW格式下create、insert、update、delete操做產生的binlog事件

關於Event的分析，有須要能夠查看參考文檔進行推算。

參考文檔

關注_小旋鋒_微信公衆號
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程