（一） binlog介紹

binlog,即二進制日志,它記錄了數據庫上的所有改變，并以二進制的形式保存在磁盤中；

它可以用來查看數據庫的變更歷史、數據庫增量備份和恢復、Mysql的復制（主從數據庫的復制）。

（二） binlog格式

binlog有三種格式：Statement、Row以及Mixed。

–基于SQL語句的復制(statement-based replication,SBR)，?
–基于行的復制(row-based replication,RBR)，?
–混合模式復制(mixed-based replication,MBR)。

2.1 Statement?
每一條會修改數據的sql都會記錄在binlog中。

優點：不需要記錄每一行的變化，減少了binlog日志量，節約了IO，提高性能。

缺點：由于記錄的只是執行語句，為了這些語句能在slave上正確運行，因此還必須記錄每條語句在執行的時候的一些相關信息，以保證所有語句能在slave得到和在master端執行時候相同 的結果。另外mysql 的復制,像一些特定函數功能，slave可與master上要保持一致會有很多相關問題。

ps：相比row能節約多少性能與日志量，這個取決于應用的SQL情況，正常同一條記錄修改或者插入row格式所產生的日志量還小于Statement產生的日志量，但是考慮到如果帶條件的update操作，以及整表刪除，alter表等操作，ROW格式會產生大量日志，因此在考慮是否使用ROW格式日志時應該跟據應用的實際情況，其所產生的日志量會增加多少，以及帶來的IO性能問題。

2.2 Row

5.1.5版本的MySQL才開始支持row level的復制,它不記錄sql語句上下文相關信息，僅保存哪條記錄被修改。

優點： binlog中可以不記錄執行的sql語句的上下文相關的信息，僅需要記錄那一條記錄被修改成什么了。所以rowlevel的日志內容會非常清楚的記錄下每一行數據修改的細節。而且不會出現某些特定情況下的存儲過程，或function，以及trigger的調用和觸發無法被正確復制的問題.

缺點:所有的執行的語句當記錄到日志中的時候，都將以每行記錄的修改來記錄，這樣可能會產生大量的日志內容。

ps:新版本的MySQL中對row level模式也被做了優化，并不是所有的修改都會以row level來記錄，像遇到表結構變更的時候就會以statement模式來記錄，如果sql語句確實就是update或者delete等修改數據的語句，那么還是會記錄所有行的變更。

2.3 Mixed

從5.1.8版本開始，MySQL提供了Mixed格式，實際上就是Statement與Row的結合。

在Mixed模式下，一般的語句修改使用statment格式保存binlog，如一些函數，statement無法完成主從復制的操作，則采用row格式保存binlog，MySQL會根據執行的每一條具體的sql語句來區分對待記錄的日志形式，也就是在Statement和Row之間選擇一種。

只查看第一個binlog文件的內容
mysql> show binlog events;

查看指定binlog文件的內容
mysql> show binlog events in 'mysql-bin.000001';

獲取binlog文件列表

mysql> show binary logs;

[python]?view plain?copy

1. mysql>?show?binary?logs;??
2. +------------------+-----------+??
3. |?Log_name?????????|?File_size?|??
4. +------------------+-----------+??
5. |?mysql-bin.000001?|??????3548?|??
6. |?mysql-bin.000002?|???????106?|??
7. +------------------+-----------+??
8. 2?rows?in?set?(0.00?sec)??
9. ?

?

1 當停止或重啟服務器時，服務器會把日志文件記入下一個日志文件，Mysql會在重啟時生成一個新的日志文件，文件序號遞增；

2 如果日志文件超過max_binlog_size（默認值1G）系統變量配置的上限時，也會生成新的日志文件（在這里需要注意的是，如果你正使用大的事務，二進制日志還會超過max_binlog_size，不會生成新的日志文件，事務全寫入一個二進制日志中,這種情況主要是為了保證事務的完整性）

3 日志被刷新時，新生成一個日志文件。

如：

?

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?294”說明“事件”的起點，是以第294字節開始；“end_log_pos?388??”說明以第388?字節結束

?

時間戳
事件發生的時間戳：“120330 17:54:46”

?

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

?

錯誤碼
錯誤碼為：“error_code=0”

?

服務器的標識
服務器的標識id：“server id 1”

?

轉自：

http://blog.csdn.net/nuli888/article/details/52106910

http://blog.csdn.net/ouyang111222/article/details/50300851

http://blog.csdn.net/wyzxg/article/details/7412777