1 什麼是 binary log
二進位制日誌包含 “events”。這些“events” 描述了資料庫的變更，例如建立資料表的操作，或者表資料的變革。如果使用的不是基於行的日誌，二進位制日誌同時也包含那些 “有可能”改變資料表的“events”，例如 沒有匹配任何 的 DELETE 語句。它也包含每條語句更新資料所花費的時間。

The binary log contains “events” that describe database changes such as table creation operations or changes to table data. It also contains events for statements that potentially could have made changes (for example, a DELETE which matched no rows), unless row-based logging is used. The binary log also contains information about how long each statement took that updated data

2 binary log 的用途
A 複製。 master server 的 bin-log 記載了 master server 的 資料變更記錄，這個變更記錄隨後被髮送給 slave servers, slave servers 執行這些變更，使得自身資料與 master server 資料一致

B 資料恢復。 當一個備份被恢復後，在 備份恢復後的 “events”需要重新執行

bin-log 不會記錄 SELECT 和 SHOW 之類 對資料沒有修改的的語句
bin-log 使得伺服器的效能有輕微下降，但是相對於通過它 進行 複製和恢復帶來的好處，開啟bin-log是完全值得的

The binary log has two important purposes:
A： For replication, the binary log on a master replication server provides a record of the data changes to be sent to slave servers. The master server sends the events contained in its binary log to its slaves, which execute those events to make the same data changes that were made on the master. See Section 18.2, “Replication Implementation”.

B ： Certain data recovery operations require use of the binary log.
After a backup has been restored, the events in the binary log that
were recorded after the backup was made are re-executed. These events
bring databases up to date from the point of the backup. See Section
8.5, “Point-in-Time (Incremental) Recovery Using the Binary Log”.

3 開啟 binary log

step1 檢視是否開啟

mysql> show variables like  '%bin%';
+-----------------------------------------+----------------------+
| Variable_name                           | Value                |
+-----------------------------------------+----------------------+
| binlog_cache_size                       | 32768                |
| binlog_direct_non_transactional_updates | OFF                  |
| binlog_format                           | STATEMENT            |
| binlog_stmt_cache_size                  | 32768                |
| innodb_locks_unsafe_for_binlog          | OFF                  |
| log_bin                                 | OFF                  |
| log_bin_trust_function_creators         | OFF                  |
| max_binlog_cache_size                   | 18446744073709547520 |
| max_binlog_size                         | 1073741824           |
| max_binlog_stmt_cache_size              | 18446744073709547520 |
| sql_log_bin                             | ON                   |
| sync_binlog                             | 0                    |
+-----------------------------------------+----------------------+
12 rows in set (0.00 sec)

step2 開啟
修改 mysql 配置檔案並重啟伺服器

log_bin = mysql_bin

或者附加 –log-bin[=base_name] 選項重啟伺服器

mysqld --log-bin=mysql_bin restart

step3

mysql> show variables like  '%bin%';
+-----------------------------------------+----------------------+
| Variable_name                           | Value                |
+-----------------------------------------+----------------------+
| binlog_cache_size                       | 32768                |
| binlog_direct_non_transactional_updates | OFF                  |
| binlog_format                           | STATEMENT            |
| binlog_stmt_cache_size                  | 32768                |
| innodb_locks_unsafe_for_binlog          | OFF                  |
| log_bin                                 | ON                   |
| log_bin_trust_function_creators         | OFF                  |
| max_binlog_cache_size                   | 18446744073709547520 |
| max_binlog_size                         | 1073741824           |
| max_binlog_stmt_cache_size              | 18446744073709547520 |
| sql_log_bin                             | ON                   |
| sync_binlog                             | 0                    |
+-----------------------------------------+----------------------+
12 rows in set (0.00 sec)

解釋：
如果 base_name 預設，預設值 是 pid-file 的value 後面加上 “-bin”,例如iZ23aazo3fzZ-bin （pid-file 預設value 是 機器名）。bin-log 預設目錄是 data-directory,可以在 base_name 前面加上絕對路徑指定其他目錄
如果指定字尾名，例如 –log-bin=base_name.extension，字尾名將被忽略。

mysqld 在 base_name 後面 附件一個數字字尾。伺服器新建一個log file,數字字尾就會增加，形成一系列有序的log files。
伺服器在以下三種情況下會建立新的log file：
a 伺服器重啟
b flush log
c 當前 bin-log 檔案大小超出 max_binlog_size
由於事務只能記錄於同一個檔案，當使用一個大的事務時，bin-log 可能 超出 max_binlog_size 所規定的大小
mysqld 會建立一個 bin-log 索引檔案，它包含所有被使用的bin-log 名稱。預設的，它的檔名是base_name加上 “.index”字尾。
可以通過 –log-bin-index[=file_name] 選項修改索引檔名稱。
不要手工編輯索引檔案，這會使得 mysqld 無法識別

4 檢視bin-log

step1

mysql> show binlog events in  'mysql_bin.000001'\G
*************************** 1. row ***************************
   Log_name: mysql_bin.000001
        Pos: 4
 Event_type: Format_desc
  Server_id: 1
End_log_pos: 107
       Info: Server ver: 5.5.40-log, Binlog ver: 4
1 row in set (0.00 sec)

step2

create table test.test_bin( 
    `id` int(10) primary key auto_increment,
    `name` varchar(255)
); 

step3

mysql> show binlog events in  'mysql_bin.000001'\G
*************************** 1. row ***************************
   Log_name: mysql_bin.000001
        Pos: 4
 Event_type: Format_desc
  Server_id: 1
End_log_pos: 107
       Info: Server ver: 5.5.40-log, Binlog ver: 4
*************************** 2. row ***************************
   Log_name: mysql_bin.000001
        Pos: 107
 Event_type: Query
  Server_id: 1
End_log_pos: 266
       Info: use `test`; create table test.test_bin(
        `id` int(10) primary key auto_increment,
        `name` varchar(255)
)
2 rows in set (0.00 sec)

step4

insert into test.test_bin(`name`) values ('orange'); 

step5

 mysql> show binlog events in  'mysql_bin.000001'\G
*************************** 1. row ***************************
   Log_name: mysql_bin.000001
        Pos: 4
 Event_type: Format_desc
  Server_id: 1
End_log_pos: 107
       Info: Server ver: 5.5.40-log, Binlog ver: 4
*************************** 2. row ***************************
   Log_name: mysql_bin.000001
        Pos: 107
 Event_type: Query
  Server_id: 1
End_log_pos: 266
       Info: use `test`; create table test.test_bin(
        `id` int(10) primary key auto_increment,
        `name` varchar(255)
)
*************************** 3. row ***************************
   Log_name: mysql_bin.000001
        Pos: 266
 Event_type: Query
  Server_id: 1
End_log_pos: 334
       Info: BEGIN
*************************** 4. row ***************************
   Log_name: mysql_bin.000001
        Pos: 334
 Event_type: Intvar
  Server_id: 1
End_log_pos: 362
       Info: INSERT_ID=1
*************************** 5. row ***************************
   Log_name: mysql_bin.000001
        Pos: 362
 Event_type: Query
  Server_id: 1
End_log_pos: 474
       Info: use `test`; insert into test.test_bin(name) values ('orange')
*************************** 6. row ***************************
   Log_name: mysql_bin.000001
        Pos: 474
 Event_type: Query
  Server_id: 1
End_log_pos: 543
       Info: COMMIT
6 rows in set (0.00 sec)

解釋：
Log_name: 此條log存在那個檔案中
Pos: log在bin-log中的開始位置
Event_type: log的型別資訊
Server_id: 可以檢視配置中的server_id,表示log是那個伺服器產生
End_log_pos：log在bin-log中的結束位置
Info: log的一些備註資訊，可以直觀的看出進行了什麼操作

5 相關引數

mysql> show variables like  '%bin%';
+-----------------------------------------+----------------------+
| Variable_name                           | Value                |
+-----------------------------------------+----------------------+
| binlog_cache_size                       | 32768                |
| binlog_direct_non_transactional_updates | OFF                  |
| binlog_format                           | STATEMENT            |
| binlog_stmt_cache_size                  | 32768                |
| innodb_locks_unsafe_for_binlog          | OFF                  |
| log_bin                                 | ON                   |
| log_bin_trust_function_creators         | OFF                  |
| max_binlog_cache_size                   | 18446744073709547520 |
| max_binlog_size                         | 1073741824           |
| max_binlog_stmt_cache_size              | 18446744073709547520 |
| sql_log_bin                             | ON                   |
| sync_binlog                             | 0                    |
+-----------------------------------------+----------------------+
12 rows in set (0.00 sec)

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資訊都會丟失

6 bin_log 操作

a1 刪除bin-log
方法一：設定日誌保留時長expire_logs_days自動刪除
step1 檢視當前日誌儲存天數 (預設是0，也就是logs不過期，可通過設定全域性的引數，使他臨時生效)

mysql> show variables like 'expire_logs_days';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| expire_logs_days | 0     |
+------------------+-------+
1 row in set (0.00 sec)

step2 設定了只保留7天BINLOG, 下次重啟mysql這個引數預設會失敗，所以需在my.cnf中設定

set global expire_logs_days=7;  

方法二：手動刪除BINLOG (purge binary logs)

reset {MASTER | SLAVE}
PURGE {MASTER | BINARY} LOGS TO ‘log_name’ 
PURGE {MASTER | BINARY} LOGS BEFORE ‘date’ 

例如

mysql> reset master;   //刪除master的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日誌檔案

方法三 ：用作業系統命令直接刪除

a2 檢視最後一個bin日誌檔案是那個

mysql> show master status;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql_bin.000002 |      107 |              |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

a3 啟用新的日誌檔案,一般備份完資料庫後執行

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

mysql> show master status;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql_bin.000003 |      107 |              |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

a4 如果使用者有super許可權，可以啟用或禁用當前會話的binlog記錄

mysql> set sql_log_bin=1/0;

a5 檢視master的binlog日誌

mysql> show master logs;

或者

mysql> show binary logs;

a6 顯示當前註冊的slave的列表。不以–report-host=slave_name選項為開頭的slave不會顯示在本列表中

mysql> show slave hosts; 

7 bin-log 三種格式

Mysql binlog日誌有三種格式，分別為Statement,MiXED,以及ROW

a 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 更多的行級鎖

b Row:不記錄sql語句上下文相關資訊，僅儲存哪條記錄被修改。

優點： binlog中可以不記錄執行的sql語句的上下文相關的資訊，僅需要記錄那一條記錄被修改成什麼了。所以rowlevel的日誌內容會非常清楚的記錄下每一行資料修改的細節。而且不會出現某些特定情況下的儲存過程，或function，以及trigger的呼叫和觸發無法被正確複製的問題

缺點:所有的執行的語句當記錄到日誌中的時候，都將以每行記錄的修改來記錄，這樣可能會產生大量的日誌內容,比如一條update語句，修改多條記錄，則binlog中每一條修改都會有記錄，這樣造成binlog日誌量會很大，特別是當執行alter table之類的語句的時候，由於表結構修改，每條記錄都發生改變，那麼該表每一條記錄都會記錄到日誌中。

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

Mysql預設是使用Statement日誌格式，推薦使用MIXED.
由於一些特殊使用，可以考慮使用ROWED，如自己通過binlog日誌來同步資料的修改，這樣會節省很多相關操作。對於binlog資料處理會變得非常輕鬆,相對mixed，解析也會很輕鬆(當然前提是增加的日誌量所帶來的IO開銷在容忍的範圍內即可)。

The server uses several logging formats to record information in the binary log. The exact format employed depends on the version of MySQL being used. There are three logging formats:

Replication capabilities in MySQL originally were based on propagation of SQL statements from master to slave. This is called statement-based logging. You can cause this format to be used by starting the server with --binlog-format=STATEMENT.

In row-based logging, the master writes events to the binary log that indicate how individual table rows are affected. It is important therefore that tables always use a primary key to ensure rows can be efficiently identified. You can cause the server to use row-based logging by starting it with --binlog-format=ROW.

A third option is also available: mixed logging. With mixed logging, statement-based logging is used by default, but the logging mode switches automatically to row-based in certain cases as described below. You can cause MySQL to use mixed logging explicitly by starting mysqld with the option --binlog-format=MIXED. 

Prior to MySQL 5.7.7, statement-based logging format was the default. In MySQL 5.7.7 and later, row-based logging format is the default.

The logging format can also be set or limited by the storage engine being used. This helps to eliminate issues when replicating certain statements between a master and slave which are using different storage engines.

With statement-based replication, there may be issues with replicating nondeterministic statements. In deciding whether or not a given statement is safe for statement-based replication, MySQL determines whether it can guarantee that the statement can be replicated using statement-based logging. If MySQL cannot make this guarantee, it marks the statement as potentially unreliable and issues the warning, Statement may not be safe to log in statement format.

You can avoid these issues by using MySQL’s row-based replication instead.