1 REDOLOG / BINLOG
redolog | binlog | |
---|---|---|
日誌作用 | 保護髒數據 | 數據庫備份恢復使用 |
引擎支持 | 只適合InnoDB引擎 | 所有引擎 |
日誌格式 | 物理日誌 | 邏輯日誌,SQL語句 |
提交方式 | 快速提交 | 提交時一次性寫入 |
保存形式 | 會被循環覆蓋 | 長期保存 |
- redolog記錄的是對於每個頁的修改
- binlog只是記錄DML、DDL、DCL,不記錄SELECT
2 BINLOG參數
2.1 開啓binlog
修改配置文件/etc/my.cnf,在[mysqld]下添加:
log-bin = …/mydata5470/mysql-bin.log
2.2 存儲binlog
mysql> show variables like 'log_bin%';
+---------------------------------+--------------------------------------------------------+
| Variable_name | Value |
+---------------------------------+--------------------------------------------------------+
| log_bin | ON
| log_bin_basename | .../mydata5470/mysql-bin
| log_bin_index | .../mydata5470/master-log-bin.index
| log_bin_trust_function_creators | ON
| log_bin_use_v1_row_events | OFF
+---------------------------------+--------------------------------------------------------+
2.3 手工切換binlog
1、重啓數據庫,每次重啓都會新切binlog
2、mysql> flush logs;
2.4 查看binlog日誌文件
mysqlbinlog -vv mysql-bin.000005 | more
2.5 binlog_cache_size
show variables like 'binlog_cache_size';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| binlog_cache_size | 32768 |
+-------------------+-------+
所有未提交的二進制日誌文件會被記錄到用戶工作空間的binlog cache中,等該事務提交時直接將緩衝區中的binlog寫入二進制日誌文件裏。
show global status like 'Binlog_cache_disk_use';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| Binlog_cache_disk_use | 10 |
+-----------------------+-------+
判斷binlog_cache_size是否設置過小的依據,如果Binlog_cache_disk_use>0(次數),說明事務未提交,binlog在用戶工作空間存放不下,需要借用tmp目錄。
2.6 臨時關閉BINLOG
--log-bin [=file_name]:設置此參數表示啓用binlog功能,並指定路徑名稱,生產中都要開啓binlog。
重要:會話關閉
sql_log_bin
:會話級別的binlog開關控制,默認是開啓的,可以在當前會話級別動態修改臨時關閉binlog(主從延遲優化),set session sql_log_bin=0
;注意:SESSION級別的只會當前會話不記錄binlog
重要:全局關閉
set global sql_log_bin=0
:所有會話都會生效,但是當前所有已經連接上的會話不會生效。再次連接就生效了。
2.7 sync_binlog
//同步binlog的方式
0:默認,提交同步到文件系統緩存
1:commit,通過fsync方式,直接寫入disk的binlog文件中(最安全),與redo的雙一模式。
>1:sync_binlog=N,如果N>1,在意外發生的時候,就表示會有N-1個dml沒有被寫入binlog中,有可能就會發生主從數據不一致的情況。
2.8 max_binlog_size
//binlog文件大小,默認1G
如果是row模式,需要增加binlog文件的大小,因爲行模式產生的日誌量相對較大。如果超過了該值,就會產生新的日誌文件,後綴名+1,並且記錄到.index文件裏面。
2.9 binlog_format
//row、statement、mixed,設置binlog記錄的模式:行模式、語句模式、mixed模式。動態參數,可以會話級別修改
2.10 --binlog-do-db、--binlog-ingore-db
表示需要寫入或者忽略寫入哪些庫的日誌,默認爲空,表示可以將所有庫的日誌寫入到二進制文件裏面。
2.11 log-slave-updates
啓用從機服務器上的slave日誌功能,使這臺計算機可以用來構成一個鏡像鏈(A->B->C) ,可以讓從庫上面產生二進制日誌文件,在從庫上再掛載一個從庫
2.12 binlog_rows_query_log_events
便於定位執行過的SQL語句
2.13 expire_logs_days
binlog過期清理時間,默認是0:不自動清除
binlog的刪除策略,假設expire_logs_days=5,表示系統保留5天binlog,第六天到來時會刪除
3 binlog_format
1、STATEMENT
每一條會修改數據的sql都會記錄在binlog中。
優點:不需要記錄每一行的變化,減少了binlog日誌量,節約了IO,提高性能。只需要記錄在 master 上所執行的語句的細節,以及執行語句時候的上下文的信息。
缺點:由於記錄的只是執行語句,爲了這些語句能在slave上正確運行,因此還必須記錄每條語句在執行的時候的一些相關信息,以保證所有語句能在slave得到和在master端執行時候相同的結果。像一些特定函數功能,slave可與master上要保持一致會有很多相關問題(如sleep()函數,rand()函數等會出現問題warning)。
2、ROW
不記錄sql語句上下文相關信息,僅保存哪條記錄被修改,也就是說日誌中會記錄成每一行數據被修改的形式,然後在 slave 端再對相同的數據進行修改。
優點:binlog中可以不記錄執行的sql語句的上下文相關的信息,僅需要記錄那一條記錄被修改成什麼了。所以rowlevel的日誌內容會非常清楚的記錄下每一行數據修改的細節。而且不會出現某些特定情況下的存儲過程,或function,以及trigger的調用和觸發無法被正確複製的問題。
缺點:在 row 模式下,所有的執行的語句當記錄到日誌中的時候,都將以每行記錄的修改來記錄,這樣可能會產生大量的日誌內容。
3、MIXED
是以上兩種level的混合使用,一般的語句修改使用statment格式保存binlog,如一些函數,statement無法完成主從複製的操作,則採用row格式保存binlog,MySQL會根據執行的每一條具體的sql語句來區分對待記錄的日誌形式,也就是在Statement和Row之間選擇一種;
新版本的MySQL中對row模式也被做了優化,並不是所有的修改都會以rowl來記錄,像遇到表結構變更的時候就會以statement模式來記錄。至於update或者delete等修改數據的語句,還是會記錄所有行的變更。
4 使用場景
-
二進制日誌兩個最重要的使用場景
- MySQL replication在master端開啓binlog,master把它的二進制日誌傳遞給slaves來達到master-slave數據一致的目的,也就是主從備份。
- 數據恢復,通過使用mysqlbinlog工具來使恢復數據
-
常用binlog日誌操作命令
- 查看所有binlog日誌列表
mysql> show master logs;
- 查看master狀態,即最後(最新)一個binlog日誌的編號名稱,及其最後一個操作事件pos結束點(Position)值
mysql> show master status;
//結合上述binlog文件,進行binlog生成速度監控 - 刷新log日誌,自此刻開始產生一個新編號的binlog日誌文件
mysql> flush logs;
//注:每當mysqld服務重啓時,會自動執行此命令,刷新binlog日誌;在mysqldump備份數據時加 -F 選項也會刷新binlog日誌; - 重置(清空)所有binlog日誌
mysql> reset master;
- 查看所有binlog日誌列表
-
查看binlog日誌內容
- OS層面查看binlog文件
shell> mysqlbinlog -vv mysql-bin.000001
- 數據庫層面show binlog events
mysql> show binlog events [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count];
選項解析:
- OS層面查看binlog文件
1、in 'log_name':指定要查詢的binlog文件名(不指定就是第一個binlog文件)
2、from pos:指定從哪個pos起始點開始查起(不指定就是從整個文件首個pos點開始算)
3、limit [offset,]:偏移量(不指定就是0)
4、row_count:查詢總條數(不指定就是所有行)
-
從binlog日誌恢復語法
1、恢復語法格式: # mysqlbinlog [選項] mysql-bin.0000xx | mysql -u用戶名 -p密碼 數據庫名 2、常用選項: --start-position=953 起始pos點 --stop-position=1437 結束pos點 --start-datetime="2017-6-8 13:18:54" 起始時間點 --stop-datetime="2017-6-8 13:21:53" 結束時間點 --database=TEST 指定只恢復TEST數據庫(一臺主機上往往有多個數據庫,只限本地log日誌) 3、不常用選項: -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命令。這些命令、文件儘量寫成絕對路徑;所謂恢復,就是讓MySQL將保存在binlog日誌中指定段落區間的SQL語句逐個重新執行一次而已。
關於雙一模式
1、redolog、binlog:雙1(絕對安全)
1、innodb_flush_log_at_trx_commit=1
2、sync_binlog=1
2、innodb_support_xa=1:分佈式事務,默認開啓ON
1、保證binlog裏面存在的事務一定在redo log裏面存在
2、保證binlog裏面事務順序與redo log事務順序一致性
3、commit,要麼成功要麼失敗,防止出現主從不一致
所以在雙一的情況下,也要配合開啓innodb_support_xa,更安全。