猿們必知的MySQL知識小貼士！

目錄

• MySQL主從複製什麼緣由會形成不一致，如何預防及解決？
• 你爲何會決定進行分庫分表，分庫分表過程當中遇到什麼難題，如何解決的？
• MySQL高可用架構應該考慮什麼? 你認爲應該如何設計？
• MySQL備份，使用xtrabackup備份全實例數據時，會形成鎖等待嗎？那麼若是使用mysqldump進行備份呢？
• MySQL 5.7開始支持JSON，那還有必要使用MongoDB存JSON嗎？請列出你的觀點/理由。
• 當數據被誤刪除/誤操做後形成數據丟失。你嘗試過用什麼手段來挽救數據/損失？
• MySQL 5.7的複製架構,在有異步複製、半同步、加強半同步、MGR等的生產中，該如何選擇？

---

1、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自己機制致使這個問題）

2、你爲何會決定進行分庫分表，分庫分表過程當中遇到什麼難題，如何解決的？

（一）爲何決定進行分庫分表？

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的進行整改

3、MySQL高可用架構應該考慮什麼? 你認爲應該如何設計？

（一）MySQL高可用架構應該考慮什麼？

1.對業務的瞭解，須要考慮業務對數據庫一致性要求的敏感程度，切換過程當中是否有事務會丟失

2.對於基礎設施的瞭解，須要瞭解基礎設施的高可用的架構。例如 單網線，單電源等狀況

3.對於數據庫故障時間掌握，業務方最多能容忍時間範圍，由於高可用切換致使的應用不可用時間

4.須要瞭解主流的高可用的優缺點：例如 MHA/PXC/MGR 等。

5.考慮多IDC多副本分佈，支持IDC級別節點所有掉線後，業務能夠切到另外一個機房

（二）你認爲應該如何設計?

1.基礎層 和基礎運維部門配合，瞭解和避免網絡/ 硬盤/ 電源等是否會出現單點故障

2.應用層 和應用開發同窗配合，在關鍵業務中記錄SQL日誌，能夠作到即便切換，出現丟事務的狀況，也能夠經過手工補的方式保證數據一致性，例如：交易型的業務引入狀態機，事務狀態，應對數據庫切換後事務重作

3.業務層 瞭解本身的應用，根據不一樣的應用制定合理的高可用策略。

4.單機多實例 環境及基於虛擬機或容器的設計不能分佈在同一臺物理機上。

5.最終大招 在數據庫不可用 ，能夠把已說起的事務先存儲到隊列或者其餘位置，等數據庫恢復，從新應用

4、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 進程

5、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

6、當數據被誤刪除/誤操做後形成數據丟失。你嘗試過用什麼手段來挽救數據/損失？

（一）前提

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來恢復

7、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