最近有幸前去美國參加Percona Live 2016會議并分享了我們最近在MySQL復制上所做的工作，也就是基于InnoDB的物理復制。會后很多小伙伴私信我說分享的PPT太內(nèi)核了，不太容易理解。因此本文主要針對分享的內(nèi)容進行展開描述，希望能對大家有所幫助。
背景知識
在開始之前，你需要對InnoDB的事務(wù)系統(tǒng)有個基本的認識。如果您不了解，可以參考我之前的幾篇關(guān)于InnoDB的文章，包括InnoDB的事務(wù)子系統(tǒng)，事務(wù)鎖，redo log，undo log，以及崩潰恢復邏輯。在這里我們簡單的概述一下幾個基本的概念：
事務(wù)ID：一個自增的序列號，每次開啟一個讀寫事務(wù)（或者事務(wù)從只讀轉(zhuǎn)換成讀寫模式）時分配并遞增，每更新256次后持久化到Ibdata的事務(wù)系統(tǒng)頁中。每個讀寫事務(wù)都必須保證擁有的ID是唯一的。
Read View:用于一致性讀的snapshot，InnoDB里稱為視圖；在需要一致性讀時開啟一個視圖，記錄當時的事務(wù)狀態(tài)快照，包括當時活躍的事務(wù)ID以及事務(wù)ID的上下水位值，以此用于判斷數(shù)據(jù)的可見性。
Redo Log：用于記錄對物理文件的修改，所有對InnoDB物理文件的修改都需要通過Redo保護起來，這樣才能從崩潰中恢復。
Mini Transaction(mtr)：是InnoDB中修改物理塊的最小原子操作單位，同時也負責生產(chǎn)本地的redo日志，并在提交mtr時將redo日志拷貝到全局log buffer中。
LSN:一個一直在遞增的日志序列號，在InnoDB中代表了從實例安裝到當前已經(jīng)產(chǎn)生的日志總量?？梢酝ㄟ^LSN計算出其在日志文件中的位置。每個block在寫盤時，其最近一次修改的LSN也會記入其中，這樣在崩潰恢復時，無需Apply該LSN之前的日志。
Undo Log:用于存儲記錄被修改之前的舊版本，如果被多次修改，則會產(chǎn)生一個版本鏈。保留舊版本的目的是用于可重復讀。通過結(jié)合Undo和視圖控制來實現(xiàn)InnoDB的MVCC。
Binary Log:構(gòu)建在存儲引擎之上的統(tǒng)一的日志格式；有兩種存儲方式，一種是記錄執(zhí)行的SQL，另外一種是記錄修改的行記錄。Binlog本質(zhì)上是一種邏輯日志，因此能夠適用所有的存儲引擎，并進行數(shù)據(jù)復制。
原生復制的優(yōu)缺點
MySQL的每條讀寫事務(wù)都需要維持兩份日志，一份是redo log，一份是binary log。MySQL使用兩階段提交協(xié)議，只有當redo 和binlog都寫入磁盤時，事務(wù)才算真正的持久化了。如果只寫入redo，未寫入binlog，這樣的事務(wù)在崩潰恢復時需要回滾掉。MySQL通過XID來關(guān)聯(lián)InnoDB的事務(wù)和binlog。
MySQL的原生事務(wù)日志復制有一些顯著的優(yōu)點：
首先，相比InnoDB的redo log而言，Binary Log更加可讀，有成熟的配套工具來進行解析；由于記錄了行級別的更改。我們可以通過解析binlog，轉(zhuǎn)換成DML語句來將數(shù)據(jù)變更同步到異構(gòu)數(shù)據(jù)庫。另外一種典型的做法是使用Binlog來失效構(gòu)建在前端的cache。事實上，基于Binlog的數(shù)據(jù)流服務(wù)在阿里內(nèi)部使用的非常廣泛，也是最重要的基礎(chǔ)設(shè)施之一。
其次由于Binary log是一種統(tǒng)一的日志格式，你可以在主備上使用不同的存儲引擎，例如當你需要測試某種新的存儲引擎時，你可以搭建一個備庫，將所有表alter到新引擎，然后開啟數(shù)據(jù)復制進行觀察。
此外基于Binary Log你還可以構(gòu)建起非常復雜的復制拓撲結(jié)構(gòu)，尤其是在引入了GTID之后，這種優(yōu)勢尤為明顯: 如果設(shè)計妥當，你可以實現(xiàn)相當復雜的復制結(jié)構(gòu)。甚至可以做到多點寫入?？傮w使用起來非常靈活。
然而，也正是這種日志架構(gòu)可能會帶來一些問題：首先MySQL需要記錄兩份日志：redo及binlog，只有當兩份日志都fsync到磁盤，我們才能認為事務(wù)是持久化的，而眾所周知，fsync是一種開銷非常昂貴的操作。更多的日志寫入還增加了磁盤IO壓力。這兩點都會影響到響應(yīng)時間和吞吐量。
Binlog復制還會帶來復制延遲的問題。我們知道只有主庫事務(wù)提交后，日志才會寫入到binlog文件并傳遞到備庫，這意味著備庫至少延遲一個事務(wù)的執(zhí)行時間。另外有些操作例如DDL，大事務(wù)等等，由于在備庫需要繼續(xù)保持事務(wù)完整性，這些執(zhí)行時間很長的操作會長時間占用某個worker線程，而協(xié)調(diào)線程會碰到復制同步點，導致后續(xù)的任務(wù)無法分發(fā)到其他空閑的worker線程。
MySQL是原生復制是MySQL生態(tài)的一個非常重要的組成部分。官方也在積極的改進其特性，例如MySQL5.7在這一塊就有非常顯著的改進。
Why Phsyical Replication
既然原生復制這么成熟，優(yōu)點這么多，為什么我們還要考慮基于物理日志的復制呢？
首先最重要的原因就是性能！當我們事先了物理復制后，就可以關(guān)閉binlog和gtid，大大減少了數(shù)據(jù)寫盤量。這種情況下，最多只需要一次fsync既可以將事務(wù)持久化到磁盤。實例整體的吞吐量和響應(yīng)時間都得到了非常大的提升。
另外，通過物理復制，我們能獲得更加理想的物理復制性能。事務(wù)在執(zhí)行過程中產(chǎn)生的redo log只要寫到文件中，就會被傳送到備庫。這意味著我們可以同時在主備庫上執(zhí)行事務(wù)，而無需等待主庫上執(zhí)行完成。我們可以基于(space_id, page_no)來進行并發(fā)apply，同一個page上的變更也可以做到合并寫操作，相比傳統(tǒng)復制，具有更好的并發(fā)性。最重要的是，基于物理變更的復制，可以最大程度保證主備的數(shù)據(jù)總是一致的。
當然物理復制不是銀彈，當啟用該特性后，我們將只能支持InnoDB存儲引擎；我們也很難去設(shè)計多點寫復制拓撲。物理復制無法取代原生復制，而是應(yīng)對特定的場景，例如需求高并發(fā)DML性能的場景。
因此在正式開始前，我們設(shè)置了這些前提：1.主庫上不應(yīng)該有任何限制； 2.備庫上只允許執(zhí)行查詢操作，不允許通過用戶接口對數(shù)據(jù)產(chǎn)生任何的變更。
下文默認MySQL已包含如下特性：
沒有只讀事務(wù)鏈表，并且不為只讀事務(wù)分配事務(wù)ID
使用全局事務(wù)ID數(shù)組來構(gòu)建read view快照
所有MySQL庫下的系統(tǒng)表都使用InnoDB存儲引擎
High Level Architecture
復制架構(gòu)
這里復制的基礎(chǔ)架構(gòu)和原生復制類似，但代碼是完全獨立的。如下圖所示：
首先，我們在備庫上配置好連接后，執(zhí)行START INNODB SLAVE，備庫上會開啟一個io線程，同時InnoDB層啟動一個Log Apply協(xié)調(diào)線程以及多個worker線程。
IO線程建立和主庫的連接，并發(fā)送一個dump請求，請求的內(nèi)容包括：
master_uuid: 最近備庫上日志最初產(chǎn)生所在的實例的server_uuid
start_lsn: 開始復制的點
在主庫上，一個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ù)fold(space id ,page no)% (n_workers + 1)進行分發(fā)，系統(tǒng)表空間的變更存放到sys hash中，用戶表空間的變更存儲到user hash中。協(xié)調(diào)線程在解析&&分發(fā)完畢后，也會參與到日志apply中。
當Apply日志時，我們總是先應(yīng)用系統(tǒng)表空間，再是用戶表空間。原因是我們需要保證undo日志先應(yīng)用，否則外部查詢檢索用戶表的btree，試圖通過回滾段指針查詢undo page，可能對應(yīng)的Undo還沒構(gòu)成。
日志文件管理
要實現(xiàn)上述架構(gòu)，第一個要解決的問題是需要重新整理InnoDB的日志文件。 因為原生邏輯中，InnoDB采用循環(huán)寫文件的方式，例如當我們設(shè)置innodb_log_files_in_group為4時，會創(chuàng)建4個ib logfile文件。當?shù)谒膫€文件寫滿時，會回到第一個文件循環(huán)寫入。但是在物理復制架構(gòu)下，我們需要保留老的日志文件，這些文件既可以防止例如網(wǎng)絡(luò)出現(xiàn)問題，日志未曾及時傳送到備庫，也可以用于備份目的。
我們像binlog那樣，當當前日志文件寫滿時，則切換到下一個日志文件，文件的序號總是向前遞增的。然而這里需要解決的一個問題是：切換文件需要盡量減小對性能的影響，我們引入了獨立的后臺線程，并允許已被清理的日志文件重用。
和binlog類似，我們也需要清理已經(jīng)沒用的日志文件，既需要提供接口，由用戶手動清理，也可以開啟后臺線程自動判斷并進行清理，但兩種方案都需要滿足條件：
1. 不允許超過當前checkpoint所在的文件
2. 如果有正在連接的備庫，則不允許清理尚未傳送到備庫的日志
文件架構(gòu)如下圖所示：
這里我們增加了一個新的文件ib_checkpoint，原因是原生邏輯中，checkpoint信息是存儲在ib_logfile0中的，而在新的架構(gòu)下，該文件可能被刪除掉，我們需要單獨對checkpoint信息進行存儲，包含checkpoint no, checkpoint lsn, 以及該Lsn所在的日志文件號及文件內(nèi)偏移量。
后臺清理線程被稱為log purge thread，當該線程被喚醒被執(zhí)行清理操作時，將目標日志文件rename到以purged作為前綴，并放到一個回收池中，如果池子滿了，則直接刪除掉。
為了避免日志切換到新文件時造成的性能抖動，后臺log file allocate線程總是預(yù)先將下一個文件準備好，也就是說，當前正在寫第N個文件，后臺線程會被喚醒，并創(chuàng)建好第N+1個文件。這樣對前臺線程的影響僅僅是關(guān)閉并打開新文件句柄。
log file allocate線程在準備下一個文件時，先嘗試從回收池中獲取文件，并進行必要的判斷（確保下一個文件開始的LSN轉(zhuǎn)換成block no后不和文件內(nèi)的內(nèi)容重疊），如果可以使用，則直接取出來并rename為下一個文件名。如果回收池無可用文件，則創(chuàng)建文件，并extend到指定的大小。通過這種方式，我們盡量保證了性能的平緩。
實例角色
和原生復制不同，對于備庫，我們總是不允許做任何的數(shù)據(jù)變更，這種行為不受是否重啟，是否崩潰而影響，只受failover影響。一臺備庫無論重啟多少次總是為備庫。
日志最初產(chǎn)生的服務(wù)器我們稱為日志源實例。日志可能通過復雜的復制拓撲傳遞到多級級聯(lián)實例上。但所有的這些備庫都應(yīng)具有相同的源實例信息。我們需要通過這個信息來判斷一個dump請求是否是合法的，例如作為備庫，所有dump的日志都應(yīng)產(chǎn)自同一個日志源實例，除非在復制拓撲中發(fā)生了failover。
我們?yōu)閷嵗x了三種狀態(tài)：master, slave,以及upgradable-slave;其中第三種是一種中間狀態(tài)，只在failover時產(chǎn)生。
這些狀態(tài)信息被持久化到本地文件innodb_repl.info文件中。同時也單獨存儲了日志源實例的server_uuid。
我們以下圖為例：
server 1的uuid為1，和文件中記錄的uuid相同，因此認為該實例為master;
server 2的uuid為2，和文件中記錄的uuid不同，因為該實例為slave;
server 3的uuid為3，但文件中記錄的值為0，表明最近剛發(fā)生過一次failover（server 1 和server 2發(fā)生過一次切換），但還沒來得及獲取到切換日志，因此該實例角色為upgradable-slave
innodb_repl.info文件維持了所有的復制和failover狀態(tài)信息，很顯然，如果我們想從已有的拓撲中restore出一個新的實例，對應(yīng)的innodb_repl.info文件也要拷貝出來。
后臺線程
有些后臺線程可能對數(shù)據(jù)產(chǎn)生變更，因此在備庫上我們需要禁止這些線程：
1. 不允許開啟Purge線程
2. master線程不允許去做ibuf merge之類的工作，只負責定期做lazy checkpoint
3. dict_stats線程只負責更新表的內(nèi)存統(tǒng)計信息，不可以觸發(fā)統(tǒng)計信息的物理存儲。
此外備庫的page cleaner線程的刷臟算法也需要重新調(diào)整以盡量平緩，不要影響到日志apply。
MySQL Server層數(shù)據(jù)復制
文件操作復制
為了實現(xiàn)Server-Engine的架構(gòu)，MySQL在Server層另外冗余了一些元數(shù)據(jù)信息，以在存儲引擎之上建立統(tǒng)一的標準。這些元數(shù)據(jù)文件包括FRM，PAR，DB.OPT，TRG，TRN以及代表數(shù)據(jù)庫的目錄。對這些文件和目錄的操作都沒有寫到redo中。
為了能夠?qū)崿F(xiàn)文件層的操作，我們需要將文件變更操作寫到日志中，主要擴展了三種新的日志類型：
MLOG_METAFILE_CREATE: [FIL_NAME | CONTENT]
MLOG_METAFILE_RENAME: [ORIGINAL_NAME | TARGET_NAME]
MLOG_METAFILE_DELETE: [FIL_NAME]
這里包含了三種操作，文件的創(chuàng)建，重命名及刪除。注意這里沒有修改文件操作，原因是Server層總是通過創(chuàng)建新文件，刪除舊文件的方式來進行元數(shù)據(jù)更新。
DDL復制
當MySQL在執(zhí)行DDL修改元數(shù)據(jù)時，是不允許訪問表空間的，否則可能導致各種異常錯誤。MySQL使用排他的MDL鎖來阻塞用戶訪問。我們需要在備庫保持相同的行為。這就需要識別修改元數(shù)據(jù)的起點和結(jié)束點。我們引入兩類日志來進行標識。
舉個簡單的例子:
執(zhí)行： CREATE TABLE t1 (a INT PRIMARY KEY, b INT);舉個簡單的例子:
從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ù)修改開始點和結(jié)束點所代表的兩個日志并不是原子的，這意味著主庫上在修改元數(shù)據(jù)的過程中如果crash了，就會丟失后面的結(jié)束標記。備庫可能一直持有這個表上的MDL鎖無法釋放。為了解決這個問題，我們在主庫每次崩潰恢復后，都寫一條特殊的日志，通知所有連接的備庫釋放其持有的所有MDL排他鎖。
另外一個問題存在于備庫，舉個例子，執(zhí)行MLOG_METACHANGE_START后，做一次checkpoint，在接受到MLOG_METACHANGE_END之前crash。當備庫實例從崩潰中恢復時，需要能夠繼續(xù)保持MDL鎖，避免用戶訪問。
為了能夠恢復MDL，首先我們需要控制checkpoint的LSN，保證不超過所有未完成元數(shù)據(jù)變更的最老的開始點；其次，在重啟時搜集未完成元數(shù)據(jù)變更的表名，并在崩潰恢復完成后依次把MDL 排他鎖加上。
Cache失效
在Server層還維護了一些Cache結(jié)構(gòu)，然而數(shù)據(jù)的更新是體現(xiàn)在物理層的，備庫在應(yīng)用完redo后，需要感知到哪些Cache是需要進行更新的，目前來看主要有以下幾種情況：
1. 權(quán)限操作，備庫上需要進行ACL Reload，才能讓新的權(quán)限生效；
2. 存儲過程操作，例如增刪存儲過程，在備庫需要遞增一個版本號，以告訴用戶線程重新載入cache；
3. 表級統(tǒng)計信息，主庫上通過更新的行的數(shù)量來觸發(fā)表統(tǒng)計信息更新；但在備庫上，所有的變更都是基于塊級別的，并不能感知到變化了多少行。因此每次主庫更新統(tǒng)計信息時同時寫一條日志到redo中，通知備庫進行內(nèi)存統(tǒng)計信息更新。
備庫MVCC
視圖控制
備庫一致性讀的最基本要求是用戶線程不應(yīng)該看到主庫上尚未執(zhí)行完成的事務(wù)所產(chǎn)生的變更。換句話說，當備庫上開啟一個read view時，在該時間點，如果有尚未提交的事務(wù)變更，這些變更應(yīng)該是不可見的。
基于此，我們需要知道一個事務(wù)的開始點和結(jié)束點。我們增加了兩種日志來進行標示：
MLOG_TRX_START：在主庫上為一個讀寫事務(wù)分配事務(wù)ID后，同時生成一條日志，日志中記錄了該ID的值；由于是持有trx_sys->mutex鎖生成的日志記錄，因此保證寫入redo的事務(wù)ID是有序的。
MLOG_TRX_COMMIT：在事務(wù)提交階段，標記undo狀態(tài)為提交后，寫入該類型日志，記錄對應(yīng)事務(wù)的事務(wù)ID
在備庫上，我們通過這兩類日志來重現(xiàn)事務(wù)場景，具體的我們采用一種延遲構(gòu)建的方式：只有在完成apply一批日志后才對全局事務(wù)狀態(tài)進行更新：
1. 在apply一批日志時，選擇其中最大的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ù)組中。
依次類推。該方案是復制效率和數(shù)據(jù)可見性的一個權(quán)衡。
注意如果主庫崩潰，那么可能存在事務(wù)存在開始點，但丟失結(jié)束點的情況，因此主庫在崩潰恢復后寫入一條特殊的日志，以告訴所有的備庫去通過遍歷undo slot重新初始化全局事務(wù)狀態(tài)。
Purge控制
既然要維持MVCC特性，那么作為一致性讀的重要組成部分的Undo log，就需要對其進行控制，那些仍然可能被讀視圖引用的Undo不應(yīng)該被清理掉。這里我們提供了兩種方式來供用戶選擇：
方案一：控制備庫上的Purge
當主庫每次Purge時，都將當前Purge的最老快照寫入redo；備庫在拿到這個快照后，會去判斷其和當期實例上活躍的最老視圖是否有可見性上的重疊，并等待直到這些視圖關(guān)閉；我們也提供了一個超時選項，當?shù)却龝r間過長時，就直接更新本地Purge視圖，用戶線程將獲得一個錯誤碼DB_MISSING_HISTORY
這種方案的缺點很明顯：當備庫讀負載很重，或者存在大查詢時，備庫可能產(chǎn)生復制延遲。
方案二：控制主庫上的Purge，備庫定期向其連接的實例發(fā)送反饋，反饋的內(nèi)容為當前可安全Purge的最小ID。如下圖所示：
這種方案的缺點是，犧牲了主庫的Purge效率，在整個復制拓撲上，只要有長時間未關(guān)閉的視圖，都有可能引起主庫上的Undo膨脹。
B-TREE結(jié)構(gòu)變更復制
當發(fā)生B-TREE的結(jié)構(gòu)變更時，例如Page合并或分裂，我們需要禁止用戶線程對btree進行檢索。
解決方案很簡單：當主庫上的mtr在commit時，如果是持有索引的排他鎖，并且一個mtr中的變更超過一個page時，則將涉及的索引id寫到日志中；備庫在解析到該日志時，會產(chǎn)生一個同步點：完成已經(jīng)解析的日志；獲取索引X鎖；完成日志組Apply；釋放索引X鎖。
復制Change Buffer
備庫change buffer合并
Change buffer是InnoDB的一種特殊的緩存結(jié)構(gòu)，其本質(zhì)上是一棵存在于ibdata的btree。當修改用戶表空間的二級索引頁時，如果對應(yīng)的page不在內(nèi)存中，該操作將可能被記錄到change buffer中，從而減少了二級索引的隨機IO，并達到了合并更新的效果。
隨后當對應(yīng)的page被讀入內(nèi)存時，會進行一次merge操作；后臺Master線程也會定期發(fā)起Merge。關(guān)于change buffer本文不做深入，感興趣的可以閱讀我之前的這篇月報（http://mysql.taobao.org/monthly/2015/07/01/?spm=5176.blog49320.yqblogcon1.19.3Jakrz）
然而在備庫，我們需要保證對數(shù)據(jù)不做任何的變更，只讀操作不應(yīng)該對物理數(shù)據(jù)產(chǎn)生任何的影響。為了實現(xiàn)這一點，我們采用了如下方式來解決這個問題：
1. 當將Page讀入內(nèi)存，如果發(fā)現(xiàn)其需要進行ibuf merge，則為其分配一個shadow page，將未修改的數(shù)據(jù)頁保存到其中；
2. 將change buffer記錄合并到數(shù)據(jù)頁上，同時關(guān)閉該Mtr的redo log，這樣修改后的Page就不會放到flush list上了；
3. change buffer bitmap頁和change buffer btree上的頁都不允許產(chǎn)生任何的修改；
4. 當數(shù)據(jù)頁從buffer pool驅(qū)逐或者被log apply線程請求時，shadow page會被釋放掉。
另外一個問題是，主備庫的內(nèi)存狀態(tài)可能是不一樣的，例如一個Page在主庫上未讀入內(nèi)存，因此為其緩存到change buffer。但備庫上這個page已經(jīng)存在于buffer pool了。為了保證數(shù)據(jù)一致性，在備庫上我們需要將新的change buffer記錄合并到這個page上。
具體的，當在備庫解析到新的change buffer entry時，如果對應(yīng)的Page已經(jīng)在內(nèi)存中了，就對其打個標簽。隨后用戶線程如果訪問到這個page，就從shadow page中恢復出未修改的Page（如果有shadow page），再進行一次change buffer合并操作。
復制change buffer合并
由于一次change buffer merge涉及到ibuf bitmap page，二級索引頁，change buffer btree三類，其存在嚴格的先后關(guān)系，而在備庫上，我們是并行進行日志apply的。為了保證在合并的過程中，用戶線程不能訪問到正在被修改的數(shù)據(jù)頁。我們增加了新的日志類型：
MLOG_IBUF_MERGE_START ：在主庫上進行ibuf merge之前寫入；當備庫解析到該日志時，apply所有已解析的日志，獲取對應(yīng)的block，并加上排他鎖；如果有shadow page的話，則將未修改的數(shù)據(jù)恢復出來，并釋放shadow page。
MLOG_IBUF_MERGE_END：在主庫上清除ibuf bitmap page上對應(yīng)位后寫入；備庫解析到時apply所有已解析的日志并釋放block鎖。
很顯然該方案構(gòu)成了一個性能瓶頸點，可能會影響到復制性能。后續(xù)再研究下有沒有更完美的解決方案。
Failover
Planned Failover
當執(zhí)行計劃中的切換時，我們需要執(zhí)行嚴格的步驟，以確保在切換時所有的實例處于一致的狀態(tài)。具體的分為4步：
Step1: 主庫上執(zhí)行降級操作，狀態(tài)從MASTER修改成UPGRADABLE-SLAVE；這里會退出所有的讀寫事務(wù)，掛起或退出哪些可能修改數(shù)據(jù)的后臺線程；同時一條MLOG_DEMOTE日志寫入到redo文件中。
Step2: 所有連接的備庫在讀取到MLOG_DEMOTE日志后，將自己的狀態(tài)修改為UPGRADALE-SLAVE；
Step3: 任意挑選一個復制拓撲中的實例，將其提升為主庫，同時初始化各種內(nèi)存狀態(tài)值；并寫入一條類型為MLOG_PROMOTE的日志；
Step4: 所有連接過來的備庫在解析到MLOG_PROMOTE日志后，將自己的狀態(tài)從UPGRADABLE-SLAVE修改成SLAVE
Unplanned Failover
然而多數(shù)情況下，切換都是在意外情況下發(fā)生的，為了減少宕機時間，我們需要選擇一個備庫快速接管用戶負載。這種場景下需要解決的問題是：老主庫在恢復訪問后，如何確保和新主庫的狀態(tài)一致。更具體的說，如果老主庫上還有一部分日志還沒傳送到新主庫，這部分的不一致數(shù)據(jù)該怎么恢復。
我們采用覆蓋寫的方法來解決這一問題：
1. 首先禁止老主庫上所有的訪問，包括查詢；同時將老主庫降級成備庫；
2. 獲取新主庫切換時的LSN，然后在老主庫上從這個LSN開始遍歷redo日志，搜集所有影響到（space id, page no），如果發(fā)現(xiàn)有DDL操作，則認為恢復失敗，需要從外部第三方工具進行比較同步，或者重做實例；
3. 從新主庫上獲取到這些page并在本地進行覆蓋寫操作；
4. 完成覆蓋寫后，將多出來的redo log從磁盤上truncate掉，同時更新checkpoint信息；
5. 恢復復制，并開啟讀請求。
測試及性能
我們測試了三個版本的性能：
ALI_RDS_56_redo: 使用物理復制，并禁止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)核月報
原文：http://mysql.taobao.org/monthly/2016/05/01/
如有侵權(quán)或不周之處，敬請勞煩聯(lián)系若飛（微信：1321113940）馬上刪除，謝謝！
·END·
架構(gòu)師
我們都是架構(gòu)師！
