最近有幸前去美國參加Percona Live 2016會議并分享了我們最近在MySQL復制上所做的工作,也就是基于InnoDB的物理復制。會后很多小伙伴私信我說[分享的PPT](https://www.percona.com/live/data-performance-conference-2016/sessions/physical-replication-based-innodb)太內核了,不太容易理解。因此本文主要針對分享的內容進行展開描述,希望能對大家有所幫助。
## 背景知識
在開始之前,你需要對InnoDB的事務系統有個基本的認識。如果您不了解,可以參考我之前的幾篇關于InnoDB的文章,包括InnoDB的[事務子系統](http://mysql.taobao.org/monthly/2015/12/01/),[事務鎖](http://mysql.taobao.org/monthly/2016/01/01/),[redo log](http://mysql.taobao.org/monthly/2015/05/01/),[undo log](http://mysql.taobao.org/monthly/2015/04/01/),以及[崩潰恢復邏輯](http://mysql.taobao.org/monthly/2015/06/01/)。在這里我們簡單的概述一下幾個基本的概念:
事務ID:一個自增的序列號,每次開啟一個讀寫事務(或者事務從只讀轉換成讀寫模式)時分配并遞增,每更新256次后持久化到Ibdata的事務系統頁中。每個讀寫事務都必須保證擁有的ID是唯一的。
Read View: 用于一致性讀的snapshot,InnoDB里稱為視圖;在需要一致性讀時開啟一個視圖,記錄當時的事務狀態快照,包括當時活躍的事務ID以及事務ID的上下水位值,以此用于判斷數據的可見性。
Redo Log:用于記錄對物理文件的修改,所有對InnoDB物理文件的修改都需要通過Redo保護起來,這樣才能從崩潰中恢復。
Mini Transaction(mtr):是InnoDB中修改物理塊的最小原子操作單位,同時也負責生產本地的redo日志,并在提交mtr時將redo日志拷貝到全局log buffer中。
LSN: 一個一直在遞增的日志序列號,在InnoDB中代表了從實例安裝到當前已經產生的日志總量。可以通過LSN計算出其在日志文件中的位置。每個block在寫盤時,其最近一次修改的LSN也會記入其中,這樣在崩潰恢復時,無需Apply該LSN之前的日志。
Undo Log: 用于存儲記錄被修改之前的舊版本,如果被多次修改,則會產生一個版本鏈。保留舊版本的目的是用于可重復讀。通過結合Undo和視圖控制來實現InnoDB的MVCC。
Binary Log: 構建在存儲引擎之上的統一的日志格式;有兩種存儲方式,一種是記錄執行的SQL,另外一種是記錄修改的行記錄。Binlog本質上是一種邏輯日志,因此能夠適用所有的存儲引擎,并進行數據復制。
## 原生復制的優缺點
MySQL的每條讀寫事務都需要維持兩份日志,一份是redo log,一份是binary log。MySQL使用兩階段提交協議,只有當redo 和binlog都寫入磁盤時,事務才算真正的持久化了。如果只寫入redo,未寫入binlog,這樣的事務在崩潰恢復時需要回滾掉。MySQL通過XID來關聯InnoDB的事務和binlog。
MySQL的原生事務日志復制有一些顯著的優點:
首先,相比InnoDB的redo log而言,Binary Log更加可讀,有成熟的配套工具來進行解析;由于記錄了行級別的更改。我們可以通過解析binlog,轉換成DML語句來將數據變更同步到異構數據庫。另外一種典型的做法是使用Binlog來失效構建在前端的cache。事實上,基于Binlog的數據流服務在阿里內部使用的非常廣泛,也是最重要的基礎設施之一。
其次由于Binary log是一種統一的日志格式,你可以在主備上使用不同的存儲引擎,例如當你需要測試某種新的存儲引擎時,你可以搭建一個備庫,將所有表alter到新引擎,然后開啟數據復制進行觀察。
此外基于Binary Log你還可以構建起非常復雜的復制拓撲結構,尤其是在引入了GTID之后,這種優勢尤為明顯: 如果設計妥當,你可以實現相當復雜的復制結構。甚至可以做到多點寫入。總體使用起來非常靈活。
然而,也正是這種日志架構可能會帶來一些問題:首先MySQL需要記錄兩份日志:redo及binlog,只有當兩份日志都fsync到磁盤,我們才能認為事務是持久化的,而眾所周知,fsync是一種開銷非常昂貴的操作。更多的日志寫入還增加了磁盤IO壓力。這兩點都會影響到響應時間和吞吐量。
Binlog復制還會帶來復制延遲的問題。我們知道只有主庫事務提交后,日志才會寫入到binlog文件并傳遞到備庫,這意味著備庫至少延遲一個事務的執行時間。另外有些操作例如DDL,大事務等等,由于在備庫需要繼續保持事務完整性,這些執行時間很長的操作會長時間占用某個worker線程,而協調線程會碰到復制同步點,導致后續的任務無法分發到其他空閑的worker線程。
MySQL是原生復制是MySQL生態的一個非常重要的組成部分。官方也在積極的改進其特性,例如MySQL5.7在這一塊就有非常顯著的改進。
## Why Phsyical Replication
既然原生復制這么成熟,優點這么多,為什么我們還要考慮基于物理日志的復制呢?
首先最重要的原因就是性能!當我們事先了物理復制后,就可以關閉binlog和gtid,大大減少了數據寫盤量。這種情況下,最多只需要一次fsync既可以將事務持久化到磁盤。實例整體的吞吐量和響應時間都得到了非常大的提升。
另外,通過物理復制,我們能獲得更加理想的物理復制性能。事務在執行過程中產生的redo log只要寫到文件中,就會被傳送到備庫。這意味著我們可以同時在主備庫上執行事務,而無需等待主庫上執行完成。我們可以基于(space_id, page_no)來進行并發apply,同一個page上的變更也可以做到合并寫操作,相比傳統復制,具有更好的并發性。最重要的是,基于物理變更的復制,可以最大程度保證主備的數據總是一致的。
當然物理復制不是銀彈,當啟用該特性后,我們將只能支持InnoDB存儲引擎;我們也很難去設計多點寫復制拓撲。物理復制無法取代原生復制,而是應對特定的場景,例如需求高并發DML性能的場景。
因此在正式開始前,我們設置了這些前提:1.主庫上不應該有任何限制; 2.備庫上只允許執行查詢操作,不允許通過用戶接口對數據產生任何的變更。
下文默認MySQL已包含如下特性:
* 沒有只讀事務鏈表,并且不為只讀事務分配事務ID
* 使用全局事務ID數組來構建read view快照
* 所有MySQL庫下的系統表都使用InnoDB存儲引擎
## High Level Architecture
### 復制架構
這里復制的基礎架構和原生復制類似,但代碼是完全獨立的。如下圖所示:

首先,我們在備庫上配置好連接后,執行START INNODB SLAVE,備庫上會開啟一個io線程,同時InnoDB層啟動一個Log Apply協調線程以及多個worker線程。
IO線程建立和主庫的連接,并發送一個dump請求,請求的內容包括:
master_uuid: 最近備庫上日志最初產生所在的實例的server_uuid
start_lsn: 開始復制的點
在主庫上,一個log_dump線程被創建,先檢查dump請求是否是合法的,如果合法,就去從本地的ib_logfile中讀取日志,并發送到備庫。
備庫IO線程在接受到日志后,將其拷貝到InnoDB的Log Buffer中,然后調用log_write_up_to將其寫入到本地的ib_logfile文件中。
Log Apply協調線程被喚醒,從文件中讀取日志進行解析,并根據fold(space id ,page no)% (n_workers + 1)進行分發,系統表空間的變更存放到sys hash中,用戶表空間的變更存儲到user hash中。協調線程在解析&&分發完畢后,也會參與到日志apply中。
當Apply日志時,我們總是先應用系統表空間,再是用戶表空間。原因是我們需要保證undo日志先應用,否則外部查詢檢索用戶表的btree,試圖通過回滾段指針查詢undo page,可能對應的Undo還沒構成。
### 日志文件管理
要實現上述架構,第一個要解決的問題是需要重新整理InnoDB的日志文件。 因為原生邏輯中,InnoDB采用循環寫文件的方式,例如當我們設置innodb_log_files_in_group為4時,會創建4個ib logfile文件。當第四個文件寫滿時,會回到第一個文件循環寫入。但是在物理復制架構下,我們需要保留老的日志文件,這些文件既可以防止例如網絡出現問題,日志未曾及時傳送到備庫,也可以用于備份目的。
我們像binlog那樣,當當前日志文件寫滿時,則切換到下一個日志文件,文件的序號總是向前遞增的。然而這里需要解決的一個問題是:切換文件需要盡量減小對性能的影響,我們引入了獨立的后臺線程,并允許已被清理的日志文件重用。
和binlog類似,我們也需要清理已經沒用的日志文件,既需要提供接口,由用戶手動清理,也可以開啟后臺線程自動判斷并進行清理,但兩種方案都需要滿足條件:
1\. 不允許超過當前checkpoint所在的文件
2\. 如果有正在連接的備庫,則不允許清理尚未傳送到備庫的日志
文件架構如下圖所示:

這里我們增加了一個新的文件ib_checkpoint,原因是原生邏輯中,checkpoint信息是存儲在ib_logfile0中的,而在新的架構下,該文件可能被刪除掉,我們需要單獨對checkpoint信息進行存儲,包含checkpoint no, checkpoint lsn, 以及該Lsn所在的日志文件號及文件內偏移量。
后臺清理線程被稱為log purge thread,當該線程被喚醒被執行清理操作時,將目標日志文件rename到以purged作為前綴,并放到一個回收池中,如果池子滿了,則直接刪除掉。
為了避免日志切換到新文件時造成的性能抖動,后臺log file allocate線程總是預先將下一個文件準備好,也就是說,當前正在寫第N個文件,后臺線程會被喚醒,并創建好第N+1個文件。這樣對前臺線程的影響僅僅是關閉并打開新文件句柄。
log file allocate線程在準備下一個文件時,先嘗試從回收池中獲取文件,并進行必要的判斷(確保下一個文件開始的LSN轉換成block no后不和文件內的內容重疊),如果可以使用,則直接取出來并rename為下一個文件名。如果回收池無可用文件,則創建文件,并extend到指定的大小。通過這種方式,我們盡量保證了性能的平緩。
### 實例角色
和原生復制不同,對于備庫,我們總是不允許做任何的數據變更,這種行為不受是否重啟,是否崩潰而影響,只受failover影響。一臺備庫無論重啟多少次總是為備庫。
日志最初產生的服務器我們稱為日志源實例。日志可能通過復雜的復制拓撲傳遞到多級級聯實例上。但所有的這些備庫都應具有相同的源實例信息。我們需要通過這個信息來判斷一個dump請求是否是合法的,例如作為備庫,所有dump的日志都應產自同一個日志源實例,除非在復制拓撲中發生了failover。
我們為實例定義了三種狀態:master, slave,以及upgradable-slave;其中第三種是一種中間狀態,只在failover時產生。
這些狀態信息被持久化到本地文件innodb_repl.info文件中。同時也單獨存儲了日志源實例的server_uuid。
我們以下圖為例:

server 1的uuid為1,和文件中記錄的uuid相同,因此認為該實例為master;
server 2的uuid為2,和文件中記錄的uuid不同,因為該實例為slave;
server 3的uuid為3,但文件中記錄的值為0,表明最近剛發生過一次failover(server 1 和server 2發生過一次切換),但還沒來得及獲取到切換日志,因此該實例角色為upgradable-slave
innodb_repl.info文件維持了所有的復制和failover狀態信息,很顯然,如果我們想從已有的拓撲中restore出一個新的實例,對應的innodb_repl.info文件也要拷貝出來。
### 后臺線程
有些后臺線程可能對數據產生變更,因此在備庫上我們需要禁止這些線程:
1\. 不允許開啟Purge線程
2\. master線程不允許去做ibuf merge之類的工作,只負責定期做lazy checkpoint
3\. dict_stats線程只負責更新表的內存統計信息,不可以觸發統計信息的物理存儲。
此外備庫的page cleaner線程的刷臟算法也需要重新調整以盡量平緩,不要影響到日志apply。
## MySQL Server層數據復制
### 文件操作復制
為了實現Server-Engine的架構,MySQL在Server層另外冗余了一些元數據信息,以在存儲引擎之上建立統一的標準。這些元數據文件包括FRM,PAR,DB.OPT,TRG,TRN以及代表數據庫的目錄。對這些文件和目錄的操作都沒有寫到redo中。
為了能夠實現文件層的操作,我們需要將文件變更操作寫到日志中,主要擴展了三種新的日志類型:
~~~
MLOG_METAFILE_CREATE: [FIL_NAME | CONTENT]
MLOG_METAFILE_RENAME: [ORIGINAL_NAME | TARGET_NAME]
MLOG_METAFILE_DELETE: [FIL_NAME]
~~~
這里包含了三種操作,文件的創建,重命名及刪除。注意這里沒有修改文件操作,原因是Server層總是通過創建新文件,刪除舊文件的方式來進行元數據更新。
### DDL復制
當MySQL在執行DDL修改元數據時,是不允許訪問表空間的,否則可能導致各種異常錯誤。MySQL使用排他的MDL鎖來阻塞用戶訪問。我們需要在備庫保持相同的行為。這就需要識別修改元數據的起點和結束點。我們引入兩類日志來進行標識。
| Name | Write On Master | Apply On Slave |
| --- | --- | --- |
| MLOG_METACHANGE_BEGIN | 在獲取MDL鎖,修改元數據之前寫入 | 獲取表上的顯式排他MDL鎖,同時失效該表的所有table cache對象 |
| MLOG_METACHANGE_END | 在釋放MDL鎖之前寫入 | 釋放表上的MDL鎖 |
舉個簡單的例子:
~~~
執行: CREATE TABLE t1 (a INT PRIMARY KEY, b INT);
從Server層產生的日志包括:
* MLOG_METACHANGE_START
* MLOG_METAFILE_CREATE (test/t1.frm)
* MLOG_METACHANGE_END
執行: ALTER TABLE t1 ADD KEY (b);
從Server層產生的日志包括:
* Prepare Phase
MLOG_METACHANGE_START
MLOG_METAFILE_CREATE (test/#sql-3c36_1.frm)
MLOG_METACHANGE_END
* In-place build…slow part of DDL
* Commit Phase
MLOG_METACHANGE_START
MLOG_METAFILE_RENAME(./test/#sql-3c36_1.frm to ./test/t1.frm)
MLOG_METACHANGE_END
~~~
然而元數據修改開始點和結束點所代表的兩個日志并不是原子的,這意味著主庫上在修改元數據的過程中如果crash了,就會丟失后面的結束標記。備庫可能一直持有這個表上的MDL鎖無法釋放。為了解決這個問題,我們在主庫每次崩潰恢復后,都寫一條特殊的日志,通知所有連接的備庫釋放其持有的所有MDL排他鎖。
另外一個問題存在于備庫,舉個例子,執行MLOG_METACHANGE_START后,做一次checkpoint,在接受到MLOG_METACHANGE_END之前crash。當備庫實例從崩潰中恢復時,需要能夠繼續保持MDL鎖,避免用戶訪問。
為了能夠恢復MDL,首先我們需要控制checkpoint的LSN,保證不超過所有未完成元數據變更的最老的開始點;其次,在重啟時搜集未完成元數據變更的表名,并在崩潰恢復完成后依次把MDL 排他鎖加上。
### Cache失效
在Server層還維護了一些Cache結構,然而數據的更新是體現在物理層的,備庫在應用完redo后,需要感知到哪些Cache是需要進行更新的,目前來看主要有以下幾種情況:
1\. 權限操作,備庫上需要進行ACL Reload,才能讓新的權限生效;
2\. 存儲過程操作,例如增刪存儲過程,在備庫需要遞增一個版本號,以告訴用戶線程重新載入cache;
3\. 表級統計信息,主庫上通過更新的行的數量來觸發表統計信息更新;但在備庫上,所有的變更都是基于塊級別的,并不能感知到變化了多少行。因此每次主庫更新統計信息時同時寫一條日志到redo中,通知備庫進行內存統計信息更新。
## 備庫MVCC
### 視圖控制
備庫一致性讀的最基本要求是用戶線程不應該看到主庫上尚未執行完成的事務所產生的變更。換句話說,當備庫上開啟一個read view時,在該時間點,如果有尚未提交的事務變更,這些變更應該是不可見的。
基于此,我們需要知道一個事務的開始點和結束點。我們增加了兩種日志來進行標示:
MLOG_TRX_START:?在主庫上為一個讀寫事務分配事務ID后,同時生成一條日志,日志中記錄了該ID的值;由于是持有trx_sys->mutex鎖生成的日志記錄,因此保證寫入redo的事務ID是有序的。
MLOG_TRX_COMMIT:?在事務提交階段,標記undo狀態為提交后,寫入該類型日志,記錄對應事務的事務ID
在備庫上,我們通過這兩類日志來重現事務場景,具體的我們采用一種延遲構建的方式:只有在完成apply一批日志后才對全局事務狀態進行更新:
1\. 在apply一批日志時,選擇其中最大的MLOG_TRX_START+1來更新trx_sys->max_trx_id
2\. 所有未提交的事務ID被加入到全局事務數組中。
如下圖所示:

在初始狀態下,最大未分配事務id(trx_sys->max_trx_id)為11,活躍事務ID數組為空;
在執行第一批日志期間,所有用戶請求構建的視圖都具有一樣的結構。即low_limit_id = up_limit_id = 11,本地trx_ids為空;
在執行完第一批日志后,max_trx_id被被更新成12 + 1,未完成的事務ID 12加入到全局活躍事務ID數組中。
依次類推。該方案是復制效率和數據可見性的一個權衡。
注意如果主庫崩潰,那么可能存在事務存在開始點,但丟失結束點的情況,因此主庫在崩潰恢復后寫入一條特殊的日志,以告訴所有的備庫去通過遍歷undo slot重新初始化全局事務狀態。
### Purge控制
既然要維持MVCC特性,那么作為一致性讀的重要組成部分的Undo log,就需要對其進行控制,那些仍然可能被讀視圖引用的Undo不應該被清理掉。這里我們提供了兩種方式來供用戶選擇:
方案一:控制備庫上的Purge
當主庫每次Purge時,都將當前Purge的最老快照寫入redo;備庫在拿到這個快照后,會去判斷其和當期實例上活躍的最老視圖是否有可見性上的重疊,并等待直到這些視圖關閉;我們也提供了一個超時選項,當等待時間過長時,就直接更新本地Purge視圖,用戶線程將獲得一個錯誤碼DB_MISSING_HISTORY
這種方案的缺點很明顯:當備庫讀負載很重,或者存在大查詢時,備庫可能產生復制延遲。
方案二:控制主庫上的Purge,備庫定期向其連接的實例發送反饋,反饋的內容為當前可安全Purge的最小ID。如下圖所示:

這種方案的缺點是,犧牲了主庫的Purge效率,在整個復制拓撲上,只要有長時間未關閉的視圖,都有可能引起主庫上的Undo膨脹。
### B-TREE結構變更復制
當發生B-TREE的結構變更時,例如Page合并或分裂,我們需要禁止用戶線程對btree進行檢索。
解決方案很簡單:當主庫上的mtr在commit時,如果是持有索引的排他鎖,并且一個mtr中的變更超過一個page時,則將涉及的索引id寫到日志中;備庫在解析到該日志時,會產生一個同步點:完成已經解析的日志;獲取索引X鎖;完成日志組Apply;釋放索引X鎖。
## 復制Change Buffer
### 備庫change buffer合并
Change buffer是InnoDB的一種特殊的緩存結構,其本質上是一棵存在于ibdata的btree。當修改用戶表空間的二級索引頁時,如果對應的page不在內存中,該操作將可能被記錄到change buffer中,從而減少了二級索引的隨機IO,并達到了合并更新的效果。
隨后當對應的page被讀入內存時,會進行一次merge操作;后臺Master線程也會定期發起Merge。關于change buffer本文不做深入,感興趣的可以閱讀我之前的[這篇月報](http://mysql.taobao.org/monthly/2015/07/01/)
然而在備庫,我們需要保證對數據不做任何的變更,只讀操作不應該對物理數據產生任何的影響。為了實現這一點,我們采用了如下方式來解決這個問題:
1\. 當將Page讀入內存,如果發現其需要進行ibuf merge,則為其分配一個shadow page,將未修改的數據頁保存到其中;
2\. 將change buffer記錄合并到數據頁上,同時關閉該Mtr的redo log,這樣修改后的Page就不會放到flush list上了;
3\. change buffer bitmap頁和change buffer btree上的頁都不允許產生任何的修改;
4\. 當數據頁從buffer pool驅逐或者被log apply線程請求時,shadow page會被釋放掉。
另外一個問題是,主備庫的內存狀態可能是不一樣的,例如一個Page在主庫上未讀入內存,因此為其緩存到change buffer。但備庫上這個page已經存在于buffer pool了。為了保證數據一致性,在備庫上我們需要將新的change buffer記錄合并到這個page上。
具體的,當在備庫解析到新的change buffer entry時,如果對應的Page已經在內存中了,就對其打個標簽。隨后用戶線程如果訪問到這個page,就從shadow page中恢復出未修改的Page(如果有shadow page),再進行一次change buffer合并操作。
### 復制change buffer合并
由于一次change buffer merge涉及到ibuf bitmap page,二級索引頁,change buffer btree三類,其存在嚴格的先后關系,而在備庫上,我們是并行進行日志apply的。為了保證在合并的過程中,用戶線程不能訪問到正在被修改的數據頁。我們增加了新的日志類型:
MLOG_IBUF_MERGE_START :?在主庫上進行ibuf merge之前寫入;當備庫解析到該日志時,apply所有已解析的日志,獲取對應的block,并加上排他鎖;如果有shadow page的話,則將未修改的數據恢復出來,并釋放shadow page。
MLOG_IBUF_MERGE_END:?在主庫上清除ibuf bitmap page上對應位后寫入;備庫解析到時apply所有已解析的日志并釋放block鎖。
很顯然該方案構成了一個性能瓶頸點,可能會影響到復制性能。后續再研究下有沒有更完美的解決方案。
## Failover
### Planned Failover
當執行計劃中的切換時,我們需要執行嚴格的步驟,以確保在切換時所有的實例處于一致的狀態。具體的分為4步:
Step1: 主庫上執行降級操作,狀態從MASTER修改成UPGRADABLE-SLAVE;這里會退出所有的讀寫事務,掛起或退出哪些可能修改數據的后臺線程;同時一條MLOG_DEMOTE日志寫入到redo文件中。
Step2: 所有連接的備庫在讀取到MLOG_DEMOTE日志后,將自己的狀態修改為UPGRADALE-SLAVE;
Step3: 任意挑選一個復制拓撲中的實例,將其提升為主庫,同時初始化各種內存狀態值;并寫入一條類型為MLOG_PROMOTE的日志;
Step4: 所有連接過來的備庫在解析到MLOG_PROMOTE日志后,將自己的狀態從UPGRADABLE-SLAVE修改成SLAVE
### Unplanned Failover
然而多數情況下,切換都是在意外情況下發生的,為了減少宕機時間,我們需要選擇一個備庫快速接管用戶負載。這種場景下需要解決的問題是:老主庫在恢復訪問后,如何確保和新主庫的狀態一致。更具體的說,如果老主庫上還有一部分日志還沒傳送到新主庫,這部分的不一致數據該怎么恢復。
我們采用覆蓋寫的方法來解決這一問題:
1\. 首先禁止老主庫上所有的訪問,包括查詢;同時將老主庫降級成備庫;
2\. 獲取新主庫切換時的LSN,然后在老主庫上從這個LSN開始遍歷redo日志,搜集所有影響到(space id, page no),如果發現有DDL操作,則認為恢復失敗,需要從外部第三方工具進行比較同步,或者重做實例;
3\. 從新主庫上獲取到這些page并在本地進行覆蓋寫操作;
4\. 完成覆蓋寫后,將多出來的redo log從磁盤上truncate掉,同時更新checkpoint信息;
5\. 恢復復制,并開啟讀請求。
## 測試及性能
我們測試了三個版本的性能:
* ALI_RDS_56_redo: 使用物理復制,并禁止binlog
* ALI_RDS_56: 目前RDS的MySQL版本
* MySQL5629: Upstream 5.6.29
測試環境
* Sysbench 0.5
* 50 tables, each with 200,000 records
* Buffer pool size: 16GB, 8 buffer pool instance, all data fit in memory
* innodb_thread_concurrency = 32
* Log file group is big enough, so no sharp checkpoint will happen Gtid disabled
* 2 threads per core; 6 cores per socket; 2 CPU sockets
Update_non_index (TPS)

Update_non_index (RT)

Update_non_index(TPS)

Update_non_index(RT)

- 數據庫內核月報目錄
- 數據庫內核月報 - 2016/09
- MySQL · 社區貢獻 · AliSQL那些事兒
- PetaData · 架構體系 · PetaData第二代低成本存儲體系
- MySQL · 社區動態 · MariaDB 10.2 前瞻
- MySQL · 特性分析 · 執行計劃緩存設計與實現
- PgSQL · 最佳實踐 · pg_rman源碼淺析與使用
- MySQL · 捉蟲狀態 · bug分析兩例
- PgSQL · 源碼分析 · PG優化器淺析
- MongoDB · 特性分析· Sharding原理與應用
- PgSQL · 源碼分析 · PG中的無鎖算法和原子操作應用一則
- SQLServer · 最佳實踐 · TEMPDB的設計
- 數據庫內核月報 - 2016/08
- MySQL · 特性分析 ·MySQL 5.7新特性系列四
- PgSQL · PostgreSQL 邏輯流復制技術的秘密
- MySQL · 特性分析 · MyRocks簡介
- GPDB · 特性分析· Greenplum 備份架構
- SQLServer · 最佳實踐 · RDS for SQLServer 2012權限限制提升與改善
- TokuDB · 引擎特性 · REPLACE 語句優化
- MySQL · 專家投稿 · InnoDB物理行中null值的存儲的推斷與驗證
- PgSQL · 實戰經驗 · 旋轉門壓縮算法在PostgreSQL中的實現
- MySQL · 源碼分析 · Query Cache并發處理
- PgSQL · 源碼分析· pg_dump分析
- 數據庫內核月報 - 2016/07
- MySQL · 特性分析 ·MySQL 5.7新特性系列三
- MySQL · 特性分析 · 5.7 代價模型淺析
- PgSQL · 實戰經驗 · 分組TOP性能提升44倍
- MySQL · 源碼分析 · 網絡通信模塊淺析
- MongoDB · 特性分析 · 索引原理
- SQLServer · 特性分析 · XML與JSON應用比較
- MySQL · 最佳實戰 · 審計日志實用案例分析
- MySQL · 性能優化 · 條件下推到物化表
- MySQL · 源碼分析 · Query Cache內部剖析
- MySQL · 捉蟲動態 · 備庫1206錯誤問題說明
- 數據庫內核月報 - 2016/06
- MySQL · 特性分析 · innodb 鎖分裂繼承與遷移
- MySQL · 特性分析 ·MySQL 5.7新特性系列二
- PgSQL · 實戰經驗 · 如何預測Freeze IO風暴
- GPDB · 特性分析· Filespace和Tablespace
- MariaDB · 新特性 · 窗口函數
- MySQL · TokuDB · checkpoint過程
- MySQL · 特性分析 · 內部臨時表
- MySQL · 最佳實踐 · 空間優化
- SQLServer · 最佳實踐 · 數據庫實現大容量插入的幾種方式
- 數據庫內核月報 - 2016/05
- MySQL · 引擎特性 · 基于InnoDB的物理復制實現
- MySQL · 特性分析 · MySQL 5.7新特性系列一
- PostgreSQL · 特性分析 · 邏輯結構和權限體系
- MySQL · 特性分析 · innodb buffer pool相關特性
- PG&GP · 特性分析 · 外部數據導入接口實現分析
- SQLServer · 最佳實踐 · 透明數據加密在SQLServer的應用
- MySQL · TokuDB · 日志子系統和崩潰恢復過程
- MongoDB · 特性分析 · Sharded cluster架構原理
- PostgreSQL · 特性分析 · 統計信息計算方法
- MySQL · 捉蟲動態 · left-join多表導致crash
- 數據庫內核月報 - 2016/04
- MySQL · 參數故事 · innodb_additional_mem_pool_size
- GPDB · 特性分析 · Segment事務一致性與異常處理
- GPDB · 特性分析 · Segment 修復指南
- MySQL · 捉蟲動態 · 并行復制外鍵約束問題二
- PgSQL · 性能優化 · 如何瀟灑的處理每天上百TB的數據增量
- Memcached · 最佳實踐 · 熱點 Key 問題解決方案
- MongoDB · 最佳實踐 · 短連接Auth性能優化
- MySQL · 最佳實踐 · RDS 只讀實例延遲分析
- MySQL · TokuDB · TokuDB索引結構--Fractal Tree
- MySQL · TokuDB · Savepoint漫談
- 數據庫內核月報 - 2016/03
- MySQL · TokuDB · 事務子系統和 MVCC 實現
- MongoDB · 特性分析 · MMAPv1 存儲引擎原理
- PgSQL · 源碼分析 · 優化器邏輯推理
- SQLServer · BUG分析 · Agent 鏈接泄露分析
- Redis · 特性分析 · AOF Rewrite 分析
- MySQL · BUG分析 · Rename table 死鎖分析
- MySQL · 物理備份 · Percona XtraBackup 備份原理
- GPDB · 特性分析· GreenPlum FTS 機制
- MySQL · 答疑解惑 · 備庫Seconds_Behind_Master計算
- MySQL · 答疑解惑 · MySQL 鎖問題最佳實踐
- 數據庫內核月報 - 2016/02
- MySQL · 引擎特性 · InnoDB 文件系統之文件物理結構
- MySQL · 引擎特性 · InnoDB 文件系統之IO系統和內存管理
- MySQL · 特性分析 · InnoDB transaction history
- PgSQL · 會議見聞 · PgConf.Russia 2016 大會總結
- PgSQL · 答疑解惑 · PostgreSQL 9.6 并行查詢實現分析
- MySQL · TokuDB · TokuDB之黑科技工具
- PgSQL · 性能優化 · PostgreSQL TPC-C極限優化玩法
- MariaDB · 版本特性 · MariaDB 的 GTID 介紹
- MySQL · 特性分析 · 線程池
- MySQL · 答疑解惑 · mysqldump tips 兩則
- 數據庫內核月報 - 2016/01
- MySQL · 引擎特性 · InnoDB 事務鎖系統簡介
- GPDB · 特性分析· GreenPlum Primary/Mirror 同步機制
- MySQL · 專家投稿 · MySQL5.7 的 JSON 實現
- MySQL · 特性分析 · 優化器 MRR & BKA
- MySQL · 答疑解惑 · 物理備份死鎖分析
- MySQL · TokuDB · Cachetable 的工作線程和線程池
- MySQL · 特性分析 · drop table的優化
- MySQL · 答疑解惑 · GTID不一致分析
- PgSQL · 特性分析 · Plan Hint
- MariaDB · 社區動態 · MariaDB on Power8 (下)
- 數據庫內核月報 - 2015/12
- MySQL · 引擎特性 · InnoDB 事務子系統介紹
- PgSQL · 特性介紹 · 全文搜索介紹
- MongoDB · 捉蟲動態 · Kill Hang問題排查記錄
- MySQL · 參數優化 ·RDS MySQL參數調優最佳實踐
- PgSQL · 特性分析 · 備庫激活過程分析
- MySQL · TokuDB · 讓Hot Backup更完美
- PgSQL · 答疑解惑 · 表膨脹
- MySQL · 特性分析 · Index Condition Pushdown (ICP)
- MariaDB · 社區動態 · MariaDB on Power8
- MySQL · 特性分析 · 企業版特性一覽
- 數據庫內核月報 - 2015/11
- MySQL · 社區見聞 · OOW 2015 總結 MySQL 篇
- MySQL · 特性分析 · Statement Digest
- PgSQL · 答疑解惑 · PostgreSQL 用戶組權限管理
- MySQL · 特性分析 · MDL 實現分析
- PgSQL · 特性分析 · full page write 機制
- MySQL · 捉蟲動態 · MySQL 外鍵異常分析
- MySQL · 答疑解惑 · MySQL 優化器 range 的代價計算
- MySQL · 捉蟲動態 · ORDER/GROUP BY 導致 mysqld crash
- MySQL · TokuDB · TokuDB 中的行鎖
- MySQL · 捉蟲動態 · order by limit 造成優化器選擇索引錯誤
- 數據庫內核月報 - 2015/10
- MySQL · 引擎特性 · InnoDB 全文索引簡介
- MySQL · 特性分析 · 跟蹤Metadata lock
- MySQL · 答疑解惑 · 索引過濾性太差引起CPU飆高分析
- PgSQL · 特性分析 · PG主備流復制機制
- MySQL · 捉蟲動態 · start slave crash 診斷分析
- MySQL · 捉蟲動態 · 刪除索引導致表無法打開
- PgSQL · 特性分析 · PostgreSQL Aurora方案與DEMO
- TokuDB · 捉蟲動態 · CREATE DATABASE 導致crash問題
- PgSQL · 特性分析 · pg_receivexlog工具解析
- MySQL · 特性分析 · MySQL權限存儲與管理
- 數據庫內核月報 - 2015/09
- MySQL · 引擎特性 · InnoDB Adaptive hash index介紹
- PgSQL · 特性分析 · clog異步提交一致性、原子操作與fsync
- MySQL · 捉蟲動態 · BUG 幾例
- PgSQL · 答疑解惑 · 詭異的函數返回值
- MySQL · 捉蟲動態 · 建表過程中crash造成重建表失敗
- PgSQL · 特性分析 · 談談checkpoint的調度
- MySQL · 特性分析 · 5.6 并行復制恢復實現
- MySQL · 備庫優化 · relay fetch 備庫優化
- MySQL · 特性分析 · 5.6并行復制事件分發機制
- MySQL · TokuDB · 文件目錄談
- 數據庫內核月報 - 2015/08
- MySQL · 社區動態 · InnoDB Page Compression
- PgSQL · 答疑解惑 · RDS中的PostgreSQL備庫延遲原因分析
- MySQL · 社區動態 · MySQL5.6.26 Release Note解讀
- PgSQL · 捉蟲動態 · 執行大SQL語句提示無效的內存申請大小
- MySQL · 社區動態 · MariaDB InnoDB表空間碎片整理
- PgSQL · 答疑解惑 · 歸檔進程cp命令的core文件追查
- MySQL · 答疑解惑 · open file limits
- MySQL · TokuDB · 瘋狂的 filenum++
- MySQL · 功能分析 · 5.6 并行復制實現分析
- MySQL · 功能分析 · MySQL表定義緩存
- 數據庫內核月報 - 2015/07
- MySQL · 引擎特性 · Innodb change buffer介紹
- MySQL · TokuDB · TokuDB Checkpoint機制
- PgSQL · 特性分析 · 時間線解析
- PgSQL · 功能分析 · PostGIS 在 O2O應用中的優勢
- MySQL · 引擎特性 · InnoDB index lock前世今生
- MySQL · 社區動態 · MySQL內存分配支持NUMA
- MySQL · 答疑解惑 · 外鍵刪除bug分析
- MySQL · 引擎特性 · MySQL logical read-ahead
- MySQL · 功能介紹 · binlog拉取速度的控制
- MySQL · 答疑解惑 · 浮點型的顯示問題
- 數據庫內核月報 - 2015/06
- MySQL · 引擎特性 · InnoDB 崩潰恢復過程
- MySQL · 捉蟲動態 · 唯一鍵約束失效
- MySQL · 捉蟲動態 · ALTER IGNORE TABLE導致主備不一致
- MySQL · 答疑解惑 · MySQL Sort 分頁
- MySQL · 答疑解惑 · binlog event 中的 error code
- PgSQL · 功能分析 · Listen/Notify 功能
- MySQL · 捉蟲動態 · 任性的 normal shutdown
- PgSQL · 追根究底 · WAL日志空間的意外增長
- MySQL · 社區動態 · MariaDB Role 體系
- MySQL · TokuDB · TokuDB數據文件大小計算
- 數據庫內核月報 - 2015/05
- MySQL · 引擎特性 · InnoDB redo log漫游
- MySQL · 專家投稿 · MySQL數據庫SYS CPU高的可能性分析
- MySQL · 捉蟲動態 · 5.6 與 5.5 InnoDB 不兼容導致 crash
- MySQL · 答疑解惑 · InnoDB 預讀 VS Oracle 多塊讀
- PgSQL · 社區動態 · 9.5 新功能BRIN索引
- MySQL · 捉蟲動態 · MySQL DDL BUG
- MySQL · 答疑解惑 · set names 都做了什么
- MySQL · 捉蟲動態 · 臨時表操作導致主備不一致
- TokuDB · 引擎特性 · zstd壓縮算法
- MySQL · 答疑解惑 · binlog 位點刷新策略
- 數據庫內核月報 - 2015/04
- MySQL · 引擎特性 · InnoDB undo log 漫游
- TokuDB · 產品新聞 · RDS TokuDB小手冊
- PgSQL · 社區動態 · 說一說PgSQL 9.4.1中的那些安全補丁
- MySQL · 捉蟲動態 · 連接斷開導致XA事務丟失
- MySQL · 捉蟲動態 · GTID下slave_net_timeout值太小問題
- MySQL · 捉蟲動態 · Relay log 中 GTID group 完整性檢測
- MySQL · 答疑釋惑 · UPDATE交換列單表和多表的區別
- MySQL · 捉蟲動態 · 刪被引用索引導致crash
- MySQL · 答疑釋惑 · GTID下auto_position=0時數據不一致
- 數據庫內核月報 - 2015/03
- MySQL · 答疑釋惑· 并發Replace into導致的死鎖分析
- MySQL · 性能優化· 5.7.6 InnoDB page flush 優化
- MySQL · 捉蟲動態· pid file丟失問題分析
- MySQL · 答疑釋惑· using filesort VS using temporary
- MySQL · 優化限制· MySQL index_condition_pushdown
- MySQL · 捉蟲動態·DROP DATABASE外鍵約束的GTID BUG
- MySQL · 答疑釋惑· lower_case_table_names 使用問題
- PgSQL · 特性分析· Logical Decoding探索
- PgSQL · 特性分析· jsonb類型解析
- TokuDB ·引擎機制· TokuDB線程池
- 數據庫內核月報 - 2015/02
- MySQL · 性能優化· InnoDB buffer pool flush策略漫談
- MySQL · 社區動態· 5.6.23 InnoDB相關Bugfix
- PgSQL · 特性分析· Replication Slot
- PgSQL · 特性分析· pg_prewarm
- MySQL · 答疑釋惑· InnoDB丟失自增值
- MySQL · 答疑釋惑· 5.5 和 5.6 時間類型兼容問題
- MySQL · 捉蟲動態· 變量修改導致binlog錯誤
- MariaDB · 特性分析· 表/表空間加密
- MariaDB · 特性分析· Per-query variables
- TokuDB · 特性分析· 日志詳解
- 數據庫內核月報 - 2015/01
- MySQL · 性能優化· Group Commit優化
- MySQL · 新增特性· DDL fast fail
- MySQL · 性能優化· 啟用GTID場景的性能問題及優化
- MySQL · 捉蟲動態· InnoDB自增列重復值問題
- MySQL · 優化改進· 復制性能改進過程
- MySQL · 談古論今· key分區算法演變分析
- MySQL · 捉蟲動態· mysql client crash一例
- MySQL · 捉蟲動態· 設置 gtid_purged 破壞AUTO_POSITION復制協議
- MySQL · 捉蟲動態· replicate filter 和 GTID 一起使用的問題
- TokuDB·特性分析· Optimize Table
- 數據庫內核月報 - 2014/12
- MySQL· 性能優化·5.7 Innodb事務系統
- MySQL· 踩過的坑·5.6 GTID 和存儲引擎那會事
- MySQL· 性能優化·thread pool 原理分析
- MySQL· 性能優化·并行復制外建約束問題
- MySQL· 答疑釋惑·binlog event有序性
- MySQL· 答疑釋惑·server_id為0的Rotate
- MySQL· 性能優化·Bulk Load for CREATE INDEX
- MySQL· 捉蟲動態·Opened tables block read only
- MySQL· 優化改進· GTID啟動優化
- TokuDB· Binary Log Group Commit with TokuDB
- 數據庫內核月報 - 2014/11
- MySQL· 捉蟲動態·OPTIMIZE 不存在的表
- MySQL· 捉蟲動態·SIGHUP 導致 binlog 寫錯
- MySQL· 5.7改進·Recovery改進
- MySQL· 5.7特性·高可用支持
- MySQL· 5.7優化·Metadata Lock子系統的優化
- MySQL· 5.7特性·在線Truncate undo log 表空間
- MySQL· 性能優化·hash_scan 算法的實現解析
- TokuDB· 版本優化· 7.5.0
- TokuDB· 引擎特性· FAST UPDATES
- MariaDB· 性能優化·filesort with small LIMIT optimization
- 數據庫內核月報 - 2014/10
- MySQL· 5.7重構·Optimizer Cost Model
- MySQL· 系統限制·text字段數
- MySQL· 捉蟲動態·binlog重放失敗
- MySQL· 捉蟲動態·從庫OOM
- MySQL· 捉蟲動態·崩潰恢復失敗
- MySQL· 功能改進·InnoDB Warmup特性
- MySQL· 文件結構·告別frm文件
- MariaDB· 新鮮特性·ANALYZE statement 語法
- TokuDB· 主備復制·Read Free Replication
- TokuDB· 引擎特性·壓縮
- 數據庫內核月報 - 2014/09
- MySQL· 捉蟲動態·GTID 和 DELAYED
- MySQL· 限制改進·GTID和升級
- MySQL· 捉蟲動態·GTID 和 binlog_checksum
- MySQL· 引擎差異·create_time in status
- MySQL· 參數故事·thread_concurrency
- MySQL· 捉蟲動態·auto_increment
- MariaDB· 性能優化·Extended Keys
- MariaDB·主備復制·CREATE OR REPLACE
- TokuDB· 參數故事·數據安全和性能
- TokuDB· HA方案·TokuDB熱備
- 數據庫內核月報 - 2014/08
- MySQL· 參數故事·timed_mutexes
- MySQL· 參數故事·innodb_flush_log_at_trx_commit
- MySQL· 捉蟲動態·Count(Distinct) ERROR
- MySQL· 捉蟲動態·mysqldump BUFFER OVERFLOW
- MySQL· 捉蟲動態·long semaphore waits
- MariaDB·分支特性·支持大于16K的InnoDB Page Size
- MariaDB·分支特性·FusionIO特性支持
- TokuDB· 性能優化·Bulk Fetch
- TokuDB· 數據結構·Fractal-Trees與LSM-Trees對比
- TokuDB·社區八卦·TokuDB團隊