MySQL是一種關(guān)系數(shù)據(jù)庫管理系統(tǒng)幢码，關(guān)系數(shù)據(jù)庫將數(shù)據(jù)保存在不同的表中恼琼，而不是將所有數(shù)據(jù)放在一個大倉庫內(nèi)唠摹，這樣就增加了速度并提高了靈活性魂务。
MySQL所使用的 SQL 語言是用于訪問數(shù)據(jù)庫的最常用標準化語言。MySQL 軟件采用了雙授權(quán)政策考阱，分為社區(qū)版和商業(yè)版翠忠，由于其體積小、速度快乞榨、總體擁有成本低秽之，尤其是開放源碼這一特點当娱，一般中小型網(wǎng)站的開發(fā)都選擇MySQL 作為網(wǎng)站數(shù)據(jù)庫。
在這篇文章政溃，小編要跟大家介紹的是在MySQL面試中的一些題目和答案：
1.mysql的復(fù)制原理以及流程趾访。
（1） 先問基本原理流程态秧，3 個線程以及之間的關(guān)聯(lián)董虱。
MySQL 的復(fù)制原理：Master 上面事務(wù)提交時會將該事務(wù)的 binlog event 寫入binlog file,然后 master 將 binlog event 傳到 slave 上面，slave 應(yīng)用該 binlog event 實現(xiàn)邏輯復(fù)制申鱼。MySQL 的復(fù)制是基于如下 3 個線程的交互（多線程復(fù)制里面應(yīng)該是 4 類線程）：
a. Master 上面的 binlog dump 線程愤诱，該線程負責將 master 的 binlog event 傳到slave；
b. Slave 上面的 IO 線程捐友，該線程負責接收 Master 傳過來的 binlog淫半，并寫入 relay log；
c. Slave 上面的 SQL 線程匣砖，該線程負責讀取 relay log 并執(zhí)行科吭；
d. 如果是多線程復(fù)制，無論是 5.6 庫級別的假多線程還是 MariaDB 或者 5.7 的真正的多線程復(fù)制猴鲫，SQL 線程只做 coordinator对人，只負責把 relay log 中的 binlog讀出來然后交給worker 線程，woker 線程負責具體 binlog event 的執(zhí)行拂共；
（2） 再問一致性延時性牺弄，數(shù)據(jù)恢復(fù)。
一致性可以從以下幾個方面來講：
a.在 MySQL5.5 以及之前宜狐，slave 的 SQL 線程執(zhí)行的 relay log 的位置只能保存在文件（relay-log.info）里面势告，并且該文件默認每執(zhí)行 10000 次事務(wù)做一次同步到磁盤，這意味著 slave 意外 crash 重啟時抚恒，SQL 線程執(zhí)行到的位置和數(shù)據(jù)庫的數(shù)據(jù)是不一致的咱台，將導(dǎo)致復(fù)制報錯，如果不重搭復(fù)制俭驮，則有可能會導(dǎo)致數(shù)據(jù)不一致回溺。MySQL 5.6 引入?yún)?shù) relay_log_info_repository，將該參
數(shù)設(shè)置為TABLE 時表鳍，MySQL 將 SQL 線程執(zhí)行到的位置存到mysql.slave_relay_log_info 表馅而，這樣更新該表的位置和 SQL 線程執(zhí)行的用戶事務(wù)綁定成一個事務(wù)，這樣slave 意外宕機后譬圣，slave 通過 innodb 的崩潰恢復(fù)可以把SQL 線程執(zhí)行到的位置和用戶事務(wù)恢復(fù)到一致性的狀態(tài)瓮恭。
b. MySQL 5.6 引入 GTID 復(fù)制，每個 GTID 對應(yīng)的事務(wù)在每個實例上面最多執(zhí)行一次厘熟，這極大地提高了復(fù)制的數(shù)據(jù)一致性屯蹦；
c. MySQL 5.5 引入半同步復(fù)制维哈，用戶安裝半同步復(fù)制插件并且開啟參數(shù)后，設(shè)置超時時間登澜，可保證在超時時間內(nèi)如果binlog 不傳到 slave 上面阔挠，那么用戶提交事務(wù)時不會返回，直到超時后切成異步復(fù)制脑蠕，但是如果切成異步之前用戶線程提交時在master 上面等待的時候购撼，事務(wù)已經(jīng)提交，該事務(wù)對 master資源由www.eimhe.com 美河學習在線收集提供上面的其他 session 是可見的谴仙，如果這時 master 宕機迂求，那么到 slave 上面該事務(wù)又不可見了，該問題直到 5.7 才解決晃跺；
d. MySQL 5.7 引入無損半同步復(fù)制揩局，引入?yún)?rpl_semi_sync_master_wait_point，該參數(shù)默認為 after_sync掀虎，指的是在切成半同步之前凌盯，事務(wù)不提交，而是接收到 slave 的 ACK 確認之后才提交該事務(wù)烹玉，從此驰怎，復(fù)制真正可以做到無損的了。
e.可以再說一下 5.7 的無損復(fù)制情況下春霍，master 意外宕機砸西，重啟后發(fā)現(xiàn)有 binlog沒傳到 slave 上面，這部分 binlog 怎么辦址儒？芹枷？？分 2 種情況討論莲趣，1 宕機時已經(jīng)切成異步了鸳慈，2 是宕機時還沒切成異步？喧伞？走芋？這個怎么判斷宕機時有沒有切成異步呢？潘鲫？翁逞？分別怎么處理？溉仑？挖函？
延時性：
可以講下5.5 是單線程復(fù)制，5.6 是多庫復(fù)制（對于單庫或者單表的并發(fā)操作是沒用的）浊竟，5.7 是真正意義的多線程復(fù)制怨喘，它的原理是基于 group commit津畸，只要master 上面的事務(wù)是 group commit 的，那 slave 上面也可以通過多個 worker線程去并發(fā)執(zhí)行必怜。和 MairaDB10.0.0.5 引入多線程復(fù)制的原理基本一樣肉拓。數(shù)據(jù)恢復(fù)？梳庆？暖途？他想問什么？靠益？丧肴？
（3）再問各種工作遇到的復(fù)制 bug 的解決方法
復(fù)制的bug残揉？胧后？？上面說的算嗎抱环？我還真沒遇到過壳快，5.6 的多庫復(fù)制有時候自己會停止，我們寫了一個腳本重新 start slave;待補充…
這篇文章中小編只列舉的一個個例子镇草，大家要是覺得有用的話可以關(guān)注公眾號“鯨魚湖南”眶痰，回復(fù)“MySQL面試題”或者“干貨”，小編會發(fā)送給大家一全套的MySQL面試題解梯啤。
