Group Commit of Binary Log

160222 09:19:26 mysqld_safe Starting mysqld daemon with databases from /data01/mysql
2016-02-22 09:19:32 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use –explicit_defaults_for_timestamp server option (see documentation for more details).
2016-02-22 09:19:34 1589 [Note] Plugin ‘FEDERATED’ is disabled.
2016-02-22 09:19:34 1589 [Note] InnoDB: Using atomics to ref count buffer pool pages
2016-02-22 09:19:34 1589 [Note] InnoDB: The InnoDB memory heap is disabled
2016-02-22 09:19:34 1589 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2016-02-22 09:19:34 1589 [Note] InnoDB: Memory barrier is not used
2016-02-22 09:19:34 1589 [Note] InnoDB: Compressed tables use zlib 1.2.3
2016-02-22 09:19:34 1589 [Note] InnoDB: Using CPU crc32 instructions
2016-02-22 09:19:34 1589 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2016-02-22 09:19:34 1589 [Note] InnoDB: Completed initialization of buffer pool
2016-02-22 09:19:35 1589 [Note] InnoDB: Highest supported file format is Barracuda.
2016-02-22 09:19:35 1589 [Note] InnoDB: The log sequence numbers 1625997 and 1625997 in ibdata files do not match the log sequence number 14714403811 in the ib_logfiles!
2016-02-22 09:19:35 1589 [Note] InnoDB: Database was not shutdown normally!
2016-02-22 09:19:35 1589 [Note] InnoDB: Starting crash recovery.
2016-02-22 09:19:35 1589 [Note] InnoDB: Reading tablespace information from the .ibd files…
2016-02-22 09:19:36 1589 [Note] InnoDB: Restoring possible half-written data pages
2016-02-22 09:19:36 1589 [Note] InnoDB: from the doublewrite buffer…
InnoDB: Last MySQL binlog file position 0 196060496, file name mysql-bin.000005
2016-02-22 09:19:38 1589 [Note] InnoDB: 128 rollback segment(s) are active.
2016-02-22 09:19:38 1589 [Note] InnoDB: Waiting for purge to start
2016-02-22 09:19:38 1589 [Note] InnoDB: 5.6.22 started; log sequence number 14714403811
^G/usr/local/mysql/bin/mysqld: File ‘/data01/mysqllog/binlog/mysql-bin.000005’ not found (Errcode: 2 - No such file or directory)
2016-02-22 09:19:39 1589 [ERROR] Failed to open log (file ‘/data01/mysqllog/binlog/mysql-bin.000005’, errno 2)
2016-02-22 09:19:39 1589 [ERROR] Could not open log file
2016-02-22 09:19:39 1589 [ERROR] Can’t init tc log
2016-02-22 09:19:39 1589 [ERROR] Aborting

其實他是先查看redo log，找出prepared但沒有commited或aborted的事務列表，而後檢查binlog，binlog沒記錄就commit，不然rollback

Group Commit of Binary Log

問題彙總:

當binlog 被啓用, 會有一個急劇的性能降低 因爲下面的緣由:

1.binary log 不利用 組提交技術

2.有幾個訪問磁盤 即 寫和flush

MySQL 使用預寫記錄來提供耐久性和一致性。

具體而言, 它們寫redo和不多的undo 更改到日誌

確保當提交事務的改變會被寫入和刷新到磁盤

但注意的是,每秒事務提交的數量越多 越高的速度寫和flush logs.

若是什麼都沒作 log會最終變成性能瓶頸。

繞過這個問題,一個延期的當 任何訪問存儲爲蒐集在內儘量多的提交

這樣一次寫和刷新對於一組事務

這個技術被命名爲group commit 是普遍用於數據庫系統 來改善性能

建議的解決方案(總結):

咱們要:

使用該組提交技術來減小寫入和flush

問題詳情:

看下面看到會發生什麼, 當你提交一個事務 和啓用binary log.

這個描述是基於Harrison分析當前實現的性能問題相關和使用InnoDB 做爲存儲引擎

由於惟一的真正的事務性引擎

1. Prepare Innodb:

a) 寫 prepare record 到InnoDB的log buffer
b) 同步log file 到磁盤

c) Take prepare_commit_mutex

1. 「Prepare」 binary log:

a) 寫事務到binary log
b) 同步binary log 基於sync_binlog

若是sync_binlog值大於0, MYSQL server 同步它的binary log 到磁盤(使用fdatasync()）

在每次sync_binlog 寫到binary log.若是自動提交啓用,會把每一個語句寫到binary log裏

默認值是0,不是同步寫到磁盤的 在這種狀況下, server 依賴操做系統來flush binary log的內存

值設爲1 是安全的選擇,因爲crash 你最多丟失一個語句或者事務。然而,那也是最慢的選擇

1. Commit Innodb:

a) 寫commit 記錄到log

b) 釋放 prepare_commit_mutex

c) 同步log file 到磁盤

d) 釋放InnoDB 鎖

1. 提交 binary log

這種模型有5個問題:

1. Prepare_commit_mutex 阻止binary log 和Innodb 進行group commit

prepare_commit_mutex 是用於確保事務是被提交到binary log 經過相同的順序 它們被提交到InnoDB logs.

這是 Innodb Hot Backup的須要 咱們沒有意圖改變

2.binary log 沒有準備group commiting

因爲這個互斥鎖一次只有一個事務執行步驟2 ,這樣binary log 不能group 一組事務

來下降寫和flush的數量。

此外, 這個代碼是不許備利用group 提交。

3.鎖是持有用於 fsync的週期

MySQL 使用鎖來實現它的一致性讀模式,顯然, 更高的鎖級別 會更低的併發級別

通常來講, 它是安全的釋放事務的鎖 當已經提交記錄到磁盤。

鎖被分爲兩個不一樣的組,共享和獨佔鎖。 共享鎖會在找出一個事務已經進行它的事務後釋放

並很願意到提交。

1. 沒必要要的磁盤訪問，好比 太多的fsync

事務被寫入磁盤3次,當binary log 被啓用。

這個能夠被改善做爲Binary log 是做爲來源和用於恢復

目前, 當恢復的時候,InnoDB 變異一個事務的列表 是prepared和不是提交也不是aborted

檢查binary log 來決定。若是一個事務是被寫入到binary log，它是提交的 不然它是回滾的

很顯然, 不須要寫和flush 提交的事務由於 最終會被其餘的事務寫入 在 prepare 階段

或者 Innodb的後臺進程 每秒寫和刷新 innnodb buffer logs.

做用：事務在內存中的緩衝。
分配原則：控制在2-8M.這個值不用太多的。他裏面的內存通常一秒鐘寫到磁盤一次。具體寫入方式和你的事務提交方式有關。在Ｏｒａｃｌｅ等數據庫瞭解這個，通常最大指定爲３Ｍ比較合適。

咱們推遲寫和flush 在提交階段, 爲了改善性能和週期性的寫和flushed 配置。

週期設置越大,會增長恢復的時間。

在功能上, 咱們應該改善這種狀況經過避免寫和flush 在prepare階段和

依賴binary log 來重現 丟失的事務。

5.

binary log 工做在存儲引擎和一個事務協調 讓它很難維護和發展。

binary log 註冊爲一個handler 和獲得回調 當preparing,
committing, and aborting.

這個容許它寫cached 數據到binary log 或者操做 事務裝態以另一種方式。

此外, binary log 表現爲一個事務協調器事實上是惟一的事務協調器。

事實上它註冊做爲一個handler 致使一些問題 在維護方面(和潛在的性能)

建議的解決方案（細節）

啓用binary log 來提升性能 能夠產分下面的任務:

1. 消除 prepare_commit_mutex, 或者須要它。

這與處理binary log 事務的順序 相比innodb logs的事務的順序

1. Flush the binary log properly.

prepareing和 提交一個事務到一個binary log 不會自動的 意味着 binary log 是被刷新了。

事實上,執行一個group 提交的整個點 是不須要 每次事務都flush binary log

代替的是改善性能經過下降每一個事務的flush次數

1. 處理讀鎖的釋放 以便進一步提升性能

更早的釋放鎖 是改善性能特別是對於有大量讀的應用

4.延遲寫和flush 在提交階段

這將改善性能經過減小寫和flush的數量 當binary log 啓用時

5.讓binary log 只是一個事務協調器: