Mongodb踩坑經(jīng)歷分享

IT那活兒發(fā)布于2023-01-11 13:19 / 1169人閱讀

Mongodb踩坑經(jīng)歷分享

點擊上方“IT那活兒”公眾號，關(guān)注后了解更多內(nèi)容，不管IT什么活兒，干就完了！！！

背景：

主庫dbpath目錄使用率96%，剩余空間只有40GB左右，且無法進(jìn)行磁盤擴(kuò)容。

經(jīng)查，其中一個集合占用空間600GB左右，字段timestamp上有TTL索引（Mongodb的一種索引屬性，創(chuàng)建在單列時間字段上，可設(shè)置數(shù)據(jù)過期時間，超過時間隨即自動刪除數(shù)據(jù)），保留期限31天，經(jīng)與業(yè)務(wù)側(cè)確認(rèn)，可修改數(shù)據(jù)保留期限為7天。

閑言少敘，直入主題！

數(shù)據(jù)庫架構(gòu)：復(fù)制集1主+2從架構(gòu)。

修改前索引屬性：

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索引屬性無需重建索引，修改命令如下：

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天，大約會釋放400GB左右的空間，但是mongodb機(jī)制跟oracle一樣，delete數(shù)據(jù)不會釋放給OS（或者表空間），而需要進(jìn)行compact操作(類似于oracle的高水位回收)后才會釋放空間給OS。

compact操作會加庫級鎖，所以該操作一般在從庫實施，實施過程中從庫狀態(tài)會從secondary轉(zhuǎn)換為recovering，此時不再接收oplog（類似于oracle的歸檔日志，但不是OS文件，而是local庫中的一個固定大小的集合，重復(fù)寫入，達(dá)到規(guī)定大小就刪除最老的記錄），compact完成后，重新開始接收oplog然后繼續(xù)同步。

本次踩坑就發(fā)生在compact操作后。

大集合包含20億+的文檔數(shù)，TTL刪除大概會持續(xù)4-5天，修改TTL屬性兩天后，眼看/data磁盤目錄使用率不斷上升，所以決定分兩次執(zhí)行compact，先釋放一部分空間給其他集合使用。

在一月黑風(fēng)高的夜晚，哥將compact命令（db.runCommand({compact:"lis***ord"})）放到從庫后臺就找周公去了（按之前的經(jīng)驗，會耗時2-3小時）,第二天一大早起來一看，傻眼了。

主從同步延遲越來越大，后臺日志出現(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丟了幾個小時。只能通過重新初始化從庫解決了。分析原因，我們發(fā)現(xiàn)oplog只能保存不到1.5小時，而compact操作需要耗時2小時以上，所以丟失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ù)長期運維此數(shù)據(jù)庫的經(jīng)驗，此數(shù)據(jù)庫的oplog至少會保留5小時以上，為什么現(xiàn)在只能保留1小時呢？恍然大悟，此時正在進(jìn)行TTL刪除數(shù)據(jù)，產(chǎn)生大量的oplog。在oracle數(shù)據(jù)庫中，如果大量的DML操作產(chǎn)生大量歸檔日志，可從alert日志上看到頻繁的redo切換，在mongodb中，不會有任何提示，只能通過rs.printReplicationInfo()檢查oplog保留時間。

正確的操作方式應(yīng)該是：

因為主庫空間不足，所以應(yīng)該在另外一個從節(jié)點進(jìn)行oplog擴(kuò)容db.adminCommand({replSetResizeOplog:1, size: 40960})；
操作前將操作節(jié)點的同步源指向擴(kuò)容了oplog的節(jié)點rs.syncFrom(“10.2***.**.138:27017”);
執(zhí)行compact操作，并隨時注意觀察oplog保留時間，若oplog大小仍然不夠，則繼續(xù)擴(kuò)容。