MySQL 丟失數(shù)據(jù)的原因及解決
前言
最近偶爾會(huì)收到用戶(hù)反饋數(shù)據(jù)不見(jiàn)了,數(shù)據(jù)丟失了的問(wèn)題。從現(xiàn)象上來(lái)看,這類(lèi)問(wèn)題在數(shù)據(jù)庫(kù)層面就是緊急程度最高的那一類(lèi)了,拋開(kāi)客觀條件來(lái)說(shuō),針對(duì)這一類(lèi)問(wèn)題的恢復(fù)手段幾乎只有備份恢復(fù)+回放 Binlog,耗時(shí)一般比較久,對(duì)業(yè)務(wù)的影響也會(huì)很大。
但是,作為一個(gè)以穩(wěn)定為主的軟件,其實(shí)丟數(shù)據(jù)的概率是非常低的,所以這些反饋的問(wèn)題,是不是真的“丟失數(shù)據(jù)了”?
問(wèn)題描述
某日中午接到用戶(hù)反饋,用業(yè)務(wù)賬號(hào)登錄數(shù)據(jù)庫(kù)以后,業(yè)務(wù)庫(kù)不見(jiàn)了。
原因分析
收到這個(gè)問(wèn)題的時(shí)候,氣氛還是很緊張的,一邊聯(lián)系用戶(hù)授權(quán)登錄數(shù)據(jù)庫(kù)排查,一邊也在和用戶(hù)溝通,看看最近進(jìn)行了哪些變更。
登錄到數(shù)據(jù)庫(kù)之后,發(fā)現(xiàn)業(yè)務(wù)庫(kù)是存在的,結(jié)合用戶(hù)的反饋:“業(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,類(lèi)似如下效果:
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)上,類(lèi)似于:
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ù)本身又一切正常的話(huà),其實(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í)間。
另外一類(lèi)屬于“丟失部分?jǐn)?shù)據(jù)”,比如某張表不見(jiàn)了,或者是表的某些數(shù)據(jù)不見(jiàn)了等等。嚴(yán)格的來(lái)說(shuō),這一類(lèi)問(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è)操作在騰訊云上封裝成了“回檔”的功能。
總結(jié)一下
遇到這一類(lèi)問(wèn)題時(shí),可以先花一點(diǎn)觀察一下問(wèn)題的現(xiàn)象,可能只需要幾秒鐘的時(shí)間重新授權(quán)就解決這類(lèi)“丟失數(shù)據(jù)”的非常緊急且非常嚴(yán)重問(wèn)題。
以上就是MySQL 丟失數(shù)據(jù)的原因及解決的詳細(xì)內(nèi)容,更多關(guān)于MySQL 丟失數(shù)據(jù)的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章!
- MySQL 數(shù)據(jù)丟失排查案例
- 解決docker重啟redis,mysql數(shù)據(jù)丟失的問(wèn)題
- MySQL使用Replace操作時(shí)造成數(shù)據(jù)丟失的問(wèn)題解決
- Python3.6-MySql中插入文件路徑,丟失反斜杠的解決方法
- Mysql掛掉后無(wú)法重啟報(bào)pid文件丟失的解決方法
- 使用SKIP-GRANT-TABLES 解決 MYSQL ROOT密碼丟失
- MySQL下PID文件丟失的相關(guān)錯(cuò)誤的解決方法
- 防止服務(wù)器宕機(jī)時(shí)MySQL數(shù)據(jù)丟失的幾種方案
- MySQL遠(yuǎn)程連接丟失問(wèn)題解決方法(Lost connection to MySQL server)
- 記一次mysql字符串末尾空白丟失的排查
相關(guān)文章
從一個(gè)MySQL的例子來(lái)學(xué)習(xí)查詢(xún)語(yǔ)句
從一個(gè)MySQL的例子來(lái)學(xué)習(xí)查詢(xún)語(yǔ)句...2006-12-12MySql 8.0.16版本安裝提示已經(jīng)不使用“UTF8B3”而是使用“UTF8B4”問(wèn)題
這篇文章主要介紹了MySql 8.0.16版本安裝提示已經(jīng)不使用“UTF8B3”而是使用“UTF8B4”問(wèn)題 ,需要的朋友可以參考下2019-07-07mysql中關(guān)鍵詞exists的用法實(shí)例詳解
在mysql中exists用于檢查子查詢(xún)是否至少會(huì)返回一行數(shù)據(jù),該子查詢(xún)實(shí)際上并不返回任何數(shù)據(jù),而是返回true或false,下面這篇文章主要給大家介紹了關(guān)于mysql中關(guān)鍵詞exists用法的相關(guān)資料,需要的朋友可以參考下2022-06-06具有負(fù)載均衡功能的MySQL服務(wù)器集群部署及實(shí)現(xiàn)
MySQL是一個(gè)高速度、高性能、多線(xiàn)程的關(guān)系型數(shù)據(jù)庫(kù)管理系統(tǒng),適用平臺(tái)多,可擴(kuò)展性強(qiáng)。2011-05-05mysql使用字符串字段判斷是否包含某個(gè)字符串的方法
在MySQL中,判斷字符串字段是否包含特定子字符串,可使用LIKE操作符、INSTR()函數(shù)、LOCATE()函數(shù)、POSITION()函數(shù)、FIND_IN_SET()函數(shù)以及正則表達(dá)式REGEXP或RLIKE,每種方法適用于不同的場(chǎng)景和需求,LIKE和INSTR()通常用于簡(jiǎn)單包含判斷2024-09-09