我們經(jīng)常會遇到操作一張大表,發(fā)現(xiàn)操作時間過長或影響在線業(yè)務(wù)了,想要回退大表操作的場景。在我們停止大表操作之后,等待回滾是一個很漫長的過程,盡管你可能對知道一些縮短時間的方法,處于對生產(chǎn)環(huán)境數(shù)據(jù)完整性的敬畏,也會選擇不做介入。最終選擇不作為的原因大多源于對操作影響的不確定性。實踐出真知,下面針對兩種主要提升事務(wù)回滾速度的方式進行驗證,一種是提升操作可用內(nèi)存空間,一種是通過停實例,禁用 redo 回滾方式進行進行驗證。
成都創(chuàng)新互聯(lián)專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務(wù),包含不限于成都網(wǎng)站設(shè)計、成都做網(wǎng)站、長葛網(wǎng)絡(luò)推廣、小程序定制開發(fā)、長葛網(wǎng)絡(luò)營銷、長葛企業(yè)策劃、長葛品牌公關(guān)、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運營等,從售前售中售后,我們都將竭誠為您服務(wù),您的肯定,是我們最大的嘉獎;成都創(chuàng)新互聯(lián)為所有大學(xué)生創(chuàng)業(yè)者提供長葛建站搭建服務(wù),24小時服務(wù)熱線:18982081108,官方網(wǎng)址:www.cdcxhl.com
仔細閱讀過官方手冊的同學(xué),一定留意到了對于提升大事務(wù)回滾效率,官方提供了兩種方法:一是增加 innodb_buffer_pool_size 參數(shù)大小,二是合理利用 innodb_force_recovery=3 參數(shù),跳過事務(wù)回滾過程。第一種方式比較溫和,innodb_buffer_pool_size 參數(shù)是可以動態(tài)調(diào)整的,可行性也較高。第二種方式相較之下較暴力,但效果較好。
兩種方式各有自己的優(yōu)點,第一種方式對線上業(yè)務(wù)系統(tǒng)影響較小,不會中斷在線業(yè)務(wù)。第二種方式效果更顯著,會短暫影響業(yè)務(wù)連續(xù),回滾所有沒有提交的事務(wù)。
MYSQL 事務(wù)處理主要有兩種方法
1、用 begin, rollback, commit 來實現(xiàn)
begin 或/ start transaction )開始一個事務(wù)
rollback 事務(wù)回滾
commit 事務(wù)確認
2、直接用 SET 來改變 MySQL 的自動提交模式:
set autocommit=0 禁止自動提交
set autocommit=1 開啟自動提交
1.不管 autocommit 是1還是0
start transaction 后,只有當(dāng) commit 數(shù)據(jù)才會生效, rollback 后就會回滾。
2、當(dāng) autocommit 為 0 時
不管有沒有 start transaction .
只有當(dāng) commit 數(shù)據(jù)才會生效, rollback 后就會回滾。
3、如果 autocommit 為1 ,并且沒有 start transaction .
調(diào)用 rollback 是沒有用的。因為事務(wù)已經(jīng)自動提交了。
事務(wù)測試1
事務(wù)測試2
flag 相當(dāng)一定義這個保存點的名字
savepoint flag : savepoint 允許在事務(wù)中創(chuàng)建一個保存點,一個事務(wù)中可以有多個savepoint ;
release savepoint flag :刪除一個事務(wù)的保存點,當(dāng)沒有指定的保存點時,執(zhí)行該語句會拋出一個異常;
rollback to flag :把事務(wù)回滾到標記點;
set transaction :用來設(shè)置事務(wù)的隔離級別。InnoDB存儲引擎提供事務(wù)的隔離級別有
READ UNCOMMITTED 、 READ COMMITTED 、 REPEATABLE READ 和 SERIALIZABLE
select @@transaction_isolation;
SELECT @@SESSION.transaction_isolation, @@SESSION.transaction_read_only;
當(dāng)啟動Binlog后,事務(wù)會產(chǎn)生Binlog Event,這些Event被看做事務(wù)數(shù)據(jù)的一部分。因此要保證事務(wù)的Binlog Event和InnoDB引擎中的數(shù)據(jù)的一致性。所以帶Binlog的CrashSafe要求MySQL宕機重啟后能夠保證:
- 所有已經(jīng)提交的事務(wù)的數(shù)據(jù)仍然存在。
- 所有沒有提交的事務(wù)的數(shù)據(jù)自動回滾。
- 所有已經(jīng)提交了的事務(wù)的Binlog Event也仍然存在。
- 所有沒有提交事務(wù)沒有記錄Binlog Event。
這些要求很好理解,如果重啟后數(shù)據(jù)還在,但是Binlog Event沒有了,就沒辦法復(fù)制到其他節(jié)點上了。如果重啟后,數(shù)據(jù)沒了,但是Binlog Event還在,那么不存在的數(shù)據(jù)就會被復(fù)制到其他節(jié)點上,從而導(dǎo)致主從的不一致。
為了保證帶Binlog的CrashSafe,MySQL內(nèi)部使用的兩階段提交(Two Phase Commit)。
2 - MySQL的Two Phase Commit(2PC)
在開啟Binlog后,MySQL內(nèi)部會自動將普通事務(wù)當(dāng)做一個XA事務(wù)來處理:
- 自動為每個事務(wù)分配一個唯一的ID
- COMMIT會被自動的分成Prepare和Commit兩個階段。
- Binlog會被當(dāng)做事務(wù)協(xié)調(diào)者(Transaction Coordinator),Binlog Event會被當(dāng)做協(xié)調(diào)者日志。
想了解2PC,可以參考文檔:【?!?/p>
- 分布式事務(wù)ID(XID)
使用2PC時,MySQL會自動的為每一個事務(wù)分配一個ID,叫XID。XID是唯一的,每個事務(wù)的XID都不相同。XID會分別被Binlog和InnoDB記入日志中,供恢復(fù)時使用。MySQ內(nèi)部的XID由三部分組成:
- 前綴部分
前綴部分是字符串"MySQLXid"
- Server ID部分
當(dāng)前MySQL的server_id
- query_id部分
為了保證XID的的唯一性,數(shù)字部分使用了query_id。MySQL內(nèi)部會自動的為每一個語句分配一個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來通知InnoDB引擎來執(zhí)行prepare,commit或者rollback的步驟。事務(wù)提交的整個過程如下:
1. 協(xié)調(diào)者準備階段(Prepare Phase)
告訴引擎做Prepare,InnoDB更改事務(wù)狀態(tài),并將Redo Log刷入磁盤。
2. 協(xié)調(diào)者提交階段(Commit Phase)
2.1 記錄協(xié)調(diào)者日志,即Binlog日志。
2.2 告訴引擎做commit。
注意:記錄Binlog是在InnoDB引擎Prepare(即Redo Log寫入磁盤)之后,這點至關(guān)重要。
在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;
而在事務(wù)提交時,會依次執(zhí)行:
tc_log-prepare();
tc_log-commit();
參考代碼:sql/binlog.cc中的ha_commit_trans()。當(dāng)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需要將事務(wù)的XID記入日志,供恢復(fù)時使用。Xid_log_event有以下幾個特點:
- 僅記錄query_id
因為前綴部分不變,server_id已經(jīng)記錄在Event Header中,Xid_log_event中只記錄query_id部分。
- 標志事務(wù)的結(jié)束
在Binlog中相當(dāng)于一個事務(wù)的COMMIT語句。
一個事務(wù)在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
事務(wù)在Slave上重做時,會重新產(chǎn)生XID。所以Slave服務(wù)器的CrashSafe并不依賴于Xid_log_event 。Xid_log_event 和Query_log_event("COMMIT"),只是作為事務(wù)的結(jié)尾,告訴Slave Applier去提交這個事務(wù)。因此二者在Slave上的影響是一樣的。
3 - 恢復(fù)(Recovery)
這個機制是如何保證MySQL的CrashSafe的呢,我們來分析一下。這里我們假設(shè)用戶設(shè)置了以下參數(shù)來保證可靠性:
- 恢復(fù)前事務(wù)的狀態(tài)
在恢復(fù)開始前事務(wù)有以下幾種狀態(tài):
- InnoDB中已經(jīng)提交
根據(jù)前面2PC的過程,可知Binlog中也一定記錄了該事務(wù)的的Events。所以這種事務(wù)是一致的不需要處理。
- InnoDB中是prepared狀態(tài),Binlog中有該事務(wù)的Events。
需要通知InnoDB提交這些事務(wù)。
- InnoDB中是prepared狀態(tài),Binlog中沒有該事務(wù)的Events。
因為Binlog還沒記錄,需要通知InnoDB回滾這些事務(wù)。
- Before InnoDB Prepare
事務(wù)可能還沒執(zhí)行完,因此InnoDB中的狀態(tài)還沒有prepare。根據(jù)2PC的過程,Binlog中也沒有該事務(wù)的events。 需要通知InnoDB回滾這些事務(wù)。
- 恢復(fù)過程
從上面的事務(wù)狀態(tài)可以看出:恢復(fù)時事務(wù)要提交還是回滾,是由Binlog來決定的。
- 事務(wù)的Xid_log_event 存在,就要提交。
- 事務(wù)的Xid_log_event 不存在,就要回滾。
恢復(fù)的過程非常簡單:
- 從Binlog中讀出所有的Xid_log_event
- 告訴InnoDB提交這些XID的事務(wù)
- InnoDB回滾其它的事務(wù)
關(guān)于事務(wù)
設(shè)置savepoint和回滾到savepoint