總結

創(chuàng)新互聯(lián)建站云計算的互聯(lián)網服務提供商,擁有超過13年的服務器租用、雅安服務器托管、云服務器、網站空間、網站系統(tǒng)開發(fā)經驗，已先后獲得國家工業(yè)和信息化部頒發(fā)的互聯(lián)網數(shù)據中心業(yè)務許可證。專業(yè)提供云主機、網站空間、國際域名空間、VPS主機、云服務器、香港云服務器、免備案服務器等。

1、ib_logfile類似oracle的online redo log，包含commit和uncommit的數(shù)據

2、binary log類似oracle的online redo log和archive redo log,但是只有commit的數(shù)據

statement 格式的 binlog，最后會有 COMMIT；
row 格式的 binlog，最后會有一個 XID event

3、為什么MySQL有binlog，還要redo log？因為MySQL是多存儲引擎的，不管使用那種存儲引擎，都會有binlog，而不一定有redo log。而redo log 事務日志ib_logfile文件是InnoDB存儲引擎產生的

4、ib_logfile是循環(huán)使用，binary log不是循環(huán)使用，在寫滿或者重啟之后，會生成新的binary log文件

5、兩種日志記錄的內容差不多類似，都是事務對應DML、DDL的信息，只是作用不同，內容可能重復，比如一個DML記錄在了ib_logfile也記錄在了binary log

6、ib_logfile作為異常宕機后啟動時恢復使用

7、binary log作為數(shù)據恢復使用，主從復制搭建使用

8、兩種日志寫入磁盤的觸發(fā)點不同，二進制日志只在事務提交完成后進行一次寫入，重做日志在事務提交會寫入每隔1秒也會寫入。MySQL為了保證master和slave的數(shù)據一致性，就必須保證binlog和InnoDB redo日志的一致性（因為備庫通過二進制日志重放主庫提交的事務，如果主庫commit之前就寫入binlog，一旦主庫crash，再次啟動時會回滾事務。但此時從庫已經執(zhí)行，則會造成主備數(shù)據不一致）。所以必須保證二進制日志只在事務提交完成后進行一次寫入

9、在主從復制結構中，要保證事務的持久性和一致性，對兩種日志的相關變量設置為如下最為妥當：sync_binlog=1(即每提交一次事務同步寫到磁盤中)；innodb_flush_log_at_trx_commit=1(即每提交一次事務都寫到磁盤中)。這兩項變量的設置保證了：每次提交事務都寫入二進制日志和事務日志，并在提交時將它們刷新到磁盤中

10、innodb中，表數(shù)據刷盤的規(guī)則只有一個：checkpoint。但是觸發(fā)checkpoint的情況卻有幾種（1.重用redo log文件；2.臟頁達到一定比例）

11、ib_logfile作為redo log記錄的是“做了什么改動”，是物理日志，記錄的是"在某個數(shù)據頁上做了什么修改"；

       binary log記錄的是這個語句的原始邏輯，分兩種模式，statement格式記錄的是sql語句，row格式記錄的是行的內容，記錄更新前和更新后的兩條數(shù)據。

使用下面的方法查看ib_logfile里的內容

[root@mydb ~]# strings /var/lib/mysql/ib_logfile0

使用下面兩種方法查看binary log的內容

mysqlbinlog mysql-bin.000002

mysql> show binlog events in 'mysql-bin.000002';

mysql> show binlog events in 'mysql-bin.00002' from 504769752 limit 30,30;
mysql> show binlog events [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count];
選項解析：
IN 'log_name'   指定要查詢的binlog文件名(不指定就是第一個binlog文件)
FROM pos        指定從哪個pos起始點開始查起(不指定就是從整個文件首個pos點開始算)
LIMIT [offset,] 偏移量(不指定就是0)
row_count       查詢總條數(shù)(不指定就是所有行)

ib_logfile

官方文檔https://dev.mysql.com/doc/refman/5.7/en/glossary.html

A set of files, typically named ib_logfile0 and ib_logfile1, that form the redo log. Also sometimes referred to as the log group. These files record statements that attempt to change data in InnoDB tables. These statements are replayed automatically to correct data written by incomplete transactions, on startup following a crash.

This data cannot be used for manual recovery; for that type of operation, use the binary log.

一組文件，通常名為ib_logfile0和ib_logfile1，構成重做日志。 有時也稱為日志組。 這些文件記錄了嘗試更改InnoDB表中數(shù)據的語句。 在崩潰后啟動時，會自動重播這些語句以更正由不完整事務寫入的數(shù)據。

此數(shù)據不能用于手動恢復; 對于該類型的操作，請使用二進制日志。

binary log

官方文檔https://dev.mysql.com/doc/refman/5.7/en/binary-log.html

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. The binary log has two important purposes:

For replication

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.

二進制日志包含描述數(shù)據庫更改的“事件”，例如表創(chuàng)建操作或對表數(shù)據的更改。 它還包含可能已進行更改的語句的事件（例如，不匹配任何行的DELETE），除非使用基于行的日志記錄。 二進制日志還包含有關每個語句獲取更新數(shù)據的時間長度的信息。 

二進制日志有兩個重要目的：

用于復制

某些數(shù)據恢復操作需要使用二進制日志。備份恢復后，將重新執(zhí)行備份后記錄的二進制日志中的事件。 這些事件使數(shù)據庫從備份點更新。

The binary log is not used for statements such as SELECT or SHOW that do not modify data.

二進制日志不用于不修改數(shù)據的SELECT或SHOW等語句

checkpoint

https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_checkpoint

As changes are made to data pages that are cached in the buffer pool, those changes are written to the data files sometime later, a process known as flushing. The checkpoint is a record of the latest changes (represented by an LSN value) that have been successfully written to the data files.

當對緩沖池中緩存的數(shù)據頁進行更改時，這些更改將在稍后的某個時間寫入數(shù)據文件，這一過程稱為刷新。 檢查點是已成功寫入數(shù)據文件的最新更改（由LSN值表示）的記錄。

sharp checkpoint

The process of flushing to disk all dirty buffer pool pages whose redo entries are contained in certain portion of the redo log. Occurs before InnoDB reuses a portion of a log file ; the log files are used in a circular fashion. Typically occurs with write-intensive workloads.

將重做條目包含在重做日志的某些部分中的所有臟緩沖池頁面刷新到磁盤的過程。 在InnoDB覆蓋重用日志文件之前發(fā)生 ; 日志文件以循環(huán)方式使用。 通常發(fā)生寫入密集型工作負載。

flush

To write changes to the database files , that had been buffered in a memory area or a temporary disk storage area. The InnoDB storage structures that are periodically flushed include the redo log, the undo log, and the buffer pool.

Flushing can happen because a memory area becomes full and the system needs to free some space , because a commit operation means the changes from a transaction can be finalized, or because a slow shutdown operation means that all outstanding work should be finalized. When it is not critical to flush all the buffered data at once, InnoDB can use a technique called fuzzy checkpointing to flush small batches of pages to spread out the I/O overhead.

將發(fā)生在內存區(qū)域或臨時磁盤存儲區(qū)域中緩沖的 更改寫入數(shù)據庫文件 。 定期刷新的InnoDB存儲結構包括重做日志，撤消日志和緩沖池。

刷新可能是因為 內存區(qū)域已滿并且系統(tǒng)需要釋放一些空間 ，因為提交操作意味著可以最終確定事務的更改，或者因為慢速關閉操作意味著應該最終完成所有未完成的工作。 當一次刷新所有緩沖數(shù)據并不重要時，InnoDB可以使用一種稱為 模糊檢查點 的技術來刷新小批量頁面以分散I / O開銷。

當前標題：mysql關于ib_logfile事務日志和binarylog二進制日志的區(qū)別
轉載來源：http://www.chinadenli.net/article34/pgdipe.html

成都網站建設公司_創(chuàng)新互聯(lián)，為您提供網站改版、自適應網站、網站建設、網站策劃、企業(yè)網站制作、做網站

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)