(轉)Mysql數據庫之Binlog日誌使用總結

 使用mysqlbinlog提取二進制日誌

原文：http://blog.csdn.net/leshami/article/details/41962243

 MySQL binlog日誌記錄了MySQL數據庫從啓用日誌以來全部對當前數據庫的變動。binlog日誌屬於二進制文件，咱們能夠從binlog提取出來生成可閱讀的SQL語句來重建當前數據庫以及根據須要實現時點恢復或不徹底恢復。本文主要描述了若是提取binlog日誌，並給出相關示例。

    有關binlog的介紹與描述請參考：MySQL 二進制日誌(Binary Log)

 

一、提取mysqlbinlog的幾種方式
a、使用show binlog events方式能夠獲取當前以及指定binlog的日誌，不適宜提取大量日誌。
b、使用mysqlbinlog命令行提取(適宜批量提取日誌)。

 

二、演示show binlog events方式

mysql> show variables like 'version';
+---------------+------------+
| Variable_name | Value      |
+---------------+------------+
| version       | 5.6.12-log |
+---------------+------------+

mysql> show binary logs;
+-----------------+-----------+
| Log_name        | File_size |
+-----------------+-----------+
| APP01bin.000001 |       120 |
+-----------------+-----------+

a、只查看第一個binlog文件的內容(show binlog events)
mysql> use replication;
Database changed
mysql> select * from tb;
+------+-------+
| id   | val   |
+------+-------+
|    1 | robin |
+------+-------+

mysql> insert into tb values(2,'jack');
Query OK, 1 row affected (0.02 sec)

mysql> flush logs;
Query OK, 0 rows affected (0.00 sec)

mysql> insert into tb values(3,'fred');
Query OK, 1 row affected (0.00 sec)

mysql> show binary logs;
+-----------------+-----------+
| Log_name        | File_size |
+-----------------+-----------+
| APP01bin.000001 |       409 |
| APP01bin.000002 |       363 |
+-----------------+-----------+

mysql> show binlog events;
+-----------------+-----+-------------+-----------+-------------+----------------------------------------------------+
| Log_name        | Pos | Event_type  | Server_id | End_log_pos | Info                                               |
+-----------------+-----+-------------+-----------+-------------+----------------------------------------------------+
| APP01bin.000001 |   4 | Format_desc |        11 |         120 | Server ver: 5.6.12-log, Binlog ver: 4              |
| APP01bin.000001 | 120 | Query       |        11 |         213 | BEGIN                                              |
| APP01bin.000001 | 213 | Query       |        11 |         332 | use `replication`; insert into tb values(2,'jack') |
| APP01bin.000001 | 332 | Xid         |        11 |         363 | COMMIT /* xid=382 */                               |
| APP01bin.000001 | 363 | Rotate      |        11 |         409 | APP01bin.000002;pos=4                              |
+-----------------+-----+-------------+-----------+-------------+----------------------------------------------------+
-- 在上面的結果中第3行能夠看到咱們執行的SQL語句，第4行爲自動提交
-- Author : Leshami
-- Blog   : http://blog.csdn.net/leshami

b、查看指定binlog文件的內容(show binlog events in 'binname.xxxxx')
mysql> show binlog events in 'APP01bin.000002';
+-----------------+-----+-------------+-----------+-------------+----------------------------------------------------+
| Log_name        | Pos | Event_type  | Server_id | End_log_pos | Info                                               |
+-----------------+-----+-------------+-----------+-------------+----------------------------------------------------+
| APP01bin.000002 |   4 | Format_desc |        11 |         120 | Server ver: 5.6.12-log, Binlog ver: 4              |
| APP01bin.000002 | 120 | Query       |        11 |         213 | BEGIN                                              |
| APP01bin.000002 | 213 | Query       |        11 |         332 | use `replication`; insert into tb values(3,'fred') |
| APP01bin.000002 | 332 | Xid         |        11 |         363 | COMMIT /* xid=394 */                               |
+-----------------+-----+-------------+-----------+-------------+----------------------------------------------------+

c、查看當前正在寫入的binlog文件(show master status\G)
mysql> show master status\G
*************************** 1. row ***************************
             File: APP01bin.000002
         Position: 363
     Binlog_Do_DB:
 Binlog_Ignore_DB:
Executed_Gtid_Set:
1 row in set (0.00 sec)

d、獲取指定位置binlog的內容(show binlog events from)
mysql> show binlog events from 213;
+-----------------+-----+------------+-----------+-------------+----------------------------------------------------+
| Log_name        | Pos | Event_type | Server_id | End_log_pos | Info                                               |
+-----------------+-----+------------+-----------+-------------+----------------------------------------------------+
| APP01bin.000001 | 213 | Query      |        11 |         332 | use `replication`; insert into tb values(2,'jack') |
| APP01bin.000001 | 332 | Xid        |        11 |         363 | COMMIT /* xid=382 */                               |
| APP01bin.000001 | 363 | Rotate     |        11 |         409 | APP01bin.000002;pos=4                              |
+-----------------+-----+------------+-----------+-------------+----------------------------------------------------+

三、演示mysqlbinlog方式提取binlog

a、提取指定的binlog日誌
# mysqlbinlog /opt/data/APP01bin.000001
# mysqlbinlog /opt/data/APP01bin.000001|grep insert
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
insert into tb values(2,'jack')

b、提取指定position位置的binlog日誌
# mysqlbinlog --start-position="120" --stop-position="332" /opt/data/APP01bin.000001

c、提取指定position位置的binlog日誌並輸出到壓縮文件
# mysqlbinlog --start-position="120" --stop-position="332" /opt/data/APP01bin.000001 |gzip >extra_01.sql.gz

d、提取指定position位置的binlog日誌導入數據庫
# mysqlbinlog --start-position="120" --stop-position="332" /opt/data/APP01bin.000001 | mysql -uroot -p

e、提取指定開始時間的binlog並輸出到日誌文件
# mysqlbinlog --start-datetime="2014-12-15 20:15:23" /opt/data/APP01bin.000002 --result-file=extra02.sql

f、提取指定位置的多個binlog日誌文件
# mysqlbinlog --start-position="120" --stop-position="332" /opt/data/APP01bin.000001 /opt/data/APP01bin.000002|more

g、提取指定數據庫binlog並轉換字符集到UTF8
# mysqlbinlog --database=test --set-charset=utf8 /opt/data/APP01bin.000001 /opt/data/APP01bin.000002 >test.sql

h、遠程提取日誌，指定結束時間
# mysqlbinlog -urobin -p -h192.168.1.116 -P3306 --stop-datetime="2014-12-15 20:30:23" --read-from-remote-server mysql-bin.000033 |more

i、遠程提取使用row格式的binlog日誌並輸出到本地文件
# mysqlbinlog -urobin -p -P3606 -h192.168.1.177 --read-from-remote-server -vv inst3606bin.000005 >row.sql

四、獲取mysqlbinlog的幫助信息(僅列出經常使用選項)
-?, --help
   顯示幫助消息並退出。

-d, --database=name
   只列出該數據庫的條目(只適用本地日誌)。

-f, --force-read
   使用該選項，若是mysqlbinlog讀它不能識別的二進制日誌事件，它會打印警告，忽略該事件並繼續。沒有該選項，若是mysqlbinlog讀到此類事件則中止。

-h, --host=name
   獲取給定主機上的MySQL服務器的二進制日誌。

-l, --local-load=name
   爲指定目錄中的LOAD DATA INFILE預處理本地臨時文件。

-o, --offset=# 
   跳過前N個條目。

-p, --password[=name]
   當鏈接服務器時使用的密碼。若是使用短選項形式(-p)，選項和密碼之間不能有空格。 
   若是在命令行中–password或-p選項後面沒有密碼值，則提示輸入一個密碼。

-P, --port=# 
   用於鏈接遠程服務器的TCP/IP端口號。

--protocol=name
   使用的鏈接協議。

-R, --read-from-remote-server|--read-from-remote-master=name
   從MySQL服務器讀二進制日誌。若是未給出該選項，任何鏈接參數選項將被忽略，即鏈接到本地。
   這些選項是–host、–password、–port、–protocol、–socket和–user。

-r, --result-file=name 
   將輸出指向給定的文件。

-s, --short-form
   只顯示日誌中包含的語句，不顯示其它信息，該方式能夠縮小生成sql文件的尺寸。

-S, --socket=name
   用於鏈接的套接字文件。

--start-datetime=name
   從二進制日誌中讀取等於或晚於datetime參量的事件，datetime值相對於運行mysqlbinlog的機器上的本地時區。
   該值格式應符合DATETIME或TIMESTAMP數據類型。例如：2004-12-25 11:25:56 ，建議使用引號標識。

--stop-datetime=name
   從二進制日誌中讀取小於或等於datetime的全部日誌事件。關於datetime值的描述參見--start-datetime選項。

-j, --start-position=# 
   從二進制日誌中第1個位置等於N參量時的事件開始讀。

--stop-position=#
   從二進制日誌中第1個位置等於和大於N參量時的事件起中止讀。

--server-id=#   
   僅僅提取指定server_id的binlog日誌

--set-charset=name 
   添加SET NAMES character_set到輸出      
                
-t, --to-last-log 
   在MySQL服務器中請求的二進制日誌的結尾處不中止，而是繼續打印直到最後一個二進制日誌的結尾。
   若是將輸出發送給同一臺MySQL服務器，會致使無限循環。該選項要求–read-from-remote-server。

-D, --disable-log-bin
   禁用二進制日誌。若是使用–to-last-logs選項將輸出發送給同一臺MySQL服務器，能夠避免無限循環。
   該選項在崩潰恢復時也頗有用，能夠避免複製已經記錄的語句。註釋：該選項要求有SUPER權限。

-u, --user=name
   鏈接遠程服務器時使用的MySQL用戶名。

-v, --verbose
   用於輸出基於row模式的binlog日誌，-vv爲列數據類型添加註釋

-V, --version
   顯示版本信息並退出。

 

五、小結
a、能夠經過show binlog events以及mysqlbinlog方式來提取binlog日誌。
b、show binlog events 參數有限不適宜批量提取，mysqlbinlog可用於批量提取來創建恢復數據庫的SQL。
c、mysqlbinlog能夠基於時間點，position等方式實現不徹底恢復或時點恢復。
d、mysqlbinlog能夠從支持本地或遠程方式提取binlog日誌。
e、mysqlbinlog能夠基於server_id，以及基於數據庫級別提取日誌，不支持表級別。

 

Mysql數據庫之Binlog日誌使用總結

原文:http://www.cnblogs.com/kevingrace/p/6065088.html

binlog二進制日誌對於mysql數據庫的重要性有多大，在此就很少說了。下面根據本人的平常操做經歷，並結合網上參考資料，對binlog日誌使用作一梳理：

1、binlog日誌介紹
1）什麼是binlog
binlog日誌用於記錄全部更新了數據或者已經潛在更新了數據（例如，沒有匹配任何行的一個DELETE）的全部語句。語句以「事件」的形式保存，它描述數據更改。

2）binlog做用
由於有了數據更新的binlog，因此能夠用於實時備份，與master/slave主從複製結合。

3）和binlog有關參數
log_bin
設置此參數表示啓用binlog功能，並指定路徑名稱
log_bin_index
設置此參數是指定二進制索引文件的路徑與名稱
binlog_do_db
此參數表示只記錄指定數據庫的二進制日誌
binlog_ignore_db
此參數表示不記錄指定的數據庫的二進制日誌
max_binlog_cache_size
此參數表示binlog使用的內存最大的尺寸
binlog_cache_size
此參數表示binlog使用的內存大小，能夠經過狀態變量binlog_cache_use和binlog_cache_disk_use來幫助測試。
binlog_cache_use：使用二進制日誌緩存的事務數量
binlog_cache_disk_use:使用二進制日誌緩存但超過binlog_cache_size值並使用臨時文件來保存事務中的語句的事務數量

max_binlog_size
Binlog最大值，最大和默認值是1GB，該設置並不能嚴格控制Binlog的大小，尤爲是Binlog比較靠近最大值而又遇到一個比較大事務時，爲了保證事務的完整性，不可能作切換日誌的動做，只能將該事務的全部SQL都記錄進當前日誌，直到事務結束
sync_binlog
這個參數直接影響mysql的性能和完整性
sync_binlog=0
當事務提交後，Mysql僅僅是將binlog_cache中的數據寫入Binlog文件，但不執行fsync之類的磁盤 同步指令通知文件系統將緩存刷新到磁盤，而讓Filesystem自行決定何時來作同步，這個是性能最好的。
sync_binlog=n，在進行n次事務提交之後，Mysql將執行一次fsync之類的磁盤同步指令，同志文件系統將Binlog文件緩存刷新到磁盤。
Mysql中默認的設置是sync_binlog=0，即不做任何強制性的磁盤刷新指令，這時性能是最好的，但風險也是最大的。一旦系統繃Crash，在文件系統緩存中的全部Binlog信息都會丟失

4）binlog的刪除
binlog的刪除能夠手工刪除或自動刪除：
a）自動刪除binlog
經過binlog參數（expire_logs_days ）來實現mysql自動刪除binlog
mysql> show binary logs;
mysql> show variables like 'expire_logs_days';      //該參數表示binlog日誌自動刪除/過時的天數，默認值爲0，表示不自動刪除
mysql> set global expire_logs_days=3;        //表示日誌保留3天，3天后就自動過時。
b）手工刪除binlog
mysql> reset master;        //刪除master的binlog，即手動刪除全部的binlog日誌
mysql> reset slave;          //刪除slave的中繼日誌
mysql> purge master logs before '2012-03-30 17:20:00';         //刪除指定日期之前的日誌索引中binlog日誌文件
mysql> purge master logs to 'binlog.000002';       //刪除指定日誌文件的日誌索引中binlog日誌文件

mysql> set sql_log_bin=1/0;       //若是用戶有super權限，能夠啓用或禁用當前會話的binlog記錄
mysql> show master logs;          //查看master的binlog日誌列表
mysql> show binary logs;           //查看master的binlog日誌文件大小
mysql> show master status;     //用於提供master二進制日誌文件的狀態信息
mysql> show slave hosts;        //顯示當前註冊的slave的列表。不以--report-host=slave_name選項爲開頭的slave不會顯示在本列表中

mysql> flush logs;     //產生一個新的binlog日誌文件

 

mysql binlog日誌自動清理及手動刪除案例說明：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52

當開啓MySQL數據庫主從時，會產生大量如mysql-bin.00000*  log 的文件，這會大量耗費您的硬盤空間。 mysql-bin.000001 mysql-bin.000002 mysql-bin.000003 mysql-bin.000004 mysql-bin.000005 …   刪除這些binlog日誌有三種解決方法： 1.關閉mysql主從，關閉binlog； 實例操做以下： [root@huqniupc ~]# vim /etc/my.cnf     //註釋掉log-bin和binlog_format # Replication Master Server (default) # binary logging is required for replication # log-bin=mysql-bin # binary logging format - mixed recommended # binlog_format=mixed 而後重啓數據庫   2.開啓mysql主從，設置expire_logs_days； 實例操做以下： [root@huqniupc ~]# vim /etc/my.cnf   //修改expire_logs_days,x是自動刪除的天數，通常將x設置爲短點，如10 expire_logs_days = x   //二進制日誌自動刪除的天數。默認值爲0,表示「沒有自動刪除」 此方法須要重啓mysql   固然也能夠不重啓mysql,開啓mysql主從，直接在mysql裏設置expire_logs_days > show binary logs; > show variables like  '%log%' ; > set global expire_logs_days = 10;     3.手動清除binlog文件，(好比Mysql> PURGE MASTER LOGS TO ‘MySQL-bin.010′;） 實例操做以下： [root@huqniupc ~]# /usr/local/mysql/bin/mysql -u root -p > PURGE MASTER LOGS BEFORE DATE_SUB(CURRENT_DATE, INTERVAL 10 DAY);    //刪除10天前的MySQL binlog日誌,附錄2有關於PURGE MASTER LOGS手動刪除用法及示例 > show master logs;    也能夠重置master，刪除全部binlog文件： # /usr/local/mysql/bin/mysql -u root -p > reset master;   //附錄3有清除binlog時，對從mysql的影響說明    ----------------------------------------------------------------------------------------------------------------------------------------------- PURGE MASTER LOGS手動刪除用法及示例,MASTER和BINARY是同義詞 > PURGE {MASTER | BINARY} LOGS TO  'log_name' > PURGE {MASTER | BINARY} LOGS BEFORE  'date' 刪除指定的日誌或日期以前的日誌索引中的全部二進制日誌。這些日誌也會從記錄在日誌索引文件中的清單中被刪除MySQL BIN-LOG 日誌，這樣被給定的日誌成爲第一個。   實例： > PURGE MASTER LOGS TO  'MySQL-bin.010' ;   //清除MySQL-bin.010日誌 > PURGE MASTER LOGS BEFORE  '2008-06-22 13:00:00' ;    //清除2008-06-22 13:00:00前binlog日誌 > PURGE MASTER LOGS BEFORE DATE_SUB( NOW( ), INTERVAL 3 DAY);   //清除3天前binlog日誌BEFORE，變量的date自變量能夠爲'YYYY-MM-DD hh:mm:ss'格式。 -----------------------------------------------------------------------------------------------------------------------------------------------

5）清除binlog時，對從mysql的影響
若是有一個活躍的slave從屬服務器，該服務器當前正在讀取您正在試圖刪除的日誌之一，則本語句不會起做用，而是會失敗，並伴隨一個錯誤；不過若是slave從屬服務器是關閉的（或master-slave主從關係關閉），而且碰巧清理了其想要讀取的日誌之一，則slave從屬服務器啓動後不能複製；當從屬服務器正在複製時，本語句能夠安全運行，不須要中止它們。

6）binglog的查看
經過mysqlbinlog命令能夠查看binlog的內容
[root@localhost ~]# mysqlbinlog /home/mysql/binlog/binlog.000003 | more
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#120330 16:51:46 server id 1 end_log_pos 98 Start: binlog v 4, server v 5.0.45-log created 120330 1
6:51:46
# Warning: this binlog was not closed properly. Most probably mysqld crashed writing it.
# at 196
#120330 17:54:15 server id 1 end_log_pos 294 Query thread_id=3 exec_time=2 error_code=0
SET TIMESTAMP=1333101255/*!*/;
insert into tt7 select * from tt7/*!*/;
# at 294
#120330 17:54:46 server id 1 end_log_pos 388 Query thread_id=3 exec_time=28 error_code=0
SET TIMESTAMP=1333101286/*!*/;
alter table tt7 engine=innodb/*!*/;

解析binlog格式：
位置
位於文件中的位置，「at 196」說明「事件」的起點，是以第196字節開始；「end_log_pos 294」說明以第294字節結束

時間戳
事件發生的時間戳：「120330 17:54:46」

事件執行時間
事件執行花費的時間:"exec_time=28"

錯誤碼
錯誤碼爲：「error_code=0」

服務器的標識
服務器的標識id：「server id 1」

注意下面幾點：
1.mysql的日誌切不可想象是能夠恢復到任什麼時候間的狀態，這個恢復是有前提的！
至少得有一個從日誌記錄開始後的數據庫備份，經過日誌恢復數據庫實際上只是一個對之前操做的回放過程而已，不用想得太複雜。
既然是回放操做，那麼就得注意了，若是是執行了兩次恢復那就至關因而回放了兩次，後果可想而知。
因此：
1）恢復前務必先備份數據.
2）因爲二進制文件多,而且須要恢復的數據跨度大,能夠考慮將日誌文件合併在恢復.

2. 開啓binlog日誌功能
要想經過日誌恢復數據庫，必須首先在my.cnf文件裏定義，log-bin=mysql-bin，這樣產生的binlog日誌名就是以mysql-bin命名的

3.何時會生成新的binlog文件
1）在備份的時候加入--flush-logs
2）從新啓動mysql服務的時候
特別提示，mysql每次啓動都會從新生成一個相似mysql-bin.00000n的文件，若是你的mysql天天都要從新啓動一次的話，這時候你就要特別注意不要選錯日誌文件了。

 

2、binlog日誌格式介紹 

（1）Mysql binlog日誌有三種格式，分別是Statement、MiXED、ROW

1）Statement：每一條會修改數據的sql都會記錄在binlog中
優勢：不須要記錄每一行的變化，減小了binlog日誌量，節約了IO，提升性能。(相比row能節約多少性能與日誌量，這個取決於應用的SQL狀況，正常同一條記錄修改或者插入row格式所產生的日誌量還小於Statement產生的日誌量，可是考慮到若是帶條件的update操做，以及整表刪除，alter表等操做，ROW格式會產生大量日誌，所以在考慮是否使用ROW格式日誌時應該跟據應用的實際狀況，其所產生的日誌量會增長多少，以及帶來的IO性能問題。)
缺點：因爲記錄的只是執行語句，爲了這些語句能在slave上正確運行，所以還必須記錄每條語句在執行的時候的一些相關信息，以保證全部語句能在slave獲得和在master端執行時候相同 的結果。另外mysql 的複製,像一些特定函數功能，slave可與master上要保持一致會有不少相關問題(如sleep()函數， last_insert_id()，以及user-defined functions(udf)會出現問題).

使用如下函數的語句也沒法被複制：
* LOAD_FILE()
* UUID()
* USER()
* FOUND_ROWS()
* SYSDATE() (除非啓動時啓用了 --sysdate-is-now 選項)

同時在INSERT ...SELECT 會產生比 RBR 更多的行級鎖

2）Row:不記錄sql語句上下文相關信息，僅保存哪條記錄被修改
優勢： binlog中能夠不記錄執行的sql語句的上下文相關的信息，僅須要記錄那一條記錄被修改爲什麼了。因此rowlevel的日誌內容會很是清楚的記錄下每一行數據修改的細節。並且不會出現某些特定狀況下的存儲過程，或function，以及trigger的調用和觸發沒法被正確複製的問題
缺點:全部的執行的語句當記錄到日誌中的時候，都將以每行記錄的修改來記錄，這樣可能會產生大量的日誌內容,好比一條update語句，修改多條記錄，則binlog中每一條修改都會有記錄，這樣形成binlog日誌量會很大，特別是當執行alter table之類的語句的時候，因爲表結構修改，每條記錄都發生改變，那麼該表每一條記錄都會記錄到日誌中。

3）Mixedlevel: 是以上兩種level的混合使用，通常的語句修改使用statment格式保存binlog，如一些函數，statement沒法完成主從複製的操做，則採用row格式保存binlog,MySQL會根據執行的每一條具體的sql語句來區分對待記錄的日誌形式，也就是在Statement和Row之間選擇一種.新版本的MySQL中隊row level模式也被作了優化，並非全部的修改都會以row level來記錄，像遇到表結構變動的時候就會以statement模式來記錄。至於update或者delete等修改數據的語句，仍是會記錄全部行的變動。

Mixed日誌說明：
在slave日誌同步過程當中，對於使用now這樣的時間函數，MIXED日誌格式，會在日誌中產生對應的unix_timestamp()*1000的時間字符串，slave在完成同步時，取用的是sqlEvent發生的時間來保證數據的準確性。另外對於一些功能性函數slave能完成相應的數據同步，而對於上面指定的一些相似於UDF函數，致使Slave沒法知曉的狀況，則會採用ROW格式存儲這些Binlog，以保證產生的Binlog能夠供Slave完成數據同步。

（2）binlog基本配製與格式設定
1）基本配製
binlog日誌格式能夠經過mysql的my.cnf文件的屬性binlog_format指定。如如下：
binlog_format = MIXED              //binlog日誌格式
log_bin =目錄/mysql-bin.log       //binlog日誌名
expire_logs_days = 7                 //binlog過時清理時間
max_binlog_size 100m              //binlog每一個日誌文件大小

binlog-do-db=須要備份的數據庫名，若是備份多個數據庫，重複設置這個選項便可
binlog-ignore-db=不須要備份的數據庫苦命，若是備份多個數據庫，重複設置這個選項便可

2）Binlog日誌格式選擇
Mysql默認是使用Statement日誌格式，推薦使用MIXED.
因爲一些特殊使用，能夠考慮使用ROWED，如本身經過binlog日誌來同步數據的修改，這樣會節省不少相關操做。對於binlog數據處理會變得很是輕鬆,相對mixed，解析也會很輕鬆(固然前提是增長的日誌量所帶來的IO開銷在容忍的範圍內便可)。

3）mysqlbinlog格式選擇
mysql對於日誌格式的選定原則:若是是採用 INSERT，UPDATE，DELETE 等直接操做表的狀況，則日誌格式根據 binlog_format 的設定而記錄,若是是採用 GRANT，REVOKE，SET PASSWORD 等管理語句來作的話，那麼不管如何 都採用 SBR 模式記錄

（3）Mysql Binlog日誌分析

經過MysqlBinlog指令查看具體的mysql日誌，以下:

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

SET TIMESTAMP=1350355892/*!*/;

BEGIN

/*!*/;

# at 1643330

#121016 10:51:32 server id 1 end_log_pos 1643885 Query thread_id=272571 exec_time=0 error_code=0

SET TIMESTAMP=1350355892/*!*/;

Insert into T_test….)

/*!*/;

# at 1643885

#121016 10:51:32 server id 1 end_log_pos 1643912 Xid = 0

COMMIT/*!*/;

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

1.開始事物的時間:

SET TIMESTAMP=1350355892/*!*/;

BEGIN

2.sqlevent起點

#at 1643330 :爲事件的起點，是以1643330字節開始。

3.sqlevent 發生的時間點

#121016 10:51:32:是事件發生的時間，

4.serverId

server id 1 :爲master 的serverId

5.sqlevent終點及花費時間，錯誤碼

end_log_pos 1643885:爲事件的終點，是以1643885 字節結束。

execTime 0: 花費的時間

error_code=0:錯誤碼

Xid:事件指示提交的XA事務

 

3、mysql日誌（重點binlog日誌）的優化說明
MySQL系統的伸縮性很強，既能夠在充足的硬件資源環境下高效運行，也能夠在極少資源環境下很好的運行，
但無論怎樣，儘量充足的硬件資源對MySQL的性能提高老是有幫助的。

下面着重分析一下MySQL的日誌（主要是Binlog）對系統性能的影響，並根據日誌的相關特性得出相應的優化思路。

1）日誌產生的性能影響
因爲日誌的記錄帶來的直接性能損耗就是數據庫系統中最爲昂貴的IO資源。

MySQL的日誌主要包括錯誤日誌（ErrorLog），更新日誌（UpdateLog），二進制日誌（Binlog），查詢日誌（QueryLog），慢查詢日誌（SlowQueryLog）等。
特別注意：更新日誌是老版本的MySQL纔有的，目前已經被二進制日誌替代。

在默認狀況下，系統僅僅打開錯誤日誌，關閉了其餘全部日誌，以達到儘量減小IO損耗提升系統性能的目的。
可是在通常稍微重要一點的實際應用場景中，都至少須要打開二進制日誌，由於這是MySQL不少存儲引擎進行增量備份的基礎，也是MySQL實現複製的基本條件。
有時候爲了進一步的mysql性能優化，定位執行較慢的SQL語句，不少系統也會打開慢查詢日誌來記錄執行時間超過特定數值（由咱們自行設置）的SQL語句。

通常狀況下，在生產系統中不多有系統會打開查詢日誌。由於查詢日誌打開以後會將MySQL中執行的每一條Query都記錄到日誌中，會該系統帶來比較大的IO負擔，而帶來的實際效益卻並非很是大。通常只有在開發測試環境中，爲了定位某些功能具體使用了哪些SQL語句的時候，纔會在短期段內打開該日誌來作相應的分析。
因此，在MySQL系統中，會對性能產生影響的MySQL日誌（不包括各存儲引擎本身的日誌）主要就是Binlog了。

2）Binlog 相關參數及優化策略
咱們首先看看Binlog的相關參數，經過執行以下命令能夠得到關於Binlog的相關參數。
固然，其中也顯示出了「innodb_locks_unsafe_for_binlog」這個Innodb存儲引擎特有的與Binlog相關的參數：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

mysql> show variables  like  '%binlog%' ; + -----------------------------------------+----------------------+ | Variable_name                           | Value                | + -----------------------------------------+----------------------+ | binlog_cache_size                       | 16777216             | | binlog_checksum                         | CRC32                | | binlog_direct_non_transactional_updates |  OFF                   | | binlog_error_action                     | IGNORE_ERROR         | | binlog_format                           | MIXED                | | binlog_gtid_simple_recovery             |  OFF                   | | binlog_max_flush_queue_time             | 0                    | | binlog_order_commits                    |  ON                    | | binlog_row_image                        |  FULL                  | | binlog_rows_query_log_events            |  OFF                   | | binlog_stmt_cache_size                  | 32768                | | binlogging_impossible_mode              | IGNORE_ERROR         | | innodb_api_enable_binlog                |  OFF                   | | innodb_locks_unsafe_for_binlog          |  OFF                   | | max_binlog_cache_size                   | 18446744073709547520 | | max_binlog_size                         | 1073741824           | | max_binlog_stmt_cache_size              | 18446744073709547520 | | simplified_binlog_gtid_recovery         |  OFF                   | | sync_binlog                             | 1                    | + -----------------------------------------+----------------------+ 19  rows  in  set  (0.00 sec)

「binlog_cache_size"：在事務過程當中容納二進制日誌SQL語句的緩存大小。二進制日誌緩存是服務器支持事務存儲引擎而且服務器啓用了二進制日誌(—log-bin選項)的前提下爲每一個客戶端分配的內存，注意，是每一個Client均可以分配設置大小的binlogcache空間。若是讀者朋友的系統中常常會出現多語句事務的華，能夠嘗試增長該值的大小，以得到更有的性能。固然，咱們能夠經過MySQL的如下兩個狀態變量來判斷當前的binlog_cache_size的情況：Binlog_cache_use和Binlog_cache_disk_use。

「max_binlog_cache_size」：和"binlog_cache_size"相對應，可是所表明的是binlog可以使用的最大cache內存大小。當咱們執行多語句事務的時候，max_binlog_cache_size若是不夠大的話，系統可能會報出「Multi-statementtransactionrequiredmorethan'max_binlog_cache_size'bytesofstorage」的錯誤。

「max_binlog_size」：Binlog日誌最大值，通常來講設置爲512M或者1G，但不能超過1G。該大小並不能很是嚴格控制Binlog大小，尤爲是當到達Binlog比較靠近尾部而又遇到一個較大事務的時候，系統爲了保證事務的完整性，不可能作切換日誌的動做，只能將該事務的全部SQL都記錄進入當前日誌，直到該事務結束。這一點和Oracle的Redo日誌有點不同，由於Oracle的Redo日誌所記錄的是數據文件的物理位置的變化，並且裏面同時記錄了Redo和Undo相關的信息，因此同一個事務是否在一個日誌中對Oracle來講並不關鍵。而MySQL在Binlog中所記錄的是數據庫邏輯變化信息，MySQL稱之爲Event，實際上就是帶來數據庫變化的DML之類的Query語句。

「sync_binlog」：這個參數是對於MySQL系統來講是相當重要的，他不只影響到Binlog對MySQL所帶來的性能損耗，並且還影響到MySQL中數據的完整性。對於「sync_binlog」參數的各類設置的說明以下：

sync_binlog=0，當事務提交以後，MySQL不作fsync之類的磁盤同步指令刷新binlog_cache中的信息到磁盤，而讓Filesystem自行決定何時來作同步，或者cache滿了以後才同步到磁盤。

sync_binlog=n，當每進行n次事務提交以後，MySQL將進行一次fsync之類的磁盤同步指令來將binlog_cache中的數據強制寫入磁盤。

在MySQL中系統默認的設置是sync_binlog=0，也就是不作任何強制性的磁盤刷新指令，這時候的性能是最好的，可是風險也是最大的。由於一旦系統Crash，在binlog_cache中的全部binlog信息都會被丟失。而當設置爲「1」的時候，是最安全可是性能損耗最大的設置。由於當設置爲1的時候，即便系統Crash，也最多丟失binlog_cache中未完成的一個事務，對實際數據沒有任何實質性影響。從以往經驗和相關測試來看，對於高併發事務的系統來講，「sync_binlog」設置爲0和設置爲1的系統寫入性能差距可能高達5倍甚至更多。

另：
MySQL的複製（Replication），實際上就是經過將Master端的Binlog經過利用IO線程經過網絡複製到Slave端，而後再經過SQL線程解析Binlog中的日誌再應用到數據庫中來實現的。因此，Binlog量的大小對IO線程以及Msater和Slave端之間的網絡都會產生直接的影響。

MySQL中Binlog的產生量是沒辦法改變的，只要咱們的Query改變了數據庫中的數據，那麼就必須將該Query所對應的Event記錄到Binlog中。那咱們是否是就沒有辦法優化複製了呢？固然不是，在MySQL複製環境中，其實是是有8個參數可讓咱們控制須要複製或者須要忽略而不進行復制的DB或者Table的，分別爲：

Binlog_Do_DB：設定哪些數據庫（Schema）須要記錄Binlog；

Binlog_Ignore_DB：設定哪些數據庫（Schema）不要記錄Binlog；

Replicate_Do_DB：設定須要複製的數據庫（Schema），多個DB用逗號（「,」）分隔；

Replicate_Ignore_DB：設定能夠忽略的數據庫（Schema）；

Replicate_Do_Table：設定須要複製的Table；

Replicate_Ignore_Table：設定能夠忽略的Table；

Replicate_Wild_Do_Table：功能同Replicate_Do_Table，但能夠帶通配符來進行設置；

Replicate_Wild_Ignore_Table：功能同Replicate_Ignore_Table，可帶通配符設置；

經過上面這八個參數，咱們就能夠很是方便按照實際需求，控制從Master端到Slave端的Binlog量儘量的少，從而減少Master端到Slave端的網絡流量，減小IO線程的IO量，還能減小SQL線程的解析與應用SQL的數量，最終達到改善Slave上的數據延時問題。

實際上，上面這八個參數中的前面兩個是設置在Master端的，然後面六個參數則是設置在Slave端的。雖然前面兩個參數和後面六個參數在功能上並無很是直接的關係，可是對於優化MySQL的Replication來講均可以啓到類似的功能。固然也有必定的區別，其主要區別以下：

若是在Master端設置前面兩個參數，不只僅會讓Master端的Binlog記錄所帶來的IO量減小，還會讓Master端的IO線程就能夠減小Binlog的讀取量，傳遞給Slave端的IO線程的Binlog量天然就會較少。這樣作的好處是能夠減小網絡IO，減小Slave端IO線程的IO量，減小Slave端的SQL線程的工做量，從而最大幅度的優化複製性能。固然，在Master端設置也存在必定的弊端，由於MySQL的判斷是否須要複製某個Event不是根據產生該Event的Query所更改的數據

所在的DB，而是根據執行Query時刻所在的默認Schema，也就是咱們登陸時候指定的DB或者運行「USEDATABASE」中所指定的DB。只有當前默認DB和配置中所設定的DB徹底吻合的時候IO線程纔會將該Event讀取給Slave的IO線程。因此若是在系統中出如今默認DB和設定須要複製的DB不同的狀況下改變了須要複製的DB中某個Table的數據的時候，該Event是不會被複制到Slave中去的，這樣就會形成Slave端的數據和Master的數據不一致的狀況出現。一樣，若是在默認Schema下更改了不須要複製的Schema中的數據，則會被複制到Slave端，當Slave端並無該Schema的時候，則會形成複製出錯而中止。

而若是是在Slave端設置後面的六個參數，在性能優化方面可能比在Master端要稍微遜色一點，由於無論是須要仍是不須要複製的Event都被會被IO線程讀取到Slave端，這樣不只僅增長了網絡IO量，也給Slave端的IO線程增長了RelayLog的寫入量。可是仍然能夠減小Slave的SQL線程在Slave端的日誌應用量。雖然性能方面稍有遜色，可是在Slave端設置複製過濾機制，能夠保證不會出現由於默認Schema的問題而形成Slave和Master數據不一致或者複製出錯的問題。

3）慢查詢日誌Query Log 相關參數及使用建議
再來看看SlowQueryLog的相關參數配置。有些時候，咱們爲了定位系統中效率比較地下的Query語句，則須要打開慢查詢日誌，也就是SlowQueryLog。咱們能夠以下查看系統慢查詢日誌的相關設置：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

mysql> show variables  like  'log_slow%' ; + ------------------+-------+ | Variable_name | Value | + ------------------+-------+ | log_slow_queries |  ON  | + ------------------+-------+ 1 row  in  set  (0.00 sec)   mysql> show variables  like  'long_query%' ; + -----------------+-------+ | Variable_name | Value | + -----------------+-------+ | long_query_time | 1 | + -----------------+-------+ 1 row  in  set  (0.01 sec)

「log_slow_queries」參數顯示了系統是否已經打開SlowQueryLog功能，而「long_query_time」參數則告訴咱們當前系統設置的SlowQuery記錄執行時間超過多長的Query。在MySQLAB發行的MySQL版本中SlowQueryLog能夠設置的最短慢查詢時間爲1秒，這在有些時候可能沒辦法徹底知足咱們的要求，若是但願可以進一步縮短慢查詢的時間限制，可使用Percona提供的microslow-patch（件成爲mslPatch）來突破該限制。mslpatch不只僅能將慢查詢時間減少到毫秒級別，同時還能經過一些特定的規則來過濾記錄的SQL，如僅記錄涉及到某個表的SlowQuery等等附加功能。

打開SlowQueryLog功能對系統性能的總體影響沒有Binlog那麼大，畢竟SlowQueryLog的數據量比較小，帶來的IO損耗也就較小，可是，系統須要計算每一條Query的執行時間，因此消耗老是會有一些的，主要是CPU方面的消耗。若是你們的系統在CPU資源足夠豐富的時候，能夠沒必要在意這一點點損耗，畢竟他可能會給咱們帶來更大性能優化的收穫。但若是咱們的CPU資源也比較緊張的時候，也徹底能夠在大部分時候關閉該功能，而只須要間斷性的打開SlowQueryLog功能來定位可能存在的慢查詢。

MySQL的其餘日誌因爲使用不多（QueryLog）或者性能影響不多，在此就不作過多分析了。

 

***************當你發現本身的才華撐不起野心時，就請安靜下來學習吧***************