1 在my.ini(window)配置文件裡面
[mysqld]
log-bin=mysql-bin(名字可以隨便起)
我們每次進行操作的時候，File_size都會增長
2、show binlog events
4. 用mysqlbinlog 工具來顯示記錄的二進制結果，然後導入到文本文件，為了以後的恢復。
詳細過程如下：
bin>mysqlbinlog --start-position=4 --stop-position=106 mysqlbin-log.000001 > D:\\test1.txt
B. mysql 設置binlog
在安裝後的系統配置文件（my.ini或my.cnf）中進行配置。如下：
C. linux mysql怎麼打開binlog
首先確定binlog的路徑：
這個你可以看配置文件 啟用了才有這樣的記錄默認是沒有的 /etc/my.conf log-bin = mysqlbin 一般放在/var/lib/mysql
比如上面的設置重啟資料庫會生成mysqlbin.000001文件
使用命令的方式： cat /var/lib/mysql/mysqlbin.000001
D. 如何管理 MySQL 的 binlog
當啟動Binlog後，事務會產生Binlog Event，這些Event被看做事務數據的一部分。因此要保證事務的Binlog Event和InnoDB引擎中的數據的一致性。所以帶Binlog的CrashSafe要求MySQL宕機重啟後能夠保證：
- 所有已經提交的事務的數據仍然存在。
- 所有沒有提交的事務的數據自動回滾。
- 所有已經提交了的事務的Binlog Event也仍然存在。
- 所有沒有提交事務沒有記錄Binlog Event。
這些要求很好理解，如果重啟後數據還在，但是Binlog Event沒有了，就沒辦法復制到其他節點上了。如果重啟後，數據沒了，但是Binlog Event還在，那麼不存在的數據就會被復制到其他節點上，從而導致主從的不一致。
為了保證帶Binlog的CrashSafe，MySQL內部使用的兩階段提交(Two Phase Commit)。
2 - MySQL的Two Phase Commit(2PC)
在開啟Binlog後，MySQL內部會自動將普通事務當做一個XA事務來處理：
- 自動為每個事務分配一個唯一的ID
- COMMIT會被自動的分成Prepare和Commit兩個階段。
- Binlog會被當做事務協調者(Transaction Coordinator)，Binlog Event會被當做協調者日誌。
想了解2PC，可以參考文檔：【https://en.wikipedia.org/wiki/Two-phase_commit_protocol。】
- 分布式事務ID(XID)
使用2PC時，MySQL會自動的為每一個事務分配一個ID，叫XID。XID是唯一的，每個事務的XID都不相同。XID會分別被Binlog和InnoDB記入日誌中，供恢復時使用。MySQ內部的XID由三部分組成：
- 前綴部分
前綴部分是字元串"MySQLXid"
- Server ID部分
當前MySQL的server_id
- query_id部分
為了保證XID的的唯一性，數字部分使用了query_id。MySQL內部會自動的為每一個語句分配一個query_id，全局唯一。
參考代碼：sql/xa。h的struct xid_t結構。
- 事務的協調者Binlog
Binlog在2PC中充當了事務的協調者（Transaction Coordinator）。由Binlog來通知InnoDB引擎來執行prepare，commit或者rollback的步驟。事務提交的整個過程如下：
1. 協調者准備階段(Prepare Phase)
告訴引擎做Prepare，InnoDB更改事務狀態，並將Redo Log刷入磁碟。
2. 協調者提交階段(Commit Phase)
2.1 記錄協調者日誌，即Binlog日誌。
2.2 告訴引擎做commit。
注意：記錄Binlog是在InnoDB引擎Prepare(即Redo Log寫入磁碟)之後，這點至關重要。
在MySQ的代碼中將協調者叫做tc_log。在MySQL啟動時，tc_log將被初始化為mysql_bin_log對象。參考sql/binlog.cc中的init_server_components()：
if (opt_bin_log) tc_log= &mysql_bin_log;
而在事務提交時，會依次執行：
tc_log->prepare()；
tc_log->commit()；
參考代碼：sql/binlog.cc中的ha_commit_trans()。當mysql_bin_log是tc_log時，prepare和commit的代碼在sql/binlog.cc中：
MYSQL_BIN_LOG::prepare()；
MYSQL_BIN_LOG::commit()；
-協調者日誌Xid_log_event
作為協調者，Binlog需要將事務的XID記入日誌，供恢復時使用。Xid_log_event有以下幾個特點：
- 僅記錄query_id
因為前綴部分不變，server_id已經記錄在Event Header中，Xid_log_event中只記錄query_id部分。
- 標志事務的結束
在Binlog中相當於一個事務的COMMIT語句。
一個事務在Binlog中看起來時這樣的：
Query_log_event("BEGIN");DML產生的events; Xid_log_event;
- DDL沒有BEGIN，也沒有Xid_log_event 。
- 僅InnoDB的DML會產生Xid_log_event
因為MyISAM不支持2PC所以不能用Xid_log_event ，但會有COMMIT Event。
Query_log_event("BEGIN");DML產生的events;Query_log_event("COMMIT");
問題：Query_log_event("COMMIT")和Xid_log_event 有不同的影響嗎？
- Xid_log_event 中的Xid可以幫助master實現CrashSafe。
- Slave的CrashSafe不依賴Xid_log_event
事務在Slave上重做時，會重新產生XID。所以Slave伺服器的CrashSafe並不依賴於Xid_log_event 。Xid_log_event 和Query_log_event("COMMIT")，只是作為事務的結尾，告訴Slave Applier去提交這個事務。因此二者在Slave上的影響是一樣的。
3 - 恢復(Recovery)
這個機制是如何保證MySQL的CrashSafe的呢，我們來分析一下。這里我們假設用戶設置了以下參數來保證可靠性：
- 恢復前事務的狀態
在恢復開始前事務有以下幾種狀態：
- InnoDB中已經提交
根據前面2PC的過程，可知Binlog中也一定記錄了該事務的的Events。所以這種事務是一致的不需要處理。
- InnoDB中是prepared狀態，Binlog中有該事務的Events。
需要通知InnoDB提交這些事務。
- InnoDB中是prepared狀態，Binlog中沒有該事務的Events。
因為Binlog還沒記錄，需要通知InnoDB回滾這些事務。
- Before InnoDB Prepare
事務可能還沒執行完，因此InnoDB中的狀態還沒有prepare。根據2PC的過程，Binlog中也沒有該事務的events。 需要通知InnoDB回滾這些事務。
- 恢復過程
從上面的事務狀態可以看出：恢復時事務要提交還是回滾，是由Binlog來決定的。
- 事務的Xid_log_event 存在，就要提交。
- 事務的Xid_log_event 不存在，就要回滾。
恢復的過程非常簡單：
- 從Binlog中讀出所有的Xid_log_event
- 告訴InnoDB提交這些XID的事務
- InnoDB回滾其它的事務
E. mysql資料庫怎麼開啟binlog
當啟動Binlog後，事務會產生Binlog Event，這些Event被看做事務數據的一部分。因此要保證事務的Binlog Event和InnoDB引擎中的數據的一致性。所以帶Binlog的CrashSafe要求MySQL宕機重啟後能夠保證：
- 所有已經提交的事務的數據仍然存在。
- 所有沒有提交的事務的數據自動回滾。
- 所有已經提交了的事務的Binlog Event也仍然存在。
- 所有沒有提交事務沒有記錄Binlog Event。
這些要求很好理解，如果重啟後數據還在，但是Binlog Event沒有了，就沒辦法復制到其他節點上了。如果重啟後，數據沒了，但是Binlog Event還在，那麼不存在的數據就會被復制到其他節點上，從而導致主從的不一致。
為了保證帶Binlog的CrashSafe，MySQL內部使用的兩階段提交(Two Phase Commit)。
F. mysql開啟binlog日誌
mysqlbinlog 是將 binlog 解析成可讀可執行的 SQL 的重要工具。
但解析體積較大的 binlog 時，如何查看 mysqlbinlog 的執行進度就變成了一個問題，mysqlbinlog 並未提供 –progress 這樣的參數。
那要怎麼查看 mysqlbinlog 的解析進度？
實驗
我們在 實驗 08 中介紹了如何生成隨機數據。可以利用其中技巧，生成較大的 binlog，我們忽略這個過程。
從已有的 binlog 開始，bin.000002 大約有 1.1 個 G：
可以看到 mysqlbinlog 此時的進度大概是 600M 左右，整體進度估算為 54%。
結論
我們無法讓 mysqlbinlog 直接輸出進度，於是通過觀察 mysqlbinlog 對 binlog 的讀取進度，估算mysqlbinlog 的整體處理進度。
G. mysql 怎麼啟用binlog
1. check table 和 repair table
登陸mysql 終端：
mysql -uxxxxx -p dbname
check table tabTest;
如果出現的結果說Status是OK，則不用修復，如果有Error，可以用：
repair table tabTest;
進行修復，修復之後可以在用check table命令來進行檢查。在新版本的phpMyAdmin裡面也可以使用check/repair的功能。
2. myisamchk, isamchk
其中myisamchk適用於MYISAM類型的數據表，而isamchk適用於ISAM類型的數據表。這兩條命令的主要參數相同，一般新的系統都使用MYISAM作為預設的數據表類型，這里以myisamchk為例子進行說明。當發現某個數據表出現問題時可以使用：
myisamchk tablename.MYI
進行檢測，如果需要修復的話，可以使用：
myisamchk -of tablename.MYI
關於myisamchk的詳細參數說明，可以參見它的使用幫助。需要注意的時在進行修改時必須確保MySQL伺服器沒有訪問這個數據表，保險的情況下是最好在進行檢測時把MySQL伺服器Shutdown掉。
H. linux 怎樣恢復mysql資料庫日誌
一、binlog 介紹
伺服器的二進制日誌記錄著該資料庫的所有增刪改的操作日誌(前提是要在自己的伺服器上開啟binlog)，還包括了這些操作的執行時間。為了顯示這些二進制內容，我們可以使用mysqlbinlog命令來查看。
用途1：主從同步
用途2：恢復資料庫（也是線上出現一次資料庫文件丟失後，才對這個有所了解並學習的）
mysqlbinlog命令用法：shell> mysqlbinlog [options] log_file ...
1)mysqlbinlog 選項示例
常見的選項有以下幾個：
--start-datetime
從二進制日誌中讀取指定等於時間戳或者晚於本地計算機的時間。取值如：="1470733768" 或者="2016-08-09 5:09:28"
示例:
[root@hcloud ~]# mysqlbinlog --start-datetime="2016-08-09 5:05:27" /var/lib/mysql/mysql-bin.000001
--stop-datetime
從二進制日誌中讀取指定小於時間戳或者等於本地計算機的時間取值和上述一樣
--start-position
從二進制日誌中讀取指定position 事件位置作為開始。取值：="2698"
示例：
[root@hcloud ~]# mysqlbinlog --start-position="2698" /var/lib/mysql/mysql-bin.000001
--stop-position
從二進制日誌中讀取指定position 事件位置作為事件截至。取值：="2698"
二、環境准備以及備份恢復
1) 安裝好mysql後，檢查開啟binlog
mysql> SHOW BINARY LOGS;
ERROR 1381 (HY000): You are not using binary logging
：上面提示說明沒有伺服器開啟binlog
修改/etc/my.cnf
在mysqld選項中添加一行內容如下:
log-bin=mysql-bin
默認如果不給值的話，log-bin 的會