关于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 正本集节点品种

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

1. wiredTiger 是一个文档级别的并发管制，容许同一时间批改同一个汇合的不同文档。
2. wiredTiger 应用 mvcc 版本控制，所有的数据提供一个批改的快照 snapshot, 每隔一段时间将所有的快照写入，作为一个 checkpoint(数据恢复点)。
   同一时间只会有一个无效的 checkpoint。最新的生成，删除上一个。4.0+ 每 60s 生成一个 checkpoint。
3. 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 日志进行数据恢复。复原到宕机之前的状态。

1. wiredTiger 页面类型

   • 内存页面 磁盘页面解压，解决成内存的 page 格局。
   • 磁盘页面 磁盘页面是内存页面通过解决，并压缩而成的(reconcile)。磁盘页面能够间接输出磁盘。

2. 脏页类型

   • 齐全脏页：页面内的数据全部都是齐全提交的数据，和被笼罩的数据。刷盘时，删除笼罩数据(数据被屡次批改，以前的提交曾经不会被任何事务看见的数据)，将最新的数据页面 reconcile 成磁盘页面刷盘。(这类必定很少)
   • 不齐全脏页：除了齐全提交，还有未齐全提交，只有局部事务可见的数据。刷盘时，删除笼罩数据，将提交的数据刷盘，然而页面保留 modify 局部。
3. 缓存淘汰机制
   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 数据库复原官网计划：

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

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

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

mongo 社区

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

问题

1. 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 优化分享

分享的挺好的

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