目錄：

MySQL高可用架構應該考慮什么? 你認為應該如何設計？

MySQL備份，使用xtrabackup備份全實例數據時，會造成鎖等待嗎？那么如果使用mysqldump進行備份呢？

MySQL 5.7開始支持JSON，那還有必要使用MongoDB存JSON嗎？請列出你的觀點/理由。

當數據被誤刪除/誤操作后造成數據丟失。你嘗試過用什么手段來挽救數據/損失？

MySQL 5.7的復制架構,在有異步復制、半同步、增強半同步、MGR等的生產中，該如何選擇？

---

一、MySQL高可用架構應該考慮什么? 你認為應該如何設計？

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

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

對于基礎設施的了解，需要了解基礎設施的高可用的架構。例如 單網線，單電源等情況

對于數據庫故障時間掌握，業務方最多能容忍時間范圍，因為高可用切換導致的應用不可用時間

需要了解主流的高可用的優缺點：例如 MHA/PXC/MGR 等。

考慮多IDC多副本分布，支持IDC級別節點全部掉線后，業務可以切到另一個機房

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

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

應用層 和應用開發同學配合，在關鍵業務中記錄SQL日志，可以做到即使切換，出現丟事務的情況，也可以通過手工補的方式保證數據一致性，例如：交易型的業務引入狀態機，事務狀態，應對數據庫切換后事務重做

業務層 了解自己的應用，根據不同的應用制定合理的高可用策略。

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

最終大招 在數據庫不可用 ，可以把已提及的事務先存儲到隊列或者其他位置，等數據庫恢復，重新應用

二、MySQL備份，使用xtrabackup備份全實例數據時，會造成鎖等待嗎？那么如果使用mysqldump進行備份呢？

（一）xtrabackup和mysqldump會造成鎖等待嗎？

xtrabackup會，它在備份時會產生短暫的全局讀鎖FTWL(flush table with read lock)，用于拷貝frm/MYD/MYI等文件，以及記錄binlog信息。如果MyISAM表的數據量非常大，則拷貝時間就越長，加鎖的時間也越長

mysqldump有可能會。如果只是添加 --single-transacton 選項用于保證備份數據一致性，這時就不會產生FTWL鎖了。但通常我們為了讓備份文件和binlog保持一致，通常也會設置 --master-data 選項用于獲得當前binlog信息，這種情況也會短暫加鎖

數據量特別大的話，建議優先用 xtrabackup，提高備份/恢復速度。而如果數據量不是太大或者想備份單表，則建議用mysqldump了，方便邏輯恢復。各有利弊，注意其適用場景

（二）xtrabackup冷知識

基于MySQL 5.6版本開發的xtrabackup，會在備份過程中生成內部通信文件 suspend file，用于 xtrabackup 和 innobackupex 的通信，備份結束后文件刪除，默認文件位置 /tmp/xtrabackup_suspended

如果在備份過程中，修改了 /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等的生產中，該如何選擇？

（一）生產環境中：

幾種復制場景都有存在的價值。下面分別描述一下：

從成熟度上來選擇，推薦：異步復制(GTID+ROW)

從數據安全及更高性能上選擇：增強半同步 （在這個結構下也可以把innodb_flush_log_trx_commit調整到非1， 從而獲得更好的性能)

對于主從切換控制覺的不好管理，又對數據一致性要求特別高的場景，可以使用MGR

（二）理由：

異步復制，相對來講非常成熟，對于環境運維也比較容易上手

增強半同步復制，可以安全的保證數據傳輸到從庫上，對于單節點的配置上不用要求太嚴格，特別從庫上也可以更寬松一點，而且在一致性和性能有較高的提升，但對運維上有一定的要求

MGR組復制。相對增強半同步復制，MGR更能確保數據的一致性，事務的提交，必須經過組內大多數節點（n/2+1）決議并通過，才能得以提交。MGR架構對運維難度要更高，不過它也更完美

總的來講，從技術實現上來看：MGR> 增強半同步>異步復制。

未來可能見到更多的MGR在生產中使用，對于MySQL的運維的要求也會更上一層樓。

總結

以上是生活随笔為你收集整理的mysql数据丢失_当数据被误删除/误操作后造成数据丢失。你尝试过用什么手段来挽救数据/损失？...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。