最近偶爾會(huì)收到用戶反饋數(shù)據(jù)不見(jiàn)了，數(shù)據(jù)丟失了的問(wèn)題。從現(xiàn)象上來(lái)看，這類問(wèn)題在數(shù)據(jù)庫(kù)層面就是緊急程度最高的那一類了，拋開(kāi)客觀條件來(lái)說(shuō)，針對(duì)這一類問(wèn)題的恢復(fù)手段幾乎只有備份恢復(fù)+回放 Binlog，耗時(shí)一般比較久，對(duì)業(yè)務(wù)的影響也會(huì)很大。

但是，作為一個(gè)以穩(wěn)定為主的軟件，其實(shí)丟數(shù)據(jù)的概率是非常低的，所以這些反饋的問(wèn)題，是不是真的“丟失數(shù)據(jù)了”？

某日中午接到用戶反饋，用業(yè)務(wù)賬號(hào)登錄數(shù)據(jù)庫(kù)以后，業(yè)務(wù)庫(kù)不見(jiàn)了。

收到這個(gè)問(wèn)題的時(shí)候，氣氛還是很緊張的，一邊聯(lián)系用戶授權(quán)登錄數(shù)據(jù)庫(kù)排查，一邊也在和用戶溝通，看看最近進(jìn)行了哪些變更。

登錄到數(shù)據(jù)庫(kù)之后，發(fā)現(xiàn)業(yè)務(wù)庫(kù)是存在的，結(jié)合用戶的反饋：“業(yè)務(wù)庫(kù)不見(jiàn)了”，初步判斷是業(yè)務(wù)賬號(hào)沒(méi)有權(quán)限，用show grants查看之后，發(fā)現(xiàn)業(yè)務(wù)賬號(hào)的權(quán)限只有 USAGE，類似如下效果：

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

由于只有最低的權(quán)限，這個(gè)賬號(hào)顯然是“看不到業(yè)務(wù)數(shù)據(jù)的”，所以重新授權(quán)之后，問(wèn)題解決了。事后排查發(fā)現(xiàn)最初的授權(quán)操作發(fā)生在一個(gè)其他的同名賬號(hào)上，類似于：

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>拓展一下

對(duì)于“丟失數(shù)據(jù)”這個(gè)現(xiàn)象來(lái)看，如果是“丟失”了整個(gè)庫(kù)級(jí)別的數(shù)據(jù)，但是數(shù)據(jù)庫(kù)本身又一切正常的話，其實(shí)有蠻大的可能性和這個(gè)案例是一樣的問(wèn)題：權(quán)限錯(cuò)誤。引起這種問(wèn)題的可能性一般是兩個(gè)：1. 登錄的賬號(hào)匹配到了同名的其他賬號(hào)；2. 授權(quán)出現(xiàn)了問(wèn)題，導(dǎo)致業(yè)務(wù)賬號(hào)沒(méi)有權(quán)限。當(dāng)然，最糟糕的情況肯定是drop database的操作，通過(guò)解析 binlog 才能定位到執(zhí)行這個(gè)操作的時(shí)間。

另外一類屬于“丟失部分?jǐn)?shù)據(jù)”，比如某張表不見(jiàn)了，或者是表的某些數(shù)據(jù)不見(jiàn)了等等。嚴(yán)格的來(lái)說(shuō)，這一類問(wèn)題也有可能是權(quán)限錯(cuò)誤引起的，因?yàn)?MySQL 的權(quán)限控制確實(shí)可以做到表和列級(jí)別，只是現(xiàn)實(shí)中一般不會(huì)用到。大多數(shù)時(shí)候是誤操作，比如 update 或者 delete 的時(shí)候沒(méi)有 where 條件。這種時(shí)候只能通過(guò)歷史備份，再利用 binlog 進(jìn)行恢復(fù)，這個(gè)操作在騰訊云上封裝成了“回檔”的功能。

遇到這一類問(wèn)題時(shí)，可以先花一點(diǎn)觀察一下問(wèn)題的現(xiàn)象，可能只需要幾秒鐘的時(shí)間重新授權(quán)就解決這類“丟失數(shù)據(jù)”的非常緊急且非常嚴(yán)重問(wèn)題。

以上就是MySQL 丟失數(shù)據(jù)的原因及解決的詳細(xì)內(nèi)容，更多關(guān)于MySQL 丟失數(shù)據(jù)的資料請(qǐng)關(guān)注好吧啦網(wǎng)其它相關(guān)文章！