資訊專欄INFORMATION COLUMN
閑言少敘，直入主題。
數據庫架構：復制集1主+2從架構
背景：主庫dbpath目錄使用率96%，剩余空間只有40GB左右，且無法進行磁盤擴容，經查，其中一個集合占用空間600GB左右，字段timestamp上有TTL索引（Mongodb的一種索引屬性，創建在單列時間字段上，可設置數據過期時間，超過時間隨即自動刪除數據），保留期限31天，經與業務側確認，可修改數據保留期限為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索引屬性無需重建索引，修改命令如下：
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" } ] |
將數據從31天清理到7天，大約會釋放400GB左右的空間，但是mongodb機制跟oracle一樣，delete數據不會釋放給OS（或者表空間），而需要進行compact操作(類似于oracle的高水位回收)后才會釋放空間給OS。compact操作會加庫級鎖，所以該操作一般在從庫實施，實施過程中從庫狀態會從secondary轉換為recovering，此時不再接收oplog（類似于oracle的歸檔日志，但不是OS文件，而是local庫中的一個固定大小的集合，重復寫入，達到規定大小就刪除最老的記錄），compact完成后，重新開始接收oplog然后繼續同步。本次踩坑就發生在compact操作后。
大集合包含20億+的文檔數，TTL刪除大概會持續4-5天，修改TTL屬性兩天后，眼看/data磁盤目錄使用率不斷上升，所以決定分兩次執行compact，先釋放一部分空間給其他集合使用。在一月黑風高的夜晚，哥將compact命令（db.runCommand({compact:"lis***ord"})）放到從庫后臺就找周公去了（按之前的經驗，會耗時2-3小時）,第二天一大早起來一看，傻眼了。
主從同步延遲越來越大，后臺日志出現如下信息：
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丟了幾個小時。只能通過重新初始化從庫解決了。分析原因，我們發現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) |
根據長期運維此數據庫的經驗，此數據庫的oplog至少會保留5小時以上，為什么現在只能保留1小時呢？恍然大悟，此時正在進行TTL刪除數據，產生大量的oplog。在oracle數據庫中，如果大量的DML操作產生大量歸檔日志，可從alert日志上看到頻繁的redo切換，在mongodb中，不會有任何提示，只能通過rs.printReplicationInfo()檢查oplog保留時間。
正確的操作方式應該是：
因為主庫空間不足，所以應該在另外一個從節點進行oplog擴容db.adminCommand({replSetResizeOplog:1, size: 40960})；
操作前將操作節點的同步源指向擴容了oplog的節點rs.syncFrom(“10.2***.**.138:27017”);
執行compact操作，并隨時注意觀察oplog保留時間，若oplog大小仍然不夠，則繼續擴容。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/130158.html
摘要：先睹為快振奮人心的時刻終于到來了，在經過一個上市的日子后，終于發布了。實戰在線開啟認證模式解讀我是上海小胖，專注等開源數據庫的，擁抱開源，接受收費。上海小胖原創地址歡迎各位大神前來評論。每周五，敬請期待，上海小胖獨更。 MongoDB 3.6 先睹為快 Part 1 振奮人心的時刻終于到來了，在經過一個MongoDB 上市的日子后，MongoDB 終于發布了MongoDB 3.6 RC...
摘要：先睹為快振奮人心的時刻終于到來了，在經過一個上市的日子后，終于發布了。實戰在線開啟認證模式解讀我是上海小胖，專注等開源數據庫的，擁抱開源，接受收費。上海小胖原創地址歡迎各位大神前來評論。每周五，敬請期待，上海小胖獨更。 MongoDB 3.6 先睹為快 Part 1 振奮人心的時刻終于到來了，在經過一個MongoDB 上市的日子后，MongoDB 終于發布了MongoDB 3.6 RC...
摘要：出現的問題筆者前段時間開發一個新項目的某個功能模塊要讀取老游戲中某個數據庫計作庫連續讀庫中的個集合相當于的張表取數據在測試環境單次操作時是內但是并發測試情況下比如內個并發時讀取庫個集合的耗時能達到以上甚至且個并發請求幾乎同時完成但是在我本地 出現的問題 筆者前段時間開發一個新項目的某個功能模塊,要讀取老游戲中某個Mongo數據庫(計作A庫),連續讀A庫中的6個集合(相當于MySQL的6...
摘要：大家好，我是冰河有句話叫做投資啥都不如投資自己的回報率高。馬上就十一國慶假期了，給小伙伴們分享下，從小白程序員到大廠高級技術專家我看過哪些技術類書籍。 大家好，我是...
閱讀 1346·2023-01-11 13:20
閱讀 1684·2023-01-11 13:20
閱讀 1132·2023-01-11 13:20
閱讀 1858·2023-01-11 13:20
閱讀 4100·2023-01-11 13:20
閱讀 2704·2023-01-11 13:20
閱讀 1385·2023-01-11 13:20
閱讀 3597·2023-01-11 13:20
