mongodb 集群重构和释放磁盘空间实例详解

(编辑:jimmy 日期: 2024/12/24 浏览:2)

MongoDB集群重构,释放磁盘空间

由于mongodb删除了一部分数据后,不会回收相应的磁盘空间,所以这里通过重建数据目录的方式释放磁盘空间。

一 实验环境

配置了一个副本集,该副本集由以下三个节点组成:

10.192.203.201:27017 PRIMARY

10.192.203.202:27017 SECONDARY

10.192.203.202:10001  ARBITER

二 实验步骤

2.1 模拟环境


use dba; 
for(var i=0;i<1000000;i++)db.c.insert({uid:i,uname:'osqlfan'+i}); 
db.c.find().count();#1000000 
 db.stats(); 
{ 
  "db" : "dba", 
  "collections" : 5, 
  "objects" : 1000111, 
  "avgObjSize" : 111.9994880568257, 
  "dataSize" : 112011920, 
  "storageSize" : 174796800, 
  "numExtents" : 17, 
  "indexes" : 3, 
  "indexSize" : 32475072, 
  "fileSize" : 469762048, 
  "nsSizeMB" : 16, 
  "extentFreeList" : { 
    "num" : 0, 
    "totalSize" : 0 
  }, 
  "dataFileVersion" : { 
    "major" : 4, 
    "minor" : 22 
  }, 
  "ok" : 1 
} 

磁盘空间增加了400M数据:

-rw-------. 1 root root  134217728 Nov 7 13:38 dba.1

-rw-------. 1 root root  268435456 Nov 7 13:38 dba.2

[root@slave2 ~]# du -sh /data/mongo/data

4.7G /data/mongo/data



#删除dba.c表数据: 
MyReplset:PRIMARY> db.c.drop(); 
true 
MyReplset:PRIMARY> db.c.find().count(); 
0 
MyReplset:PRIMARY> db.stats(); 
{ 
"db" : "dba", 
"collections" : 4, 
"objects" : 108, 
"avgObjSize" : 108.44444444444444, 
"dataSize" : 11712, 
"storageSize" : 61440, 
"numExtents" : 5, 
"indexes" : 2, 
"indexSize" : 16352, 
"fileSize" : 469762048, 
"nsSizeMB" : 16, 
"extentFreeList" : { 
"num" : 18, 
"totalSize" : 212492288 
}, 
"dataFileVersion" : { 
"major" : 4, 
"minor" : 22 
}, 
"ok" : 1 
} 

看到dataSize,indexSize,storageSize都变小了,但是fileSize没有变化,而且mongo data目录仍然占用4.7G。

 2.2 确保先在从库10.192.203.202:27017上进行重构 

#查看主从关系



MyReplset:PRIMARY>rs.status(); 
{ 
"set" : "MyReplset", 
"date" :ISODate("2016-11-07T07:10:50.717Z"), 
"myState" : 1, 
"members" : [ 
      { 
          "_id" : 0, 
          "name" :"10.192.203.201:27017", 
          "health" : 1, 
          "state" : 1, 
          "stateStr" :"PRIMARY", 
          "uptime" : 964, 
          "optime" :Timestamp(1478239977, 594), 
          "optimeDate" :ISODate("2016-11-04T06:12:57Z"), 
          "electionTime" :Timestamp(1478502021, 1), 
          "electionDate" :ISODate("2016-11-07T07:00:21Z"), 
          "configVersion" :2, 
          "self" : true 
      }, 
      { 
          "_id" : 1, 
          "name" :"10.192.203.202:27017", 
          "health" : 1, 
          "state" : 2, 
          "stateStr" :"SECONDARY", 
          "uptime" : 628, 
          "optime" :Timestamp(1478239977, 594), 
          "optimeDate" :ISODate("2016-11-04T06:12:57Z"), 
          "lastHeartbeat" :ISODate("2016-11-07T07:10:49.257Z"), 
          "lastHeartbeatRecv": ISODate("2016-11-07T07:10:50.143Z"), 
          "pingMs" : 2, 
          "configVersion" :2 
      }, 
      { 
          "_id" : 2, 
          "name" :"10.192.203.202:10001", 
          "health" : 1, 
          "state": 7, 
          "stateStr" :"ARBITER", 
          "uptime" : 618, 
          "lastHeartbeat" :ISODate("2016-11-07T07:10:49.416Z"), 
          "lastHeartbeatRecv": ISODate("2016-11-07T07:10:49.847Z"), 
          "pingMs" : 2, 
          "configVersion" :2 
      } 
], 
"ok" : 1 
} 
 

2.2.1 关闭数据库

MyReplset:SECONDARY> use admin; 
switched to db admin 
MyReplset:SECONDARY> db.shutdownServer(); 
2016-11-07T15:14:42.548+0800 I NETWORK DBClientCursor::init call() failed 
server should be down... 
2016-11-07T15:14:42.571+0800 I NETWORK trying reconnect to 127.0.0.1:27017(127.0.0.1) failed 
2016-11-07T15:14:42.575+0800 W NETWORK Failed to connect to 127.0.0.1:27017, reason:errno:111 Connection refused 
2016-11-07T15:14:42.575+0800 I NETWORK reconnect 127.0.0.1:27017 (127.0.0.1) failedfailed couldn't connect to server 127.0.0.1:27017 (127.0.0.1), connectionattempt failed 
2016-11-07T15:14:42.634+0800 I NETWORK trying reconnect to 127.0.0.1:27017(127.0.0.1) failed 
2016-11-07T15:14:42.637+0800 W NETWORK Failed to connect to 127.0.0.1:27017, reason:errno:111 Connection refused 
2016-11-07T15:14:42.638+0800I NETWORK reconnect 127.0.0.1:27017(127.0.0.1) failed failed couldn't connect to server 127.0.0.1:27017(127.0.0.1), connection attempt failed 

2.2.2 备份,删除,重建数据目录

备份10.192.203.202:27017的数据目录,这里省略

备份完成后,删除,重建该目录。

rm-rf /data/mongo/data

mkdir/data/mongo/data

2.2.3 启动数据库

启动10.192.203.202:27017进程:

/usr/local/mongodb/bin/mongod--config /usr/local/mongodb/mongod.cnf --replSet MyReplset -rest

2.2.4 检查

检查数据库是否正常,之前的数据库是否都存在。

检查下磁盘空间是否缩小。

经检查,空间缩小为4.3G,收缩了400MB。

2.3 重构主库

2.3.1 切换主从关系

因201是主,所以需要把201和202:27017之间的主从关系切换一下。本实验除了仲裁节点外,只有一个从节点。假如有多个节点的话,需要在其余从节点上

执行:rs.freeze(300);(锁定从,使其不会转变成主库)

在10.192.203.201:27017执行:rs.stepDown(30);(对其进行降级)

--freeze()和stepDown单位都是秒。

rs.status()查看主从关系是否切换完毕。

2.3.2 关闭数据库

停止10.192.203.201:27017进程:

MyReplset:SECONDARY>use admin;

switched to db admin

MyReplset:SECONDARY> db.shutdownServer();

2.3.3 备份删除,重建其数据目录

备份略。

rm-rf /data/mongo/data

mkdir/data/mongo/data

2.3.4 启动数据库

启动10.192.203.201:27017进程:

/usr/local/mongodb/bin/mongod--config /usr/local/mongodb/mongod.cnf --replSet MyReplset -rest

2.3.4 检查

检查数据库是否正常,之前的数据库是否都存在。

检查下磁盘空间是否缩小。

经检查,空间缩小为4.3G,收缩了400MB。

--仲裁节点不需要重构。

重构完成后可以再切换回原来的主从状态。

感谢阅读,希望能帮助到大家,谢谢大家对本站的支持!

一句话新闻

一文看懂荣耀MagicBook Pro 16
荣耀猎人回归!七大亮点看懂不只是轻薄本,更是游戏本的MagicBook Pro 16.
人们对于笔记本电脑有一个固有印象:要么轻薄但性能一般,要么性能强劲但笨重臃肿。然而,今年荣耀新推出的MagicBook Pro 16刷新了人们的认知——发布会上,荣耀宣布猎人游戏本正式回归,称其继承了荣耀 HUNTER 基因,并自信地为其打出“轻薄本,更是游戏本”的口号。
众所周知,寻求轻薄本的用户普遍更看重便携性、外观造型、静谧性和打字办公等用机体验,而寻求游戏本的用户则普遍更看重硬件配置、性能释放等硬核指标。把两个看似难以相干的产品融合到一起,我们不禁对它产生了强烈的好奇:作为代表荣耀猎人游戏本的跨界新物种,它究竟做了哪些平衡以兼顾不同人群的各类需求呢?