資料的一致性和程式設計客棧完整性對於**業www.cppcns.com務的重要性不言而喻，如何保證資料不丟呢？今天我們就**下關於資料的完整性和強一致性，mysql做了哪些改進。
一. mysql的二階段提交
在oracle和mysql這種關係型資料庫中，講究日誌先行策略（write-ahead logging）,只要日誌持久化到磁碟，就能保證mysql異常重啟後，資料不丟失。在mysql中，提到日誌不得不提的就是redo log和binlog。
1. redo log
redo log又稱重做日誌檔案，詳細的記錄了對每乙個資料頁裡面的資料行的修改，記錄的是資料修改之後的值。redo log是用來做資料庫crash recovery的，是保證資料安全的非常重要的功能之一。
redo log的寫入的方式是順序寫、迴圈寫，通過innodb_log_file_size和innodb_log_files_in_group兩個引數控制redo log的檔案大小和個數。redo log在寫入磁碟前會先寫redo log buffer中，大小由innodb_log_buffer_size控制。日誌在寫入redo log buffer後是如何持久化到磁碟的呢？為了控制redo log的寫入策略，innodb根據innodb_flush_log_at_trx_commit引數不同的取值採用不同的策略，它有三種不同的取值：
三種模式下，0的效能最好，但是不安全，mysql程序一旦崩潰會導致丟失一秒的資料。1的安全性最高，但是對效能影響最大，2的話主要由作業系統自行控制刷磁碟的時間，如果僅僅是mysql宕機，對資料不會產生影響，如果是主機異常宕機了，同樣會丟失資料。
2. binlog
binlog又稱二進位制日誌，記錄了對mysql資料庫執行更改的所有操作，不包含select和show操作，主要起到了恢復、複製、審計等功能。binlog的格式主要有statement、row、mixed三種。
statement：基於操作的sql語句記錄到binlog中，不建議使用。
row：基於行的變更情況記錄，會記錄行更改前後的內容，row模式也是資料庫不丟資料的重要保證，推薦使用。
mixed：混合前兩個模式，不建議使用。
binlog的寫入邏輯也比較簡單：事務執行過程中，先寫入binlog cache,事務提交時再寫入binlog檔案。binlog cache由binlog_cache_size和max_binlog_size引數控制，每個執行緒分配乙個binlog cache,但是共用binlog檔案。
binlog的寫入日誌檔案的機制由sync_binlog控制：
innodb_flush_log_at_trx_commit和sync_binlog都設定為1是mysql資料中經典的雙一模式，是資料庫不丟資料的保障。
mysql資料採取wal機制就是為了減少每次髒資料刷盤帶來的效能影響，如果設定」雙一」策略會不會影響資料庫的效能呢？其實這主要得益於redo log和binlog都是順序寫，磁碟的順序寫比隨機寫的速度要快的多，加上mysql內部的組提交機制，已經大幅降低了對磁碟的iops消耗了。
3. 兩階段提交
mysql引入二階段提交（two phase commit or 2pc），mysql內部會將普通事務當做乙個xa事務（內部分布式事務）來處理,會自動為每個事務分配乙個唯一的id（xid），commit會被動的分成prepare和commit兩個階段。
第一階段：transaction prepare phase
此時sql已經成功執行，並生成xid資訊及redo和undo的記憶體日誌。然後呼叫prepare方法完成第一階段，將事務狀態設為trx_prepared，並將redo log刷盤。
第二階段：commit phase
如果事務第一階段進入prepare階段，則將產生的binlog寫入檔案並刷盤，此時事務已經鐵定要提交了。
具體異常場景分析：
1. 當事務在prepare階段crash，資料庫recovery的時候該事務未寫⼊binary log並且儲存引擎未提交，則該事務rollback。
2. 當事務在binlog階段crash，此時⽇志還沒有成功寫⼊到磁碟中，啟動時會rollback此事務。3. 當事務在binlog⽇志已經fsync()到磁碟後crash，但是innodb沒有來得及commit，此時mysql資料庫recovery的時候將會讀出⼆進製⽇志的xid_log_event，然後告訴innodb程式設計客棧提交這些xid的事務，innodb提交完這些事務後會回滾其它的事務，使儲存引擎和⼆進製⽇志始終保持⼀致。
mysql的二階段提交就保證了資料庫在異常宕機重啟後的資料不丟失。
二. double write
前面我們說了，redo log、binlog以及二階段提交保證了資料在mysql異常重啟後能夠通過前滾和回滾恢復資料。mysql在recovery時通過redo log進行恢復，redo log記錄的是頁上的物理操作，但是這裡有個問題，如果頁本身就是錯的，比如發生頁的部分寫ocdeerdisp問題(頁大小是 16k，假設在把記憶體中的髒頁寫到資料庫的時候，寫了4k 突然掉電。也就是前兩 4k 是新的，後 12k 是舊的，那麼這個資料頁就是不完整的，是乙個壞掉的資料頁), 這時redo恢復的時候會去校驗資料頁的完整性，此時資料頁已經損壞了，故無法使用 redo log 進行恢復，這個資料就丟失了。
double write原理:
1、當重新整理緩衝池髒頁時，並不直接寫到資料檔案中，而是先拷貝至double write buffer。
2、然後從double write buffer分兩次寫入磁碟共享表空間中，每次寫入 1mb。
3、最後再從double write buffer寫入資料檔案。雖然資料總是寫入兩次，但是由於double write 寫入的時候是順序寫，實際上也就犧牲了系統效能的 10%左右。
這樣就可以解決上文提到的部分寫失效的問題，因為在磁碟共享表空間中已有資料頁副本拷貝，如果資料庫在頁寫入資料檔案的過程中宕機，在例項恢復時，可以從共享表空間中找到該頁副本，將其拷貝覆蓋原有的資料頁，再應用重做日誌即可。
3. 小結
今天我們聊了mysql的二階段提交和double write機制，分別解決了在mysql宕機重啟以及發生頁的部分寫的場景下，mysql是如何做到不丟失資料。那如果我們的作業系統宕機無法啟動了，又該怎麼辦呢？mysql在集群架構中又做了哪些優化來保證資料不丟失呢？我們下一章再來和大家分享mysql在集群架構中的優化改進。
本文標題: mysql是如何保證資料的完整性
本文位址: /shujuku/mysql/333713.html
HDFS如何保證資料的完整性
總的來說，hdfs 會對寫入的資料計算校驗和，並在讀取資料時驗證校驗和。具體來說，datanode 負責收到資料後儲存該資料及其校驗和。datanode 的資料 可分為兩種 其一為是從客戶端收到的資料，其二為從其他 datanode 複製來的資料。還有一種情況，客戶端將資料及其校驗和傳送到由一系列 ...
保證資料的完整性
資料完整性 可靠性 準確性。保證資料的完整性可以從下面幾個方面進行完善 1 實體完整性 2 域完整性 3 引用完整性 4 使用者自定義完整性 實體完整性 保證行資料是有效的 主鍵約束，唯一約束 保證列資料是有效的 非空約束，預設約束，外來鍵約束等 主鍵約束 primary key 運用主鍵是要注意的...
保證資料完整性
1.資料的完整性 資料的完整性分為四類 實體完整性，域完整性，引用完整性，自定義完整性。2.資料完整性的實現 建立非空約束的語法 create table friend name varchar 50 not null 設定主鍵約束 主鍵約束是應用於表的列的乙個約束。設定唯一約束 指給定列的所有的值...