欧美性猛交XXXX免费看蜜桃,成人网18免费韩国,亚洲国产成人精品区综合,欧美日韩一区二区三区高清不卡,亚洲综合一区二区精品久久

bin-log & redo-log & undo log

1. 避免從刪庫到跑路 - bin log

怎么避免從刪庫到跑路 – 詳解 mysql binlog 的配置與使用

1.1 什么是bin log

• binlog 即二進(jìn)制日志，他記錄了引起或可能引起數據庫改變事件，包括事件發(fā)生的時(shí)間、開(kāi)始位置、結束位置等信息，select、show 等查詢(xún)語(yǔ)句不會(huì )引起數據庫改變，因此不會(huì )被記錄在 binlog 中
• 對于事務(wù)的執行，只有事務(wù)提交時(shí)才會(huì )一次性寫(xiě)入 binlog，對于非事務(wù)操作，則每次語(yǔ)句執行成功后都會(huì )直接寫(xiě)入 binlog
• 因此，基于 binlog，我們可以看到每一次對數據庫的修改是在何時(shí)以何種方式執行的，從而可以實(shí)現對任意條操作的回滾，當然
• mysql 的主從同步機制也是依賴(lài) binlog 來(lái)實(shí)現的，binlog 讓從數據庫可以精準還原主庫的每一個(gè)操作

1.2 bin log結構

binlog是可以追加寫(xiě)入的，追加寫(xiě)入指的是binlog文件寫(xiě)到一定大小后會(huì )切換到下一個(gè)文件，并不會(huì )覆蓋以前的文件

1.3 如何靠bin log恢復數據

bin log會(huì )記錄所有的邏輯操作，并且采用“追加寫(xiě)”的形式，如果你的DBA承諾說(shuō)半個(gè)月內可以恢復，那么備份系統中一定會(huì )保存最近半個(gè)月的所有bin-log，同時(shí)系統會(huì )定期做整庫備份
當需要恢復到指定的某一秒時(shí)，比如某天下午兩點(diǎn)發(fā)現中午12點(diǎn)有一次誤刪表，需要找回數據，那么可以這么做

• 首先，找到最近的一次去全量備份，如果你運氣好，可能就是昨天晚上的一個(gè)備份，從這個(gè)備份恢復到臨時(shí)庫
• 然后，從備份的時(shí)間點(diǎn)開(kāi)始，將備份的binlog一次取出來(lái)，重放到中午誤刪表之前的那個(gè)時(shí)刻

這樣你的臨時(shí)庫就和誤刪之前的線(xiàn)上庫一樣了，然后你可以把表數據從臨時(shí)庫中求出來(lái)，按需求恢復到線(xiàn)上庫中

2. 異常情況下的事務(wù)安全 - 重做日志redo log

mysql日志系統之redo log和bin log
mysql 異常情況下的事務(wù)安全 – 詳解 mysql redolog

2.1 更新操作是否應該直接操作磁盤(pán)數據？

對于每次更新來(lái)說(shuō)，最簡(jiǎn)單的方法就是每次都把操作記錄到磁盤(pán)，去磁盤(pán)找相應的數據，再進(jìn)行更新，但這樣頻繁的IO操作會(huì )導致性能的下降

2.2 WAL技術(shù)

數據庫如何用 WAL 保證事務(wù)一致性？
再同一事務(wù)中，當有記錄需要更新時(shí)，InnoDB引擎將修改結果更新到內存后，會(huì )在redo log添加一行記錄來(lái)記錄“需要在哪個(gè)數據頁(yè)上做什么修改”，并將該記錄的狀態(tài)置為prepare，等到commit提交事務(wù)后，會(huì )將此次事務(wù)中在redo log添加的記錄的狀態(tài)都置為commit狀態(tài)，同時(shí)，InnoDB引擎會(huì )在適當的時(shí)候，將redo log中狀態(tài)為commit的記錄的修改更新到磁盤(pán)里面，而這個(gè)更新往往是在系統比較空閑的時(shí)候做

這樣的操作叫做Write Ahead Logging，他的關(guān)鍵在于先寫(xiě)日志，再寫(xiě)磁盤(pán)

寫(xiě)日志也是在磁盤(pán)上的寫(xiě)操作，為什么比直接在磁盤(pán)持久化數據高效？
WAL是順序寫(xiě)入的，也就是一直在文件末尾append，而持久化數據庫的數據是一個(gè)隨機寫(xiě)入的操作，順序寫(xiě)會(huì )節省大量磁盤(pán)懸臂來(lái)回尋址的過(guò)程，效率更高

現在是否還需要WAL？
現在都用SSD而不在使用HARD，SSD沒(méi)有機械結構，無(wú)需尋道，那么上面所說(shuō)的優(yōu)點(diǎn)是否就不存在了？

2.3 redo-log的結構

InnoDB 的 redo log 是固定大小的，比如可以配置為一組 4 個(gè)文件，每個(gè)文件的大小是 1GB，那么這塊“粉板”總共就可以記錄 4GB 的操作。從頭開(kāi)始寫(xiě)，寫(xiě)到末尾就又回到開(kāi)頭循環(huán)寫(xiě)

• write pos 是當前記錄的位置，一邊寫(xiě)一邊后移，寫(xiě)到第 3 號文件末尾后就回到 0 號文件開(kāi)頭
• checkpoint 是當前要擦除的位置，也是往后推移并且循環(huán)的，擦除記錄前要把記錄更新到數據文件
• write pos 和 checkpoint 之間的是“粉板”上還空著(zhù)的部分，可以用來(lái)記錄新的操作。如果 write pos 追上 checkpoint，表示“粉板”滿(mǎn)了，這時(shí)候不能再執行新的更新，得停下來(lái)先擦掉一些記錄，把 checkpoint 推進(jìn)一下

2.4 crash-safe

有了 redo log，InnoDB 就可以保證即使數據庫發(fā)生異常重啟，之前提交的記錄都不會(huì )丟失，當數據庫發(fā)生宕機重啟后，可以通過(guò)redo log將未落盤(pán)的數據恢復，這個(gè)能力稱(chēng)為 crash-safe

2.5 redo log是如何保證crash safe的

每條 redolog 都有兩個(gè)狀態(tài) – prepare 與 commit 狀態(tài)

例如對于一張 mysql 表

（CREATE TABLE `A` (`ID` int(10) unsigned NOT NULL AUTO_INCREMENT, `C` int(10) NOT NULL DEFAULT 0, PRIMARY KEY (`ID`)) ENGINE=InnoDB）

我們執行一條 SQL 語(yǔ)句：

mysql> update T set c=c 1 where ID=2

1. 執行器先找引擎取 ID=2 這一行。ID 是主鍵，引擎直接用樹(shù)搜索找到這一行。如果 ID=2 這一行所在的數據頁(yè)本來(lái)就在內存中，就直接返回給執行器；否則，需要先從磁盤(pán)讀入內存，然后再返回。
2. 執行器拿到引擎給的行數據，把這個(gè)值加上 1，比如原來(lái)是 N，現在就是 N 1，得到新的一行數據，再調用引擎接口寫(xiě)入這行新數據。
3. 引擎將這行新數據更新到內存中，同時(shí)將這個(gè)更新操作記錄到 redo log 里面，此時(shí) redo log 處于 prepare 狀態(tài)。然后告知執行器執行完成了，隨時(shí)可以提交事務(wù)。
4. 執行器生成這個(gè)操作的 binlog，并把 binlog 寫(xiě)入磁盤(pán)。
5. 執行器調用引擎的提交事務(wù)接口，引擎把剛剛寫(xiě)入的 redo log 改成提交（commit）狀態(tài)，更新完成

可以看到，在寫(xiě)入 binlog 及事務(wù)提交前，innodb 先記錄了 redolog，并標記為 prepare 狀態(tài)，在事務(wù)提交后，innodb 會(huì )將 redolog 更新為 commit 狀態(tài)，這樣在異常發(fā)生時(shí)，就可以按照下面兩條策略來(lái)處理：

1. 當異常情況發(fā)生時(shí)，如果第一次寫(xiě)入 redolog 成功，寫(xiě)入 binlog 失敗，MySQL 會(huì )當做事務(wù)失敗直接回滾，保證了后續 redolog 和 binlog 的準確性
2. 如果第一次寫(xiě)入 redolog 成功，binlog 也寫(xiě)入成功，當第二次寫(xiě)入 redolog 時(shí)候失敗了，那數據恢復的過(guò)程中，MySQL 判斷 redolog 狀態(tài)為 prepare，且存在對應的 binlog 記錄，則會(huì )重放事務(wù)提交，數據庫中會(huì )進(jìn)行相應的修改操作