MySQL binlog日誌操作詳解
MySQL binlog日誌操作詳解
MySQL的二進位制日誌可以說是MySQL最重要的日誌了,它記錄了所有的DDL和DML(除了資料查詢語句)語句,以事件形式記錄,還包含語句所執行的消耗的時間,MySQL的二進位制日誌是事務安全型的。
binlog日誌的作用
- 其一:MySQL Replication在Master端開啟binlog,Mster把它的二進位制日誌傳遞給slaves來達到master-slave資料一致的目的。
- 其二:自然就是資料恢復了,通過使用mysqlbinlog工具來使恢復資料。
- MySQL二進位制日誌包括兩類檔案:二進位制日誌索引檔案(檔名字尾為.index)用於記錄所有的二進位制檔案,二進位制日誌檔案(檔名字尾為.00000*)記錄資料庫所有的DDL和DML(除了資料查詢語句)語句事件。
一、開啟binlog日誌
vim /etc/my.cnf
[mysqld]
log_bin = /data/log/mysql/binlog/mysql-bin.log
重啟mysqld服務使配置生效
/etc/init.d/mysqld restart
二、登入mysql伺服器,通過mysql的變數配置表,檢視二進位制日誌是否已開啟.
mysql> show variables like 'log_%'; +----------------------------------------+----------------------------------------+ | Variable_name | Value | +----------------------------------------+----------------------------------------+ | log_bin | ON | | log_bin_basename | /data/log/mysql/binlog/mysql-bin | | log_bin_index | /data/log/mysql/binlog/mysql-bin.index | | log_bin_trust_function_creators | OFF | | log_bin_use_v1_row_events | OFF | | log_builtin_as_identified_by_password | OFF | | log_error | ./mysql-error.log | | log_error_verbosity | 2 | | log_output | FILE | | log_queries_not_using_indexes | ON | | log_slave_updates | ON | | log_slow_admin_statements | ON | | log_slow_slave_statements | ON | | log_statements_unsafe_for_binlog | ON | | log_syslog | OFF | | log_syslog_facility | daemon | | log_syslog_include_pid | ON | | log_syslog_tag | | | log_throttle_queries_not_using_indexes | 10 | | log_timestamps | SYSTEM | | log_warnings | 1 | +----------------------------------------+----------------------------------------+ 21 rows in set (0.02 sec)
三、檢視某個binlog日誌內容,常用有兩種方式:
- 使用mysqlbinlog自帶檢視命令法:
binlog是二進位制檔案,普通檔案檢視器cat more vim 等開啟都是亂碼,必須使用自帶的 mysqlbinlog 命令檢視.
[root@mysql ~]# su - mysql
[mysql@mysql ~]$ mysqlbinlog /data/log/mysql/binlog/mysql-bin.000005
- 使用show binlog events 檢視binlog日誌.
mysql> show binlog events [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count]; 選項解析: IN 'log_name' 指定要查詢的binlog檔名(不指定就是第一個binlog檔案) FROM pos 指定從哪個pos起始點開始查起(不指定就是從整個檔案首個pos點開始算) LIMIT [offset,] 偏移量(不指定就是0) row_count 查詢總條數(不指定就是所有行)
擷取部分查詢結果:
mysql> show binlog events in 'mysql-bin.000005'\G
*************************** 1. row ***************************
Log_name: mysql-bin.000005
Pos: 4
Event_type: Format_desc
Server_id: 4294967295
End_log_pos: 123
Info: Server ver: 5.7.27-log, Binlog ver: 4
*************************** 2. row ***************************
Log_name: mysql-bin.000005
Pos: 123
Event_type: Previous_gtids
Server_id: 4294967295
End_log_pos: 194
Info: a775a0a0-37aa-11eb-a07c-000c29292583:1-7
*************************** 3. row ***************************
Log_name: mysql-bin.000005
Pos: 194
Event_type: Gtid
Server_id: 4294967295
End_log_pos: 259
Info: SET @@SESSION.GTID_NEXT= 'a775a0a0-37aa-11eb-a07c-000c29292583:8'
*************************** 4. row ***************************
Log_name: mysql-bin.000005 ----> 查詢的binlog日誌檔名
Pos: 259 ----> pos起始點:
Event_type: Query ----> 事件型別
Server_id: 4294967295 ----> 標識是由哪臺伺服器執行的
End_log_pos: 376 ----> pos結束點:120(即:下行的pos起始點)
Info: use `test`; create table test (id int,name varchar(10)) ---> 執行的sql語句
這條語句可以將指定的binlog日誌檔案,分成有效事件行的方式返回,並可使用limit指定pos點的起始偏移,查詢條數;
- 查詢第一個(即mysql-bin.000001)binlog日誌:
mysql> show binlog events\G
- 指定查詢 mysql-bin.00005 這個檔案:
mysql> show binlog events in 'mysql-bin.000005'\G
- 指定查詢 mysql-bin.000005 這個檔案,從pos點:666開始查起:
mysql> show binlog events in 'mysql-bin.000005' from 666\G
- 指定查詢 mysql-bin.000005 這個檔案,從pos點:376開始查起,查詢10條
mysql> show binlog events in 'mysql-bin.000005' from 376 limit 10\G
- 指定查詢 mysql-bin.000005 這個檔案,從pos點:376開始查起,偏移2行,查詢10條
mysql> show binlog events in 'mysql-bin.000005' from 376 limit 2,10\G
四、 通過全備和binlog日誌恢復資料例項:
- 假設現在是凌晨1:00,我的計劃任務開始執行一次完整的資料庫備份:
將test資料庫備份到 /tmp/bak_test.sql 檔案中:
[mysql@mysql ~]$ mysqldump -S /data/mysql/data/mysql.sock -usys -p123456 -h192.168.1.200 -lF --log-error=/tmp/myDump.err -B test > /tmp/bak_test.sql
大約過若干分鐘,全備份就完成了,我不用擔心資料丟失了,因為我有備份了,嘎嘎~~~
由於我使用了-F選項,當備份工作剛開始時系統會重新整理log日誌,產生新的binlog日誌來記錄備份之後的資料庫“增刪改”操作,檢視一下:
mysql> show master status;
+------------------+----------+--------------+------------------+-------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------------------------------+
| mysql-bin.000006 | 194 | | | a775a0a0-37aa-11eb-a07c-000c29292583:1-14 |
+------------------+----------+--------------+------------------+-------------------------------------------+
1 row in set (0.00 sec)
也就是說, mysql-bin.000006 是用來記錄1:00之後對資料庫的所有“增刪改”操作
- 早9:30上班了,業務的需求會對資料庫進行各種“增刪改”操作
比如:建立一個tb1表並插入、修改了資料等等:
mysql>use test;
mysql>CREATE TABLE IF NOT EXISTS `yjh1` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(16) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
匯入資料:
mysql> insert into test.yjh1(name) values('DBA'),('CBA'),('NBA'),('UFO');
檢視資料
mysql> select * from yjh1;
+----+------+
| id | name |
+----+------+
| 1 | DBA |
| 2 | CBA |
| 3 | NBA |
| 4 | UFO |
+----+------+
4 rows in set (0.00 sec)
中午時分又執行了修改資料操作
mysql> update test.yjh1 set name='BBA' where id=4;
修改後的結果:
mysql> select * from yjh1;
+----+------+
| id | name |
+----+------+
| 1 | DBA |
| 2 | CBA |
| 3 | NBA |
| 4 | BBA |
+----+------+
4 rows in set (0.00 sec)
假設此時是下午,腦子一熱莫名地執行了一條悲催的SQL語句,整個資料庫都沒了:
mysql> drop database test;
然後,就沒然後了,凌亂一會,開始恢復吧!!
先仔細檢視最後一個binlog日誌,並記錄下關鍵的pos點,到底是哪個pos點的操作導致了資料庫的破壞(通常在最後幾步);
備份一下最後一個binlog日誌檔案:
cp -v /data/log/mysql/binlog/mysql-bin.000006 /tmp/
此時執行一次重新整理日誌索引操作,重新開始新的binlog日誌記錄檔案,理論說 mysql-bin.000007 這個檔案不會再有後續寫入了(便於我們分析原因及查詢pos點),以後所有資料庫操作都會寫入到下一個日誌檔案;
mysql> flush logs;
Query OK, 0 rows affected (0.08 sec)
mysql> show master status;
+------------------+----------+--------------+------------------+-------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------------------------------+
| mysql-bin.000007 | 194 | | | a775a0a0-37aa-11eb-a07c-000c29292583:1-18 |
+------------------+----------+--------------+------------------+-------------------------------------------+
1 row in set (0.00 sec)
- 讀取binlog日誌,分析問題
方式一:使用mysqlbinlog讀取binlog日誌:
mysqlbinlog /data/log/mysql/binlog/mysql-bin.000006
方式二:登入伺服器,並檢視(推薦):
以下為末尾片段:
mysql> show binlog events in 'mysql-bin.000006'\G
...前面行數很多,省略。
*************************** 17. row ***************************
Log_name: mysql-bin.000006
Pos: 1238
Event_type: Gtid
Server_id: 4294967295
End_log_pos: 1303
Info: SET @@SESSION.GTID_NEXT= 'a775a0a0-37aa-11eb-a07c-000c29292583:18'
*************************** 18. row ***************************
Log_name: mysql-bin.000006
Pos: 1303
Event_type: Query
Server_id: 4294967295
End_log_pos: 1395
Info: drop database test
*************************** 19. row ***************************
Log_name: mysql-bin.000006
Pos: 1395
Event_type: Rotate
Server_id: 4294967295
End_log_pos: 1442
Info: mysql-bin.000007;pos=4
19 rows in set (0.00 sec)
通過分析,造成資料庫破壞的pos點區間是介於 1303--1395 之間,只要恢復到1395前就可。
- 現在先把凌晨備份的資料恢復:
mysql -S /data/mysql/data/mysql.sock -usys -p123456 -h192.168.1.200 -v < /tmp/bak_test.sql
注: 至此截至當日凌晨(1:00)前的備份資料都恢復了。
但今天一整天(1:00--現在)的資料腫麼辦呢?就得從前文提到的 mysql-bin.000007 新日誌做文章了...... - 從binlog日誌恢復資料
恢復語法格式:
# mysqlbinlog mysql-bin.0000xx | mysql -u使用者名稱 -p密碼 資料庫名
常用選項:
--start-position=953 起始pos點
--stop-position=1437 結束pos點
--start-datetime="2017-6-20 13:18:54" 起始時間點
--stop-datetime="2017-6-20 13:21:53" 結束時間點
--database=test 指定只恢復test資料庫(一臺主機上往往有多個數據庫,只限本地log日誌)
不常用選項:
-u --user=name Connect to the remote server as username.連線到遠端主機的使用者名稱
-p --password[=name] Password to connect to remote server.連線到遠端主機的密碼
-h --host=name Get the binlog from server.從遠端主機上獲取binlog日誌
--read-from-remote-server Read binary logs from a MySQL server.從某個MySQL伺服器上讀取binlog日誌
小結:實際是將讀出的binlog日誌內容,通過管道符傳遞給mysql命令。這些命令、檔案儘量寫成絕對路徑;
- 方法1:通過binlog日誌mysql-bin.000007直接恢復.
使用-d引數表示從binlog中只匯出test庫的資料.
mysqlbinlog mysql-bin.000007 -d test > mysql-bin.sql
然後vim mysql-bin.sql檔案,找到誤操作的mysql語句,一定要刪除.我們這裡誤操作的sql為drop database test,找到並刪除即可.
然後匯入/tmp/mysql-bin.sql檔案.
mysql -S /data/mysql/data/mysql.sock -usys -p123456 -h192.168.1.200 -v < /tmp/mysql-bin.sql
- 另一種指定位置點匯出sql的方法(-r和重定向是一個作用.):
mysqlbinlog mysqlbin.000020 --start-position=365 --stop-postition=456 -r pos.sql
- 方法2:指定pos點恢復資料(部分恢復):
A.指定pos結束點恢復某段時間的資料
@ --stop-position=759 pos結束點
注:此pos結束點介於“匯入實驗資料”與更新 name='UFO'之間,這樣可以恢復到更改name='BBA'之前的“匯入測試資料”
mysqlbinlog --stop-position=759 --database=test mysql-bin.000007 | mysql -S /data/mysql/data/mysql.sock -usys -p123456 -h192.168.1.200 -v test
在另一終端登入檢視結果(成功恢復了):
mysql> select * from yjh1;
+----+------+
| id | name |
+----+------+
| 1 | DBA |
| 2 | CBA |
| 3 | NBA |
| 4 | UFO |
+----+------+
4 rows in set (0.00 sec)
B.指定Pos點區間恢復(部分恢復):
更新name='BBA'這條資料, Info: use `test`; update test.yjh1 set name='BBA' where id=4
mysqlbinlog --start-position=759 --stop-position=880 --database=test mysql-bin.000007 | mysql -S /data/mysql/data/mysql.sock -usys -p123456 -h192.168.1.200 test
在另一終端登入檢視結果(成功恢復了):
mysql> select * from yjh1;
+----+------+
| id | name |
+----+------+
| 1 | DBA |
| 2 | CBA |
| 3 | NBA |
| 4 | BBA |
+----+------+
4 rows in set (0.00 sec)
事務區間:INFO資訊為兩個BEGIN 之間的為按事務區間分 如:Pos: 469 End_log_pos: 759
日誌區間:日誌區間為Pos: 759 到 End_log_pos: 880
除了用Pos點的辦法進行資料恢復,也可以通過指定時間區間進行恢復,按時間恢復需要用mysqlbinlog命令讀取binlog日誌內容,找時間節點。
例如:
@ --start-datetime="2017-6-20 13:18:54" 起始時間點
@ --stop-datetime="2013-16-20 14:21:53" 結束時間點
通過起始時間段則可以這樣恢復資料
mysqlbinlog --start-datetime="2017-6-20 13:18:54" --stop-datetime="2013-16-20 14:21:53" --database=test mysql-bin.000007 | mysql -S /data/mysql/data/mysql.sock -usys -p123456 -h192.168.1.200 -v test
總結:所謂恢復,就是讓MySQL將儲存在binlog日誌中指定段落區間的sql語句逐個重新執行一次而已。
--master-data引數解釋:
--master-data
該選項將binlog的位置和檔名追加到輸出檔案中。
- 如果為1,將會輸出CHANGE MASTER 命令;
- 如果為2,輸出的CHANGE MASTER命令前添加註釋資訊。
該選項將開啟--lock-all-tables選項,除非--single-transaction也被指定(在這種情況下,全域性讀鎖在開始匯出時獲得很短的時間;其他內容參考下面的--single-transaction選項)。
該選項自動關閉--lock-tables選項。
--master-data=1
從庫: 告訴從庫,從主庫的那個位置開始同步.
--master-data=2
註釋中記錄了需要獲取的binlog檔案和位置點
myisam備份場景:
myisam備份是要鎖表,不然資料可能會不一致.
mysqldump -uroot -p123456 -A -B --master-data=2 -x|gzip >/opt/all.sql.gz
innodb備份場景:
mysqldump -uroot -p123456 -A -B --master-data=2 --single-transaction|gzip >/opt/all.sql.gz
innoDB備份示例:
mysqldump --user=root --all-databases --flush-privileges --single-transaction --master-data=1 --flush-logs --triggers --routines --events --hex-blob > /tmp/full_dump.sql
五、常用binlog日誌操作命令
- 檢視所有binlog日誌列表
mysql> show master logs;
- 檢視master狀態,即最後(最新)一個binlog日誌的編號名稱,及其最後一個操作事件pos結束點(Position)值
mysql> show master status;
- 重新整理log日誌,自此刻開始產生一個新編號的binlog日誌檔案
mysql> flush logs;
注:每當mysqld服務重啟時,會自動執行此命令,重新整理binlog日誌;在mysqldump備份資料時加 -F 選項也會重新整理binlog日誌;
- binlog日誌的刪除
binlog的刪除可以手工刪除或自動刪除
自動刪除binlog
通過binlog引數(expire_logs_days)來實現mysql自動刪除binlog
mysql> show master logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000001 | 167 |
| mysql-bin.000002 | 531688179 |
| mysql-bin.000003 | 1091 |
| mysql-bin.000004 | 360363501 |
| mysql-bin.000005 | 1798 |
| mysql-bin.000006 | 577 |
| mysql-bin.000007 | 1056 |
| mysql-bin.000008 | 720729027 |
| mysql-bin.000009 | 3010 |
+------------------+-----------+
9 rows in set (0.00 sec)
mysql> show variables like 'expire_logs_days';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| expire_logs_days | 0 |
+------------------+-------+
1 row in set (0.00 sec)
mysql> set global expire_logs_days=14;
Query OK, 0 rows affected (0.00 sec)
mysql> show variables like 'expire_logs_days';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| expire_logs_days | 14 |
+------------------+-------+
1 row in set (0.01 sec)
手工刪除binlog
mysql> reset master; //清空所有的binlog日誌
mysql> reset slave; //清空slave的中繼日誌
mysql> purge master logs before '2017-03-30 00:20:00'; //刪除指定日期以前的日誌索引中binlog日誌檔案
mysql> purge master logs to 'mysql-bin.000009'; //刪除指定日誌檔案的日誌索引之前的日誌檔案
或者直接用作業系統命令直接刪除
- 顯示當前註冊的slave的列表。不以--report-host=slave_name選項為開頭的slave不會顯示在本列表中
mysql> show slave hosts;
MySQLbinlog的三種日誌模式:
1.Statement Level模式:
每一條會修改資料的sql都會記錄到master的bin-log中,slave在賦值的時候sql程序會解析成和master端執行過的相同的sql來再次執行.
日誌量小,節約IO,提高效能
2.Row Level模式:
日誌中會記錄成每一行資料被修改的形式,然後在slave端再對相同的資料進行修改
記錄下每一行資料修改的細節,解決函式、儲存過程等的複製問題.
日誌量大.
3.Mixed(混合)模式:
實際就是前兩種模式的結合,在Mixed模式下,MySQL會根據執行的每一條具體的sql語句來區分對待記錄的日誌形式,
也就是在Statement和Row之間選擇一種.
修改日誌模式的方式:
在配置檔案中修改:
log-bin=mysql-bin
binlog_format='STATEMENT'
binlog_format='ROW'
binlog_format='MIXED'
線上修改立即生效方法:
SET SESSION binlog_format = 'STATEMENT';
SET SESSION binlog_format = 'ROW';
SET SESSION binlog_format = 'MIXED';
全域性生效:
SET GLOBAL binlog_format = 'STATEMENT';
SET GLOBAL binlog_format = 'ROW';
SET GLOBAL binlog_format = 'MIXED';