事務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在這一塊就有非常顯著的改進。
既然原生複制這麼成熟，優點這麼多，為什麼我們還要考慮基于實體日志的複制呢？
首先最重要的原因就是性能！當我們事先了實體複制後，就可以關閉binlog和gtid，大大減少了資料寫盤量。這種情況下，最多隻需要一次fsync既可以将事務持久化到磁盤。執行個體整體的吞吐量和響應時間都得到了非常大的提升。
另外，通過實體複制，我們能獲得更加理想的實體複制性能。事務在執行過程中産生的redo log隻要寫到檔案中，就會被傳送到備庫。這意味着我們可以同時在主備庫上執行事務，而無需等待主庫上執行完成。我們可以基于(space_id, page_no)來進行并發apply，同一個page上的變更也可以做到合并寫操作，相比傳統複制，具有更好的并發性。最重要的是，基于實體變更的複制，可以最大程度保證主備的資料總是一緻的。
當然實體複制不是銀彈，當啟用該特性後，我們将隻能支援innodb存儲引擎；我們也很難去設計多點寫複制拓撲。實體複制無法取代原生複制，而是應對特定的場景，例如需求高并發dml性能的場景。
是以在正式開始前，我們設定了這些前提：1.主庫上不應該有任何限制； 2.備庫上隻允許執行查詢操作，不允許通過使用者接口對資料産生任何的變更。
下文預設mysql已包含如下特性：
沒有隻讀事務連結清單，并且不為隻讀事務配置設定事務id
使用全局事務id數組來建構read view快照
所有mysql庫下的系統表都使用innodb存儲引擎
這裡複制的基礎架構和原生複制類似，但代碼是完全獨立的。如下圖所示：
首先，我們在備庫上配置好連接配接後，執行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。
為了實作server-engine的架構，mysql在server層另外備援了一些中繼資料資訊，以在存儲引擎之上建立統一的标準。這些中繼資料檔案包括frm，par，db.opt，trg，trn以及代表資料庫的目錄。對這些檔案和目錄的操作都沒有寫到redo中。
為了能夠實作檔案層的操作，我們需要将檔案變更操作寫到日志中，主要擴充了三種新的日志類型：
這裡包含了三種操作，檔案的建立，重命名及删除。注意這裡沒有修改檔案操作，原因是server層總是通過建立新檔案，删除舊檔案的方式來進行中繼資料更新。
當mysql在執行ddl修改中繼資料時，是不允許通路表空間的，否則可能導緻各種異常錯誤。mysql使用排他的mdl鎖來阻塞使用者通路。我們需要在備庫保持相同的行為。這就需要識别修改中繼資料的起點和結束點。我們引入兩類日志來進行辨別。
name
write on master
apply on slave
mlog_metachange_begin
在擷取mdl鎖，修改中繼資料之前寫入
擷取表上的顯式排他mdl鎖，同時失效該表的所有table cache對象
mlog_metachange_end
在釋放mdl鎖之前寫入
釋放表上的mdl鎖
舉個簡單的例子:
然而中繼資料修改開始點和結束點所代表的兩個日志并不是原子的，這意味着主庫上在修改中繼資料的過程中如果crash了，就會丢失後面的結束标記。備庫可能一直持有這個表上的mdl鎖無法釋放。為了解決這個問題，我們在主庫每次崩潰恢複後，都寫一條特殊的日志，通知所有連接配接的備庫釋放其持有的所有mdl排他鎖。
另外一個問題存在于備庫，舉個例子，執行mlog_metachange_start後，做一次checkpoint，在接受到mlog_metachange_end之前crash。當備庫執行個體從崩潰中恢複時，需要能夠繼續保持mdl鎖，避免使用者通路。
為了能夠恢複mdl，首先我們需要控制checkpoint的lsn，保證不超過所有未完成中繼資料變更的最老的開始點；其次，在重新開機時搜集未完成中繼資料變更的表名，并在崩潰恢複完成後依次把mdl 排他鎖加上。
在server層還維護了一些cache結構，然而資料的更新是展現在實體層的，備庫在應用完redo後，需要感覺到哪些cache是需要進行更新的，目前來看主要有以下幾種情況：
1. 權限操作，備庫上需要進行acl reload，才能讓新的權限生效；
2. 存儲過程操作，例如增删存儲過程，在備庫需要遞增一個版本号，以告訴使用者線程重新載入cache；
3. 表級統計資訊，主庫上通過更新的行的數量來觸發表統計資訊更新；但在備庫上，所有的變更都是基于塊級别的，并不能感覺到變化了多少行。是以每次主庫更新統計資訊時同時寫一條日志到redo中，通知備庫進行記憶體統計資訊更新。
備庫一緻性讀的最基本要求是使用者線程不應該看到主庫上尚未執行完成的事務所産生的變更。換句話說，當備庫上開啟一個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重新初始化全局事務狀态。
既然要維持mvcc特性，那麼作為一緻性讀的重要組成部分的undo log，就需要對其進行控制，那些仍然可能被讀視圖引用的undo不應該被清理掉。這裡我們提供了兩種方式來供使用者選擇：
方案一：控制備庫上的purge
當主庫每次purge時，都将目前purge的最老快照寫入redo；備庫在拿到這個快照後，會去判斷其和當期執行個體上活躍的最老視圖是否有可見性上的重疊，并等待直到這些視圖關閉；我們也提供了一個逾時選項，當等待時間過長時，就直接更新本地purge視圖，使用者線程将獲得一個錯誤碼db_missing_history
這種方案的缺點很明顯：當備庫讀負載很重，或者存在大查詢時，備庫可能産生複制延遲。
方案二：控制主庫上的purge，備庫定期向其連接配接的執行個體發送回報，回報的内容為目前可安全purge的最小id。如下圖所示：
這種方案的缺點是，犧牲了主庫的purge效率，在整個複制拓撲上，隻要有長時間未關閉的視圖，都有可能引起主庫上的undo膨脹。
當發生b-tree的結構變更時，例如page合并或分裂，我們需要禁止使用者線程對btree進行檢索。
解決方案很簡單：當主庫上的mtr在commit時，如果是持有索引的排他鎖，并且一個mtr中的變更超過一個page時，則将涉及的索引id寫到日志中；備庫在解析到該日志時，會産生一個同步點：完成已經解析的日志；擷取索引x鎖；完成日志組apply；釋放索引x鎖。
change buffer是innodb的一種特殊的緩存結構，其本質上是一棵存在于ibdata的btree。當修改使用者表空間的二級索引頁時，如果對應的page不在記憶體中，該操作将可能被記錄到change buffer中，進而減少了二級索引的随機io，并達到了合并更新的效果。
然而在備庫，我們需要保證對資料不做任何的變更，隻讀操作不應該對實體資料産生任何的影響。為了實作這一點，我們采用了如下方式來解決這個問題：
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 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鎖。
很顯然該方案構成了一個性能瓶頸點，可能會影響到複制性能。後續再研究下有沒有更完美的解決方案。
當執行計劃中的切換時，我們需要執行嚴格的步驟，以確定在切換時所有的執行個體處于一緻的狀态。具體的分為4步：
step1: 主庫上執行降級操作，狀态從master修改成upgradable-slave；這裡會退出所有的讀寫事務，挂起或退出哪些可能修改資料的背景線程；同時一條mlog_demote日志寫入到redo檔案中。
step2: 所有連接配接的備庫在讀取到mlog_demote日志後，将自己的狀态修改為upgradale-slave；
step3: 任意挑選一個複制拓撲中的執行個體，将其提升為主庫，同時初始化各種記憶體狀态值；并寫入一條類型為mlog_promote的日志；
step4: 所有連接配接過來的備庫在解析到mlog_promote日志後，将自己的狀态從upgradable-slave修改成slave
然而多數情況下，切換都是在意外情況下發生的，為了減少當機時間，我們需要選擇一個備庫快速接管使用者負載。這種場景下需要解決的問題是：老主庫在恢複通路後，如何確定和新主庫的狀态一緻。更具體的說，如果老主庫上還有一部分日志還沒傳送到新主庫，這部分的不一緻資料該怎麼恢複。
我們采用覆寫寫的方法來解決這一問題：
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)