建站
咨詢
售后
建站咨詢
新聞中心
汗顏！工作10年去面試，被“MySQL怎么保證事物一致性”難倒了
阿牛去一家中意的公司面試，本以為憑借以往豐富的經(jīng)驗，肯定手到擒來，結(jié)果第一個問題，我就“出門右拐”了。
成都創(chuàng)新互聯(lián)公司成立與2013年，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項目成都網(wǎng)站制作、成都做網(wǎng)站網(wǎng)站策劃，項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命，1280元赤城做網(wǎng)站,已為上家服務(wù),為赤城各地企業(yè)和個人服務(wù),聯(lián)系電話:13518219792
問題就是：MySQL是怎么保證事務(wù)一致性的？
回到家阿牛翻閱資料，終于搞懂了，在這里分享給大家。
定義
在搞清楚問題答案之前，先搞清楚以下幾個名詞以及大致的用處
redo log：
通常是物理日志，記錄的是數(shù)據(jù)頁的物理修改，而不是某一行或某幾行修改成怎樣怎樣，它用來恢復(fù)提交后的物理數(shù)據(jù)頁(恢復(fù)數(shù)據(jù)頁，且只能恢復(fù)到最后一次提交的位置)、Innodb特有的，他在存儲引擎層。循環(huán)寫的，空間固定會用完。作用是crash-safe能力
binlog：
是邏輯日志，記錄的是這個語句的原始邏輯，比如“給 ID=2 這一行的 c 字段加 1 ” 是 MySQL 的 Server 層實現(xiàn)的，所有引擎都可以使用。是可以追加寫入的,“追加寫”是指 binlog 文件寫到一定大小后會切換到下一個，并不會覆蓋以前的日志。作用是數(shù)據(jù)歸檔
undo log：
有兩個作用：提供回滾和多個行版本控制(MVCC)。
在數(shù)據(jù)修改的時候，不僅記錄了redo，還記錄了相對應(yīng)的undo，如果因為某些原因?qū)е率聞?wù)失敗或回滾了，可以借助該undo進行回滾。
SQL執(zhí)行的過程
了解了以上名詞之后，讓我們看一下“一條更新SQL語句執(zhí)行的過程是什么？”
如圖1有幾個關(guān)鍵步驟：
1、先查找記錄所在的Innodb頁在不在內(nèi)存里；如果不在內(nèi)存里則將記錄所在的頁加載在內(nèi)存里；根據(jù)SQL語句在內(nèi)存中將記錄更新
2、將更新前的記錄寫入undolog
3、根據(jù)記錄的更新值將變更寫入redolog（buffer）中，并將狀態(tài)變更為prepare
4、將變更記錄到邏輯日志
5、redolog日志中的狀態(tài)修改為commit，返回結(jié)束
至此：一條更新語句的過程結(jié)束
上面的步驟中有些同學(xué)可能會有一些疑問：為什么更新一條記錄要把一整頁數(shù)據(jù)加載到內(nèi)存里答：因為Innodb引擎中，最小的存儲單位是頁為什么一定要加載到內(nèi)存里？答：因為所有的計算操作都是在內(nèi)存里，操作完成后最終才寫回磁盤為什么要寫入redolog，直接寫入磁盤，然后寫入binlog就好了?。看穑哼@將在下面會提到，請往后看
為了加深理解，準(zhǔn)備了下面2張圖輔助理解
以圖3為例，讓我們看看在每個步驟出現(xiàn)異常的時候，到底怎么保證事物一致性的吧！1、步驟123，所有的操作最多還只是內(nèi)存里，如果出現(xiàn)宕機、斷電等異常，? 記錄不會有任何變動，事物是一致的2、步驟4剛執(zhí)行完，斷電了，因為redolog還處在prepare狀態(tài)，???這時候事物也是一致的3、步驟5記錄binlog的過程中斷電了，這時候要保證主從一致性，? 事物也是不生效的，最終也是一致的4、步驟6、7如果中間任何一個時刻斷電了，這時候情況就不一樣了，事物是生效的，因為redolog、binlog的數(shù)據(jù)都是完整的，服務(wù)器重啟后可以按照xid來去查看binlog、redolog中是否都存在，? 都存在該事物就是生效的。上面就是怎么保證事務(wù)一致性的根本原因
為什么要使用redolog？
回答這個問題之前，我們先看看redolog用圖形表示的
圖4是redolog的形象一點的表現(xiàn)，并不是說redolog 長這個樣子，只是為了更形象；一般情況下redolog一組4個文件，每個文件1個G，其中write pos是指redolog當(dāng)前寫到什么位置了，check point是指上次刷臟結(jié)束的位置，當(dāng)write log和check point重合時，所有的進程停止，開始新一輪的刷臟操作。刷完后redolog清空開始下一輪的寫入，往返重復(fù)。
可能這樣表示有點抽象，讓我們看下圖5
從上圖中可以看的更形象一點，在sql執(zhí)行的時候，會有磁盤IO將數(shù)據(jù)頁加載到內(nèi)存，然后在內(nèi)存中將數(shù)據(jù)修改，修改后的數(shù)據(jù)頁在內(nèi)存中叫做臟頁（叫臟頁因為和磁盤中的數(shù)據(jù)不一致?。?，又因為在內(nèi)存中容易丟失，所以將數(shù)據(jù)頁的變更記錄如redolog中，隨著記錄插入、更新等操作的增多，redolog空間慢慢的滿了，這時候就開始刷臟操作了，page cleaner thread線程會將所有的臟頁數(shù)據(jù)刷新到磁盤，使得變更最終被持久化到磁盤。
講到這里一定還會有人不太理解，刷臟之前斷電了咋辦？
這就是redolog的另一個重要的作用，crash-safe能力，實現(xiàn)的邏輯是這樣的，斷電后內(nèi)存的數(shù)據(jù)都沒了，重啟后讀取redolog文件，因為redolog文件記錄的是在Innodb頁x的m處做了y的修改，所以根據(jù)redolog將涉及到的Innodb頁重新加載到內(nèi)存，根據(jù)redolog的記錄將內(nèi)存中的數(shù)據(jù)重新修改，這樣就能恢復(fù)斷電前的數(shù)據(jù)了。
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?完
下期預(yù)告：還是MySQL，敬請期待
本文首發(fā)自： 程序員阿牛
怎么避免mysql從庫同步 怎么保證數(shù)據(jù)一致性
用 pt-table-checksum 時，會不會影響業(yè)務(wù)性能？
實驗
實驗開始前，給大家分享一個小經(jīng)驗：任何性能評估，不要相信別人的評測結(jié)果，要在自己的環(huán)境上測試，并（大概）知曉原理。
我們先建一對主從：
然后用 mysqlslap跑一個持續(xù)的壓力：
開另外一個會話，將 master 上的 general log 打開：
然后通過 pt-table-checksum 進行一次比較：
查看 master 的 general log，由于 mysqlslap 的影響，general log 中有很多內(nèi)容，我們找到與 pt-table-checksum 相關(guān)的線程：
將該線程的操作單獨列出來：
操作比較多，我們一點一點來說明：
這里工具調(diào)小了 innodb 鎖等待時間。使得之后的操作，只要在 innodb 上稍微有鎖等待，就會馬上放棄操作，對業(yè)務(wù)影響很小。
另外工具調(diào)小了 wait_timeout 時間，倒是沒有特別的作用。
工具將隔離級別調(diào)整為了 RR 級別，事務(wù)的維護代價會比 RC 要高，不過后面我們會看到工具使用的每個事務(wù)都很小，加上之前提到 innodb 鎖等待時間調(diào)到很小，對線上業(yè)務(wù)產(chǎn)生的成本比較小。
RR 級別是數(shù)據(jù)對比的基本要求。
工具通過一系列操作，了解表的概況。工具是一個數(shù)據(jù)塊一個數(shù)據(jù)塊進行校驗，這里獲取了第一個數(shù)據(jù)塊的下邊界。
接下來工具獲取了下一個數(shù)據(jù)塊的下邊界，每個 SQL前都會 EXPLAIN 一下，看一下執(zhí)行成本，非常小心翼翼。
之后工具獲取了一個數(shù)據(jù)塊的 checksum，這個數(shù)據(jù)塊不大，如果跟業(yè)務(wù)流量有沖突，會馬上出發(fā) innodb 的鎖超時，立刻退讓。
以上是 pt-table-checksum 的一些設(shè)計，可以看到這幾處都是精心維護了業(yè)務(wù)流量不受影響。
工具還設(shè)計了其他的一些機制保障業(yè)務(wù)流量，比如參數(shù) --max-load 和 --pause-file 等，還有精心設(shè)計的數(shù)據(jù)塊劃分方法，索引選擇方法等。大家根據(jù)自己的情況配合使用即可達到很好的效果。
總結(jié)
本期我們介紹了簡單分析 pt-table-checksum 是否會影響業(yè)務(wù)流量，坊間會流傳工具的各種參數(shù)建議或者不建議使用，算命的情況比較多，大家都可以用簡單的實驗來分析其中機制。
還是那個觀點，性能測試不能相信道聽途說，得通過實驗去分析。
mysql 如何解決數(shù)據(jù)一致性
MySQL主從復(fù)制
現(xiàn)在常用的MySQL高可用方案，十有八九是基于 MySQL的主從復(fù)制（replication）來設(shè)計的，包括常規(guī)的一主一從、雙主模式，或者半同步復(fù)制（semi-sync replication）。
我們常常把MySQL replication說成是MySQL同步（sync），但事實上這個過程是異步（async）的。大概過程是這樣的：
在master上提交事務(wù)后，并且寫入binlog，返回事務(wù)成功標(biāo)記；
將binlog發(fā)送到slave，轉(zhuǎn)儲成relay log；
在slave上再將relay log讀取出來應(yīng)用。
步驟1和步驟3之間是異步進行的，無需等待確認各自的狀態(tài)，所以說MySQL replication是異步的。
MySQL semi-sync replication在之前的基礎(chǔ)上做了加強完善，整個流程變成了下面這樣：
首先，master和至少一個slave都要啟用semi-sync replication模式；
某個slave連接到master時，會主動告知當(dāng)前自己是否處于semi-sync模式；
在master上提交事務(wù)后，寫入binlog后，還需要通知至少一個slave收到該事務(wù)，等待寫入relay log并成功刷新到磁盤后，向master發(fā)送“slave節(jié)點已完成該事務(wù)”確認通知；
master收到上述通知后，才可以真正完成該事務(wù)提交，返回事務(wù)成功標(biāo)記；
在上述步驟中，當(dāng)slave向master發(fā)送通知時間超過rpl_semi_sync_master_timeout設(shè)定值時，主從關(guān)系會從semi-sync模式自動調(diào)整成為傳統(tǒng)的異步復(fù)制模式。
半同步復(fù)制看起來很美好有木有，但如果網(wǎng)絡(luò)質(zhì)量不高，是不是出現(xiàn)抖動，觸發(fā)上述第5條的情況，會從半同步復(fù)制降級為普通復(fù)制；此外，采用半同步復(fù)制，會導(dǎo)致master上的tps性能下降非常嚴重，最嚴重的情況下可能會損失50%以上。
這樣來看，除非需要非常嚴格保證數(shù)據(jù)一致性等迫不得已的場景，就不太建議使用半同步復(fù)制了。當(dāng)然了，事實上我們也可以通過加強程序端的邏輯控制，來避免主從數(shù)據(jù)不一致時發(fā)生邏輯錯誤，比如說如果在從上讀取到的數(shù)據(jù)和主不一致的話，那么就觸發(fā)主從間的一次數(shù)據(jù)修復(fù)工作。或者，我們也可以用 pt-table-checksum pt-table-sync 兩個工具來校驗并修復(fù)數(shù)據(jù)，只要運行頻率適當(dāng)，是可行的。
真想要提高多節(jié)點間的數(shù)據(jù)一致性，可以考慮采用PXC方案?，F(xiàn)在已知用PXC規(guī)模較大的有qunar、sohu，如果團隊里初期沒有人能比較專注PXC的話，還是要謹慎些，畢竟和傳統(tǒng)的主從復(fù)制差異很大，出現(xiàn)問題時需要花費更多精力去排查解決。
如何保證主從復(fù)制數(shù)據(jù)一致性
上面說完了異步復(fù)制、半同步復(fù)制、PXC，我們回到主題：在常規(guī)的主從復(fù)制場景里，如何能保證主從數(shù)據(jù)的一致性，不要出現(xiàn)數(shù)據(jù)丟失等問題呢？
在MySQL中，一次事務(wù)提交后，需要寫undo、寫redo、寫binlog，寫數(shù)據(jù)文件等等。在這個過程中，可能在某個步驟發(fā)生crash，就有可能導(dǎo)致主從數(shù)據(jù)的不一致。為了避免這種情況，我們需要調(diào)整主從上面相關(guān)選項配置，確保即便發(fā)生crash了，也不能發(fā)生主從復(fù)制的數(shù)據(jù)丟失。
1. 在master上修改配置
innodb_flush_log_at_trx_commit = 1
sync_binlog = 1
上述兩個選項的作用是：保證每次事務(wù)提交后，都能實時刷新到磁盤中，尤其是確保每次事務(wù)對應(yīng)的binlog都能及時刷新到磁盤中，只要有了binlog，InnoDB就有辦法做數(shù)據(jù)恢復(fù)，不至于導(dǎo)致主從復(fù)制的數(shù)據(jù)丟失。
2. 在slave上修改配置
master_info_repository = "TABLE"
relay_log_info_repository = "TABLE"
relay_log_recovery = 1
上述前兩個選項的作用是：確保在slave上和復(fù)制相關(guān)的元數(shù)據(jù)表也采用InnoDB引擎，受到InnoDB事務(wù)安全的保護，而后一個選項的作用是開啟relay log自動修復(fù)機制，發(fā)生crash時，會自動判斷哪些relay log需要重新從master上抓取回來再次應(yīng)用，以此避免部分數(shù)據(jù)丟失的可能性。
通過上面幾個選項的調(diào)整，就可以確保主從復(fù)制數(shù)據(jù)不會發(fā)生丟失了。但是，這并不能保證主從數(shù)據(jù)的絕對一致性，因為，有可能設(shè)置了ignore\do\rewrite等replication規(guī)則，或者某些SQL本身存在不確定因素，或者人為在slave上修改數(shù)據(jù)，最終導(dǎo)致主從數(shù)據(jù)不一致。這種情況下，可以采用pt-table-checksum?和?pt-table-sync?工具來進行數(shù)據(jù)的校驗和修復(fù)。
本文名稱：mysql事物一致性怎么保證 mysql和mongodb怎么保證數(shù)據(jù)一致性
分享鏈接：http://www.dlmjj.cn/article/ddocijh.html
