mysql數據庫還原到某一時刻,mysql數據庫恢復到某個時間

本文目錄一覽：

1、怎麼恢復mysql數據庫
2、在mysql數據庫誤執行sql腳本，如何恢復到之前時間點
3、有沒有什麼辦法可以把mysql回滾到某一時間
4、mysql數據庫怎樣用日誌恢複數據sql語句
5、如何恢複數據庫到某一時間點的數據？
6、mysqlbinlog 怎麼將數據庫恢復到指定的時間

怎麼恢復mysql數據庫

mysql數據庫恢復方法：

方法一：

命令恢複數據庫：

mysql -u root –password=root密碼數據庫名備份文件.sql

方法二：

第一步：用管理員權限登錄並進入後台管理界面，點“數據庫-資料恢復”。

第二步：在數據恢復設置中選擇“從本地文件”進行恢復，然後通過右邊的“瀏覽”按鈕找到之前保存下來的.sql文件。

第三步：點“提交”按鈕後將出現詢問“分卷數據成功導入數據庫，需要自動導入本次其他的備份嗎?”一般繼續點“確定”按鈕即可。之後的數據庫文件就完全導入到當前網站了。這時出現再次要求輸入管理員帳號的提示。訪問網站地址時也會看到所有信息都恢復到備份數據庫時的內容了。

小提示：

不管採取哪種方式備份和恢複數據庫，一定要注意備份和恢復時使用的版本要相同，甚至是語言種類也要一致，否則會存在亂碼的問題。

在mysql數據庫誤執行sql腳本，如何恢復到之前時間點

您好：

通常您只能通過備份數據庫進行恢復。

如果沒有備份，基本上是很難恢復的。。。

有沒有什麼辦法可以把mysql回滾到某一時間

當啟動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，可以參考文檔：【。】

– 分布式事務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回滾其它的事務

mysql數據庫怎樣用日誌恢複數據sql語句

要想從二進制日誌恢複數據，你需要知道當前二進制日誌文件的路徑和文件名。一般可以從選項文件(即my.cnf or my.ini，取決於你的系統)中找到路徑。如果未包含在選項文件中，當服務器啟動時，可以在命令行中以選項的形式給出。啟用二進制日誌的選項為– log-bin。要想確定當前的二進制日誌文件的文件名，輸入下面的MySQL語句：

SHOW BINLOG EVENTS /G

你還可以從命令行輸入下面的內容：

mysql –user=root -pmy_pwd -e ‘SHOW BINLOG EVENTS /G’

將密碼my_pwd替換為服務器的root密碼。

1. 指定恢復時間

對於MySQL 4.1.4，可以在mysqlbinlog語句中通過–start-date和–stop-date選項指定DATETIME格式的起止時間。舉例說明，假設在今天上午10:00(今天是2006年4月20日)，執行SQL語句來刪除一個大表。要想恢復表和數據，你可以恢復前晚上的備份，並輸入：

mysqlbinlog –stop-date=”2005-04-20 9:59:59″ /var/log/mysql/bin.123456 /

mysql -u root -pmypwd

該命令將恢復截止到在–stop-date選項中以DATETIME格式給出的日期和時間的所有數據。如果你沒有檢測到幾個小時後輸入的錯誤的SQL語句，可能你想要恢復後面發生的活動。根據這些，你可以用起使日期和時間再次運行mysqlbinlog：

mysqlbinlog –start-date=”2005-04-20 10:01:00″ /var/log/mysql/bin.123456 /

mysql -u root -pmypwd /

在該行中，從上午10:01登錄的SQL語句將運行。組合執行前夜的轉儲文件和mysqlbinlog的兩行可以將所有數據恢復到上午10:00前一秒鐘。你應檢查日誌以確保時間確切。

如何恢複數據庫到某一時間點的數據？

恢複數據庫到之前的某個時間點，必須要有日誌備份。

下面是一個使用日誌的示例：

create database db1

alter database db1 set recovery full

backup database db1 to disk=’db1.bak’ with init–首先要對數據庫進行全備份，否則checkpoint會階段inactive的日誌（類似於simple recovery）

use db1

create table t(col int)

—一些數據庫操作

–假設你在15點15分以後刪除了這個表

drop table t

–如果想恢復這個表，需要對數據庫進行日誌備份

use master

backup log db1 to disk=’db1.trn’ with norecovery

—然後執行以下操作

use master

restore database db1 from disk=’db1.bak’ with norecovery

restore log db1 from disk=’db1.trn’ with recovery,stopat=’2009-03-08 15:15:00′–這時，數據庫恢復到15:15的狀態。

mysqlbinlog 怎麼將數據庫恢復到指定的時間

先用數據備份以norecovery的方式恢復到最近時間點，然後再恢復日誌備份(如中間有多份則都用norecovery方式恢復)，最後一份選擇特定時間及recovery方式。

原創文章，作者：MGZP，如若轉載，請註明出處：https://www.506064.com/zh-hant/n/137814.html