原文：http://blog.csdn.net/cdefg198/article/details/7063524
1：二進制日誌
二進制日誌記錄了所有的DDL（數據定義語言）語句和DML（數據操作語言）語句，但是不記錄包括數據查詢的語句。語句以“事件”的形式保存，它描述了數據的更改過程，此日誌對於災難時的數據恢復起着極其重要的作用
2：日誌的位置和格式
當用—log-bin[=file_name]選項啓動時，mysqld將包含所有更新數據的SQL命令寫入日誌文件。如果沒有給出file_name值，默認名爲主機名後面跟_bin，如果給出了文件名，但沒有包含路勁，則文件默認被寫入參數DATADIR（數據目錄）指定的目錄
3：日誌的讀取
由於日誌以二進制的方式存儲，不能直接讀取，需要用mysqlbinlog工具來查看，語法如下：
#mysqlbinlog log_file
4：日誌的刪除
對於比較繁忙的OLTP系統，由於每天生產日誌量大，這些日誌如果長時間不清理，將會對磁盤空間帶來很大的浪費，因此，定期刪除日誌是DBA維護Mysql數據庫的一個重要工作內容，下面將介紹幾種刪除日誌的常見方法
（1）：
執行“reset master;”命令，該命令將刪除所有二進制日誌，新日誌的編號從“000001” 開始，命令如下
Mysql>reset master;
（2）：
執行“Purge master logs to ‘mysql-bin.*****’” 命令，該命令將刪除“*****” 編號之前的所有日誌，下列中刪除了“mysql-bin.000001”之前編號的所有日誌
Mysql>purge master logs to ‘mysql-bin.000015;
從結果中發現，編號000015之前的所有日誌都已經刪除
（3）：
執行“purge master logs before ‘yyyy-mm-dd hh24:min:ss’”命令，該命令將刪除日期爲“yyyy-mm-dd hh24:mi:ss”之前產生的所有日誌，下列中刪除了日期在“2010-05-22 01:00:00”之前的所有日誌
Mysql>purge master logs before ‘2010-05-22 01:00:00’’;
（4）：
設置參數—expire_logs_days=#(days)，此參數的含義是設置日誌的過期天數，過來指定的天數後日志將會被自動刪除，這樣將有利於減少DBA管理日誌的工作量。
#vi /etc/my.cnf
[mysqld]
--expire_logs_days=3
這樣，3天前的日誌都會被刪除，系統自動刪除
MYSQL主從複製(replication)採用 RBR 模式後，binlog的格式爲"ROW"，能解決很多原先出現的主鍵重複問題。
MYSQL主從複製(replication)採用 RBR 模式後，binlog的格式爲"ROW"，能解決很多原先出現的主鍵重複問題。在一個繁忙的master db server上，binlog日誌文件增長速度很快，如果不定時清除，硬盤空間很快就會被充滿。
設置自動清理mysql binlog日誌，配置my.cnf：
expire_logs_days = 10
在運行時修改：
show binary logs;
show variables like '%log%';
set global expire_logs_days = 10;
清除之前可以採用相應的備份策略。
手動刪除10天前的mysql binlog日誌：
PURGE MASTER LOGS BEFORE DATE_SUB(CURRENT_DATE, INTERVAL 10 DAY);
show master logs;
MASTER和BINARY是同義詞。
一般情況下，推薦使用MIXED binlog的複製。http://dev.mysql.com/doc/refman/5.1/en/open-bugs-general.html中的說明:Replication uses query-level logging: The master writes the executed queries to the binary log. This is a very fast, compact, and efficient logging method that works perfectly in most cases.
附：關於MYSQL複製的幾種模式
以下轉自http://steven1981.itpub.net/post/7967/485747
從 MySQL 5.1.12 開始，可以用以下三種模式來實現：
– 基於SQL語句的複製(statement-based replication, SBR)，
– 基於行的複製(row-based replication, RBR)，
– 混合模式複製(mixed-based replication, MBR)。
相應地，binlog的格式也有三種：STATEMENT，ROW，MIXED。 MBR 模式中，SBR 模式是默認的。
在運行時可以動態改動 binlog的格式，除了以下幾種情況：
. 存儲流程或者觸發器中間
. 啓用了NDB
. 當前會話試用 RBR 模式，並且已打開了臨時表
如果binlog採用了 MIXED 模式，那麼在以下幾種情況下會自動將binlog的模式由 SBR 模式改成 RBR 模式。
. 當DML語句更新一個NDB表時
. 當函數中包含 UUID() 時
. 2個及以上包含 AUTO_INCREMENT 字段的表被更新時
. 行任何 INSERT DELAYED 語句時
. 用 UDF 時
. 視圖中必須要求運用 RBR 時，例如建立視圖是運用了 UUID() 函數
設定主從複製模式：
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';
兩種模式各自的優缺點：
SBR 的優點：
歷史悠久，技能成熟
binlog文件較小
binlog中包含了所有數據庫修改信息，可以據此來審覈數據庫的安全等情況
binlog可以用於實時的還原，而不僅僅用於複製
主從版本可以不一樣，從服務器版本可以比主服務器版本高
SBR 的缺點：
不是所有的UPDATE語句都能被複制，尤其是包含不確定操作的時候。
調用具有不確定因素的 UDF 時複製也可能出疑問
運用以下函數的語句也不能被複制：
* LOAD_FILE()
* UUID()
* USER()
* FOUND_ROWS()
* SYSDATE() (除非啓動時啓用了 –sysdate-is-now 選項)
INSERT … SELECT 會產生比 RBR 更多的行級鎖
複製須要執行 全表掃描(WHERE 語句中沒有運用到索引)的 UPDATE 時，須要比 RBR 請求更多的行級鎖
對於有 AUTO_INCREMENT 字段的 InnoDB表而言，INSERT 語句會阻塞其他 INSERT 語句
對於一些複雜的語句，在從服務器上的耗資源情況會更嚴重，而 RBR 模式下，只會對那個發生變化的記錄產生影響
存儲函數(不是存儲流程 )在被調用的同時也會執行一次 NOW() 函數，這個可以說是壞事也可能是好事
確定了的 UDF 也須要在從服務器上執行
數據表必須幾乎和主服務器保持一致才行，否則可能會導致複製出錯
執行復雜語句如果出錯的話，會消耗更多資源
RBR 的優點：
任何情況都可以被複制，這對複製來說是最安全可靠的
和其他大多數數據庫系統的複製技能一樣
多數情況下，從服務器上的表如果有主鍵的話，複製就會快了很多
複製以下幾種語句時的行鎖更少：
* INSERT … SELECT
* 包含 AUTO_INCREMENT 字段的 INSERT
* 沒有附帶條件或者並沒有修改很多記錄的 UPDATE 或 DELETE 語句
執行 INSERT，UPDATE，DELETE 語句時鎖更少
從服務器上採用多線程來執行復製成爲可能
RBR 的缺點：
binlog 大了很多
複雜的回滾時 binlog 中會包含大量的數據
主服務器上執行 UPDATE 語句時，所有發生變化的記錄都會寫到 binlog 中，而 SBR 只會寫一次，這會導致頻繁發生 binlog 的併發寫疑問
UDF 產生的大 BLOB 值會導致複製變慢
不能從 binlog 中看到都複製了寫什麼語句(加密過的)
當在非事務表上執行一段堆積的SQL語句時，最好採用 SBR 模式，否則很容易導致主從服務器的數據不一致情況發生
另外，針對系統庫 mysql 裏面的表發生變化時的處理準則如下：
如果是採用 INSERT，UPDATE，DELETE 直接操作表的情況，則日誌格式根據 binlog_format 的設定而記錄
如果是採用 GRANT，REVOKE，SET PASSWORD 等管理語句來做的話，那麼無論如何 都採用 SBR 模式記錄。
注：採用 RBR 模式後，能處理很多原先出現的主鍵重複問題。實例:
對於insert into db_allot_ids select * from db_allot_ids 這個語句:
在BINLOG_FORMAT=STATEMENT 模式下:
BINLOG日誌信息爲:
—————————————–
BEGIN
/*!*/;
# at 173
#090612 16:05:42 server id 1 end_log_pos 288 Query thread_id=4 exec_time=0 error_code=0
SET TIMESTAMP=1244793942/*!*/;
insert into db_allot_ids select * from db_allot_ids
/*!*/;
—————————————–
在BINLOG_FORMAT=ROW 模式下:
BINLOG日誌信息爲:
—————————————–
BINLOG '
hA0yShMBAAAAMwAAAOAAAAAAAA8AAAAAAAAAA1NOUwAMZGJfYWxsb3RfaWRzAAIBAwAA
hA0yShcBAAAANQAAABUBAAAQAA8AAAAAAAEAAv/8AQEAAAD8AQEAAAD8AQEAAAD8AQEAAAA=
'/*!*/;
—————————————–
