目錄
- MySQL主從複製什麼原因會造成不一致，如何預防及解決？
- 你爲什麼會決定進行分庫分表，分庫分表過程中遇到什麼難題，如何解決的？
- MySQL高可用架構應該考慮什麼? 你認爲應該如何設計？
- MySQL備份，使用xtrabackup備份全實例數據時，會造成鎖等待嗎？那麼如果使用mysqldump進行備份呢？
- MySQL 5.7開始支持JSON，那還有必要使用MongoDB存JSON嗎？請列出你的觀點/理由。
- 當數據被誤刪除/誤操作後造成數據丟失。你嘗試過用什麼手段來挽救數據/損失？
- MySQL 5.7的複製架構,在有異步複製、半同步、增強半同步、MGR等的生產中，該如何選擇？
一、MySQL主從複製什麼原因會造成不一致，如何預防及解決？
（一）導致主從不一致的原因主要有：
1.人爲原因導致從庫與主庫數據不一致（從庫寫入）
2.主從複製過程中，主庫異常宕機
2.設置了ignore/do/rewrite等replication等規則
4.binlog非row格式
5.異步複製本身不保證，半同步存在提交讀的問題，增強半同步起來比較完美。 但對於異常重啓（Replication Crash Safe），從庫寫數據（GTID）的防範，還需要策略來保證。
6.從庫中斷很久，binlog應用不連續，監控並及時修復主從
7.從庫啓用了諸如存儲過程，從庫禁用存儲過程等
8.數據庫大小版本/分支版本導致數據不一致？，主從版本統一
9.備份的時候沒有指定參數 例如mysqldump --master-data=2 等
10.主從sql_mode 不一致
11.一主二從環境，二從的server id一致
12.MySQL自增列 主從不一致
13.主從信息保存在文件裏面，文件本身的刷新是非事務的，導致從庫重啓後開始執行點大於實際執行點
14.採用5.6的after_commit方式半同步，主庫當機可能會引起主從不一致，要看binlog是否傳到了從庫
15.啓用增強半同步了（5.7的after_sync方式），但是從庫延遲超時自動切換成異步複製
（二）預防和解決的方案有：
1.master:innodb_flush_log_at_trx_commit=1&sync_binlog=1
2.slave:master_info_repository="TABLE"&relay_log_info_repository="TABLE"&relay_log_recovery=1
3.設置從庫庫爲只讀模式
4.可以使用5.7增強半同步避免數據丟失等
5.binlog row格式
6.必須引定期的數據校驗機制
7.當使用延遲複製的時候，此時主從數據也是不一致的（計劃內），但在切換中，不要把延遲從提升爲主庫哦~
8.mha在主從切換的過程中，因主庫系統宕機，可能造成主從不一致（mha本身機制導致這個問題）
二、你爲什麼會決定進行分庫分表，分庫分表過程中遇到什麼難題，如何解決的？
（一）爲什麼決定進行分庫分表？
1.根據業務類型，和業務容量的評估，來選擇和判斷是否使用分庫分表
2.當前數據庫本事具有的能力，壓力的評估
3.數據庫的物理隔離，例如減少鎖的爭用、資源的消耗和隔離等
4.熱點表較多,並且數據量大，可能會導致鎖爭搶，性能下降
5.數據庫的高併發，數據庫的讀寫壓力過大，可能會導致數據庫或系統宕機
6.數據庫（MySQL5.7以下）連接數過高，會增加系統壓力
7.單表數據量大，如SQL使用不當，會導致io隨機讀寫比例高。查詢慢（大表上的B+樹太大，掃描太慢，甚至可能需要4層B+樹）
8.備份和恢復時間比較長
（二）都遇到什麼問題?
1.全局pk（主鍵和唯一索引）的衝突檢測不準確，全局的自增主鍵支持不夠好
2.分片鍵的選擇。如沒有選擇好，可能會影響SQL執行效率
3.分佈式事務，中間價產品對分佈式事務的支持力度
4.對於開發來說，需要進行業務的拆分
5.對於開發來說，部分SQL不兼容則需要代碼重構，工作量的評估
6.對於開發來說，跨庫join，跨庫查詢
（三）如何解決?
1.使用全局分號器。或者使用全局唯一id，（應用生成順序唯一int類型做爲全局主鍵）
2.應用層來判斷唯一索引
3.配合應用選擇合適的分片鍵，並加上索引
4.配合應用，配合開發，對不兼容SQL的進行整改
三、MySQL高可用架構應該考慮什麼? 你認爲應該如何設計？
（一）MySQL高可用架構應該考慮什麼？
1.對業務的瞭解，需要考慮業務對數據庫一致性要求的敏感程度，切換過程中是否有事務會丟失
2.對於基礎設施的瞭解，需要了解基礎設施的高可用的架構。例如 單網線，單電源等情況
3.對於數據庫故障時間掌握，業務方最多能容忍時間範圍，因爲高可用切換導致的應用不可用時間
4.需要了解主流的高可用的優缺點：例如 MHA/PXC/MGR 等。
5.考慮多IDC多副本分佈，支持IDC級別節點全部掉線後，業務可以切到另一個機房
（二）你認爲應該如何設計?
1.基礎層 和基礎運維部門配合，瞭解和避免網絡/ 硬盤/ 電源等是否會出現單點故障
2.應用層 和應用開發同學配合，在關鍵業務中記錄SQL日誌，可以做到即使切換，出現丟事務的情況，也可以通過手工補的方式保證數據一致性，例如：交易型的業務引入狀態機，事務狀態，應對數據庫切換後事務重做
3.業務層 瞭解自己的應用，根據不同的應用制定合理的高可用策略。
4.單機多實例 環境及基於虛擬機或容器的設計不能分佈在同一臺物理機上。
5.最終大招 在數據庫不可用 ，可以把已提及的事務先存儲到隊列或者其他位置，等數據庫恢復，重新應用
四、MySQL備份，使用xtrabackup備份全實例數據時，會造成鎖等待嗎？那麼如果使用mysqldump進行備份呢？
（一）xtrabackup和mysqldump會造成鎖等待嗎？
1.xtrabackup會，它在備份時會產生短暫的全局讀鎖FTWL(flush table with read lock)，用於拷貝frm/MYD/MYI等文件，以及記錄binlog信息。如果MyISAM表的數據量非常大，則拷貝時間就越長，加鎖的時間也越長
2.mysqldump有可能會。如果只是添加 --single-transacton 選項用於保證備份數據一致性，這時就不會產生FTWL鎖了。但通常我們爲了讓備份文件和binlog保持一致，通常也會設置 --master-data 選項用於獲得當前binlog信息，這種情況也會短暫加鎖
3.數據量特別大的話，建議優先用 xtrabackup，提高備份/恢復速度。而如果數據量不是太大或者想備份單表，則建議用mysqldump了，方便邏輯恢復。各有利弊，注意其適用場景
（二）xtrabackup冷知識
1.基於MySQL 5.6版本開發的xtrabackup，會在備份過程中生成內部通信文件 suspend file，用於 xtrabackup 和 innobackupex 的通信，備份結束後文件刪除，默認文件位置 /tmp/xtrabackup_suspended
2.如果在備份過程中，修改了 /tmp 的訪問權限或該文件的權限，則兩個程序間直接不能通信，會造成 xtrabackup hang 住，正在備份的表不能正常釋放鎖，會造成鎖等待，此時需要強制 kill 掉 xtrabackup 進程
五、MySQL 5.7開始支持JSON，那還有必要使用MongoDB存JSON嗎？請列出你的觀點/理由。
（一）觀點A：支持MySQL存儲JSON
1.MongoDB不支持事務，而MySQL支持事務
2.MySQL相對MongoDB而言，MySQL的穩定性要優於MongoDB
3.MySQL支持多種存儲引擎
（二）觀點B:支持MongoDB存儲JSON
1.從性能的角度考慮，對於JSON讀寫效率MongoDB要優於MySQL
2.MongoDB相對MySQL而言，MongoDB的擴展性要優於MySQL
3.MongoDB支持更多的JSON函數
（三）總結
1.如果應用程序無事務要求，存儲數據表結構複雜並且經常被修改， 例如遊戲中裝備等場景用MongoDB比較適合
2.如果應用程序有事務要求，存儲數據的"表"之間相互有關聯，例如有訂單系統等場景用MySQL比較適合
3.整體來看相對看好MySQL的JSON功能，在未來官方的努力下MySQL的JSON功能有機會反超MongoDB
六、當數據被誤刪除/誤操作後造成數據丟失。你嘗試過用什麼手段來挽救數據/損失？
（一）前提
1.當數據被誤刪除/誤操作後，第一時間要關閉數據庫。業務方需要緊急掛停機公告，避免數據二次污染，用於保護數據的一致性
2.BINLOG格式爲ROW格式，不討論其他格式的BINLOG
（二）數據被誤操作(update/delete/drop)造成數據丟失，可以用哪些手段來恢復？
1.BINLOG恢復：可以使用逆向解析BINLOG工具來恢復。例如：binlog2SQL等
2.延遲從庫: 可以通過解除延遲從庫，並指定BINLOG結束位置點，可以實現數據恢復
（三）數據被誤刪除(rm/物理文件損壞)造成數據丟失，可以用哪些手段來恢復？
1.如果有備份，可以通過備份恢復 mysqldump/xtrabackup + binlog 來實現全量+增量恢復
2.如果無備份但是有從庫，可以通過主從切換，提升從庫爲主庫，從而實現數據恢復
3.如果無備份並且無從庫，但MySQL沒有重啓，可以通過拷貝/proc/$pid/fd中的文件，來進行嘗試恢復
4.如果無備份並且無從庫，但MySQL有重啓，可以通過extundelete或undrop-for-innodb來恢復
七、MySQL 5.7的複製架構,在有異步複製、半同步、增強半同步、MGR等的生產中，該如何選擇？
（一）生產環境中：
幾種複製場景都有存在的價值。下面分別描述一下：
1.從成熟度上來選擇，推薦：異步複製(GTID+ROW)
2.從數據安全及更高性能上選擇：增強半同步 （在這個結構下也可以把innodb_flush_log_trx_commit調整到非1， 從而獲得更好的性能)
3.對於主從切換控制覺的不好管理，又對數據一致性要求特別高的場景，可以使用MGR
（二）理由：
1.異步複製，相對來講非常成熟，對於環境運維也比較容易上手
2.增強半同步複製，可以安全的保證數據傳輸到從庫上，對於單節點的配置上不用要求太嚴格，特別從庫上也可以更寬鬆一點，而且在一致性和性能有較高的提升，但對運維上有一定的要求
3.MGR組複製。相對增強半同步複製，MGR更能確保數據的一致性，事務的提交，必須經過組內大多數節點（n/2+1）決議並通過，才能得以提交。MGR架構對運維難度要更高，不過它也更完美
總的來講，從技術實現上來看：MGR> 增強半同步>異步複製。
未來可能見到更多的MGR在生產中使用，對於MySQL的運維的要求也會更上一層樓。
公衆號：知數堂，更多MySQL乾貨知識，關注公衆號獲取。
原文鏈接：https://zhishutang.com/L6f
推薦閱讀：https://zhishutang.com/xdI