MongoDB 副本集
副本集：
启动MongoDB是使用—replSet rs0，或者在配置文件中添加replSet=rs0
进入其中一台MongoDB，如果有数据进有数据的那台，多台有数据的话，起不来。
rs.initiate({_id:'rs0',members:[{_id:0,host:'192.168.3.12:27017',priority:10},{_id:1,host:'192.168.3.13:27017',priority:5},{_id:2,host:'192.168.3.14:27017',priority:3}]})
rs.status()
rs.conf()
rs.remove('192.168.3.14:27017')
rs.add('192.168.3.14:27017')
rs.add({_id:1,host:"192.168.3.14:27017",priority:5})
rs.addArb('192.168.3.15:27017')
重设优先级，切换主备。
config=rs.conf()
config.members[1].priority = 15
rs.reconfig(config)
查看当前MongoDB的连接数
db.serverStatus().connections
Mongodb自带命令查看其内存使用情况
db.serverStatus().mem
db.stats()
oplogSizeMB
验证oplog的当前大小
use local
db.oplog.rs.stats().maxSize
Oplog状态
rs.printReplicationInfo()
db.getReplicationInfo()
更改副本集成员的oplog大小
db.adminCommand({replSetResizeOplog: 1, size: 16000})
内存调整：
wiredTigerCacheSizeGB=90
通过 db.currentOp() 查看正在执行的操作，目的到底是什么？
以下示例返回有关db1运行时间超过50秒的数据库的所有活动操作的信息，去掉"ns" : /^db1\./，查整个数据库：
db.currentOp(
{
"active" : true,
"secs_running" : { "$gt" : 50 },
"ns" : /^db1\./
}
)
以下示例返回有关从未产生的所有活动运行操作的信息：
db.currentOp(
{
"active" : true,
"numYields" : 0,
"waitingForLock" : false
}
)
并不是说我们要将正在执行的操作都列出来，然后通过 killOp 逐个干掉；这一步的目的是要看一下，是否有「意料之外」的耗时请求正在执行。
比如你的业务平时 CPU 利用率不高，运维管理人员连到数据库执行了一些需要全表扫描的操作，然后突然 CPU 利用率飙高，导致你的业务响应很慢，那么就要重点关注下那些执行时间很长的操作。
一旦找到罪魁祸首，拿到对应请求的 opid，执行 db.killOp(opid) 将对应的请求干掉。
MongoDB 支持 profiling 功能，将请求的执行情况记录到同DB下的 system.profile 集合里，profiling 有3种模式
0 分析器已关闭，不会收集任何数据。这是默认的探查器级别。
1 探查器收集的数据用于超过值的操作slowms。
2 分析器收集所有操作的数据。
查看分析级别：
monogodb>db.getProfilingLevel() #单独返回级别
monogodb>db.getProfilingStatus()
设置分析级别：
monogodb>db.setProfilingLevel(2) #设置分析级别，默认{ slowms: 100 }
monogodb>db.setProfilingLevel(1,20) #设置分析级别，并将mongod实例的慢速操作阈值设置为 20毫秒
取消分析器：
monogodb>db.setProfilingLevel(0)
针对所有请求开启 profiling，将所有请求的执行都记录到 system.profile 集合
针对慢请求 profiling，将超过一定阈值的请求，记录到system.profile 集合
官网：https://docs.mongodb.com/manual/tutorial/manage-the-database-profiler/
查看最近3条 慢请求，{$natrual: -1} 代表按插入数序逆序
db.system.profile.find().sort({$natrual: -1}).limit(3)
官网：https://docs.mongodb.com/manual/reference/database-profiler/
CPU杀手1：全表扫描
全集合（表）扫描 COLLSCAN，当一个查询（或更新、删除）请求需要全表扫描时，是非常耗CPU资源的，所以当你在 system.profile 集合 或者 日志文件发现 COLLSCAN 关键字时，就得注意了，很可能就是这些查询吃掉了你的 CPU 资源；确认一下，如果这种请求比较频繁，最好是针对查询的字段建立索引来优化。
一个查询扫描了多少文档，可查看 system.profile 里的 docsExamined 的值，该值越大，请求CPU开销越大。
CPU杀手2：不合理的索引
有的时候，请求即使查询走了索引，执行也很慢，通常是因为索引建立不太合理（或者是匹配的结果本身就很多，这样即使走索引，请求开销也不会优化很多）。
一个走索引的查询，扫描了多少条索引，可查看 system.profile 里的 keysExamined 字段，该值越大，CPU 开销越大。
关键字：IXSCAN、keysExamined
CPU杀手3：大量数据排序
当查询请求里包含排序的时候，如果排序无法通过索引满足，MongoDB 会在内存李结果进行排序，而排序这个动作本身是非常耗 CPU 资源的，优化的方法仍然是建立索引，对经常需要排序的字段，建立索引。
当你在 system.profile 集合 或者 日志文件发现 SORT 关键字时，就可以考虑通过索引来优化排序。当请求包含排序阶段时， system.profile 里的 hasSortStage 字段会为 true。
关键字：SORT、hasSortStage
其他还有诸如建索引，aggregationv等操作也可能非常耗 CPU 资源，但本质上也是上述几种场景；建索引需要全表扫描，而vaggeregation 也是遍历、查询、更新、排序等动作的组合。
