最近偶爾會收到用戶反饋數據不見了，數據丟失了的問題。從現象上來看，這類問題在數據庫層面就是緊急程度最高的那一類了，拋開客觀條件來說，針對這一類問題的恢復手段幾乎只有備份恢復+回放 Binlog，耗時一般比較久，對業務的影響也會很大。

但是，作為一個以穩定為主的軟件，其實丟數據的概率是非常低的，所以這些反饋的問題，是不是真的“丟失數據了”？

某日中午接到用戶反饋，用業務賬號登錄數據庫以后，業務庫不見了。

收到這個問題的時候，氣氛還是很緊張的，一邊聯系用戶授權登錄數據庫排查，一邊也在和用戶溝通，看看最近進行了哪些變更。

登錄到數據庫之后，發現業務庫是存在的，結合用戶的反饋：“業務庫不見了”，初步判斷是業務賬號沒有權限，用show grants查看之后，發現業務賬號的權限只有 USAGE，類似如下效果：

mysql> show grants;+----------------------------------+| Grants for test@%|+----------------------------------+| GRANT USAGE ON *.* TO ’test’@’%’ |+----------------------------------+1 row in set (0.00 sec)

由于只有最低的權限，這個賬號顯然是“看不到業務數據的”，所以重新授權之后，問題解決了。事后排查發現最初的授權操作發生在一個其他的同名賬號上，類似于：

mysql> show grants;+-------------------------------------------------------------+| Grants for test@10.120.117.%|+-------------------------------------------------------------+| GRANT ALL PRIVILEGES ON prd_name.* TO ’test’@’10.120.117.%’ |+-------------------------------------------------------------+1 row in set (0.00 sec)mysql>拓展一下

對于“丟失數據”這個現象來看，如果是“丟失”了整個庫級別的數據，但是數據庫本身又一切正常的話，其實有蠻大的可能性和這個案例是一樣的問題：權限錯誤。引起這種問題的可能性一般是兩個：1. 登錄的賬號匹配到了同名的其他賬號；2. 授權出現了問題，導致業務賬號沒有權限。當然，最糟糕的情況肯定是drop database的操作，通過解析 binlog 才能定位到執行這個操作的時間。

另外一類屬于“丟失部分數據”，比如某張表不見了，或者是表的某些數據不見了等等。嚴格的來說，這一類問題也有可能是權限錯誤引起的，因為 MySQL 的權限控制確實可以做到表和列級別，只是現實中一般不會用到。大多數時候是誤操作，比如 update 或者 delete 的時候沒有 where 條件。這種時候只能通過歷史備份，再利用 binlog 進行恢復，這個操作在騰訊云上封裝成了“回檔”的功能。

遇到這一類問題時，可以先花一點觀察一下問題的現象，可能只需要幾秒鐘的時間重新授權就解決這類“丟失數據”的非常緊急且非常嚴重問題。

以上就是MySQL 丟失數據的原因及解決的詳細內容，更多關于MySQL 丟失數據的資料請關注好吧啦網其它相關文章！