mysql的"雙1設置"-數據安全的關鍵參數（案例分享）
mysql的"雙1驗證"指的是innodb_flush_log_at_trx_commit和sync_binlog兩個參數設置，這兩個是是控制MySQL 磁盤寫入策略以及數據安全性的關鍵參數。下面從參數含義，性能，安全角度闡述兩個參數為不同的值時對db 性能,數據的影響。
一、參數意義
innodb_flush_log_at_trx_commit
如果innodb_flush_log_at_trx_commit設置為0：log buffer將每秒一次地寫入log file中，並且log file的flush(刷到磁盤)操作同時進行.該模式下，在事務提交的時候，不會主動觸發寫入磁盤的操作;
如果innodb_flush_log_at_trx_commit設置為2：每次事務提交時MySQL都會把log buffer的數據寫入log file，但是flush(刷到磁盤)操作並不會同時進行。該模式下,MySQL會每秒執行一次 flush(刷到磁盤)操作。
註意：由於進程調度策略問題,這個"每秒執行一次 flush(刷到磁盤)操作"並不是保證100%的"每秒"。
sync_binlog
sync_binlog 的默認值是0，像操作系統刷其他文件的機制一樣，MySQL不會同步到磁盤中去而是依賴操作系統來刷新binary log。
註意：如果啟用了autocommit，那麽每一個語句statement就會有一次寫操作；否則每個事務對應一個寫操作。
二、性能
兩個參數在不同值時對db的純寫入的影響表現如下：
測試場景1
innodb_flush_log_at_trx_commit=2
sync_binlog=1000
測試場景2
innodb_flush_log_at_trx_commit=1
sync_binlog=1000
測試場景3
innodb_flush_log_at_trx_commit=1
測試場景4
innodb_flush_log_at_trx_commit=1
sync_binlog=1000
測試場景5
innodb_flush_log_at_trx_commit=2
sync_binlog=1000
在以上5個場景下的TPS分別為:
場景1 41000
場景2 33000
場景3 26000
場景4 33000
由此可見，當兩個參數設置為雙1的時候，寫入性能最差，sync_binlog=N (N>1 ) innodb_flush_log_at_trx_commit=2 時，(在當前模式下)MySQL的寫操作才能達到最高性能。
三、安全
當innodb_flush_log_at_trx_commit和sync_binlog 都為 1 時是最安全的，在mysqld 服務崩潰或者服務器主機crash的情況下，binary log 只有可能丟失最多一個語句或者一個事務。但是魚與熊掌不可兼得，雙11 會導致頻繁的io操作，因此該模式也是最慢的一種方式。
當innodb_flush_log_at_trx_commit設置為0，mysqld進程的崩潰會導致上一秒鐘所有事務數據的丟失。
當innodb_flush_log_at_trx_commit設置為2，只有在操作系統崩潰或者系統掉電的情況下，上一秒鐘所有事務數據才可能丟失。
"雙1設置"適合數據安全性要求非常高，而且磁盤IO寫能力足夠支持業務，比如訂單,交易,充值,支付消費系統。雙1模式下，當磁盤IO無法滿足業務需求時 比如11.11 活動的壓力。推薦的做法是 innodb_flush_log_at_trx_commit=2 ，sync_binlog=N (N為500 或1000) 且使用帶蓄電池後備電源的緩存cache，防止系統斷電異常。
四、小結
系統性能和數據安全是業務系統高可用穩定的必要因素。我們在對系統的優化需要尋找一個平衡點，合適的才是最好的，根據不同的業務場景需求，可以將兩個參數做組合調整，以便是db系統的性能達到最優化。
案例分享1：一條insert語句的執行，耗時40ms原因剖析
背景：一個簡單的帶有主鍵的insert語句，執行起來居然要耗時40ms ，實在是難以忍受！排查分析過程如下：
因此需要關註的是數據從插入落地的IO中間都幹了什麽？
一、MySQL的文件
首先簡單介紹一下MySQL的數據文件，MySQL 數據庫包含如下幾種文件類型：
1）數據文件 (datafile)
存放表中的具體數據的文件。
2）數據字典
記錄數據庫中所有innodb表的信息。
3）重做日誌 (redolog)
記錄數據庫變更記錄的文件，用於系統異常crash(掉電)後的恢復操作，可以配置多個(配置這個參數inodb_log_files_in_group)比如 ib_logfile0、 ib_logfile1。
4）回滾日誌 (undolog)
也存在於mysql 的ibdata文件，用戶記錄事務的回滾操作。註在mysql5.6以上版本可以拆開出來，單獨文件夾存在。
5）歸檔日誌 (binlog)
事務提交之後，記錄到歸檔日誌中。
6）中繼日誌 (relaylog)
從master獲取到slave的中轉日誌文件，sql_thread則會應用relay log並重放於從機器。
7）其他日誌slowlolg, errorlog, querylog
這裏慢日誌也經常用。可以結合pt-query-digest工具和anemometer一起展示出來。
對於以上文件的IO訪問順序可以分為順序訪問 比如binlog ，redolog ，relay log是順序讀寫，datafile，ibdata file是隨機讀寫，這些IO訪問的特點決定了在os 配置磁盤信息時候，如何考慮分區 ，比如順序寫可以的log可以放到SAS盤 ，隨機讀寫的數據文件可以放到ssd或者fio高性能的存儲。
二、寫操作
為了保證數據寫入操作的安全性，數據庫系統設置了 undo，redo 保護機制，避免因為os或者數據庫系統異常導致的數據丟失或者不一致的異常情況發生。
1）先寫undo log。
2）在內存更新數據，這步操作就在內存中形成了臟頁，如果臟頁過多，checkpoint機制進行刷新，innodb_max_dirty_pages_pct決定了刷新臟頁比例。innodb_io_capacity參數可以動態調整刷新臟頁的數量，innodb_lru_scan_depth這個參數決定了刷新每個innodb_buffer_pool的臟頁數量。
3）記錄變更到redo log，prepare這裏會寫事務id。innodb_flush_log_at_trx_commit決定了事務的刷盤方式。為0時，log buffer將每秒一次地寫入log file中，並且log file的flush(刷到磁盤)操作同時進行。該模式下，在事務提交的時候，不會主動觸發寫入磁盤的操作。為1，每次事務提交時MySQL都會把log buffer的數據寫入log file，並且flush(刷到磁盤)中去.為2，每次事務提交時MySQL都會把log buffer的數據寫入log file.但是flush(刷到磁盤)操作並不會同時進行。該模式下，MySQL會每秒執行一次 flush(刷到磁盤)操作。
4）寫入binlog這裏會寫入一個事務id這裏有個sync_binlog參數決定多個事務進行一次性提交。
5）redo log第二階段，這裏會進行判斷前2步是否成功，成功則默認commit，否則rollback。刷入磁盤操作。這裏是先從臟頁數據刷入到內存2M大小的doublewrite buffer，然後是一次性從內存的doublewrite buffer刷新到共享表空間的doublewrite buffer，這裏產生了一次IO。然後從內存的內存的doublewrite buffer刷新2m數據到磁盤的ibd文件中，這裏需要發生128次io。然後校驗，如果不一致，就由共享表空間的副本進行修復。這裏有個參數innodb_flush_method決定了數據刷新直接刷新到磁盤，繞過os cache。
6）返回給client。
如果有slave，第4步之後經過slave服務線程io_thread寫到從庫的relay log ，再由sql thread應用relay log到從庫中。
三、關於性能
寫undo redo log ，binlog的過程中都是順序寫，都會很快的完成，隨機寫操作，inset_buffer功能。
對於非聚集類索引的插入和更新操作(5.5 版本及以上支持Update/Delete/Purge等操作的buffer功能)，不是每一次都直接插入到索引頁中，而是先插入到內存中。具體做法是：如果該索引頁在緩沖池中，直接插入；否則，先將其放入插入緩沖區中，再以一定的頻率和索引頁合並，就可以將同一個索引頁中的多個插入合並到一個IO操作中，改隨機寫為順序寫，大大提高寫性能。
關於數據安全，這是數據庫寫入的重點？
1，2，3過程失敗就是事務失敗，因為此時還未寫入磁盤，對磁盤中的數據無影響，返回事務失敗給client，從庫也不會受到影響。 4，5過程失敗的時候或者已經將寫成功返回給客戶，可以根據redo log的記錄來進行恢復，如果出現部分寫失效請參考《double write》。
MySQL的寫redo log的第一個階段會把所有需要做的操作做完，記錄數據變更，第二階段的工作比較簡單 ，只做事務提交確認。如果寫入binlog成功，而第二階段失敗，MySQL啟動時也會將事務進行重做，最終更新到磁盤中。MySQL 5.5+的smei sync可以更好的保障主從的事務一致性。
四、文件訪問方式
IO 訪問的方式分為兩種順序讀寫和隨機讀寫， 在MySQL的io過程中可以以此來將數據庫文件分類。
順序讀寫：重做日誌ib_logfile*，binlog file。
隨機讀寫：innodb表數據文件，ibdata文件。
根據系統的訪問類型，對硬件做如下分類：讀多（SSD+RAID）、寫多FIO(flashcache)、容量密集（fio + flashcache）。
由於隨機io會嚴重降低系統的性能，在當前的硬件水平下，可以考慮選擇獎數據庫服務器配置ssd/fusionio。
五、影響IO的參數和策略
影響mysql io的參數有很多個，這裏羅列幾個重要的參數。
innodb_buffer_pool_size
該參數控制innodb緩存大小，用於緩存應用訪問的數據，推薦配置為系統可用內存的80%。
binlog_cache_size
該參數控制二進制日誌緩沖大小，當事務還沒有提交時，事務日誌存放於cache，當遇到大事務cache不夠用的時，mysql會把uncommitted的部分寫入臨時文件,等到committed的時候才會寫入正式的持久化日誌文件。
innodb_max_dirty_pages_pct
該參數可以直接控制Dirty Page在BP中所占的比率，當dirty page達到了該參數的閾值，就會觸發MySQL系統刷新數據到磁盤。
innodb_flush_log_at_trx_commit
該參數確定日誌文件何時write、flush。
為0，log buffer將每秒一次地寫入log file中，並且log file的flush(刷到磁盤)操作同時進行.該模式下，在事務提交的時候，不會主動觸發寫入磁盤的操作。
為1，每次事務提交時MySQL都會把log buffer的數據寫入log file，並且flush(刷到磁盤)中去.
為2，每次事務提交時MySQL都會把log buffer的數據寫入log file.但是flush(刷到磁盤)操作並不會同時進行。該模式下,MySQL會每秒執行一次 flush(刷到磁盤)操作。
註意：由於進程調度策略問題，這個“每秒執行一次flush(刷到磁盤)操作”並不是保證100%的“每秒”。
sync_binlog
sync_binlog的默認值是0，像操作系統刷其他文件的機制一樣，MySQL不會同步到磁盤中去而是依賴操作系統來刷新binary log。
當sync_binlog =N (N>0) ，MySQL 在每寫 N次 二進制日誌binary log時，會使用fdatasync()函數將它的寫二進制日誌binary log同步到磁盤中去。
innodb_flush_method
該參數控制日誌或數據文件如何write、flush。可選的值為fsync，o_dsync，o_direct，littlesync，nosync。
數據庫的I/O是一個很復雜和細致的知識層面，涉及數據庫層和OS層面的IO寫入策略，也和硬件的配置有關。
案例分享2: 同一條sql語句，有時插入塊，有時插入慢原因剖析
背景：同一條sql ，有時插入時間幾毫秒，有時插入時間卻是幾十毫秒！為什麽呢？ 分析過程如下：
Sql角度：簡單insert
表角度: 一個主鍵
系統參數角度：
開啟了雙1 策略。
也就意味著每次事物就會有刷新磁盤
關閉雙1 ，設置為 0 100 ，或者 2 100 ，會極大提升性能。這是因為不刷硬盤了，但不能解決為什麽時快時慢問題。
操作系統角度
使用"iostat -xmd 1"命令看磁盤使用情況
以上看出磁盤明顯不夠快，讀寫0.15M就使用了7%
上面可以看出，來個順序文件拷貝操作，30M使用就使用了100%，離散讀寫更慢了！
使用"sar -B 1"命令可以查看頁面交換
pgpgin/s: 表示每秒從磁盤或SWAP置換到內存的字節數(KB)
pgpgout/s: 表示每秒從內存置換到磁盤或SWAP的字節數(KB)
fault/s: 每秒鐘系統產生的缺頁數,即主缺頁與次缺頁之和(major + minor)
majflt/s: 每秒鐘產生的主缺頁數.
pgfree/s: 每秒被放入空閑隊列中的頁個數
pgscank/s: 每秒被kswapd掃描的頁個數
pgscand/s: 每秒直接被掃描的頁個數
pgsteal/s: 每秒鐘從cache中被清除來滿足內存需要的頁個數
%vmeff: 每秒清除的頁(pgsteal)占總掃描頁(pgscank+pgscand)的百分比
以上表示內存和swap進行了頻繁的數據交換！
那個進程在使用swap呢？
下面截圖中命令是for i in $(ls /proc | grep "^[0-9]" | awk ‘$0>100‘); do awk ‘/Swap:/{a=a+$2}END{print ‘"$i"‘,a/1024"M"}‘ /proc/$i/smaps;done| sort -k2nr | head
在經過幾個小時後 ，mysql 使用swap由88M變成了104M ，這說明一直在使用和增加的。
問題基本定位
1）首先是磁盤性能不高，順序寫才30M ,離散寫會降低10倍
2）其次是mysql又使用了swap 空間，這就使得性能更差
3） Mysql 開啟了雙1 驗證，就會等待數據刷磁盤，
磁盤使用頻率不穩定，導致了mysql的插入時間會時快時慢
如何解決？
1）減少mysql使用swap方式。即把swapness設置為1。
即執行"sysctl vm.swappiness=1",並且在/etc/sysctl.conf文件中也要設置為1；
2）降低內存，比如設置innodb_buffer_pool_size =4G，原來設置的是6G ,這樣可以節約一部分內存空間；
3）開啟innodb_numa_interleave = ON 來操作numa；
4）更換SSD 或者不用開啟雙1，改成 2 100
只調整操作系統參數，不更換硬件，依然開啟雙一，重啟mysql之後呢？
可以看到mysql已經不再使用swap空間了。但是因為雙一參數的使用，每次事物都會刷磁盤，而這個機械磁盤的性能在隨機讀寫的情況下不穩定。會依然存在時快時慢的問題。
mysql的"雙1設置"-數據安全的關鍵參數（案例分享）