MySQL經過binlog日誌回滾數據

1、數據庫在進行數據更改操做時，會出現數據誤操做致使數據異常的狀況，因此數據安全是重中至重，對於數據庫服務，必須開啓binlog日誌服務，保證數據的安全，可逆回滾。
二進制日誌的格式有三種形式分別爲ROW、Statement以及MiXED
一、STATMENT模式：基於SQL語句的複製(statement-based replication, SBR)，每一條會修改數據的sql語句會記錄到binlog中。

優勢：不須要記錄每一條SQL語句與每行的數據變化，這樣子binlog的日誌也會比較少，減小了磁盤IO，提升性能。

缺點：在某些狀況下會致使master-slave中的數據不一致(如sleep()函數， last_insert_id()，以及user-defined functions(udf)等會出現問題)

二、基於行的複製(row-based replication, RBR)：不記錄每一條SQL語句的上下文信息，僅需記錄哪條數據被修改了，修改爲了什麼樣子了。

優勢：不會出現某些特定狀況下的存儲過程、或function、或trigger的調用和觸發沒法被正確複製的問題。

缺點：會產生大量的日誌，尤爲是alter table的時候會讓日誌暴漲。

三、混合模式複製(mixed-based replication, MBR)：以上兩種模式的混合使用，通常的複製使用STATEMENT模式保存binlog，對於STATEMENT模式沒法複製的操做使用ROW模式保存binlog，MySQL會根據執行的SQL語句選擇日誌保存方式。
這裏我這都個人數據庫日誌使用ROW格式。

登陸數據查看數據庫的數據信息：

覈實相關的binlog日誌的報錯路徑以及日誌是否開啓。show variables like "log_bin%";

覈實最新的binlog日誌信息：show master logs; show binary logs; show master status;

2、下面進行相關的數據恢復實踐：

建立測試數據庫：

建立數據表：相關的數據是下載網絡資源的數據。

將數據刪除：

3、經過binlog日誌覈實刪除以及建立數據的時間點或者pos點。
我這裏演示經過pos點進行數據恢復。
經過mysqlbinlog 命令覈實最近的binlog日誌名稱進行日誌查看。覈實具體的時間節點。


確認時間點後，進行數據回滾，相關命令仍是經過mysqlbinlog進行數據回滾操做。
mysqlbinlog --no-defaults --start-position="239" --stop-position="736" /var/lib/mysql/ON.000015 | mysql -uroot -p
參數說明，--start-position #開始的pos時間點。
--stop-position #結束的pos時間
若是是經過日期時間回滾的命令以下：

mysqlbinlog --start-datetime '2019-07-02 21:42:36' --stop-datetime '2019-07-02  21:57:42' /var/lib/mysql/ON.000013 | mysql -uroot -p

執行回滾後會出現以下的信息，回車確認，我這裏數據比較少，回滾時間較快。

再次覈實相關的數據信息。

注：mysqlbinlog相關的命令參數能夠經過mysqlbinlog --help 覈實查看。