mysql運行怎么回滾,mysql是如何實現事務回滾的

mysql命令行下怎樣實現數據的回滾操作

當啟動Binlog后，事務會產生Binlog Event，這些Event被看做事務數據的一部分。因此要保證事務的Binlog Event和InnoDB引擎中的數據的一致性。所以帶Binlog的CrashSafe要求MySQL宕機重啟后能夠保證：

我們提供的服務有：成都網站設計、網站建設、微信公眾號開發、網站優化、網站認證、西峰ssl等。為成百上千企事業單位解決了網站和推廣的問題。提供周到的售前咨詢和貼心的售后服務，是有科學管理、有技術的西峰網站制作公司

- 所有已經提交的事務的數據仍然存在。

- 所有沒有提交的事務的數據自動回滾。

- 所有已經提交了的事務的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之commit、rollback等事務控制命令

MYSQL 事務處理主要有兩種方法

1、用 begin, rollback, commit 來實現

begin 或/ start transaction )開始一個事務

rollback 事務回滾

commit 事務確認

2、直接用 SET 來改變 MySQL 的自動提交模式:

set autocommit=0 禁止自動提交

set autocommit=1 開啟自動提交

1.不管 autocommit 是1還是0

start transaction 后，只有當 commit 數據才會生效， rollback 后就會回滾。

2、當 autocommit 為 0 時

不管有沒有 start transaction .

只有當 commit 數據才會生效， rollback 后就會回滾。

3、如果 autocommit 為1 ，并且沒有 start transaction .

調用 rollback 是沒有用的。因為事務已經自動提交了。

事務測試1

事務測試2

flag 相當一定義這個保存點的名字

savepoint flag : savepoint 允許在事務中創建一個保存點，一個事務中可以有多個savepoint ；

release savepoint flag :刪除一個事務的保存點，當沒有指定的保存點時，執行該語句會拋出一個異常；

rollback to flag :把事務回滾到標記點；

set transaction :用來設置事務的隔離級別。InnoDB存儲引擎提供事務的隔離級別有

READ UNCOMMITTED 、 READ COMMITTED 、 REPEATABLE READ 和 SERIALIZABLE

select @@transaction_isolation;

SELECT @@SESSION.transaction_isolation, @@SESSION.transaction_read_only;

對一個執行成功的mysql命令，如何回滾

我們經常會遇到操作一張大表，發現操作時間過長或影響在線業務了，想要回退大表操作的場景。在我們停止大表操作之后，等待回滾是一個很漫長的過程，盡管你可能對知道一些縮短時間的方法，處于對生產環境數據完整性的敬畏，也會選擇不做介入。最終選擇不作為的原因大多源于對操作影響的不確定性。實踐出真知，下面針對兩種主要提升事務回滾速度的方式進行驗證，一種是提升操作可用內存空間，一種是通過停實例，禁用 redo 回滾方式進行進行驗證。

仔細閱讀過官方手冊的同學，一定留意到了對于提升大事務回滾效率，官方提供了兩種方法：一是增加 innodb_buffer_pool_size 參數大小，二是合理利用 innodb_force_recovery=3 參數，跳過事務回滾過程。第一種方式比較溫和，innodb_buffer_pool_size 參數是可以動態調整的，可行性也較高。第二種方式相較之下較暴力，但效果較好。

兩種方式各有自己的優點，第一種方式對線上業務系統影響較小，不會中斷在線業務。第二種方式效果更顯著，會短暫影響業務連續，回滾所有沒有提交的事務。

mysql不小心批量update，請問如何數據回滾

首先確定執行update語句時是否設置成的非自動提交，若設置了，直接rollback；若未設置，查看是否啟用了二進制日志文件，若是，將其恢復到執行該時間點前；若未設置，那數據庫層面就沒辦法了。

mysql如何做事件回滾

BEGIN//開始COMMIT//如果都成功，MYSQL沒錯誤就執行這個ROLLBACK//事件回滾 不過要注意的是，數據庫表要InnoDB這種格式。MyISAM這個格式不支持回滾的。

當前名稱：mysql運行怎么回滾,mysql是如何實現事務回滾的
新聞來源：http://m.kartarina.com/article22/hcspcc.html

成都網站建設公司_創新互聯，為您提供、服務器托管、網站改版、軟件開發、定制開發、網站營銷

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯