接上篇！！！
5. MySQL的復制原理以及流程
主從復制：將主數據庫中的DDL和DML操作通過二進制日志（BINLOG）傳輸到從數據庫上，然后將這些日志重新執行（重做）；從而使得從數據庫的數據與主數據庫保持一致。
主從復制的作用
主數據庫出現問題，可以切換到從數據庫。
可以進行數據庫層面的讀寫分離。
可以在從數據庫上進行日常備份。
MySQL主從復制解決的問題
數據分布：隨意開始或停止復制，并在不同地理位置分布數據備份
負載均衡：降低單個服務器的壓力
高可用和故障切換：幫助應用程序避免單點失敗
升級測試：可以用更高版本的MySQL作為從庫
MySQL主從復制工作原理
在主庫上把數據更高記錄到二進制日志
從庫將主庫的日志復制到自己的中繼日志
從庫讀取中繼日志的事件，將其重放到從庫數據中
基本原理流程，3個線程以及之間的關聯
主：binlog線程——記錄下所有改變了數據庫數據的語句，放進master上的binlog中；
從：io線程——在使用start slave 之后，負責從master上拉取 binlog 內容，放進自己的relay log中；
從：sql執行線程——執行relay log中的語句；
復制過程
Binary log：主數據庫的二進制日志
Relay log：從服務器的中繼日志
第一步：master在每個事務更新數據完成之前，將該操作記錄串行地寫入到binlog文件中。
第二步：salve開啟一個I/O Thread，該線程在master打開一個普通連接，主要工作是binlog dump process。如果讀取的進度已經跟上了master，就進入睡眠狀態并等待master產生新的事件。I/O線程最終的目的是將這些事件寫入到中繼日志中。
第三步：SQL Thread會讀取中繼日志，并順序執行該日志中的SQL事件，從而與主數據庫中的數據保持一致。
6. 讀寫分離有哪些解決方案？
讀寫分離是依賴于主從復制，而主從復制又是為讀寫分離服務的。因為主從復制要求slave不能寫只能讀（如果對slave執行寫操作，那么show slave status將會呈現Slave_SQL_Running=NO，此時你需要按照前面提到的手動同步一下slave）。
方案一
使用mysql-proxy代理
優點：直接實現讀寫分離和負載均衡，不用修改代碼，master和slave用一樣的帳號，mysql官方不建議實際生產中使用
缺點：降低性能， 不支持事務
方案二
使用AbstractRoutingDataSource+aop+annotation在dao層決定數據源。
如果采用了mybatis， 可以將讀寫分離放在ORM層，比如mybatis可以通過mybatis plugin攔截sql語句，所有的insert/update/delete都訪問master庫，所有的select 都訪問salve庫，這樣對于dao層都是透明。plugin實現時可以通過注解或者分析語句是讀寫方法來選定主從庫。不過這樣依然有一個問題， 也就是不支持事務， 所以我們還需要重寫一下DataSourceTransactionManager， 將read-only的事務扔進讀庫， 其余的有讀有寫的扔進寫庫。
方案三
使用AbstractRoutingDataSource+aop+annotation在service層決定數據源，可以支持事務.
缺點：類內部方法通過this.xx()方式相互調用時，aop不會進行攔截，需進行特殊處理。
7. 備份計劃，mysqldump以及xtranbackup的實現原理
(1)備份計劃
視庫的大小來定，一般來說 100G 內的庫，可以考慮使用 mysqldump 來做，因為 mysqldump更加輕巧靈活，備份時間選在業務低峰期，可以每天進行都進行全量備份(mysqldump 備份出來的文件比較小，壓縮之后更小)。
100G 以上的庫，可以考慮用 xtranbackup 來做，備份速度明顯要比 mysqldump 要快。一般是選擇一周一個全備，其余每天進行增量備份，備份時間為業務低峰期。
(2)備份恢復時間
物理備份恢復快，邏輯備份恢復慢
這里跟機器，尤其是硬盤的速率有關系，以下列舉幾個僅供參考
20G的2分鐘（mysqldump）
80G的30分鐘(mysqldump)
111G的30分鐘（mysqldump)
288G的3小時（xtra)
3T的4小時（xtra)
邏輯導入時間一般是備份時間的5倍以上
(3)備份恢復失敗如何處理
首先在恢復之前就應該做足準備工作，避免恢復的時候出錯。比如說備份之后的有效性檢查、權限檢查、空間檢查等。如果萬一報錯，再根據報錯的提示來進行相應的調整。
(4)mysqldump和xtrabackup實現原理
mysqldump
mysqldump 屬于邏輯備份。加入–single-transaction 選項可以進行一致性備份。后臺進程會先設置 session 的事務隔離級別為 RR(SET SESSION TRANSACTION ISOLATION LEVELREPEATABLE READ)，之后顯式開啟一個事務(START TRANSACTION /*!40100 WITH CONSISTENTSNAPSHOT */)，這樣就保證了該事務里讀到的數據都是事務事務時候的快照。之后再把表的數據讀取出來。如果加上–master-data=1 的話，在剛開始的時候還會加一個數據庫的讀鎖(FLUSH TABLES WITH READ LOCK),等開啟事務后，再記錄下數據庫此時 binlog 的位置(showmaster status)，馬上解鎖，再讀取表的數據。等所有的數據都已經導完，就可以結束事務
Xtrabackup:
xtrabackup 屬于物理備份，直接拷貝表空間文件，同時不斷掃描產生的 redo 日志并保存下來。最后完成 innodb 的備份后，會做一個 flush engine logs 的操作(老版本在有 bug，在5.6 上不做此操作會丟數據)，確保所有的 redo log 都已經落盤(涉及到事務的兩階段提交
概念，因為 xtrabackup 并不拷貝 binlog，所以必須保證所有的 redo log 都落盤，否則可能會丟最后一組提交事務的數據)。這個時間點就是 innodb 完成備份的時間點，數據文件雖然不是一致性的，但是有這段時間的 redo 就可以讓數據文件達到一致性(恢復的時候做的事
情)。然后還需要 flush tables with read lock，把 myisam 等其他引擎的表給備份出來，備份完后解鎖。這樣就做到了完美的熱備。
8. 數據表損壞的修復方式有哪些？
使用 myisamchk 來修復，具體步驟：
1）修復前將mysql服務停止。
2）打開命令行方式，然后進入到mysql的/bin目錄。
3）執行myisamchk –recover 數據庫所在路徑/*.MYI
使用repair table 或者 OPTIMIZE table命令來修復，REPAIR TABLE table_name 修復表 OPTIMIZE TABLE table_name 優化表 REPAIR TABLE 用于修復被破壞的表。OPTIMIZE TABLE 用于回收閑置的數據庫空間，當表上的數據行被刪除時，所占據的磁盤空間并沒有立即被回收，使用了OPTIMIZE TABLE命令后這些空間將被回收，并且對磁盤上的數據行進行重排（注意：是磁盤上，而非數據庫）。
最后，小編分類整理了許多java進階學習材料和BAT面試給熱愛IT行業的你，如果需要資料的請轉發此文章后再私聊小編回復【java】就能領取2019年java進階學習資料和BAT面試題以及《Effective Java》（第3版）電子版書籍。也可以加群：712263501領取海量學習資料進行學習。
