MySQL binlog

1.前言
  日誌是把數據庫的每個變化都記載到一個專用的文件裏，這種文件就叫作日誌文件。Mysql默認只打開出錯日誌，由於過多的日誌將會影響系統的處理性能。
  在5.0前支持文本格式和二進制格式，5.0後只支持二進制格式，由於二進制日誌在性能、信息處理方面有更多的優勢。
2.基礎知識
  2.一、二進制日誌的啓用
    二進制日誌由配置文件的log-bin選項負責啓用，Mysql服務器將在數據根目錄建立兩個新文件XXX-bin.001和XXX-bin.index，若配置選項沒有給出文件名，Mysql將使用主機名稱命名這兩個文件，其中.index文件包含一份全體日誌文件的清單。
    Mysql會把用戶對全部數據庫的內容和結構的修改狀況記入XXX-bin.n文件，而不會記錄SELECT和沒有實際
  2.二、更新的UPDATE語句。
  日誌文件的擴展
    當中止或重啓時，服務器會把日誌文件記入下一個日誌文件，Mysql會在重啓時生成一個新的日誌文件，文件序號遞增，此外，若是日誌文件超過max_binlog_size系統變量配置的上限時，也會生成新的日誌文件。
  2.三、日誌文件的查看
    Mysql提供了mysqlbinlog命令來查看日誌文件，如mysqlbinlog xxx-bin.001 | more。在記錄每條變動日誌的時候，日誌文件都會把當前時間給記錄下來，以便進行數據庫恢復。   
  2.四、日誌文件的停用
    可使用SET SQL_LOG_BIN=0命令中止使用日誌文件，而後能夠經過SET SQL_LOG_BIN=1命令來啓用。
  2.五、使用日誌進行數據庫恢復
    若是遇到災難事件，應該用最近一次製做的完整備份恢復數據庫，而後使用備份以後的日誌
  文件把數據庫恢復到最接近如今的可用狀態。
    使用日誌進行恢復時須要依次進行，即最先生成的日誌文件要最早恢復：
      mysqlbinlog xxx-bin.00001 | mysql -u root -p
      mysqlbinlog xxx-bin.00002 | mysql -u root -p
3.日誌跟換策略
  使用索引來循環文件，在如下條件將循環至下一個索引
  a.服務器重啓
  b.服務器被更新
  c.日誌達到了最大日誌長度max_binlog_size
  d.日誌被刷新mysql> flush logs;
4.日誌格式
  從官網文檔中看到，以前的MySQL一直都只有基於statement的複製模式，直到5.1.5版本的MySQL纔開始支持row level的複製。從5.0開始，MySQL的複製已經解決了大量老版本中出現的沒法正確複製的問題。可是因爲存儲過程的出現，給MySQL Replication複製又帶來了更大的新挑戰。另外，看到官方文檔說，從5.1.8版本開始，MySQL提供了除Statement Level和Row Level以外的第三種複製模式：Mixed，實際上就前兩種模式的結合。在Mixed模式下，MySQL會根據執行的每一條具體的sql語句來區分對待記錄的日誌形式，也就是在Statement和Row之間選擇一種。新版本中的Statement Level仍是和之前同樣，僅僅記錄執行的語句。而新版本的MySQL中對row level模式也被作了優化，並非全部的修改都會以row level來記錄，像遇到表結構變動的時候就會以statement模式來記錄，若是sql語句確實就是update或者delete等修改數據的語句，那麼仍是會記錄全部行的變動。
  --基於SQL語句的複製(statement-based replication,SBR)，
  --基於行的複製(row-based replication,RBR)，
  --混合模式複製(mixed-based replication,MBR)。
  靜態設置binlog格式：

vi my.cnf
  log-bin = mysql-bin
  #binlog_format = "STATEMENT"
  #binlog_format = "ROW"
  binlog_format = "MIXED"

  動態修改binlog格式：

  mysql> SET SESSION binlog_format = 'STATEMENT';
  mysql> SET SESSION binlog_format = 'ROW';
  mysql> SET SESSION binlog_format = 'MIXED'; 
  mysql> SET GLOBAL binlog_format = 'STATEMENT';
  mysql> SET GLOBAL binlog_format = 'ROW';
  mysql> SET GLOBAL binlog_format = 'MIXED';

5.binary log相關變量和參數

  5.一、命令行參數

  --log-bin [=file_name]

  設置此參數表示啓用binlog功能，並制定路徑名稱。

  --log-bin-index[=file]

  設置此參數是指定二進制索引文件的路徑與名稱。

  --max_binlog_size

 Binlog最大值，最大和默認值是1GB，該設置並不能嚴格控制Binlog的大小，尤爲是Binlog比較靠近最大值而又遇到一個比較大事務時，

爲了保證事務的完整性，不可能作切換日誌的動做，只能將該事務的全部SQL都記錄進當前日誌，直到事務結束。

  --binlog-do-db=db_name

  此參數表示只記錄指定數據庫的二進制日誌

  --binlog-ignore-db=db_name

  此參數表示不記錄指定的數據庫的二進制日誌

  5.二、系統變量

  log_bin

  binlog_cache_size

  此參數表示binlog使用的內存大小，能夠經過狀態變量binlog_cache_use和binlog_cache_disk_use來幫助測試。

  max_binlog_cache_size

  此參數表示binlog使用的內存最大的尺寸

  binlog_cache_use

  使用二進制日誌緩存的事務數量

  binlog_cache_disk_use

  使用二進制日誌緩存但超過binlog_cache_size值並使用臨時文件來保存事務中的語句的事務數量。

  binlog_do_db

  binlog_ignore_db

  sync_binlog

  這個參數直接影響mysql的性能和完整性。

  sync_binlog=0：

  當事務提交後，Mysql僅僅是將binlog_cache中的數據寫入binlog文件，但不執行fsync之類的磁盤，同步指令通知文件系統將緩存刷新到磁盤，而讓Filesystem自行決定何時來作同步，這個是性能最好的。

  sync_binlog=0，在進行n次事務提交之後，Mysql將執行一次fsync之類的磁盤同步指令，通知文件系統將Binlog文件緩存刷新到磁盤。

  Mysql中默認的設置是sync_binlog=0，即不作任何強制性的磁盤刷新指令，這時性能是最好的，但風險也是最大的。一旦系統Crash，在文件系統緩存中的全部Binlog信息都會丟失。

6.常見問題
  6.一、如何清除binlog
  --使用下面的兩個命令
  PURGE {MASTER|BINARY} LOGS TO 'log_name'  //log_name不會被清除
  PURGE {MASTER|BINARY} LOGS BEFORE 'date'  //date不會被清除
 
  實例以下：

mysql> show master logs;
+----------------------+-----------+
| Log_name             | File_size |
+----------------------+-----------+
| mysql3306-bin.000001 |       107 |
+----------------------+-----------+
1 row in set (0.00 sec)

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

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

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

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

mysql> show master logs;
+----------------------+-----------+
| Log_name             | File_size |
+----------------------+-----------+
| mysql3306-bin.000001 |       154 |
| mysql3306-bin.000002 |       154 |
| mysql3306-bin.000003 |       154 |
| mysql3306-bin.000004 |       154 |
| mysql3306-bin.000005 |       107 |
+----------------------+-----------+
5 rows in set (0.00 sec)

mysql> purge master logs to 'mysql3306-bin.000002';
Query OK, 0 rows affected (0.01 sec)

mysql> show master logs;
+----------------------+-----------+
| Log_name             | File_size |
+----------------------+-----------+
| mysql3306-bin.000002 |       154 |
| mysql3306-bin.000003 |       154 |
| mysql3306-bin.000004 |       154 |
| mysql3306-bin.000005 |       107 |
+----------------------+-----------+
4 rows in set (0.00 sec)

[root@node4 data]# date
Tue Jul 30 01:27:04 CST 2013
mysql> flush logs;
Query OK, 0 rows affected (0.01 sec)

mysql> show master logs;
+----------------------+-----------+
| Log_name             | File_size |
+----------------------+-----------+
| mysql3306-bin.000002 |       154 |
| mysql3306-bin.000003 |       154 |
| mysql3306-bin.000004 |       154 |
| mysql3306-bin.000005 |       154 |
| mysql3306-bin.000006 |       107 |
+----------------------+-----------+
5 rows in set (0.00 sec)

mysql> purge master logs before '2013-07-30 01:27:04';
Query OK, 0 rows affected (0.02 sec)

mysql> show master logs;
+----------------------+-----------+
| Log_name             | File_size |
+----------------------+-----------+
| mysql3306-bin.000005 |       154 |
| mysql3306-bin.000006 |       107 |
+----------------------+-----------+
2 rows in set (0.00 sec)

  --或使用命令：
  RESET MASTER

  刪除以前全部的binlog，並從新生成新的binlog，後綴從000001開始。

  注：若是您有一個活性的從屬服務器，該服務器當前正在讀取您正在試圖刪除的日誌之一，則本語句不會起做用，而是失敗，並伴隨一個錯誤。

  不過，若是從屬服務器是休止的，而且您碰巧清理了其想要讀取的日誌之一，則從屬服務器啓動後不能複製。

  當從屬服務器正在複製時，本語句能夠安全運行。您不須要中止它們。

  6.二、記錄到二進制日誌知的內容配置

   binlog-do-db=sales 只記錄sales庫 binlog-ignore-db=sales 除sales庫不記錄，其餘都記錄。

可是若是在操做數據庫以前，不使用use $dbname 那麼全部的SQL都不會記錄 若是使用了use $dbname,那麼判斷規則取決於這裏的$dbname，而不是SQL中操做的庫

  6.三、二進制日誌不許確的處理

   默認狀況下，並非每次寫入時都將二進制日誌與硬盤同步。所以若是操做系統或機器(不只僅是MySQL服務器)崩潰，有可能二進制日誌中最後的語句丟失。 要想防止這種狀況，你可使用sync_binlog全局變量(1是最安全的值，但也是最慢的)，使二進制日誌在每N次二進制日誌寫入後與硬盤同步。 即便sync_binlog設置爲1,出現崩潰時，也有可能表內容和二進制日誌內容之間存在不一致性。

   若是崩潰恢復時MySQL服務器發現二進制日誌變短了(即至少缺乏一個成功提交的InnoDB事務)， 若是sync_binlog =1而且硬盤/文件系統的確能根據須要進行同步(有些不須要)則不會發生，則輸出錯誤消息 (「二進制日誌<名>比指望的要小」)。 在這種狀況下，二進制日誌不許確，複製應從主服務器的數據快照開始。 爲了您的安全，請只打開來源可靠的網址