重做日志文件（redo log）和二進(jìn)制文件（bin log）

bin logrhino文件的歷史要比redo log日志文件的歷史久，因為bin log是server層的日志文件，而server層是所有存儲引擎共享的，其記錄的是邏輯日志，簡單的說就是具體的sql，但不是所有的sql都會記錄，而是所有的數(shù)據(jù)庫表結(jié)構(gòu)和表數(shù)據(jù)變更，而redo log是innodb才有的，是存儲引擎層的日志，記錄的是物理日志，即數(shù)據(jù)的變化。

為什么bin log無法保證crach-safe？

bin log記錄的是邏輯日志，也就是具體的操作，為什么無法保證呢？因為記錄日志和執(zhí)行操作是兩個操作，不是原子操作。假如在期間什么時候出現(xiàn)了宕機(jī)都會出現(xiàn)數(shù)據(jù)不一致的問題。

redo log如何保證crach-safe？

同樣是日志文件，為什么redo log就可以保證crach-safe呢？因為redo log記錄的是物理日志，其記錄的時間不是在事務(wù)執(zhí)行之前或者之后，而是在事務(wù)執(zhí)行中就記錄了redo log，通過事務(wù)來控制原子性。并且，redo log可以保證之前還未提交的操作被記錄了，數(shù)據(jù)可以恢復(fù)，所以保證了crach-safe。

那bin log的用途是什么？

bin log是用于主從數(shù)據(jù)同步的。

mysql的主從復(fù)制

mysql的slave模式中，為了減緩主數(shù)據(jù)庫的訪問壓力，通過添加從數(shù)據(jù)庫來減少對主數(shù)據(jù)庫的訪問，但是如何保證主從數(shù)據(jù)庫數(shù)據(jù)的一致呢？

image.png

主庫將更新操作保存在bin log 中，從庫的IO線程從主庫的bin log中讀取到relay log中，sql thread 從relay log 中執(zhí)行sql。

bin log 和redo log的一致性問題？

bin log用來實現(xiàn)主從復(fù)制，那么bin log也需要保證記錄的數(shù)據(jù)的有效性，我們知道redo log中的數(shù)據(jù)是有效的，所以我們就需要同步兩者之間的數(shù)據(jù)就行了。那如何實現(xiàn)兩者之間的數(shù)據(jù)一致性呢？這里mysql通過兩階段提交來實現(xiàn)。

兩階段提交

1. prepare階段:innodb prepare，執(zhí)行操作，寫入redo log；
2. commit階段：寫入bin log innodb commit（內(nèi)存操作）。
   兩階段提交中，當(dāng)已經(jīng)記錄到bin log 中之后，就可以認(rèn)為數(shù)據(jù)已經(jīng)持久化了，數(shù)據(jù)可以傳給從數(shù)據(jù)庫了。

開啟bin log

log-bin=ON
binlog-format=row//選擇row模式
server_id=1//配置mysql replaction需要定義，不能和canal和slaved重復(fù)
參數(shù)：
binlog_cache_size:日志緩存大小，默認(rèn)3MB。
sync_binlog:設(shè)置多少次事務(wù)刷盤，默認(rèn)1，建議設(shè)置成0。

總結(jié)：redo log能實現(xiàn)crach-safe主要還是因為事務(wù)的原子性，還有就是redo log是物理日志。bin log不能實現(xiàn)crach-safe的主要原因還是bin log是server層的日志，沒有事務(wù)的特點，導(dǎo)致數(shù)據(jù)的不一致。但是bin log的用處在于主從復(fù)制，而又引發(fā)的一個問題就是bin log 和redo log數(shù)據(jù)一致性的問題，而兩階段提交就完美的解決了這個問題。
參考文章：https://blog.csdn.net/lzhcoder/article/details/88814364