关于mongodb:mongo的基本整理

mongo

mongo的根本命令

db.help() 查看db命令帮忙

rs.help() // 在mongod中执行

sh.help() // 数据库分片的相干指令，须要在mongos中执行。

db.listCommands() // mongo的所有的命令都能够应用 db.runCommand()执行

db.adminCommand({getParameter:”*”}) // 查看服务器的以后配置参数。 db.adminCommand({setParameter:1, enableFlowControl: false}) 能够批改对应的值，这里批改的是enableFlowControl设置为false.

mongo分片

shard 命令

sh.status()

sh.isBalancerRunning()

sh.enableSharding()

sh.shardCollection()

Sharded Cluster

shard：分片，个别每个分片由一个正本集形成。
mongos: 个别解决query路由器。提供client和 sharded cluster 接口
config servers : 存储元数据和config文件

主分片primary shard

在sharded cluster中，每个数据库都会设置主的shard，也就是如果这个数据库中的表没有启用分片，默认数据全副在这个分片。相似一般的正本集。

如果启动了分片，数据会根据分片的片键散布在多个shard中。

片键

sharded cluster的汇合如果启用了分片，须要设置指定的分片的片键，数据会根据片键调配到不同的shard中。片键须要思考的至多有三个方面分片建的基数，平率，枯燥性。

分片建的基数，如果分片建只有4个值，最多能够创立4个分片，再多的分片没有用，不会有数据路由下来。
分片建的频率，如果数据绝大数都是某个建值数据，那么就会造成数据而后绝大多数都在一个分片上，不能平均调配。
调配的枯燥性，如果枯燥增减的数据，可能因为一个范畴的数据被调配到一个分片，如工夫戳分片，那么一个时间段只会在一个分片上，此时相当于单分片写入。

mongoDB 正本集相干问题。

mongo 正本集命令

rs.status() // 查看mongo正本集状态.

rs.config() //查看正本集的配置，能够获取 writemajority的数目，正本节点的投票权等配置信息

rs.add(“host:port”) // 退出节点。

rs.remove(“host:port”) // 移除节点。

rs.addArb(“host:port”) // 退出仲裁节点

var config = rs.config() // 批改正本集的配置办法
config.members[1].priority=100 // 设置投票的优先级为 100
rs.reconfig(config) // 重新配置config

rs.printSecondaryReplicationInfo() // 查看从节点的oplog状态

rs.printReplicationInfo() // 查看节点的oplog信息

mongo oplog

mongo oplog是一个非凡的汇合，保留mongo的滚动的记录。汇合local.oplog.rs 。 oplog的大小默认是磁盘的5%，最大不超出50GB。

mongo的 readConcern https://docs.mongodb.com/v4.2…

mongo正本集节点

mongo正本集节点品种

primary 主节点，负责读写。写入Oplog，提供给secondary同步批改。
secondary节点，次要是用来备份主节点的数据，同步数据syschost 起源能够是主节点，也能够是另外一个从节点。当然如果你配置了读写拆散，也会负责读。个别不特地配置，默认都是不做读。
hidden 正本节点，暗藏节点，客户端看不见的节点。不能进行读，也不会成为primary。
提早节点。设置一个节点，容许和主节点存在肯定工夫的提早。个别不应用。
仲裁节点，只参加投票，然而不会进行读写。简直不会有资源的耗费。然而如果一个正本集是主–> 从 —> 仲裁，三个节点形成的正本集，如果一个主，或者从节点挂掉。就会变得只有主 –> 仲裁，导致无奈写入majority。触发flowcontrol重大升高写入速度。能够通过调大flowcontrol，或者先把flowcontrol设置为false。

mongo write majority, read majority
majority大多数是多少，所有的能够投票节点的一半以上。

正本集的flowControl机制

mongodb正本集写入时默认是写入majority，(1 + 节点数的一半。 3个节点时，majority=2)，如果P (primary) — S (secondary) –A (arbiter)， P ,S有一个节点挂掉或者从节点性能问题，重大落后主节点，会导致写入有余2个节点。而后新的P节点就会触发flowcontrol机制，限度写入，期待从节点赶上。有时为了让mongo先复原写速度，能够调节参数。

db.adminCommand({setParameter:1, flowControlMinTicketsPerSecond:10000}) // 能够调大flowcontrol的破绽的ticket的数目，

db.adminCommand({setParameter:1, enableFlowControl: false}) // 不行就间接敞开flowControl。

对于w:majority. 按道理说，服务器默认的写入是majority(rs.conf() 查看)，那么为什么没有触发客户端的期待呢？在客户端强制设置w:majority时，客户齐全hang申请（达不到w:majority时）。rs.conf()
“getLastErrorDefaults” : {

        "w" : 1,
        "wtimeout" : 0
    }

“writeConcernMajorityJournalDefault” : true, 这个字段示意的是，如果客户端写入为majority然而没有设置journal.那么默认也要期待写入journal。
getLastErrorDefaults 示意写入的确认个数，和等待时间。

{ w: <value>, j: <boolean>, wtimeout: <number> } // 在客户端指定写入为majority时，设置了超时工夫，就算返回超时，没有达到大多数。也是胜利写入了数据的。

mongo问题

mongo目前4.0+版本的默认存储引擎应用的wiredTiger存储引擎。mongo绝大数的问题可能都是须要调优wiredTiger.

wiredTiger

wiredTiger是一个文档级别的并发管制，容许同一时间批改同一个汇合的不同文档。
wiredTiger应用mvcc版本控制，所有的数据提供一个批改的快照snapshot,每隔一段时间将所有的快照写入，作为一个checkpoint(数据恢复点)。
同一时间只会有一个无效的checkpoint。最新的生成，删除上一个。4.0+每60s生成一个checkpoint。
jounal日志，相似mysql的redo log。保留checkpoint执行的数据批改。如果在新生成的checkpoint执行，mongo呈现宕机，能够通过最初的无效的checkpoint和jounal重放，把数据进行复原。

wiredTiger的tcmalloc

wiredTiger应用tcmalloc作为申请内存的组件。tcmalloc申请内存会在主机外部缓存起来，相似与外部保护一个内存池，不用每次从操作系统申请内存，开销小。然而问题是tcmalloc内存的开释的速度不可控，容易造成内存内存的free buffer过大，却没有还给操作系统。导致oom,mongo被kill。

能够通过db.serverStatus().tcmalloc查看tcmalloc内存的应用状况。

tcmalloc提供了开释速度字段来调节缓存的开释速度tcmallocReleaseRate，从0-9，0示意永不开释，默认是1，也不是越大越好开释越快，也就和原始的malloc没有什么区别了。如果能够设置为两头值，而后察看性能吧。

mongo命令： db.adminCommand({setParameter:1, tcmallocReleaseRate:4})

wiredTiger配置

wiredTigerConcurrentReadTransactions
容许并发读取的最大值，默认128，当压力大时，能够设置调大，个别不调节。
db.adminCommand( { setParameter: 1, wiredTigerConcurrentReadTransactions: <num> } )
wiredTigerConcurrentWriteTransactions
并发写最大数，默认128

能够查看： db.serverStatus().wiredTiger.concurrentTransactions

例子：
```
{
   "write" : {
      "out" : 0,
      "available" : 128,
      "totalTickets" : 128
   },
   "read" : {
      "out" : 3,
      "available" : 125,
      "totalTickets" : 128
   }
}
```
如果读写的available值为0，阐明有有排队，能够把值调大一些。
wiredTiger cacheSize
通过db.serverStatus().wiredTiger.cache 查看maximum bytes configured字段，为以后服务器的cachesize。如果须要调整，动静不重启调整
db.adminCommand({setParameter:1, wiredTigerEngineRuntimeConfig:’cache_size=600M’}) ，重启时生效. 也能够在mongo的配置文件批改，而后重启永恒失效。

wiredTiger的cache淘汰和checkpoint

wiredTiger

checkponit，每一段时间给dirty脏页（和汇合的文件不统一），生成一个快照，也就是数据长久化点。如果mongo重启，会读取最新的长久化点，复原之前的状态。(checkponit每60秒触发一次)
journal日志，mongo的批改预写日志，每100ms写入一次。如果mongo异样敞开，mongo读取最新的checkpoint和重放journal日志进行数据恢复。复原到宕机之前的状态。

wiredTiger页面类型
- 内存页面磁盘页面解压，解决成内存的page格局。
- 磁盘页面磁盘页面是内存页面通过解决，并压缩而成的(reconcile)。磁盘页面能够间接输出磁盘。
脏页类型
- 齐全脏页：页面内的数据全部都是齐全提交的数据，和被笼罩的数据。刷盘时，删除笼罩数据(数据被屡次批改，以前的提交曾经不会被任何事务看见的数据)，将最新的数据页面reconcile成磁盘页面刷盘。(这类必定很少)
- 不齐全脏页：除了齐全提交，还有未齐全提交，只有局部事务可见的数据。刷盘时，删除笼罩数据，将提交的数据刷盘，然而页面保留modify局部。
缓存淘汰机制
eviction_target 80 当 cache used 超过 eviction_target，后盾evict线程开始淘汰 CLEAN PAGE
eviction_trigger 95 当 cache used 超过 eviction_trigger，用户线程也开始淘汰 CLEAN PAGE
eviction_dirty_target 5 当 cache dirty 超过 eviction_dirty_target，后盾evict线程开始淘汰 DIRTY PAGE
eviction_dirty_trigger 20 当 cache dirty 超过 eviction_dirty_trigger, 用户线程也开始淘汰 DIRTY PAGE

mongo每次达到checkpoint时，dirty数据量大，导致一次生成的checkpoint数据过高。如果100G的cache，dirty 5%，大略每次要刷5G进入磁盘。(不确定，mongo dirty小于5%时也会淘汰吗？)
当dirty大于5%时，eviction线程开始淘汰脏页，刷盘。尽量使每次checkpoint刷盘的数据尽可少。
当dirty大于20%时，用户线程暂停业务解决，先帮助解决evict dirty page。此时业务的性能根本都很低。

内存应用低(默认配置时，cache 应用小于87.5%，或者dirty小于17.5%)
对于齐全页面间接和谐成磁盘页面刷盘，并将洁净page页面退出LRU，提供驱赶。
对于不齐全页，将能长久化的页面刷盘，不能删除的保留。只能开释其中的脏页modify的局部内容开释。

内存应用高
对于齐全脏页面间接和谐成磁盘页面刷盘，而后删除内存page。开释内存
对于不齐全脏页，将能长久化的页面刷盘，不能删除的保留。只能开释其中的脏页modify的局部内容开释。

P-S-A (主从，仲裁)
如果一个数据节点提早或者挂掉。导致无奈满足w:majority.触发flowcontol.同时也触发了r:majority https://docs.mongodb.com/v4.2…
那么导致所有的批改，不会失去确认，属于脏数据。导致数据提交点不会被提前。导致每次做checkponit都会将之前的数据从新做。也就导致checkponit的累赘也来越重。个别被确认的数据后续会刷入具体的collection文件，然而未被确认的数据会始终在checkpoint中。在PSA架构中，尽量把r:majority关掉。不然提早就会导致触发 r：majority问题。

wiredTiger问题

wiredTiger的缓存脏缓存占比。dirty过高会导致业务的线程参加页面淘汰。业务线程就会hang住了。

参考资料

mongo权威指南第二版

https://docs.mongodb.com/v4.2… // mongo serverStatus局部

问题参考

mongo数据库复原官网计划：

https://docs.mongodb.com/v4.2… 单机版
https://docs.mongodb.com/v4.2… // 正本集

mongo jira 能够查问或者提相干问题

https://jira.mongodb.org/brow…

mongo社区

https://www.mongodb.com/commu…

问题

mongo日志中呈现 “serverStatus was slow”
个别是服务器负载过重，cpu、或者磁盘。 mongo在没有显著提早的状况下无奈相应命令状态。
参考： https://www.mongodb.com/commu…

wiredTiger参考

https://www.percona.com/blog/… (checkpoint,和脏页的调优)

一篇机器翻译的wiredTIger文章
https://blogs.vicsdf.com/arti…

内存evict：
https://www.bookstack.cn/read…

https://www.freeaihub.com/pos…

readConcern:
https://www.bookstack.cn/read…

https://docs.mongodb.com/manu…

https://developer.aliyun.com/…

https://www.cnblogs.com/xibuh… // wiredTiger缓存模型

oppo mongodb优化分享

分享的挺好的

https://zhuanlan.zhihu.com/p/…
https://zhuanlan.zhihu.com/p/…

关于mongodb:mongo的基本整理

mongo

mongo的根本命令

mongo分片

shard 命令

Sharded Cluster

主分片primary shard

片键

mongoDB 正本集相干问题。

mongo 正本集命令

mongo oplog

mongo正本集节点

正本集的flowControl机制

mongo问题

wiredTiger

wiredTiger的tcmalloc

wiredTiger配置

wiredTiger的cache淘汰和checkpoint

wiredTiger问题

参考资料

问题参考

mongo社区

问题

wiredTiger参考

oppo mongodb优化分享

评论

发表回复取消回复

更多文章

DDN HPC 存储硬件架构设计深度分析

探秘IO500：从Lustre并行文件系统出发，开启HPC存储性能新征程

苹果iOS打包的ipa应用无法安装？一篇文章带你了解可能的原因及排查方法

图解Golang：从零开始实现简易版过期LRU缓存

关于mongodb:mongo的基本整理

mongo

mongo的根本命令

mongo分片

shard 命令

Sharded Cluster

主分片primary shard

片键

mongoDB 正本集相干问题。

mongo 正本集命令

mongo oplog

mongo正本集节点

正本集的flowControl机制

mongo问题

wiredTiger

wiredTiger的tcmalloc

wiredTiger配置

wiredTiger的cache淘汰和checkpoint

wiredTiger问题

参考资料

问题参考

mongo社区

问题

wiredTiger参考

oppo mongodb优化分享

评论

发表回复 取消回复

更多文章

DDN HPC 存储硬件架构设计深度分析

探秘IO500：从Lustre并行文件系统出发，开启HPC存储性能新征程

苹果iOS打包的ipa应用无法安装？一篇文章带你了解可能的原因及排查方法

图解Golang：从零开始实现简易版过期LRU缓存

发表回复取消回复