欢乐颂小说,小说阅读网

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營(yíng)銷(xiāo)解決方案

使用binlog文件進(jìn)行數(shù)據(jù)庫(kù)恢復(fù)(通過(guò)binlog恢復(fù)數(shù)據(jù)庫(kù))

：如何在系統(tǒng)崩潰或數(shù)據(jù)誤刪除時(shí)保障數(shù)據(jù)安全

和順網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián),和順網(wǎng)站設(shè)計(jì)制作，有大型網(wǎng)站制作公司豐富經(jīng)驗(yàn)。已為和順1000+提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\外貿(mào)網(wǎng)站制作要多少錢(qián)，請(qǐng)找那個(gè)售后服務(wù)好的和順做網(wǎng)站的公司定做！

隨著數(shù)碼技術(shù)的大力發(fā)展，信息化系統(tǒng)已經(jīng)成為現(xiàn)代企業(yè)運(yùn)轉(zhuǎn)的必備手段之一。假如說(shuō)這個(gè)信息化系統(tǒng)中的數(shù)據(jù)庫(kù)在系統(tǒng)崩潰或數(shù)據(jù)誤刪除之后不能及時(shí)修復(fù)，那么對(duì)于企業(yè)的打擊將不可想象。因此，如何對(duì)數(shù)據(jù)庫(kù)進(jìn)行備份和恢復(fù)就成為很多企業(yè)需要重視的問(wèn)題。本篇文章重點(diǎn)介紹的方法。

一、什么是bin log文件?

MySQL的bin log文件是一個(gè)二進(jìn)制日志文件，它記錄了MySQL服務(wù)器執(zhí)行的所有數(shù)據(jù)更改操作。它包含從服務(wù)器啟動(dòng)到現(xiàn)在之間的所有SQL命令，以及命令執(zhí)行后影響的行數(shù)等詳細(xì)信息。

二、為什么？

在維護(hù)一個(gè)大型的數(shù)據(jù)系統(tǒng)時(shí)，數(shù)據(jù)丟失或系統(tǒng)崩潰是不可避免的。在這種情況下，從備份數(shù)據(jù)中恢復(fù)數(shù)據(jù)庫(kù)是最常用的方法。然而，在某些情況下，我們可能沒(méi)有及時(shí)地進(jìn)行數(shù)據(jù)備份工作，或者是備份數(shù)據(jù)也已經(jīng)因?yàn)楦鞣N原因而丟失了，此時(shí)我們就需要使用MySQL的bin log文件進(jìn)行數(shù)據(jù)庫(kù)恢復(fù)。

三、如何

在MySQL的bin log文件中，每一條記錄都包含一條SQL命令的執(zhí)行情況。如果要恢復(fù)到某個(gè)特定時(shí)間點(diǎn)的狀態(tài)，需要先找到該時(shí)間點(diǎn)之前的最后一個(gè)命令的位置。具體的恢復(fù)方法如下：

1. 找到最新的備份數(shù)據(jù)

在使用bin log文件恢復(fù)時(shí)需要先找到最新的備份數(shù)據(jù)，并根據(jù)該備份數(shù)據(jù)進(jìn)行恢復(fù)。如果沒(méi)有備份數(shù)據(jù)可以使用，則只能按照bin log文件中的記錄一個(gè)一個(gè)恢復(fù)。

2. 定位bin log文件

使用bin log文件進(jìn)行恢復(fù)需要先找到bin log文件。一般默認(rèn)存儲(chǔ)在MySQL的數(shù)據(jù)目錄下，以binlog開(kāi)頭，并以數(shù)字形式命名?？梢允褂肧HOW MASTER STATUS命令查看當(dāng)前的bin log文件和位置。

3. 分析bin log文件中的內(nèi)容

使用mysqlbinlog命令可以將bin log文件中的內(nèi)容以人類(lèi)可讀的形式輸出?？梢酝ㄟ^(guò)-G選項(xiàng)指定輸出的格式，例如輸出每一條記錄的時(shí)間戳，執(zhí)行數(shù)據(jù)庫(kù)命令的用戶名以及執(zhí)行的SQL命令內(nèi)容等。

4. 恢復(fù)數(shù)據(jù)

將bin log文件中的命令逐個(gè)執(zhí)行，可以把數(shù)據(jù)庫(kù)恢復(fù)到特定的時(shí)間點(diǎn)。這些命令的執(zhí)行順序非常重要，必須在正確的順序下才能有效地進(jìn)行恢復(fù)。

四、bin log文件的缺點(diǎn)

有以下缺點(diǎn)：

1. 需要手動(dòng)處理bin log文件，花費(fèi)時(shí)間較長(zhǎng)。

2. bin log文件中記錄的內(nèi)容過(guò)于詳細(xì)，恢復(fù)時(shí)需要一步步逐條執(zhí)行，比較麻煩。

3. bin log文件中包含了所有的更改操作，包括被刪除的數(shù)據(jù)，而且沒(méi)有可靠的過(guò)濾機(jī)制，無(wú)法確?；謴?fù)的數(shù)據(jù)兼容且一致。

五、

盡管bin log文件在恢復(fù)數(shù)據(jù)庫(kù)的過(guò)程中存在一定的缺點(diǎn)，但它是一種可靠的恢復(fù)數(shù)據(jù)庫(kù)的方法。事實(shí)上，在大多數(shù)情況下，使用bin log文件進(jìn)行數(shù)據(jù)恢復(fù)的成功率很高。因此，無(wú)論是一個(gè)小型的網(wǎng)站還是大型的企業(yè)系統(tǒng)，都應(yīng)該在備份的同時(shí)保留bin log文件，以保障在系統(tǒng)崩潰或數(shù)據(jù)誤刪除時(shí)的數(shù)據(jù)安全。

相關(guān)問(wèn)題拓展閱讀：

mysql恢復(fù)數(shù)據(jù)mysqlbinlog
MySQL怎么恢復(fù)半個(gè)月前的數(shù)據(jù)？

mysql恢復(fù)數(shù)據(jù)mysqlbinlog

有完整備份的話，先用完整備份還原下，然后在用binlog恢復(fù)從完整備份到當(dāng)前時(shí)間點(diǎn)的數(shù)據(jù)。

如果沒(méi)有完整備份的話，使用binlog也可以恢復(fù)，不過(guò)10G的數(shù)據(jù)可能需要很長(zhǎng)的時(shí)間。

相關(guān)語(yǔ)法如下：

mysql -hlocalhost test 1.sql

當(dāng)啟動(dòng)Binlog后，事務(wù)會(huì)產(chǎn)生Binlog Event，這些Event被看做事務(wù)數(shù)據(jù)的一部分。因此要保證事務(wù)的Binlog Event和InnoDB引擎中的數(shù)據(jù)的一致性。所以帶Binlog的CrashSafe要求MySQL宕機(jī)重啟后能夠保證：

– 所有已經(jīng)提交的事務(wù)的數(shù)據(jù)仍然存在。

– 所有沒(méi)有提交的事務(wù)的數(shù)據(jù)自動(dòng)回滾。

– 所有已經(jīng)提交了的事務(wù)的Binlog Event也仍然存在。

– 所有沒(méi)有提交事務(wù)沒(méi)有記錄Binlog Event。

這些要求很好理解，如果重啟后數(shù)據(jù)還在，但是Binlog Event沒(méi)有了，就沒(méi)辦法復(fù)制到其他節(jié)點(diǎn)上了。如果重啟后，數(shù)據(jù)沒(méi)了，但是Binlog Event還在，那么不存在的數(shù)據(jù)就會(huì)被復(fù)制到其他節(jié)點(diǎn)上，從而導(dǎo)致主從的不一致。

為了保證帶Binlog的CrashSafe，MySQL內(nèi)部使用的兩階段提交(Two Phase Commit)。

2 – MySQL的Two Phase Commit(2PC)

在開(kāi)啟Binlog后，MySQL內(nèi)部會(huì)自動(dòng)將普通事務(wù)當(dāng)做一個(gè)XA事務(wù)來(lái)處理：

– 自動(dòng)為每個(gè)事務(wù)分配一個(gè)唯一的ID

– COMMIT會(huì)被自動(dòng)的分成Prepare和Commit兩個(gè)階段。

– Binlog會(huì)被當(dāng)做事務(wù)協(xié)調(diào)者(Transaction Coordinator)，Binlog Event會(huì)被當(dāng)做協(xié)調(diào)者日志。

想了解2PC，可以參考文檔：【

。】

– 分布式事務(wù)ID(XID)

使用2PC時(shí)，MySQL會(huì)自動(dòng)的為每一個(gè)事務(wù)分配一個(gè)ID，叫XID。XID是唯一的，每個(gè)事務(wù)的XID都不相同。XID會(huì)分別被Binlog和InnoDB記入日志中，供恢復(fù)時(shí)使用。MySQ內(nèi)部的XID由三部分組成：

– 前綴部分

前綴部分是字符串”MySQLXid”

– Server ID部分

當(dāng)前MySQL的server_id

– query_id部分

為了保證XID的的唯一性，數(shù)字部分使用了query_id。MySQL內(nèi)部會(huì)自動(dòng)的為每一個(gè)語(yǔ)句分配一個(gè)query_id，全局唯一。

參考代碼：sql/xa。h的struct xid_t結(jié)構(gòu)。

– 事務(wù)的協(xié)調(diào)者Binlog

Binlog在2PC中充當(dāng)了事務(wù)的協(xié)調(diào)者（Transaction Coordinator）。由Binlog來(lái)通知InnoDB引擎來(lái)執(zhí)行prepare，commit或者rollback的步驟。事務(wù)提交的整個(gè)過(guò)程如下：

1. 協(xié)調(diào)者準(zhǔn)備階段(Prepare Phase)

告訴引擎做Prepare，InnoDB更改事務(wù)狀態(tài)，并將Redo Log刷入磁盤(pán)。

2. 協(xié)調(diào)者提交階段(Commit Phase)

2.1 記錄協(xié)調(diào)者日志，即Binlog日志。

2.2 告訴引擎做commit。

注意：記錄Binlog是在InnoDB引擎Prepare(即Redo Log寫(xiě)入磁盤(pán))之后，這點(diǎn)至關(guān)重要。

在MySQ的代碼中將協(xié)調(diào)者叫做tc_log。在MySQL啟動(dòng)時(shí)，tc_log將被初始化為mysql_bin_log對(duì)象。參考sql/binlog.cc中的init_server_components()：

if (opt_bin_log) tc_log= &mysql_bin_log;

而在事務(wù)提交時(shí)，會(huì)依次執(zhí)行：

tc_log->prepare()；

tc_log->commit()；

參考代碼：sql/binlog.cc中的ha_commit_trans()。當(dāng)mysql_bin_log是tc_log時(shí)，prepare和commit的代碼在sql/binlog.cc中：

MYSQL_BIN_LOG::prepare()；

MYSQL_BIN_LOG::commit()；

-協(xié)調(diào)者日志Xid_log_event

作為協(xié)調(diào)者，Binlog需要將事務(wù)的XID記入日志，供恢復(fù)時(shí)使用。Xid_log_event有以下幾個(gè)特點(diǎn)：

– 僅記錄query_id

因?yàn)榍熬Y部分不變，server_id已經(jīng)記錄在Event Header中，Xid_log_event中只記錄query_id部分。

– 標(biāo)志事務(wù)的結(jié)束

在Binlog中相當(dāng)于一個(gè)事務(wù)的COMMIT語(yǔ)句。

一個(gè)事務(wù)在Binlog中看起來(lái)時(shí)這樣的：

Query_log_event(“BEGIN”);DML產(chǎn)生的events; Xid_log_event;

– DDL沒(méi)有BEGIN，也沒(méi)有Xid_log_event 。

– 僅InnoDB的DML會(huì)產(chǎn)生Xid_log_event

因?yàn)镸yISAM不支持2PC所以不能用Xid_log_event ，但會(huì)有COMMIT Event。

Query_log_event(“BEGIN”);DML產(chǎn)生的events;Query_log_event(“COMMIT”);

問(wèn)題：Query_log_event(“COMMIT”)和Xid_log_event 有不同的影響嗎？

– Xid_log_event 中的Xid可以幫助master實(shí)現(xiàn)CrashSafe。

– Slave的CrashSafe不依賴(lài)Xid_log_event

事務(wù)在Slave上重做時(shí)，會(huì)重新產(chǎn)生XID。所以Slave服務(wù)器的CrashSafe并不依賴(lài)于Xid_log_event 。Xid_log_event 和Query_log_event(“COMMIT”)，只是作為事務(wù)的結(jié)尾，告訴Slave Applier去提交這個(gè)事務(wù)。因此二者在Slave上的影響是一樣的。

3 – 恢復(fù)(Recovery)

這個(gè)機(jī)制是如何保證MySQL的CrashSafe的呢，我們來(lái)分析一下。這里我們假設(shè)用戶設(shè)置了以下參數(shù)來(lái)保證可靠性：

– 恢復(fù)前事務(wù)的狀態(tài)

在恢復(fù)開(kāi)始前事務(wù)有以下幾種狀態(tài)：

– InnoDB中已經(jīng)提交

根據(jù)前面2PC的過(guò)程，可知Binlog中也一定記錄了該事務(wù)的的Events。所以這種事務(wù)是一致的不需要處理。

– InnoDB中是prepared狀態(tài)，Binlog中有該事務(wù)的Events。

需要通知InnoDB提交這些事務(wù)。

– InnoDB中是prepared狀態(tài)，Binlog中沒(méi)有該事務(wù)的Events。

因?yàn)锽inlog還沒(méi)記錄，需要通知InnoDB回滾這些事務(wù)。

– Before InnoDB Prepare

事務(wù)可能還沒(méi)執(zhí)行完，因此InnoDB中的狀態(tài)還沒(méi)有prepare。根據(jù)2PC的過(guò)程，Binlog中也沒(méi)有該事務(wù)的events。需要通知InnoDB回滾這些事務(wù)。

– 恢復(fù)過(guò)程

從上面的事務(wù)狀態(tài)可以看出：恢復(fù)時(shí)事務(wù)要提交還是回滾，是由Binlog來(lái)決定的。

– 事務(wù)的Xid_log_event 存在，就要提交。

– 事務(wù)的Xid_log_event 不存在，就要回滾。

恢復(fù)的過(guò)程非常簡(jiǎn)單：

– 從Binlog中讀出所有的Xid_log_event

– 告訴InnoDB提交這些XID的事務(wù)

– InnoDB回滾其它的事務(wù)

MySQL怎么恢復(fù)半個(gè)月前的數(shù)據(jù)？

首先確認(rèn)一下是否有散耐銷(xiāo)定期的備份任務(wù)，如果沒(méi)有在考慮下面的方式。

配置參數(shù)沖游上，是否開(kāi)啟了bin-log日志？如果開(kāi)啟了并且bin-log日志的周期保畝孝留比較長(zhǎng)，可以通過(guò)重放bin-log日志的方式恢復(fù)數(shù)據(jù)。

通過(guò)整庫(kù)備份+binlog進(jìn)行恢復(fù). 前提是要有定期整庫(kù)備份且保存了binlog日志.。

通過(guò)bin log恢復(fù)數(shù)據(jù)庫(kù)的介紹就聊到這里吧，感謝你花時(shí)間閱讀本站內(nèi)容，更多關(guān)于通過(guò)bin log恢復(fù)數(shù)據(jù)庫(kù),使用bin log文件進(jìn)行數(shù)據(jù)庫(kù)恢復(fù),mysql恢復(fù)數(shù)據(jù)mysqlbinlog,MySQL怎么恢復(fù)半個(gè)月前的數(shù)據(jù)？的信息別忘了在本站進(jìn)行查找喔。

香港服務(wù)器選創(chuàng)新互聯(lián)，2H2G首月10元開(kāi)通。
創(chuàng)新互聯(lián)（www.cdcxhl.com）互聯(lián)網(wǎng)服務(wù)提供商,擁有超過(guò)10年的服務(wù)器租用、服務(wù)器托管、云服務(wù)器、虛擬主機(jī)、網(wǎng)站系統(tǒng)開(kāi)發(fā)經(jīng)驗(yàn)。專(zhuān)業(yè)提供云主機(jī)、虛擬主機(jī)、域名注冊(cè)、VPS主機(jī)、云服務(wù)器、香港云服務(wù)器、免備案服務(wù)器等。

新聞標(biāo)題：使用binlog文件進(jìn)行數(shù)據(jù)庫(kù)恢復(fù)(通過(guò)binlog恢復(fù)數(shù)據(jù)庫(kù))
網(wǎng)頁(yè)地址：http://m.fisionsoft.com.cn/article/djjdgsc.html

新聞中心

mysql恢復(fù)數(shù)據(jù)mysqlbinlog

MySQL怎么恢復(fù)半個(gè)月前的數(shù)據(jù)？

其他資訊

MySQL怎么恢復(fù)半個(gè)月前的數(shù)據(jù)？