閑言少敘,直入主題。
數(shù)據(jù)庫(kù)架構(gòu):復(fù)制集1主+2從架構(gòu)
背景:主庫(kù)dbpath目錄使用率96%,剩余空間只有40GB左右,且無(wú)法進(jìn)行磁盤擴(kuò)容,經(jīng)查,其中一個(gè)集合占用空間600GB左右,字段timestamp上有TTL索引(Mongodb的一種索引屬性,創(chuàng)建在單列時(shí)間字段上,可設(shè)置數(shù)據(jù)過(guò)期時(shí)間,超過(guò)時(shí)間隨即自動(dòng)刪除數(shù)據(jù)),保留期限31天,經(jīng)與業(yè)務(wù)側(cè)確認(rèn),可修改數(shù)據(jù)保留期限為7天。
修改前索引屬性:
PRIMARY:AKTM> db.list***ord.getIndexes(); [ { "v" : 2, "key" :{ "timestamp": 1 }, "name" :"timestamp_1", "background": true, "ns" :"AKTM.list***ord", "expireAfterSeconds": NumberLong(2678400) }, { "v" : 2, "key" :{ "_id": 1 }, "name" :"_id_", "ns" :"AKTM.list***ord" } ] |
修改TTL索引屬性無(wú)需重建索引,修改命令如下:
db.runCommand( { collMod:"list***ord", index: { keyPattern: { timestamp:1 }, expireAfterSeconds: 604800 } }) |
修改后索引屬性:
PRIMARY:AKTM> db.list***ord.getIndexes(); [ { "v" : 2, "key" :{ "timestamp": 1 }, "name" :"timestamp_1", "background": true, "ns" :"AKTM.list***ord", "expireAfterSeconds": NumberLong(604800) }, { "v" : 2, "key" :{ "_id": 1 }, "name" :"_id_", "ns" :"AKTM.list***ord" } ] |
將數(shù)據(jù)從31天清理到7天,大約會(huì)釋放400GB左右的空間,但是mongodb機(jī)制跟oracle一樣,delete數(shù)據(jù)不會(huì)釋放給OS(或者表空間),而需要進(jìn)行compact操作(類似于oracle的高水位回收)后才會(huì)釋放空間給OS。compact操作會(huì)加庫(kù)級(jí)鎖,所以該操作一般在從庫(kù)實(shí)施,實(shí)施過(guò)程中從庫(kù)狀態(tài)會(huì)從secondary轉(zhuǎn)換為recovering,此時(shí)不再接收oplog(類似于oracle的歸檔日志,但不是OS文件,而是local庫(kù)中的一個(gè)固定大小的集合,重復(fù)寫入,達(dá)到規(guī)定大小就刪除最老的記錄),compact完成后,重新開始接收oplog然后繼續(xù)同步。本次踩坑就發(fā)生在compact操作后。
大集合包含20億+的文檔數(shù),TTL刪除大概會(huì)持續(xù)4-5天,修改TTL屬性兩天后,眼看/data磁盤目錄使用率不斷上升,所以決定分兩次執(zhí)行compact,先釋放一部分空間給其他集合使用。在一月黑風(fēng)高的夜晚,哥將compact命令(db.runCommand({compact:"lis***ord"}))放到從庫(kù)后臺(tái)就找周公去了(按之前的經(jīng)驗(yàn),會(huì)耗時(shí)2-3小時(shí)),第二天一大早起來(lái)一看,傻眼了。
主從同步延遲越來(lái)越大,后臺(tái)日志出現(xiàn)如下信息:
2020-07-01T07:17:49.265+0800 IREPL [replication-147] We are too stale to use10.***.***.83:27017 as a sync source. Blacklisting this sync sourcebecause our last fetched timestamp: Timestamp(1593529482, 5082) isbefore their earliest timestamp: Timestamp(1593553525, 1720) for 1minuntil: 2020-07-01T07:18:49.265+0800 2020-07-01T07:17:49.266+0800 IREPL [replication-147] sync source candidate: 10.**.***.138:27017 2020-07-01T07:17:49.268+0800 IREPL [replication-147] We are too stale to use10.25.151.138:27017 as a sync source. Blacklisting this sync sourcebecause our last fetched timestamp: Timestamp(1593529482, 5082) isbefore their earliest timestamp: Timestamp(1593553515, 601) for 1minuntil: 2020-07-01T07:18:49.268+0800 |
從上面的日志可以看出,oplog丟了幾個(gè)小時(shí)。只能通過(guò)重新初始化從庫(kù)解決了。分析原因,我們發(fā)現(xiàn)oplog只能保存不到1.5小時(shí),而compact操作需要耗時(shí)2小時(shí)以上,所以丟失oplog是必然。
repl1:SECONDARY>rs.printReplicationInfo(); configured oplog size: 10240MB log length start to end: 4704secs(1.31hrs) oplog first event time: Wed Jul01 2020 06:30:31 GMT+0800 (CST) oplog last event time: Wed Jul01 2020 07:48:55 GMT+0800 (CST) now: Wed Jul01 2020 07:48:56 GMT+0800 (CST) |
根據(jù)長(zhǎng)期運(yùn)維此數(shù)據(jù)庫(kù)的經(jīng)驗(yàn),此數(shù)據(jù)庫(kù)的oplog至少會(huì)保留5小時(shí)以上,為什么現(xiàn)在只能保留1小時(shí)呢?恍然大悟,此時(shí)正在進(jìn)行TTL刪除數(shù)據(jù),產(chǎn)生大量的oplog。在oracle數(shù)據(jù)庫(kù)中,如果大量的DML操作產(chǎn)生大量歸檔日志,可從alert日志上看到頻繁的redo切換,在mongodb中,不會(huì)有任何提示,只能通過(guò)rs.printReplicationInfo()檢查oplog保留時(shí)間。
正確的操作方式應(yīng)該是:
因?yàn)橹鲙?kù)空間不足,所以應(yīng)該在另外一個(gè)從節(jié)點(diǎn)進(jìn)行oplog擴(kuò)容db.adminCommand({replSetResizeOplog:1, size: 40960});
操作前將操作節(jié)點(diǎn)的同步源指向擴(kuò)容了oplog的節(jié)點(diǎn)rs.syncFrom(“10.2***.**.138:27017”);
執(zhí)行compact操作,并隨時(shí)注意觀察oplog保留時(shí)間,若oplog大小仍然不夠,則繼續(xù)擴(kuò)容。
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://m.specialneedsforspecialkids.com/yun/130158.html
摘要:先睹為快振奮人心的時(shí)刻終于到來(lái)了,在經(jīng)過(guò)一個(gè)上市的日子后,終于發(fā)布了。實(shí)戰(zhàn)在線開啟認(rèn)證模式解讀我是上海小胖,專注等開源數(shù)據(jù)庫(kù)的,擁抱開源,接受收費(fèi)。上海小胖原創(chuàng)地址歡迎各位大神前來(lái)評(píng)論。每周五,敬請(qǐng)期待,上海小胖獨(dú)更。 MongoDB 3.6 先睹為快 Part 1 振奮人心的時(shí)刻終于到來(lái)了,在經(jīng)過(guò)一個(gè)MongoDB 上市的日子后,MongoDB 終于發(fā)布了MongoDB 3.6 RC...
摘要:先睹為快振奮人心的時(shí)刻終于到來(lái)了,在經(jīng)過(guò)一個(gè)上市的日子后,終于發(fā)布了。實(shí)戰(zhàn)在線開啟認(rèn)證模式解讀我是上海小胖,專注等開源數(shù)據(jù)庫(kù)的,擁抱開源,接受收費(fèi)。上海小胖原創(chuàng)地址歡迎各位大神前來(lái)評(píng)論。每周五,敬請(qǐng)期待,上海小胖獨(dú)更。 MongoDB 3.6 先睹為快 Part 1 振奮人心的時(shí)刻終于到來(lái)了,在經(jīng)過(guò)一個(gè)MongoDB 上市的日子后,MongoDB 終于發(fā)布了MongoDB 3.6 RC...
摘要:出現(xiàn)的問(wèn)題筆者前段時(shí)間開發(fā)一個(gè)新項(xiàng)目的某個(gè)功能模塊要讀取老游戲中某個(gè)數(shù)據(jù)庫(kù)計(jì)作庫(kù)連續(xù)讀庫(kù)中的個(gè)集合相當(dāng)于的張表取數(shù)據(jù)在測(cè)試環(huán)境單次操作時(shí)是內(nèi)但是并發(fā)測(cè)試情況下比如內(nèi)個(gè)并發(fā)時(shí)讀取庫(kù)個(gè)集合的耗時(shí)能達(dá)到以上甚至且個(gè)并發(fā)請(qǐng)求幾乎同時(shí)完成但是在我本地 出現(xiàn)的問(wèn)題 筆者前段時(shí)間開發(fā)一個(gè)新項(xiàng)目的某個(gè)功能模塊,要讀取老游戲中某個(gè)Mongo數(shù)據(jù)庫(kù)(計(jì)作A庫(kù)),連續(xù)讀A庫(kù)中的6個(gè)集合(相當(dāng)于MySQL的6...
摘要:大家好,我是冰河有句話叫做投資啥都不如投資自己的回報(bào)率高。馬上就十一國(guó)慶假期了,給小伙伴們分享下,從小白程序員到大廠高級(jí)技術(shù)專家我看過(guò)哪些技術(shù)類書籍。 大家好,我是...
閱讀 1353·2023-01-11 13:20
閱讀 1699·2023-01-11 13:20
閱讀 1211·2023-01-11 13:20
閱讀 1902·2023-01-11 13:20
閱讀 4161·2023-01-11 13:20
閱讀 2751·2023-01-11 13:20
閱讀 1397·2023-01-11 13:20
閱讀 3664·2023-01-11 13:20