建站
咨詢
售后
建站咨詢
新聞中心
：如何在系統(tǒng)崩潰或數(shù)據(jù)誤刪除時保障數(shù)據(jù)安全
和順網(wǎng)站建設公司創(chuàng)新互聯(lián),和順網(wǎng)站設計制作，有大型網(wǎng)站制作公司豐富經(jīng)驗。已為和順1000+提供企業(yè)網(wǎng)站建設服務。企業(yè)網(wǎng)站搭建\外貿(mào)網(wǎng)站制作要多少錢，請找那個售后服務好的和順做網(wǎng)站的公司定做！
隨著數(shù)碼技術的大力發(fā)展，信息化系統(tǒng)已經(jīng)成為現(xiàn)代企業(yè)運轉(zhuǎn)的必備手段之一。假如說這個信息化系統(tǒng)中的數(shù)據(jù)庫在系統(tǒng)崩潰或數(shù)據(jù)誤刪除之后不能及時修復，那么對于企業(yè)的打擊將不可想象。因此，如何對數(shù)據(jù)庫進行備份和恢復就成為很多企業(yè)需要重視的問題。本篇文章重點介紹的方法。
一、什么是bin log文件?
MySQL的bin log文件是一個二進制日志文件，它記錄了MySQL服務器執(zhí)行的所有數(shù)據(jù)更改操作。它包含從服務器啟動到現(xiàn)在之間的所有SQL命令，以及命令執(zhí)行后影響的行數(shù)等詳細信息。
二、為什么？
在維護一個大型的數(shù)據(jù)系統(tǒng)時，數(shù)據(jù)丟失或系統(tǒng)崩潰是不可避免的。在這種情況下，從備份數(shù)據(jù)中恢復數(shù)據(jù)庫是最常用的方法。然而，在某些情況下，我們可能沒有及時地進行數(shù)據(jù)備份工作，或者是備份數(shù)據(jù)也已經(jīng)因為各種原因而丟失了，此時我們就需要使用MySQL的bin log文件進行數(shù)據(jù)庫恢復。
三、如何
在MySQL的bin log文件中，每一條記錄都包含一條SQL命令的執(zhí)行情況。如果要恢復到某個特定時間點的狀態(tài)，需要先找到該時間點之前的最后一個命令的位置。具體的恢復方法如下：
1. 找到最新的備份數(shù)據(jù)
在使用bin log文件恢復時需要先找到最新的備份數(shù)據(jù)，并根據(jù)該備份數(shù)據(jù)進行恢復。如果沒有備份數(shù)據(jù)可以使用，則只能按照bin log文件中的記錄一個一個恢復。
2. 定位bin log文件
使用bin log文件進行恢復需要先找到bin log文件。一般默認存儲在MySQL的數(shù)據(jù)目錄下，以binlog開頭，并以數(shù)字形式命名。可以使用SHOW MASTER STATUS命令查看當前的bin log文件和位置。
3. 分析bin log文件中的內(nèi)容
使用mysqlbinlog命令可以將bin log文件中的內(nèi)容以人類可讀的形式輸出?？梢酝ㄟ^-G選項指定輸出的格式，例如輸出每一條記錄的時間戳，執(zhí)行數(shù)據(jù)庫命令的用戶名以及執(zhí)行的SQL命令內(nèi)容等。
4. 恢復數(shù)據(jù)
將bin log文件中的命令逐個執(zhí)行，可以把數(shù)據(jù)庫恢復到特定的時間點。這些命令的執(zhí)行順序非常重要，必須在正確的順序下才能有效地進行恢復。
四、bin log文件的缺點
有以下缺點：
1. 需要手動處理bin log文件，花費時間較長。
2. bin log文件中記錄的內(nèi)容過于詳細，恢復時需要一步步逐條執(zhí)行，比較麻煩。
3. bin log文件中包含了所有的更改操作，包括被刪除的數(shù)據(jù)，而且沒有可靠的過濾機制，無法確?；謴偷臄?shù)據(jù)兼容且一致。
五、
盡管bin log文件在恢復數(shù)據(jù)庫的過程中存在一定的缺點，但它是一種可靠的恢復數(shù)據(jù)庫的方法。事實上，在大多數(shù)情況下，使用bin log文件進行數(shù)據(jù)恢復的成功率很高。因此，無論是一個小型的網(wǎng)站還是大型的企業(yè)系統(tǒng)，都應該在備份的同時保留bin log文件，以保障在系統(tǒng)崩潰或數(shù)據(jù)誤刪除時的數(shù)據(jù)安全。
相關問題拓展閱讀：
- mysql恢復數(shù)據(jù)mysqlbinlog
- MySQL怎么恢復半個月前的數(shù)據(jù)？
mysql恢復數(shù)據(jù)mysqlbinlog
有完整備份的話，先用完整備份還原下，然后在用binlog恢復從完整備份到當前時間點的數(shù)據(jù)。
如果沒有完整備份的話，使用binlog也可以恢復，不過10G的數(shù)據(jù)可能需要很長的時間。
相關語法如下：
mysql -hlocalhost test 1.sql
當啟動Binlog后，事務會產(chǎn)生Binlog Event，這些Event被看做事務數(shù)據(jù)的一部分。因此要保證事務的Binlog Event和InnoDB引擎中的數(shù)據(jù)的一致性。所以帶Binlog的CrashSafe要求MySQL宕機重啟后能夠保證：
– 所有已經(jīng)提交的事務的數(shù)據(jù)仍然存在。
– 所有沒有提交的事務的數(shù)據(jù)自動回滾。
– 所有已經(jīng)提交了的事務的Binlog Event也仍然存在。
– 所有沒有提交事務沒有記錄Binlog Event。
這些要求很好理解，如果重啟后數(shù)據(jù)還在，但是Binlog Event沒有了，就沒辦法復制到其他節(jié)點上了。如果重啟后，數(shù)據(jù)沒了，但是Binlog Event還在，那么不存在的數(shù)據(jù)就會被復制到其他節(jié)點上，從而導致主從的不一致。
為了保證帶Binlog的CrashSafe，MySQL內(nèi)部使用的兩階段提交(Two Phase Commit)。
2 – MySQL的Two Phase Commit(2PC)
在開啟Binlog后，MySQL內(nèi)部會自動將普通事務當做一個XA事務來處理：
– 自動為每個事務分配一個唯一的ID
– COMMIT會被自動的分成Prepare和Commit兩個階段。
– Binlog會被當做事務協(xié)調(diào)者(Transaction Coordinator)，Binlog Event會被當做協(xié)調(diào)者日志。
想了解2PC，可以參考文檔：【
。】
– 分布式事務ID(XID)
使用2PC時，MySQL會自動的為每一個事務分配一個ID，叫XID。XID是唯一的，每個事務的XID都不相同。XID會分別被Binlog和InnoDB記入日志中，供恢復時使用。MySQ內(nèi)部的XID由三部分組成：
– 前綴部分
前綴部分是字符串”MySQLXid”
– Server ID部分
當前MySQL的server_id
– query_id部分
為了保證XID的的唯一性，數(shù)字部分使用了query_id。MySQL內(nèi)部會自動的為每一個語句分配一個query_id，全局唯一。
參考代碼：sql/xa。h的struct xid_t結(jié)構。
– 事務的協(xié)調(diào)者Binlog
Binlog在2PC中充當了事務的協(xié)調(diào)者（Transaction Coordinator）。由Binlog來通知InnoDB引擎來執(zhí)行prepare，commit或者rollback的步驟。事務提交的整個過程如下：
1. 協(xié)調(diào)者準備階段(Prepare Phase)
告訴引擎做Prepare，InnoDB更改事務狀態(tài)，并將Redo Log刷入磁盤。
2. 協(xié)調(diào)者提交階段(Commit Phase)
2.1 記錄協(xié)調(diào)者日志，即Binlog日志。
2.2 告訴引擎做commit。
注意：記錄Binlog是在InnoDB引擎Prepare(即Redo Log寫入磁盤)之后，這點至關重要。
在MySQ的代碼中將協(xié)調(diào)者叫做tc_log。在MySQL啟動時，tc_log將被初始化為mysql_bin_log對象。參考sql/binlog.cc中的init_server_components()：
if (opt_bin_log) tc_log= &mysql_bin_log;
而在事務提交時，會依次執(zhí)行：
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()；
-協(xié)調(diào)者日志Xid_log_event
作為協(xié)調(diào)者，Binlog需要將事務的XID記入日志，供恢復時使用。Xid_log_event有以下幾個特點：
– 僅記錄query_id
因為前綴部分不變，server_id已經(jīng)記錄在Event Header中，Xid_log_event中只記錄query_id部分。
– 標志事務的結(jié)束
在Binlog中相當于一個事務的COMMIT語句。
一個事務在Binlog中看起來時這樣的：
Query_log_event(“BEGIN”);DML產(chǎn)生的events; Xid_log_event;
– DDL沒有BEGIN，也沒有Xid_log_event 。
– 僅InnoDB的DML會產(chǎn)生Xid_log_event
因為MyISAM不支持2PC所以不能用Xid_log_event ，但會有COMMIT Event。
Query_log_event(“BEGIN”);DML產(chǎn)生的events;Query_log_event(“COMMIT”);
問題：Query_log_event(“COMMIT”)和Xid_log_event 有不同的影響嗎？
– Xid_log_event 中的Xid可以幫助master實現(xiàn)CrashSafe。
– Slave的CrashSafe不依賴Xid_log_event
事務在Slave上重做時，會重新產(chǎn)生XID。所以Slave服務器的CrashSafe并不依賴于Xid_log_event 。Xid_log_event 和Query_log_event(“COMMIT”)，只是作為事務的結(jié)尾，告訴Slave Applier去提交這個事務。因此二者在Slave上的影響是一樣的。
3 – 恢復(Recovery)
這個機制是如何保證MySQL的CrashSafe的呢，我們來分析一下。這里我們假設用戶設置了以下參數(shù)來保證可靠性：
– 恢復前事務的狀態(tài)
在恢復開始前事務有以下幾種狀態(tài)：
– InnoDB中已經(jīng)提交
根據(jù)前面2PC的過程，可知Binlog中也一定記錄了該事務的的Events。所以這種事務是一致的不需要處理。
– InnoDB中是prepared狀態(tài)，Binlog中有該事務的Events。
需要通知InnoDB提交這些事務。
– InnoDB中是prepared狀態(tài)，Binlog中沒有該事務的Events。
因為Binlog還沒記錄，需要通知InnoDB回滾這些事務。
– Before InnoDB Prepare
事務可能還沒執(zhí)行完，因此InnoDB中的狀態(tài)還沒有prepare。根據(jù)2PC的過程，Binlog中也沒有該事務的events。 需要通知InnoDB回滾這些事務。
– 恢復過程
從上面的事務狀態(tài)可以看出：恢復時事務要提交還是回滾，是由Binlog來決定的。
– 事務的Xid_log_event 存在，就要提交。
– 事務的Xid_log_event 不存在，就要回滾。
恢復的過程非常簡單：
– 從Binlog中讀出所有的Xid_log_event
– 告訴InnoDB提交這些XID的事務
– InnoDB回滾其它的事務
MySQL怎么恢復半個月前的數(shù)據(jù)？
首先確認一下是否有散耐銷定期的備份任務，如果沒有在考慮下面的方式。
配置參數(shù)沖游上，是否開啟了bin-log日志？如果開啟了并且bin-log日志的周期保畝孝留比較長，可以通過重放bin-log日志的方式恢復數(shù)據(jù)。
通過整庫備份+binlog進行恢復. 前提是要有定期整庫備份且保存了binlog日志.。
通過bin log恢復數(shù)據(jù)庫的介紹就聊到這里吧，感謝你花時間閱讀本站內(nèi)容，更多關于通過bin log恢復數(shù)據(jù)庫,使用bin log文件進行數(shù)據(jù)庫恢復,mysql恢復數(shù)據(jù)mysqlbinlog,MySQL怎么恢復半個月前的數(shù)據(jù)？的信息別忘了在本站進行查找喔。
香港服務器選創(chuàng)新互聯(lián)，2H2G首月10元開通。
創(chuàng)新互聯(lián)（www.cdcxhl.com）互聯(lián)網(wǎng)服務提供商,擁有超過10年的服務器租用、服務器托管、云服務器、虛擬主機、網(wǎng)站系統(tǒng)開發(fā)經(jīng)驗。專業(yè)提供云主機、虛擬主機、域名注冊、VPS主機、云服務器、香港云服務器、免備案服務器等。
網(wǎng)站標題：使用binlog文件進行數(shù)據(jù)庫恢復(通過binlog恢復數(shù)據(jù)庫)
本文路徑：http://www.5511xx.com/article/djjdgsc.html
