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/…