MongoDB日常巡检命令总结
MongoDB日常巡检命令总结
目录
查看系统日常运行状态
> rs.slaveOk() // 允许从库可以进行查询操作，新版本命令更新为rs.secondaryOk()
> db.serverStatus() // 获取服务器的状态
> db.stats() // 获取当前数据库的信息
> db.stats(1048576) // 返回MB单位
> db.stats(1073741824) // 返回GB单位
> db.集合名称.stats() // 获取collection具体集合的信息
> db.集合名称.stats(1048576) // 返回MB单位
> db.集合名称.stats(1073741824) // 返回GB单位
> db.currentOp() // 获取当前正在执行的操作
> rs.status()
> rs.printReplicationInfo()
> sh.status() // sh的命令需通过mongos来查看
> sh.status({"verbose":1}) // 详细输出，会刷屏
- db.serverStatus()重点关注项:
...
...
// 查看当前连接数
rsB:PRIMARY> db.serverStatus().connections
{ "current" : 54, "available" : 81866, "totalCreated" : 561, "active" : 2 }
...
...
// asserts展示了服务器和客户端抛出异常或警告的数目。断言过多意味着系统存在一些问题
"asserts" : {
"regular" : 0,
"warning" : 0,
"msg" : 0,
"user" : 27014,
"rollovers" : 0
},
...
...
// opcounters展示服务器上已经执行的每种操作的数目。可以看到更新/查询/插入等大致的比例
"opcounters" : {
"insert" : NumberLong(11660322),
"query" : NumberLong(80420411),
"update" : NumberLong(49059748),
"delete" : NumberLong(110001),
"getmore" : NumberLong(54813),
"command" : NumberLong(187889461)
},
- 查看方式：db.serverStatus().key
mongos> Object.keys(db.serverStatus()) // 查看有哪些具体keys
[
"host",
"version",
"process",
"pid",
"uptime",
"uptimeMillis",
"uptimeEstimate",
"localTime",
"asserts",
"connections",
"extra_info",
"logicalSessionRecordCache",
"network",
"opcounters",
"sharding",
"shardingStatistics",
"tcmalloc",
"trafficRecording",
"transactions",
"transportSecurity",
"mem",
"metrics",
"ok",
"operationTime",
"$clusterTime"
]
查看集合和索引状态
> db.集合名称.find({条件}).count() // 统计数目
> db.集合名称.getIndexes() // 查看已存在索引，会自动按照pretty()排列
查看副本集同步状态
> use local
> db.getReplicationInfo()
> rs.printReplicationInfo()
- oplog默认大小为990MB，如果小于12小时，则需要调大oplog，使用如下命令进行调整：
Step #1: > db.adminCommand({replSetResizeOplog: 1, size: 2048})
Step #2: 同步修改对应机器的mongod.conf配置文件
$ vi ../conf/mongod.conf
replication:
oplogSizeMB: 2048
查看副本集同步状态
> use local
> db.getReplicationInfo()
> rs.printReplicationInfo()
- oplog默认大小为990MB，如果小于12小时，则需要调大oplog，使用如下命令进行调整：
Step #1: > db.adminCommand({replSetResizeOplog: 1, size: 2048})
Step #2: 同步修改对应机器的mongod.conf配置文件
$ vi ../conf/mongod.conf
replication:
oplogSizeMB: 2048
查看分片状态
> use 数据库名称
> sh.status() // 查看sharding信息
> db.数据库.getShardDistribution() // 查看数据库在所有分片上的分布情况及是否均衡
查看Balance状态
> sh.getBalancerState() // 查看balance是否启用
> sh.isBalancerRunning() // 查看balancer是否正在运行，返回true表示正在迁移数据
> sh.getBalancerWindow() // 查看balance窗口，如果未设置则显示null
- 建议将负载均衡器的执行时间设置为业务低峰期，以免影响业务高峰期的性能。例如，可以设置为“23:00-04:00”。
- 另外注意：尽量避开在备份期间执行balance，否则会造成数据不一致
> db.settings.update({ _id :"balancer" }, { $set : { activeWindow : { start :"23:00", stop :"04:00" } } }, true )
查看系统运行性能
MongoDB 提供了两个内置的性能监控工具，分别是 mongostat 和 mongotop。这两个工具可以帮助实时监控 MongoDB 实例的性能和状态。
- mongostat 提供了对 MongoDB 实例的系统状态的实时监控，包括了各种性能指标。以下是 mongostat 的示例，表示每 10 秒刷新一次 MongoDB 实例中每个集合的读写操作情况。
- 重点关注dirty和used值，当dirty>20% 或者 used>95%，表示性能有问题；
> mongostat --port port --authenticationDatabase admin -u用户 -p密码 10 --discover
host insert query update delete getmore command dirty used flushes mapped vsize res faults qrw arw net_in net_out conn set repl time
localhost:port 86 571 93 *0 2 42|0 0 0B 1.08G 437M 0 0|0 0|0 406k 38.5m 332 RTR Dec 8 11:21:08.175
db01:port 34 454 1063 *0 204 512|0 4.9% 80.0% 0 23.7G 17.0G n/a 0|0 1|0 1.49m 57.9m 70 rsA PRI Dec 8 11:20:58.207
db01:port *1 *0 *350 *0 9 6|0 1.7% 79.9% 1 25.1G 19.2G n/a 0|0 1|0 6.85k 55.5k 79 rsC SEC Dec 8 11:20:58.333
db02:port *36 *0 *472 *0 196 236|0 5.0% 79.9% 0 24.6G 16.7G n/a 0|0 1|0 292k 607k 51 rsA SEC Dec 8 11:20:58.228
db02:port 1 1387 1028 *0 243 317|0 1.1% 79.9% 1 28.6G 23.0G n/a 0|0 1|0 2.25m 60.0m 125 rsC PRI Dec 8 11:20:58.354
db03:port *35 *0 *468 *0 6 5|0 4.4% 79.4% 0 24.6G 18.9G n/a 0|0 1|0 4.90k 53.6k 51 rsA SEC Dec 8 11:20:58.249
db03:port *1 *0 *346 *0 2 4|0 5.0% 79.7% 0 25.9G 18.1G n/a 0|0 1|0 1.93k 52.0k 70 rsC SEC Dec 8 11:20:58.373
db04:port *254 *0 *336 *0 1 4|0 5.1% 79.3% 0 23.5G 17.2G n/a 0|0 1|0 1.53k 42.7k 44 rsB SEC Dec 8 11:20:58.271
db05:port 254 382 1019 *0 111 287|0 4.8% 80.0% 0 21.5G 17.1G n/a 0|0 1|0 1.52m 52.6m 63 rsB PRI Dec 8 11:20:58.293
db06:port *254 *0 *330 *0 107 138|0 5.0% 79.9% 0 24.1G 16.2G n/a 0|0 1|0 167k 878k 45 rsB SEC Dec 8 11:20:58.315
说明：
column1 说明
insert 一秒内的插入数，如果是slave，数值前往往有一个*
query 一秒内的查询数，如果是slave，数值前往往有一个*
update 一秒内的更新数，如果是slave，数值前往往有一个*
delete 一秒内的删除数，如果是slave，数值前往往有一个*
getmore 查询时游标(cursor)的getmore操作，指标用处不大
command 一秒内执行的命令数。如果是slave，会显示两个值, local
dirty WiredTiger存储引擎中dirty 数据占缓存百分比
used WiredTiger存储引擎中引擎使用缓存占百分比，理想状态是让dirty和used保持差不多的比例。当used 远远大于dirty 工作集大小大于缓存大小,说明当前大批量数据写入，内存吃紧
flushes 一秒内flush的次数，一般都是0或者1，通过计算两个1之间的间隔时间，可以大致了解多长时间flush一次。flush开销是很大的，如果频繁的flush，需要分析原因
mapped/vsize/res 和top看到的一样，mapped和vsize一般不会有大的变动，res会慢慢的上升，如果res经常突然下降，去检查是否有程序占用大量内存
faults 系统压力较大的情况下，这个数值往往不为0。如果经常不为0，就需要增加内存了
qrw queue lengths for clients waiting (read
arw active clients (read
netIn/netOut network traffic out - bits：网络带宽压力，一般MongoDB，网络不会成为瓶颈
conn number of open connections：MongoDB为每一个连接创建一个线程，线程的创建和释放也是有开销的。尽量不要让这个数值很大
- mongotop 提供了对 MongoDB 实例中每个集合的读写操作的实时监控。它显示了每个集合的读写操作的数量和耗时情况。mongotop 只能连接具体 mongod 的端口，不支持 mongos
> mongotop --port port --authenticationDatabase admin -u用户 -p密码 10
2023-12-08T14:25:22.947+0800 connected to: mongodb://localhost:port/
ns total read write 2023-12-08T14:25:32+08:00
db.collection 999ms 0ms 999ms
db.collection 36ms 0ms 36ms
local.oplog.rs 31ms 31ms 0ms
db.collection 31ms 0ms 31ms
db.collection 15ms 0ms 15ms
db.collection 10ms 0ms 10ms
db.collection 6ms 0ms 6ms
db.collection 2ms 0ms 2ms
db.collection 1ms 1ms 0ms
db.collection 1ms 1ms 0ms
查看MongoDB慢查询
建议：在生产环境MongoDB调试分析时，临时按需开启Profiling，收集足够的信息后再关闭，不建议长期开启，这样可以避免过多的性能开销。
> use admin
> db.getProfilingLevel() // 查看慢查询是否开启
> db.getProfilingStatus()
0：关闭，不收集任何数据
1：收集慢查询数据，默认是100毫秒
2：收集所有数据
- 临时开启慢查询Profile
> db.setProfilingLevel(1,2000) // 启用慢查询，设置为2000毫秒，即2秒
> db.setProfilingLevel(0) // 关闭慢查询profiler
> db.system.profile.find()
- 永久修改conf配置文件
...
...
profile = 1
slowms = 2000
分析慢查询日志并优化
- 默认情况下，MongoDB 会将执行时间超过 100 毫秒的慢查询记录到 mongod.log 中。日志的位置取决于 --logpath 参数，我们可以针对 mongod.log 进行慢查询日志分析。
例子 #1：找到日志中存在扫表的操作，不包括oplog、getMore
$ tail mongod.log -n 1000000 | grep ms | grep COLLSCAN | grep -v "getMore" | grep -v "oplog.rs"
例子 #2：找到日志中所有的慢查询，不包括oplog、getMore
$ tail mongod.log -n 1000000 | grep ms | grep op_msg | grep -v "getMore" | grep -v "oplog.rs"
- 需确保nReturned、totalKeysExamined、totalDocsExamined三个保持一致，都都跟nReturned大小一样
- 如果出现：totalKeysExamined >= totalDocsExamined > nReturned的情况需要优化
- 复合索引的顺序很重要：先进行相等测试，之后再进行范围过滤
mongos> use 数据库名称
mongos> db.数据库.find({ "geometry" : { "$nearSphere" : { ...... }}).explain("executionStats")
......
"executionStats" : {
"nReturned" : 1, // 返回的文档数
"executionTimeMillis" : 1, // 执行时间
"totalKeysExamined" : 12, // 索引整体扫描的文档个数,对应之前的nscanned
"totalDocsExamined" : 2, // 整体扫描的文档个数，对应之前的nscannedObjects
"executionStages" : {
"stage" : "SINGLE_SHARD", // 结合下面的Stage，详见下面列表
Stage 描述
COLLSCAN 全表扫描
IXSCAN 索引扫描
FETCH 根据索引去检索指定document
SHARD_MERGE 各个分片返回数据进行merge
SORT 表明在内存中进行了排序（与前期版本的scanAndOrder:true一致）
SORT_MERGE 表明在内存中进行了排序后再合并
LIMIT 使用limit限制返回数
SKIP 使用skip进行跳过
IDHACK 针对_id进行查询
SHARDING_FILTER 通过mongos对分片数据进行查询
COUNT 利用db.coll.count()之类进行count运算
COUNTSCAN count不使用用Index进行count时的stage返回
COUNT_SCAN count使用了Index进行count时的stage返回
SUBPLA 未使用到索引的$or查询的stage返回
TEXT 使用全文索引进行查询时候的stage返回
