MongoDB 常见问题处理

MongoDB 常见问题处理

       说明： 这里的问题是我在看MongoDB官网文章时，从里面总结出来的。

mongod process "disappeared" ：

           这个说的是mongodb进行消失，可以理解为死掉等。可以从下面中找问题在

               #grep mongod /var/log/messages

               #grep score /var/log/messages

Socket errors in sharded clusters and replica sets ：

          echo 300 > /proc/sys/net/ipv4/tcp_keepalive_time 默认是 7200

关于 tomm many open files:

           First: 检查以下几项：

          lsof | grep mongod

          lsof | grep mongod | grep TCP

          lsof | grep mongod | grep data | wc

       可以用： ulimit 解决 : ulimit -n X

High TCP Connection Count ：

TCP Connection 过大时，可以检查是不是 client apps 使用连接池问题

Mongod (hard) connection limit

            这个连接数限制在 20000 ，可以手动调整大小

Data files count with very large databases

            数据在 T 级以上时，确定是否做了限制（手动增加），再用 repairdatabase 时，会同时有 2 copies

No space left on device

            这个时候 reads 仍然在进行，要做的是 first shutdown servers, then to delete some      data and compact

     Checking Siez of a collection( 检查集合）

              >db.(collectionname).validate();

NUMA ：

       Linu,Numa and MongoDB 不能很好的一起工作。如果机器在 numa 硬件运行的时候，需要把它关闭。一般出现大规模性能慢下来或一段时间 cpu 占用很高的 system time 。可以从日志中抓取 NUMA 字。（我也翻译不出这个NUMA是什么意思）

关闭的方法：一：在启动 mongoDB 的时候：

                    numactl --interleave=all ${MONGODB_HOME}/bin/mongod --config conf/mongodb.conf

                   二：在不关闭 mongoDB 时：

                   echo 0 > /proc/sys/vm/zone_reclaim_mod

         案例： http://blog.csdn.net/weiyuanke/article/details/7639915 或 http://huoding.com/2011/08/09/104 或 http://www.ttlsa.com/html/1211.html

NFS：

            官网不建意采用 NFS 系统文件运行 mongoDB, 因为 NFS 版本问题会导致性能很低或无法工作

SSD ：

          mongoDB 在 SSD （固态硬盘）运行很快，但是比 RAM 低。可以用 mongoperf 进行硬盘性能状态分析。

Virtualization：

            mongoDB 在虚拟化上运行的很好，如 OpenVZ 兼容 EC2 ， VMWare 也可以但是 clone 的时候会出现一些问题由其在 a member of a replica set( 一个复制节点上），要想可用的，需要 journaling 处在可用状态，再进行 clone 。如果没有的开启 journaling 的时候， stop m ongod ,clone, and tehn restart     

        注意：在 MongoDB 中要用 IP 地址不要使用机器名或 localhost ，不然会出现链接不数据库的。

Journal （日志）：

日志的开启： --journal ；关闭： --nojournal , 默认时间是 100ms

              启动时会在数据目录下创建一个 journal 地文件目录，在受到毁坏时，再启动 mongoDB 不需要再运行 repair ，它会自动恢复的。

               可以通过运行 journalLatencyTest 测试写入磁盘的性能和同步性能。

                >use admin

                >db.runCommand("journalLatencyTest")

Backup with --journal 中 journal 是支持回滚恢复。

journaling 的时候， stop m ongod ,clone, and tehn restart     

        注意：在 MongoDB 中要用 IP 地址不要使用机器名或 localhost ，不然会出现链接不数据库的。

The Linux Out of Memory OOM Killer ：

情况一：

Feb 13 04:33:23 hostm1 kernel: [279318.262555] mongod invoked oom-killer: gfp_mask=0x1201d2, order=0, oomkilladj=0

    这是因为内存溢出导致 mongodb 进程被刹死

情况二：

   内在没有溢出，能过 db..serverStatus() 或 mongostat 查看内存 virtualbytes - mappedbytes 的界限

情况三：

    ulimit 的限制

t:minor-latin; mso-fareast-font-family:宋体;mso-fareast-theme-font:minor-fareast;mso-hansi-font-family: Calibri;mso-hansi-theme-font:minor-latin'>中 journal 是支持回滚恢复。

journaling 的时候， stop m ongod ,clone, and tehn restart     

        注意：在 MongoDB 中要用 IP 地址不要使用机器名或 localhost ，不然会出现链接不数据库的。

mongodb 占用空间过大的原因，在官方的 FAQ 中，提到有如下几个方面：

 1 、空间的预分配：为避免形成过多的硬盘碎片， mongodb 每次空间不足时都会申请生成一大块的硬盘空间，而且申请的量从 64M 、 128M 、 256M 那样的指数递增，直到 2G 为单个文件的最大体积。随着数据量的增加，你可以在其数据目录里看到这些整块生成容量不断递增的文件。

         2 、字段名所占用的空间：为了保持每个记录内的结构信息用于查询， mongodb 需要把每个字段的 key-value 都以 BSON 的形式存储，如果 value 域相对于 key 域并不大，比如存放数值型的数据，则数据的 overhead 是最大的。一种减少空间占用的方法是把字段名尽量取短一些，这样占用空间就小了，但这就要求在易读性与空间占用上作为权衡了。我曾建议作者把字段名作个 index ，每个字段名用一个字节表示，这样就不用担心字段名取多长了。但作者的担忧也不无道理，这种索引方式需要每次查询得到结果后把索引值跟原值作一个替换，再发送到客户端，这个替换也是挺耗费时间的。现在的实现算是拿空间来换取时间吧。

         3 、删除记录不释放空间：这很容易理解，为避免记录删除后的数据的大规模挪动，原记录空间不删除，只标记“已删除”即可，以后还可以重复利用。

RepairDatabase 命令：

  数据库总会出现问题的，关于修复的方法如下：

运行 db.repairDatabase() 来整理记录，但这个过程会比较缓慢。

当MongoDB做的是副本集群时：可以直接把数据rm掉，然后再重新启动。

        当在不是 primariy server 上运行时，会得到一个 "clone failed for wkgbc with error: query failed wkgbc.system.namespaces"

  解决方法： 为了修复，需要 restart server 不加 --replSet 选项并且要选用不同的端口

LINUX 下找出哪个进程造成的 IO 等待很高的方法：

       可以判断是不是IO问题造成的：

#/etc/init.d/syslog stop           #echo 1 > /proc/sys/vm/block_dump           #dmesg |egrep "READ|WRITE|dirtied"|egrep -o '([a-zA-Z*])'|sort|uniq -c|sort -rn|head

下面是从网上找的案例：

昨天我访问 mongodb 的 python 程序开始出错，经常抛出 AssertionError 异常，经查证只是 master 查询异常， slave 正常，可判断为 master 的数据出了问题。

修复过程：

1 、在 master 做 db.repairDatabase() ，不起作用； 这个时间很长

2 、停止 slave 的同步；

3 、对 slave 作 mongodump ，备份数据；

4 、对 master 作 mongostore ，把备份数据恢复，使用�C drop 参数可以先把原表删除。

5 、恢复 slave 的同步。

实例二：碎片整理 -replSet 架构

1 、 rs.freeze(60)    在 60s 内该机器无法成为 primary

2 、在 primary 机上进行 rs.stepDown([120]) 让该机器成为从节点且在 120s 内不会成为 primary

3 、在 primary 上 ，可以将 data 的数据删掉 ，启动。数据会自动两步上去的。