MySQL : 基于InnoDB的物理復(fù)制實(shí)現(xiàn)

最近有幸前去美國參加Percona Live 2016會(huì)議并分享了我們最近在MySQL復(fù)制上所做的工作榕酒，也就是基于InnoDB的物理復(fù)制热鞍。會(huì)后很多小伙伴私信我說分享的PPT太內(nèi)核了引瀑，不太容易理解趣斤。因此本文主要針對分享的內(nèi)容進(jìn)行展開描述讨衣，希望能對大家有所幫助方援。

背景知識(shí)

在開始之前没炒，你需要對InnoDB的事務(wù)系統(tǒng)有個(gè)基本的認(rèn)識(shí)。如果您不了解犯戏，可以參考我之前的幾篇關(guān)于InnoDB的文章送火，包括InnoDB的事務(wù)子系統(tǒng)拳话，事務(wù)鎖，redo log种吸，undo log弃衍，以及崩潰恢復(fù)邏輯。在這里我們簡單的概述一下幾個(gè)基本的概念：

事務(wù)ID：一個(gè)自增的序列號(hào)坚俗，每次開啟一個(gè)讀寫事務(wù)（或者事務(wù)從只讀轉(zhuǎn)換成讀寫模式）時(shí)分配并遞增镜盯，每更新256次后持久化到Ibdata的事務(wù)系統(tǒng)頁中。每個(gè)讀寫事務(wù)都必須保證擁有的ID是唯一的猖败。

Read View:用于一致性讀的snapshot速缆，InnoDB里稱為視圖；在需要一致性讀時(shí)開啟一個(gè)視圖辙浑，記錄當(dāng)時(shí)的事務(wù)狀態(tài)快照激涤，包括當(dāng)時(shí)活躍的事務(wù)ID以及事務(wù)ID的上下水位值，以此用于判斷數(shù)據(jù)的可見性判呕。

Redo Log：用于記錄對物理文件的修改倦踢，所有對InnoDB物理文件的修改都需要通過Redo保護(hù)起來，這樣才能從崩潰中恢復(fù)侠草。

Mini Transaction(mtr)：是InnoDB中修改物理塊的最小原子操作單位辱挥，同時(shí)也負(fù)責(zé)生產(chǎn)本地的redo日志，并在提交mtr時(shí)將redo日志拷貝到全局log buffer中边涕。

LSN:一個(gè)一直在遞增的日志序列號(hào)晤碘，在InnoDB中代表了從實(shí)例安裝到當(dāng)前已經(jīng)產(chǎn)生的日志總量」︱眩可以通過LSN計(jì)算出其在日志文件中的位置园爷。每個(gè)block在寫盤時(shí)，其最近一次修改的LSN也會(huì)記入其中式撼，這樣在崩潰恢復(fù)時(shí)童社，無需Apply該LSN之前的日志。

Undo Log:用于存儲(chǔ)記錄被修改之前的舊版本著隆，如果被多次修改扰楼，則會(huì)產(chǎn)生一個(gè)版本鏈。保留舊版本的目的是用于可重復(fù)讀美浦。通過結(jié)合Undo和視圖控制來實(shí)現(xiàn)InnoDB的MVCC弦赖。

Binary Log:構(gòu)建在存儲(chǔ)引擎之上的統(tǒng)一的日志格式；有兩種存儲(chǔ)方式浦辨，一種是記錄執(zhí)行的SQL式塌，另外一種是記錄修改的行記錄样勃。Binlog本質(zhì)上是一種邏輯日志傲武，因此能夠適用所有的存儲(chǔ)引擎，并進(jìn)行數(shù)據(jù)復(fù)制庆冕。

原生復(fù)制的優(yōu)缺點(diǎn)

MySQL的每條讀寫事務(wù)都需要維持兩份日志，一份是redo log劈榨，一份是binary log访递。MySQL使用兩階段提交協(xié)議，只有當(dāng)redo 和binlog都寫入磁盤時(shí)同辣，事務(wù)才算真正的持久化了拷姿。如果只寫入redo，未寫入binlog旱函，這樣的事務(wù)在崩潰恢復(fù)時(shí)需要回滾掉响巢。MySQL通過XID來關(guān)聯(lián)InnoDB的事務(wù)和binlog。

MySQL的原生事務(wù)日志復(fù)制有一些顯著的優(yōu)點(diǎn)：

首先棒妨，相比InnoDB的redo log而言踪古，Binary Log更加可讀，有成熟的配套工具來進(jìn)行解析券腔；由于記錄了行級別的更改伏穆。我們可以通過解析binlog，轉(zhuǎn)換成DML語句來將數(shù)據(jù)變更同步到異構(gòu)數(shù)據(jù)庫纷纫。另外一種典型的做法是使用Binlog來失效構(gòu)建在前端的cache枕扫。事實(shí)上，基于Binlog的數(shù)據(jù)流服務(wù)在阿里內(nèi)部使用的非常廣泛辱魁，也是最重要的基礎(chǔ)設(shè)施之一烟瞧。

其次由于Binary log是一種統(tǒng)一的日志格式，你可以在主備上使用不同的存儲(chǔ)引擎染簇，例如當(dāng)你需要測試某種新的存儲(chǔ)引擎時(shí)参滴，你可以搭建一個(gè)備庫，將所有表alter到新引擎锻弓，然后開啟數(shù)據(jù)復(fù)制進(jìn)行觀察砾赔。

此外基于Binary Log你還可以構(gòu)建起非常復(fù)雜的復(fù)制拓?fù)浣Y(jié)構(gòu)，尤其是在引入了GTID之后弥咪，這種優(yōu)勢尤為明顯: 如果設(shè)計(jì)妥當(dāng)过蹂，你可以實(shí)現(xiàn)相當(dāng)復(fù)雜的復(fù)制結(jié)構(gòu)十绑。甚至可以做到多點(diǎn)寫入聚至。總體使用起來非常靈活本橙。

然而扳躬，也正是這種日志架構(gòu)可能會(huì)帶來一些問題：首先MySQL需要記錄兩份日志：redo及binlog，只有當(dāng)兩份日志都fsync到磁盤，我們才能認(rèn)為事務(wù)是持久化的贷币，而眾所周知击胜，fsync是一種開銷非常昂貴的操作。更多的日志寫入還增加了磁盤IO壓力役纹。這兩點(diǎn)都會(huì)影響到響應(yīng)時(shí)間和吞吐量偶摔。

Binlog復(fù)制還會(huì)帶來復(fù)制延遲的問題。我們知道只有主庫事務(wù)提交后促脉，日志才會(huì)寫入到binlog文件并傳遞到備庫辰斋，這意味著備庫至少延遲一個(gè)事務(wù)的執(zhí)行時(shí)間。另外有些操作例如DDL瘸味，大事務(wù)等等宫仗，由于在備庫需要繼續(xù)保持事務(wù)完整性，這些執(zhí)行時(shí)間很長的操作會(huì)長時(shí)間占用某個(gè)worker線程旁仿，而協(xié)調(diào)線程會(huì)碰到復(fù)制同步點(diǎn)藕夫，導(dǎo)致后續(xù)的任務(wù)無法分發(fā)到其他空閑的worker線程。

MySQL是原生復(fù)制是MySQL生態(tài)的一個(gè)非常重要的組成部分枯冈。官方也在積極的改進(jìn)其特性毅贮，例如MySQL5.7在這一塊就有非常顯著的改進(jìn)。

Why Phsyical Replication

既然原生復(fù)制這么成熟霜幼，優(yōu)點(diǎn)這么多嫩码，為什么我們還要考慮基于物理日志的復(fù)制呢？

首先最重要的原因就是性能罪既！當(dāng)我們事先了物理復(fù)制后铸题，就可以關(guān)閉binlog和gtid，大大減少了數(shù)據(jù)寫盤量琢感。這種情況下丢间，最多只需要一次fsync既可以將事務(wù)持久化到磁盤。實(shí)例整體的吞吐量和響應(yīng)時(shí)間都得到了非常大的提升驹针。

另外烘挫，通過物理復(fù)制，我們能獲得更加理想的物理復(fù)制性能柬甥。事務(wù)在執(zhí)行過程中產(chǎn)生的redo log只要寫到文件中饮六，就會(huì)被傳送到備庫。這意味著我們可以同時(shí)在主備庫上執(zhí)行事務(wù)苛蒲，而無需等待主庫上執(zhí)行完成卤橄。我們可以基于(space_id, page_no)來進(jìn)行并發(fā)apply，同一個(gè)page上的變更也可以做到合并寫操作臂外，相比傳統(tǒng)復(fù)制窟扑，具有更好的并發(fā)性喇颁。最重要的是，基于物理變更的復(fù)制嚎货，可以最大程度保證主備的數(shù)據(jù)總是一致的橘霎。

當(dāng)然物理復(fù)制不是銀彈，當(dāng)啟用該特性后殖属，我們將只能支持InnoDB存儲(chǔ)引擎姐叁；我們也很難去設(shè)計(jì)多點(diǎn)寫復(fù)制拓?fù)洹Ｎ锢韽?fù)制無法取代原生復(fù)制洗显，而是應(yīng)對特定的場景七蜘，例如需求高并發(fā)DML性能的場景。

因此在正式開始前墙懂，我們設(shè)置了這些前提：1.主庫上不應(yīng)該有任何限制橡卤； 2.備庫上只允許執(zhí)行查詢操作，不允許通過用戶接口對數(shù)據(jù)產(chǎn)生任何的變更损搬。

下文默認(rèn)MySQL已包含如下特性：

沒有只讀事務(wù)鏈表碧库，并且不為只讀事務(wù)分配事務(wù)ID

使用全局事務(wù)ID數(shù)組來構(gòu)建read view快照

所有MySQL庫下的系統(tǒng)表都使用InnoDB存儲(chǔ)引擎

High Level Architecture

復(fù)制架構(gòu)

這里復(fù)制的基礎(chǔ)架構(gòu)和原生復(fù)制類似，但代碼是完全獨(dú)立的巧勤。如下圖所示：

首先嵌灰，我們在備庫上配置好連接后，執(zhí)行START INNODB SLAVE颅悉，備庫上會(huì)開啟一個(gè)io線程沽瞭，同時(shí)InnoDB層啟動(dòng)一個(gè)Log Apply協(xié)調(diào)線程以及多個(gè)worker線程。

IO線程建立和主庫的連接剩瓶，并發(fā)送一個(gè)dump請求驹溃，請求的內(nèi)容包括：

master_uuid: 最近備庫上日志最初產(chǎn)生所在的實(shí)例的server_uuid

start_lsn: 開始復(fù)制的點(diǎn)

在主庫上，一個(gè)log_dump線程被創(chuàng)建延曙，先檢查dump請求是否是合法的豌鹤，如果合法，就去從本地的ib_logfile中讀取日志枝缔，并發(fā)送到備庫布疙。

備庫IO線程在接受到日志后，將其拷貝到InnoDB的Log Buffer中愿卸，然后調(diào)用log_write_up_to將其寫入到本地的ib_logfile文件中灵临。

Log Apply協(xié)調(diào)線程被喚醒，從文件中讀取日志進(jìn)行解析趴荸，并根據(jù)fold(space id ,page no)% (n_workers + 1)進(jìn)行分發(fā)儒溉，系統(tǒng)表空間的變更存放到sys hash中，用戶表空間的變更存儲(chǔ)到user hash中赊舶。協(xié)調(diào)線程在解析&&分發(fā)完畢后睁搭，也會(huì)參與到日志apply中。

當(dāng)Apply日志時(shí)笼平，我們總是先應(yīng)用系統(tǒng)表空間园骆，再是用戶表空間。原因是我們需要保證undo日志先應(yīng)用寓调，否則外部查詢檢索用戶表的btree锌唾，試圖通過回滾段指針查詢undo page，可能對應(yīng)的Undo還沒構(gòu)成夺英。

日志文件管理

要實(shí)現(xiàn)上述架構(gòu)晌涕，第一個(gè)要解決的問題是需要重新整理InnoDB的日志文件。 因?yàn)樵壿嬛型疵酰琁nnoDB采用循環(huán)寫文件的方式余黎，例如當(dāng)我們設(shè)置innodb_log_files_in_group為4時(shí)，會(huì)創(chuàng)建4個(gè)ib logfile文件载萌。當(dāng)?shù)谒膫€(gè)文件寫滿時(shí)惧财，會(huì)回到第一個(gè)文件循環(huán)寫入。但是在物理復(fù)制架構(gòu)下扭仁，我們需要保留老的日志文件垮衷，這些文件既可以防止例如網(wǎng)絡(luò)出現(xiàn)問題，日志未曾及時(shí)傳送到備庫乖坠，也可以用于備份目的搀突。

我們像binlog那樣，當(dāng)當(dāng)前日志文件寫滿時(shí)熊泵，則切換到下一個(gè)日志文件仰迁，文件的序號(hào)總是向前遞增的。然而這里需要解決的一個(gè)問題是：切換文件需要盡量減小對性能的影響顽分，我們引入了獨(dú)立的后臺(tái)線程轩勘，并允許已被清理的日志文件重用。

和binlog類似怯邪，我們也需要清理已經(jīng)沒用的日志文件绊寻，既需要提供接口，由用戶手動(dòng)清理悬秉，也可以開啟后臺(tái)線程自動(dòng)判斷并進(jìn)行清理澄步，但兩種方案都需要滿足條件：

1. 不允許超過當(dāng)前checkpoint所在的文件

2. 如果有正在連接的備庫，則不允許清理尚未傳送到備庫的日志

文件架構(gòu)如下圖所示：

這里我們增加了一個(gè)新的文件ib_checkpoint和泌，原因是原生邏輯中村缸，checkpoint信息是存儲(chǔ)在ib_logfile0中的，而在新的架構(gòu)下武氓，該文件可能被刪除掉梯皿，我們需要單獨(dú)對checkpoint信息進(jìn)行存儲(chǔ)仇箱，包含checkpoint no, checkpoint lsn, 以及該Lsn所在的日志文件號(hào)及文件內(nèi)偏移量。

后臺(tái)清理線程被稱為log purge thread东羹，當(dāng)該線程被喚醒被執(zhí)行清理操作時(shí)剂桥，將目標(biāo)日志文件rename到以purged作為前綴，并放到一個(gè)回收池中属提，如果池子滿了权逗，則直接刪除掉。

為了避免日志切換到新文件時(shí)造成的性能抖動(dòng)冤议，后臺(tái)log file allocate線程總是預(yù)先將下一個(gè)文件準(zhǔn)備好斟薇，也就是說，當(dāng)前正在寫第N個(gè)文件恕酸，后臺(tái)線程會(huì)被喚醒堪滨，并創(chuàng)建好第N+1個(gè)文件。這樣對前臺(tái)線程的影響僅僅是關(guān)閉并打開新文件句柄蕊温。

log file allocate線程在準(zhǔn)備下一個(gè)文件時(shí)椿猎，先嘗試從回收池中獲取文件，并進(jìn)行必要的判斷（確保下一個(gè)文件開始的LSN轉(zhuǎn)換成block no后不和文件內(nèi)的內(nèi)容重疊）寿弱，如果可以使用犯眠，則直接取出來并rename為下一個(gè)文件名。如果回收池?zé)o可用文件症革，則創(chuàng)建文件筐咧，并extend到指定的大小。通過這種方式噪矛，我們盡量保證了性能的平緩量蕊。

實(shí)例角色

和原生復(fù)制不同，對于備庫艇挨，我們總是不允許做任何的數(shù)據(jù)變更残炮，這種行為不受是否重啟，是否崩潰而影響缩滨，只受failover影響势就。一臺(tái)備庫無論重啟多少次總是為備庫。

日志最初產(chǎn)生的服務(wù)器我們稱為日志源實(shí)例脉漏。日志可能通過復(fù)雜的復(fù)制拓?fù)鋫鬟f到多級級聯(lián)實(shí)例上苞冯。但所有的這些備庫都應(yīng)具有相同的源實(shí)例信息。我們需要通過這個(gè)信息來判斷一個(gè)dump請求是否是合法的侧巨，例如作為備庫舅锄，所有dump的日志都應(yīng)產(chǎn)自同一個(gè)日志源實(shí)例，除非在復(fù)制拓?fù)渲邪l(fā)生了failover司忱。

我們?yōu)閷?shí)例定義了三種狀態(tài)：master, slave,以及upgradable-slave;其中第三種是一種中間狀態(tài)皇忿，只在failover時(shí)產(chǎn)生畴蹭。

這些狀態(tài)信息被持久化到本地文件innodb_repl.info文件中。同時(shí)也單獨(dú)存儲(chǔ)了日志源實(shí)例的server_uuid鳍烁。

我們以下圖為例：

server 1的uuid為1叨襟，和文件中記錄的uuid相同，因此認(rèn)為該實(shí)例為master;

server 2的uuid為2老翘，和文件中記錄的uuid不同，因?yàn)樵搶?shí)例為slave;

server 3的uuid為3锻离，但文件中記錄的值為0铺峭，表明最近剛發(fā)生過一次failover（server 1 和server 2發(fā)生過一次切換），但還沒來得及獲取到切換日志汽纠，因此該實(shí)例角色為upgradable-slave

innodb_repl.info文件維持了所有的復(fù)制和failover狀態(tài)信息卫键，很顯然，如果我們想從已有的拓?fù)渲衦estore出一個(gè)新的實(shí)例虱朵，對應(yīng)的innodb_repl.info文件也要拷貝出來莉炉。

后臺(tái)線程

有些后臺(tái)線程可能對數(shù)據(jù)產(chǎn)生變更，因此在備庫上我們需要禁止這些線程：

1. 不允許開啟Purge線程

2. master線程不允許去做ibuf merge之類的工作碴犬，只負(fù)責(zé)定期做lazy checkpoint

3. dict_stats線程只負(fù)責(zé)更新表的內(nèi)存統(tǒng)計(jì)信息絮宁，不可以觸發(fā)統(tǒng)計(jì)信息的物理存儲(chǔ)。

此外備庫的page cleaner線程的刷臟算法也需要重新調(diào)整以盡量平緩服协，不要影響到日志apply绍昂。

MySQL Server層數(shù)據(jù)復(fù)制

文件操作復(fù)制

為了實(shí)現(xiàn)Server-Engine的架構(gòu)，MySQL在Server層另外冗余了一些元數(shù)據(jù)信息偿荷，以在存儲(chǔ)引擎之上建立統(tǒng)一的標(biāo)準(zhǔn)窘游。這些元數(shù)據(jù)文件包括FRM，PAR跳纳，DB.OPT忍饰，TRG，TRN以及代表數(shù)據(jù)庫的目錄寺庄。對這些文件和目錄的操作都沒有寫到redo中艾蓝。

為了能夠?qū)崿F(xiàn)文件層的操作，我們需要將文件變更操作寫到日志中斗塘，主要擴(kuò)展了三種新的日志類型：

MLOG_METAFILE_CREATE: [FIL_NAME | CONTENT]

MLOG_METAFILE_RENAME: [ORIGINAL_NAME | TARGET_NAME]

MLOG_METAFILE_DELETE: [FIL_NAME]

這里包含了三種操作饶深，文件的創(chuàng)建，重命名及刪除逛拱。注意這里沒有修改文件操作敌厘，原因是Server層總是通過創(chuàng)建新文件，刪除舊文件的方式來進(jìn)行元數(shù)據(jù)更新朽合。

DDL復(fù)制

當(dāng)MySQL在執(zhí)行DDL修改元數(shù)據(jù)時(shí)俱两，是不允許訪問表空間的饱狂，否則可能導(dǎo)致各種異常錯(cuò)誤。MySQL使用排他的MDL鎖來阻塞用戶訪問宪彩。我們需要在備庫保持相同的行為休讳。這就需要識(shí)別修改元數(shù)據(jù)的起點(diǎn)和結(jié)束點(diǎn)。我們引入兩類日志來進(jìn)行標(biāo)識(shí)尿孔。

舉個(gè)簡單的例子:

執(zhí)行： CREATE TABLE t1 (a INT PRIMARY KEY, b INT);舉個(gè)簡單的例子:

從Server層產(chǎn)生的日志包括：

* MLOG_METACHANGE_START

* MLOG_METAFILE_CREATE (test/t1.frm)

* MLOG_METACHANGE_END

執(zhí)行： ALTER TABLE t1 ADD KEY (b);

從Server層產(chǎn)生的日志包括：

* 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

然而元數(shù)據(jù)修改開始點(diǎn)和結(jié)束點(diǎn)所代表的兩個(gè)日志并不是原子的俊柔，這意味著主庫上在修改元數(shù)據(jù)的過程中如果crash了，就會(huì)丟失后面的結(jié)束標(biāo)記活合。備庫可能一直持有這個(gè)表上的MDL鎖無法釋放雏婶。為了解決這個(gè)問題，我們在主庫每次崩潰恢復(fù)后白指，都寫一條特殊的日志留晚，通知所有連接的備庫釋放其持有的所有MDL排他鎖。

另外一個(gè)問題存在于備庫告嘲，舉個(gè)例子错维，執(zhí)行MLOG_METACHANGE_START后，做一次checkpoint橄唬，在接受到MLOG_METACHANGE_END之前crash赋焕。當(dāng)備庫實(shí)例從崩潰中恢復(fù)時(shí)，需要能夠繼續(xù)保持MDL鎖仰楚，避免用戶訪問宏邮。

為了能夠恢復(fù)MDL，首先我們需要控制checkpoint的LSN缸血，保證不超過所有未完成元數(shù)據(jù)變更的最老的開始點(diǎn)蜜氨；其次，在重啟時(shí)搜集未完成元數(shù)據(jù)變更的表名捎泻，并在崩潰恢復(fù)完成后依次把MDL 排他鎖加上飒炎。

Cache失效

在Server層還維護(hù)了一些Cache結(jié)構(gòu)，然而數(shù)據(jù)的更新是體現(xiàn)在物理層的笆豁，備庫在應(yīng)用完redo后郎汪，需要感知到哪些Cache是需要進(jìn)行更新的，目前來看主要有以下幾種情況：

1. 權(quán)限操作闯狱，備庫上需要進(jìn)行ACL Reload煞赢，才能讓新的權(quán)限生效；

2. 存儲(chǔ)過程操作哄孤，例如增刪存儲(chǔ)過程照筑，在備庫需要遞增一個(gè)版本號(hào)，以告訴用戶線程重新載入cache；

3. 表級統(tǒng)計(jì)信息凝危，主庫上通過更新的行的數(shù)量來觸發(fā)表統(tǒng)計(jì)信息更新波俄；但在備庫上，所有的變更都是基于塊級別的蛾默，并不能感知到變化了多少行懦铺。因此每次主庫更新統(tǒng)計(jì)信息時(shí)同時(shí)寫一條日志到redo中，通知備庫進(jìn)行內(nèi)存統(tǒng)計(jì)信息更新支鸡。

備庫MVCC

視圖控制

備庫一致性讀的最基本要求是用戶線程不應(yīng)該看到主庫上尚未執(zhí)行完成的事務(wù)所產(chǎn)生的變更冬念。換句話說，當(dāng)備庫上開啟一個(gè)read view時(shí)牧挣，在該時(shí)間點(diǎn)急前，如果有尚未提交的事務(wù)變更，這些變更應(yīng)該是不可見的浸踩。

基于此叔汁，我們需要知道一個(gè)事務(wù)的開始點(diǎn)和結(jié)束點(diǎn)统求。我們增加了兩種日志來進(jìn)行標(biāo)示：

MLOG_TRX_START：在主庫上為一個(gè)讀寫事務(wù)分配事務(wù)ID后检碗，同時(shí)生成一條日志，日志中記錄了該ID的值码邻；由于是持有trx_sys->mutex鎖生成的日志記錄折剃，因此保證寫入redo的事務(wù)ID是有序的。

MLOG_TRX_COMMIT：在事務(wù)提交階段像屋，標(biāo)記undo狀態(tài)為提交后怕犁，寫入該類型日志，記錄對應(yīng)事務(wù)的事務(wù)ID

在備庫上己莺，我們通過這兩類日志來重現(xiàn)事務(wù)場景奏甫，具體的我們采用一種延遲構(gòu)建的方式：只有在完成apply一批日志后才對全局事務(wù)狀態(tài)進(jìn)行更新：

1. 在apply一批日志時(shí)，選擇其中最大的MLOG_TRX_START+1來更新trx_sys->max_trx_id

2. 所有未提交的事務(wù)ID被加入到全局事務(wù)數(shù)組中凌受。

如下圖所示：

在初始狀態(tài)下阵子，最大未分配事務(wù)id（trx_sys->max_trx_id）為11，活躍事務(wù)ID數(shù)組為空胜蛉；

在執(zhí)行第一批日志期間挠进，所有用戶請求構(gòu)建的視圖都具有一樣的結(jié)構(gòu)。即low_limit_id = up_limit_id = 11誊册，本地trx_ids為空领突；

在執(zhí)行完第一批日志后，max_trx_id被被更新成12 + 1案怯，未完成的事務(wù)ID 12加入到全局活躍事務(wù)ID數(shù)組中君旦。

依次類推。該方案是復(fù)制效率和數(shù)據(jù)可見性的一個(gè)權(quán)衡。

注意如果主庫崩潰于宙，那么可能存在事務(wù)存在開始點(diǎn)浮驳，但丟失結(jié)束點(diǎn)的情況，因此主庫在崩潰恢復(fù)后寫入一條特殊的日志捞魁，以告訴所有的備庫去通過遍歷undo slot重新初始化全局事務(wù)狀態(tài)至会。

Purge控制

既然要維持MVCC特性，那么作為一致性讀的重要組成部分的Undo log谱俭，就需要對其進(jìn)行控制奉件，那些仍然可能被讀視圖引用的Undo不應(yīng)該被清理掉。這里我們提供了兩種方式來供用戶選擇：

方案一：控制備庫上的Purge

當(dāng)主庫每次Purge時(shí)昆著，都將當(dāng)前Purge的最老快照寫入redo县貌；備庫在拿到這個(gè)快照后，會(huì)去判斷其和當(dāng)期實(shí)例上活躍的最老視圖是否有可見性上的重疊凑懂，并等待直到這些視圖關(guān)閉煤痕；我們也提供了一個(gè)超時(shí)選項(xiàng)，當(dāng)?shù)却龝r(shí)間過長時(shí)接谨，就直接更新本地Purge視圖摆碉，用戶線程將獲得一個(gè)錯(cuò)誤碼DB_MISSING_HISTORY

這種方案的缺點(diǎn)很明顯：當(dāng)備庫讀負(fù)載很重，或者存在大查詢時(shí)脓豪，備庫可能產(chǎn)生復(fù)制延遲巷帝。

方案二：控制主庫上的Purge，備庫定期向其連接的實(shí)例發(fā)送反饋扫夜，反饋的內(nèi)容為當(dāng)前可安全Purge的最小ID楞泼。如下圖所示：

這種方案的缺點(diǎn)是，犧牲了主庫的Purge效率笤闯，在整個(gè)復(fù)制拓?fù)渖隙槔灰虚L時(shí)間未關(guān)閉的視圖，都有可能引起主庫上的Undo膨脹颗味。

B-TREE結(jié)構(gòu)變更復(fù)制

當(dāng)發(fā)生B-TREE的結(jié)構(gòu)變更時(shí)超陆，例如Page合并或分裂，我們需要禁止用戶線程對btree進(jìn)行檢索脱衙。

解決方案很簡單：當(dāng)主庫上的mtr在commit時(shí)侥猬，如果是持有索引的排他鎖，并且一個(gè)mtr中的變更超過一個(gè)page時(shí)捐韩，則將涉及的索引id寫到日志中退唠；備庫在解析到該日志時(shí)，會(huì)產(chǎn)生一個(gè)同步點(diǎn)：完成已經(jīng)解析的日志荤胁；獲取索引X鎖瞧预；完成日志組Apply；釋放索引X鎖。

復(fù)制Change Buffer

備庫change buffer合并

Change buffer是InnoDB的一種特殊的緩存結(jié)構(gòu)垢油，其本質(zhì)上是一棵存在于ibdata的btree盆驹。當(dāng)修改用戶表空間的二級索引頁時(shí)欢嘿，如果對應(yīng)的page不在內(nèi)存中距帅，該操作將可能被記錄到change buffer中，從而減少了二級索引的隨機(jī)IO侠碧，并達(dá)到了合并更新的效果硝枉。

隨后當(dāng)對應(yīng)的page被讀入內(nèi)存時(shí)廉丽，會(huì)進(jìn)行一次merge操作；后臺(tái)Master線程也會(huì)定期發(fā)起Merge妻味。關(guān)于change buffer本文不做深入正压，感興趣的可以閱讀我之前的這篇月報(bào)（http://mysql.taobao.org/monthly/2015/07/01/?spm=5176.blog49320.yqblogcon1.19.3Jakrz）

然而在備庫，我們需要保證對數(shù)據(jù)不做任何的變更责球，只讀操作不應(yīng)該對物理數(shù)據(jù)產(chǎn)生任何的影響焦履。為了實(shí)現(xiàn)這一點(diǎn)，我們采用了如下方式來解決這個(gè)問題：

1. 當(dāng)將Page讀入內(nèi)存雏逾，如果發(fā)現(xiàn)其需要進(jìn)行ibuf merge嘉裤，則為其分配一個(gè)shadow page，將未修改的數(shù)據(jù)頁保存到其中校套；

2. 將change buffer記錄合并到數(shù)據(jù)頁上价脾，同時(shí)關(guān)閉該Mtr的redo log牧抵，這樣修改后的Page就不會(huì)放到flush list上了笛匙；

3. change buffer bitmap頁和change buffer btree上的頁都不允許產(chǎn)生任何的修改；

4. 當(dāng)數(shù)據(jù)頁從buffer pool驅(qū)逐或者被log apply線程請求時(shí)犀变，shadow page會(huì)被釋放掉妹孙。

另外一個(gè)問題是，主備庫的內(nèi)存狀態(tài)可能是不一樣的获枝，例如一個(gè)Page在主庫上未讀入內(nèi)存蠢正，因此為其緩存到change buffer。但備庫上這個(gè)page已經(jīng)存在于buffer pool了省店。為了保證數(shù)據(jù)一致性嚣崭，在備庫上我們需要將新的change buffer記錄合并到這個(gè)page上。

具體的懦傍，當(dāng)在備庫解析到新的change buffer entry時(shí)雹舀，如果對應(yīng)的Page已經(jīng)在內(nèi)存中了，就對其打個(gè)標(biāo)簽粗俱。隨后用戶線程如果訪問到這個(gè)page说榆，就從shadow page中恢復(fù)出未修改的Page（如果有shadow page），再進(jìn)行一次change buffer合并操作。

復(fù)制change buffer合并

由于一次change buffer merge涉及到ibuf bitmap page签财，二級索引頁串慰，change buffer btree三類，其存在嚴(yán)格的先后關(guān)系唱蒸，而在備庫上邦鲫，我們是并行進(jìn)行日志apply的。為了保證在合并的過程中神汹，用戶線程不能訪問到正在被修改的數(shù)據(jù)頁掂碱。我們增加了新的日志類型：

MLOG_IBUF_MERGE_START ：在主庫上進(jìn)行ibuf merge之前寫入；當(dāng)備庫解析到該日志時(shí)慎冤，apply所有已解析的日志疼燥，獲取對應(yīng)的block，并加上排他鎖蚁堤；如果有shadow page的話醉者，則將未修改的數(shù)據(jù)恢復(fù)出來，并釋放shadow page披诗。

MLOG_IBUF_MERGE_END：在主庫上清除ibuf bitmap page上對應(yīng)位后寫入撬即；備庫解析到時(shí)apply所有已解析的日志并釋放block鎖。

很顯然該方案構(gòu)成了一個(gè)性能瓶頸點(diǎn)呈队，可能會(huì)影響到復(fù)制性能剥槐。后續(xù)再研究下有沒有更完美的解決方案。

Failover

Planned Failover

當(dāng)執(zhí)行計(jì)劃中的切換時(shí)宪摧，我們需要執(zhí)行嚴(yán)格的步驟粒竖，以確保在切換時(shí)所有的實(shí)例處于一致的狀態(tài)。具體的分為4步：

Step1: 主庫上執(zhí)行降級操作几于，狀態(tài)從MASTER修改成UPGRADABLE-SLAVE蕊苗；這里會(huì)退出所有的讀寫事務(wù)，掛起或退出哪些可能修改數(shù)據(jù)的后臺(tái)線程沿彭；同時(shí)一條MLOG_DEMOTE日志寫入到redo文件中朽砰。

Step2: 所有連接的備庫在讀取到MLOG_DEMOTE日志后，將自己的狀態(tài)修改為UPGRADALE-SLAVE喉刘；

Step3: 任意挑選一個(gè)復(fù)制拓?fù)渲械膶?shí)例瞧柔，將其提升為主庫，同時(shí)初始化各種內(nèi)存狀態(tài)值睦裳；并寫入一條類型為MLOG_PROMOTE的日志造锅；

Step4: 所有連接過來的備庫在解析到MLOG_PROMOTE日志后，將自己的狀態(tài)從UPGRADABLE-SLAVE修改成SLAVE

Unplanned Failover

然而多數(shù)情況下推沸，切換都是在意外情況下發(fā)生的备绽，為了減少宕機(jī)時(shí)間券坞，我們需要選擇一個(gè)備庫快速接管用戶負(fù)載。這種場景下需要解決的問題是：老主庫在恢復(fù)訪問后肺素，如何確保和新主庫的狀態(tài)一致恨锚。更具體的說，如果老主庫上還有一部分日志還沒傳送到新主庫倍靡，這部分的不一致數(shù)據(jù)該怎么恢復(fù)猴伶。

我們采用覆蓋寫的方法來解決這一問題：

1. 首先禁止老主庫上所有的訪問，包括查詢塌西；同時(shí)將老主庫降級成備庫他挎；

2. 獲取新主庫切換時(shí)的LSN，然后在老主庫上從這個(gè)LSN開始遍歷redo日志捡需，搜集所有影響到（space id, page no）办桨，如果發(fā)現(xiàn)有DDL操作，則認(rèn)為恢復(fù)失敗站辉，需要從外部第三方工具進(jìn)行比較同步呢撞，或者重做實(shí)例；

3. 從新主庫上獲取到這些page并在本地進(jìn)行覆蓋寫操作饰剥；

4. 完成覆蓋寫后殊霞，將多出來的redo log從磁盤上truncate掉，同時(shí)更新checkpoint信息汰蓉；

5. 恢復(fù)復(fù)制绷蹲，并開啟讀請求。

測試及性能

我們測試了三個(gè)版本的性能：

ALI_RDS_56_redo: 使用物理復(fù)制顾孽，并禁止binlog

ALI_RDS_56: 目前RDS的MySQL版本

MySQL5629: Upstream 5.6.29

測試環(huán)境

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)

來源：數(shù)據(jù)庫內(nèi)核月報(bào)

原文：http://mysql.taobao.org/monthly/2016/05/01/

如有侵權(quán)或不周之處祝钢，敬請勞煩聯(lián)系若飛（微信：1321113940）馬上刪除，謝謝岩齿！

·END·

架構(gòu)師

我們都是架構(gòu)師太颤！