mongodb异常退出
遇到过好几次mongos异常退出，google了多次，包括升级到最新的2.0.7版本之后，该问题一直存在，表现出来的是，当压力增大之后，会在某个时刻退出，日志中典型的错误如下:
Fri Aug 17 21:22:40 [mongosMain] connection accepted from
192.168.0.50:3
Logstream::get called in uninitialized state
Logstream::get called in uninitialized state
Fri Aug 17 21:22:40 [mongosMain] dbexit:&
Fri Aug 17 21:22:40 [conn2104]&&
Assertion failure ! inShutdown() client/connpool.cpp 136
Received signal 6
Backtrace: 0x52b5f6 0x58d8 0x562a4b 0x5c55aa 0x5c4030
0x5c507 0x777aac 0x7bc89c1 0x5ed
0x3d342e767d
0x54e5b5 0x3dx3d 0x3dx3d3422ba1e
0x3d3422bae0 0x5e9f04 0x3dx3d342e767d&
CursorCache at shutdown -& sharded: 0 passthrough:
RReceived signal 11
Backtrace: 0x54e5b5 0x3dx3dx7ce9c1a
0x3dx3d342e767d
Logstream::get called in uninitialized state
Fri Aug 17 21:22:40 [conn2108] ERROR: Uncaught std::exception:
call to empty boost::function, terminating
Logstream::get called in uninitialized state
Fri Aug 17 21:22:40 [conn2108] dbexit:&
&./mongos(_ZN5mongo12sayDbContextEPKc+0x96)
[0x52b5f6]
&./mongos(_ZN5mongo8assertedEPKcS1_j+0xfb)
[0x53613b]
&./mongos(_ZN5mongo16DBConnectionPool4_getERKSsd+0x118)
[0x5628d8]
&./mongos(_ZN5mongo16DBConnectionPool3getERKSsd+0x3b)
[0x562a4b]
&./mongos(_ZN5mongo17ClientConnections13checkVersionsERKSs+0x1ba)
[0x5c55aa]
&./mongos(_ZN5mongo15ShardConnection5_initEv+0x2a0)
[0x5c4030]
&./mongos(_ZN5mongo15ShardConnectionC1ERKNS_5ShardERKSs+0x85)
[0x5c4595]
&./mongos(_ZN5mongo8Strategy7doQueryERNS_7RequestERKNS_5ShardE+0x57)
[0x769507]
&./mongos(_ZN5mongo14SingleStrategy7queryOpERNS_7RequestE+0x3fc)
[0x777aac]
&./mongos(_ZN5mongo7Request7processEi+0x187)
[0x7b6467]
&./mongos(_ZN5mongo21ShardedMessageHandler7processERNS_7MessageEPNS_21AbstractMessagingPortEPNS_9LastErrorE+0x71)
[0x7c89c1]
&./mongos(_ZN5mongo3pms9threadRunEPNS_13MessagingPortE+0x287)
[0x5e9747]
&/lib64/libpthread.so.0() [0x3d]
&/lib64/libc.so.6(clone+0x6d) [0x3d342e767d]
./mongos(_ZN5mongo17printStackAndExitEi+0x75)[0x54e5b5]
Logstream::get called in uninitialized state
Fri Aug 17 21:22:40 [conn2104] AssertionException while processing
op type : 2004 to : weibomsg.weibomsg_limitrelation :: caused by ::
0 assertion client/connpool.cpp:136
/lib64/libc.so.6[0x3d]
/lib64/libc.so.6(exit+0x35)[0x3d34235d05]
Received signal 6
Backtrace: 0x54e5b5 0x3dx3d 0x3d
0x3dx3d3422bae0 0x5e9f04 0x3dx3d342e767d
经过艰难困苦的跟进，最终发现这个问题是由于操作系统的ulimit
-u这个参数限制导致的。当一个用户所启动的进程/线程数超过这个值的时候，会导致无法创建新的线程/进程。而在mongodb中，
每当有一个新的请求，会fork一个线程（进程）来处理，而达到这个限制之后，会ᦅ现无法fork的情况，从而出错。
解决这个问题的方法很简单，就是将ulimit -u这个参数调大。另外，当出现一些无法理解的E9��题时，可以检查下ulimit
-a，看看里面的各种参数是否有太小的情况出现。下面是我们在使用中的一个ulimit的参数情况，供参考:
[root@mongodb_2 ~]# ulimit -a
size&&&&&&&&&
(blocks, -c) 0
size&&&&&&&&&&
(kbytes, -d) unlimited
scheduling
priority&&&&&&&&&&&&
size&&&&&&&&&&&&&&
(blocks, -f) unlimited
signals&&&&&&&&&&&&&&&&
(-i) 773690
max locked
memory&&&&&&
(kbytes, -l) 64
max memory
size&&&&&&&&
(kbytes, -m) unlimited
files&&&&&&&&&&&&&&&&&&&&&
(-n) 65536
size&&&&&&&&&&&
(512 bytes, -p) 8
POSIX message
queues&&&&
(bytes, -q) 819200
priority&&&&&&&&&&&&&
size&&&&&&&&&&&&&
(kbytes, -s) 10240
time&&&&&&&&&&&&&&
(seconds, -t) unlimited
processes&&&&&&&&&&&&&
(-u) 10240
memory&&&&&&&&&
(kbytes, -v) unlimited
locks&&&&&&&&&&&&&&&&&&&&&
(-x) unlimited
修改方法：
1、[root@mongodb_3 ~]# vi
/etc/security/limits.d/90-nproc.conf
# Default limit for number of user's processes to prevent
# accidental fork bombs.
# See rhbz #432903 for reasoning.
*&&&&&&&&&
Ulimit命令
设置限制&&&&
可以把命令加到profile文件里，也可以在/etc/security/limits.conf文件中定义
显示所有限制
core文件大小的上限
进程数据段大小的上限
shell所能创建的文件大小的上限
驻留内存大小的上限
堆栈大小的上限
每秒可占用的CPU时间上限
打开文件数的上限
进程数的上限
虚拟内存的上限
除可用Ulimit命令设置外，也可以在/etc/security/limits.conf文件中定义限制。
domino&type&item&value
domino是以符号@开头的用户名或组名，*表示所有用户，type设置为hard or soft。item指
定想限制的资源。如cpu,core nproc or maxlogins
。value是相应的限制值。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。后使用快捷导航没有帐号？
查看: 2478|回复: 6
启动MongoDB出错--repair
高级会员, 积分 608, 距离下一级还需 392 积分
论坛徽章:2
这周打算开始做MongoDB的作业，启动mongo server的时候发现起不了了。后来想想，上次做完作业，直接把虚拟机关了。可能强行关机，造成了数据库的损坏。后来想想，作为一款成熟的数据库产品，应该那么脆弱，可以修复才对。在修复过程中才发现，居然用上了老师上课讲的repair,本来还不知道在哪用呢。
出错信息：
Error: couldn't connect to server 127.0.0.1 shell/mongo.js:84
原因：mongodb不正常关闭造成的mongodb被锁定，这算是一个Mongod 启动的一个常见错误，非法关闭的时候，lock 文件没有remove，第二次启动的时候检查到有lock 文件的时候，就报这个错误了。
solution（查看log可以发现）：
1）首先删除/var/lib/mongo/目录下的mongod.lock文件
rm /var/lib/mongo/mongod.lock
<font color="#) repair方式启动mongodb
mongod -f /etc/mongod.conf --repair
<font color="#) 再启动一次mongodb
这里一定要再启动一次，不然启动client端仍然连不到server
mongod -f /etc/mongod.conf
高级会员, 积分 758, 距离下一级还需 242 积分
论坛徽章:10
也可以重新指定一个repairPath
高级会员, 积分 608, 距离下一级还需 392 积分
论坛徽章:2
nathanzhn 发表于
也可以重新指定一个repairPath
什么意思？可以给个命令吗？
高级会员, 积分 758, 距离下一级还需 242 积分
论坛徽章:10
gigglehou 发表于
什么意思？可以给个命令吗？
mongod --dbpath /etc/mongo/db --repair --repairPath /etc/mongo/db0
高级会员, 积分 608, 距离下一级还需 392 积分
论坛徽章:2
nathanzhn 发表于
mongod --dbpath /etc/mongo/db --repair --repairPath /etc/mongo/db0
高级会员, 积分 794, 距离下一级还需 206 积分
论坛徽章:17
谢谢了，我也遇到好几次这样的问题。1、count统计结果错误
这是由于分布式集群正在迁移数据，它导致count结果值错误，需要使用aggregate pipeline来得到正确统计结果，例如：
db.collection.aggregate([{$group: {_id: null, count: {$sum: 1}}}])
引用：&On a sharded cluster, count can result in an inaccurate count if orphaned documents exist or if a chunk migration is in progress.&
2、从shell中更新/写入到文档的数字，会变为float类型
引用：&shell中的数字都被MongoDB当作是双精度数。这意味着如果你从数据库中获得的是一个32位整数，修改文档后，将文档存回数据库的时候，这个整数也就被换成了浮点数，即便保持这个整数原封不动也会这样的。&
3、restore数据到新DB时，不要去先建索引
把bson数据文件restore到另一个DB时，需要注意：不能先创建索引再restore数据，否则性能极差，mongorestore工具默认会在restore完数据时，根据dump出来的index信息创建索引，无须自己创建，如果是要更换索引，也应该在数据入库完之后再创建。
4、DB中的namespace数量太多导致无法创建新的collection
错误提示：error: hashtable namespace index max chain reached:1335，如何解决呢？
这是DB中的collection个数太多导致，在实践中以每个collection 8KB计算（跟官方文档里说的不同，可能跟index有关系），256MB可以支持36000个collection。db.system.namespaces.count() 命令可以统计当前DB内的collection数目，DB可支持collection数量是由于nssize参数指定的，它指定了dbname.ns磁盘文件的大小，也就指定了DB可支持的最大collection数目，ns为namespace缩写。默认nssize为16MB。
如果重启MongoD并修改了nssize参数，这新nssize只会对新加入的DB生效，对以前已经存在的DB不生效，如果你想对已经存在的DB采用新的nssize，必须在加大nssize重启之后新建DB，然后把旧DB的collection 复制到新DB中。
namespace限制相关文档：http://docs.mongodb.org/manual/reference/limits/#Number-of-Namespaces
5、moveChunk因旧数据未删除而失败
错误日志：&moveChunk failed to engage TO-shard in the data transfer: can't accept new chunks because there are still 1 deletes from previous migration&。
意思是说，当前正要去接受新chunk 的shard正在删除上一次数据迁移出的数据，不能接受新Chunk，于是本次迁移失败。这种log里显示的是warning，但有时候会发现shard的删除持续了十几天都没完成，查看日志，可以发现同一个chunk的删除在不断重复执行，重启所有无法接受新chunk的shard可以解决这个问题。
如果采用了balancer自动均衡，那么可以加上_waitForDelete参数，如：
{ "_id" : "balancer", "activeWindow" : { "start" : "12:00", "stop" : "19:30" }, "stopped" : false, "_waitForDelete" : true }
这样就不会因delete堆积而导致后续migrate失败，当然，需要考虑到这里的阻塞是否会影响到程序正常运转，在实践中慎重采用使用waitForDelete，因为发现加上它之后迁移性能非常差，可能出现卡住十几个小时的情况，外界拿住了被迁移chunk的游标句柄，这时候删除不能执行，阻塞了后续其它迁移操作。
游标被打开而导致被迁移数据无法及时删除时的日志：
T10:21:20.118+0800 [RangeDeleter] rangeDeleter waiting for open cursors in: cswuyg_test.cswuyg_test,
min: { _id: -4277348 }, max: { _id: -1867067 }, elapsedSecs: 6131244, cursors: [
这可能会卡住几十小时，甚至一直卡住，影响后续的moveChunk操作，导致数据不均衡。
解决方法还是：重启。
6、bson size不能超过16MB的限制
单个文档的BSON size不能超过16MB。find查询有时会遇到16MB的限制，譬如使用$in 查询的时候，in中的数组元素不能太多。对一些特殊的数据源做MapReduce，MapReduce中间会将数据组合为&KEY：[VALUE1、VALUE2]&这样的格式，当value特别多的时候，也可能会遇上16MB的限制。
限制无处不在，需要注意，&The issue is that the 16MB document limit applies to everything - documents you store, documents MapReduce tries to generate, documents aggregation tries to return, etc.
7、批量插入
批量插入可以减少数据往服务器的提交次数，提高性能，一般批量提交的BSON size不超过48MB，如果超过了，驱动程序自动修改为往mongos的多次提交。
8、安全写入介绍及其沿革
关键字：acknowledge、write concern。
在2012年11月之前，MongoDB驱动、shell客户端默认是不安全写入，也就是fire-and-forget，动作发出之后，不关心是否真的写入成功，如果这时候出现了_id重复、非UTF8字符等异常，客户端不会知道。在2012年11月之后，默认为安全写入，安全级别相当于参数w=1，客户端可以知道写入操作是否成功。如果代码使用Mongo或者Collection来连接数据库，则说明它是默认不安全写入的legacy代码，安全写入已经把连接数据库修改为MongoClient接口。
安全写入可以分为三个级别：
第一级是默认的安全写入，确认数据写入到内存中就返回（w=N属于这一级）；
第二级是Journal save，数据在写入到DB磁盘文件之前，MongoDB会先把操作写入到Journal文件，这一级指的是确认写入了Journal文件就返回；
第三级是fysnc，所有数据刷写到到DB磁盘文件才返回。
一般第一级就足够了，第二级是为了保证在机器异常断电的情况下也不会丢失数据。安全写入要付出性能的代码：不安全写入的性能大概是默认安全写入的3倍。使用fync参数则性能更差，一般不使用。
如果是副本集（replica set），其w=N参数，N表示安全写入到多少个副本集才返回。
9、善用索引&&可能跟你以为的不一样
使用组合索引的时候，如果有两组索引，在限量查询的情况下，可能跟常规的认识不同：
利用组合索引做的查询，在不同数量级下会有不同性能：
组合索引A： {"age": 1, "username": 1}
组合索引B： {"username": 1, "age": 1}
全量查询： db.user.find({"age": {"$gte": 21, "$lte": 30}}).sort({"username" :1})，使用索引A的性能优于索引B。
限量查询： db.user.find({"age": {"$gte": 21, "$lte": 30}}).sort({"username": 1}).limit(1000)，使用索引B的性能优于索引A。
这两个查询在使用索引A的时候，是先根据age索引找到符合age的数据，然后再对这些结果做排序。使用索引B的时候，是遍历name，对应的数据判断age，然后得到的结果是name有序的。
优先使用sort key索引，在大多数应用上执行得很好。
10、查询时索引位置的无顺序性
做find的时候，并不要求索引一定要在前面，
db.test集合中对R有索引
db.test.find({R:"AA", "H": "BB"}).limit(100).explain()
db.test.find({"H":"BB", R" : "AA"}).limit(100).explain()
这两个查找性能一样，它都会使用R索引。
11、使用组合索引做shard key可以大幅度提高集群性能
&固定值+增量值& 两字段做组合索引可以有效的实现分布式集群中的分散多热点写入、读取。以下为读书笔记：在单个MongoDB实例上，最高效的写入是顺序写入，而MongoDB集群则要求写入能随机，以便平均分散到多个MongoDB实例。所以最高效的写入是有
多个局部热点：在多个MongoDB实例之间是分散写入，在实例内部是顺序写入。 要实现这一点，我们采用组合索引。
例如：shardkey的第一部分是很粗糙的，可选集很少的字段，索引的第二部分是递增字段，当数据增加到一定程度时，会出现很多第一部分相同第二部分不同的chunk，数据只会在最后一个chunk里写入数据，当第一部分不同的chunk分散在多个shard上，就实现了多热点的写入。如果在一个shard上，不止一个chunk可以写入数据，那也就是说不止一个热点，当热点非常多的时候，也就等同于无热点的随机写入。当一个chunk分裂之后，只能有一个成为热点，另一个不能再被写入，否则就会产生两个热点，不再写入的chunk也就是死掉了，后续只会对它有读操作。
我在实践中除了书中讲到的组合键方式外，还加上了预分片策略，避免了早期数据增长过程中的分片和数据迁移。另外还尽可能的制造能利用局部性原理的数据写入，例如在数据写入之前先对数据排序，有大约30%左右的update性能提升。
预分片是这样子做的：根据组合shardkey信息先分裂好chunk，把这些空chunk移动到各个shard上，避免了后续自动分裂引起的数据迁移。
12、怎么建索引更能提高查询性能？
在查询时，索引是否高效，要注意它的cardinality（cardinality越高表示该键可选择的值越多），在组合索引中，让cardinality高的放在前面。注意这里跟分布式环境选择shard key的不同。以下为读书笔记：
index cardinality（索引散列程度），表示的是一个索引所对应到的值的多少，散列程度越低，则一个索引对应的值越多，索引效果越差：在使用索引时，高散列程度的索引可以更多的排除不符合条件的文档，让后续的比较在一个更小的集合中执行，这更高效。所以一般选择高散列程度的键做索引，或者在组合索引中，把高散列程度的键放在前面。
13、非原地update，性能会很差
update文档时，如果新文档的空间占用大于旧文档加上它周围padding的空间，那么就会放弃原来的位置，把数据拷贝到新空间。
14、无法在索引建立之后再去增加索引的过期时间
如果索引建立指定了过期时间，后续要update过期时间可以这样子：db.runCommand({"collMod":"a", index:{keyPattern:{"_":-1}, expireAfterSeconds: 60}})。
注意，通过collMod能修改过期时间的前提是：这个索引有过期时间，如果这个索引之前没有设置过期时间，那么无法update，只能删了索引，重建索引并指定过期时间。
15、_id索引无法删除
16、paddingFactor是什么？
它是存储空间冗余系数，1.0表示没有冗余，1.5表示50%的冗余空间，有了冗余空间，可以让后续引发size增加的操作更快（不会导致重新分配磁盘空间和文档迁移），一般是在1到4之间。可以通过db.collection.stats()看到collection的该值&paddingFactor&。
该值是MongoDB自己处理的，使用者无法设置paddingFactor。我们可以在compact的时候对已经有的文档指定该值，但这个paddingFactor值不影响后续新插入的文档。
repairDatabase跟compact类似，也能移除冗余减少存储空间，但冗余空间少了会导致后续增加文档size的update操作变慢。
虽然我们无法设置paddingFactor，但是可以使用usePowerOf2Sizes保证分配的空间是2的倍数，这样也可以起到作用（MongoDB2.6版本起默认启用usePowerOf2Size）。
或者手动实现padding：在插入文档的时候先用默认字符占用一块空间，等到真实数据写入时，再unset掉它。
17、usePowerOf2Size是什么
这是为更有效的复用磁盘空间而设置的参数：分配的磁盘空间是2的倍数，如果超过了4MB，则是距离计算值最近的且大于它的完整MB数。可以通过db.collections.stats()看到该值&userFlags&。MongoDB2.6之后默认开启usePowerOf2Size参数使用后的效果可以看这里的PPT：http://www.slideshare.net/mongodb/use-powerof2sizes-
18、aggregate pipeline 指定运算完成输出文档跟MapReduce相比有不足
（基于MongoDB2.6版本）MapReduce可以指定输出到特定的db.collection中，例如：out_put = bson.SON([("replace", "collection_name" ), ("db", "xx_db")])
aggregate pipeline只能指定collection名字，也就意味着数据只能写入到本db，同时结果不能写入到capped collection、shard collection中。
相比之下，aggregate pipeline限制是比较多的，如果我们需要把结果放到某个DB下，则需要再做一次迁移：db.runCommand({renameCollection:"sourcedb.mycol",to:"targetdb.mycol"})
但是！！上面的这条命令要求在admin下执行，且只能迁移往同shard下的DB，且被迁移的collection不能是shard的。
附错误码信息：
/mongodb/mongo/blob/master/src/mongo/s/commands_public.cpp#L778 uassert(13140, "Don't recognize source or target DB", confFrom && confTo); uassert(13138, "You can't rename a sharded collection", !confFrom-&isSharded(fullnsFrom)); uassert(13139, "You can't rename to a sharded collection", !confTo-&isSharded(fullnsTo)); uassert(13137, "Source and destination collections must be on same shard", shardFrom == shardTo);
19、杀掉MongoD进程的几种方式
1）进入到MongoD的命令行模式执行shutdown，
$ mongo --port 10001& use admin& db.shutdownServer()
2）1方式的简化：
eg：mongo admin --port 10001 --eval "db.shutdownServer()"
3）使用MongoD命令行关闭，需要指定db路径：
mongod --dbpath ./data/db --shutdown
20、集群的shard key慎重采用hash
如果你的日志是有日期属性的，那么shard key不要使用hash，否则删除过期日志时无法成块删除；在更新日志的时候，也不能利用局部性原理，查找、更新、插入数据都会因此而变慢。一般来说，hash id应付小数据量时压力不大，但在数据量较大（热数据大于可用内存容量）时，CRUD性能极差，且会放大碎片对性能的影响：数据非常分散，当有过期日志被删除后，这些删除后的空间成为碎片，可能会因为磁盘预读策略被加载到内存中。另外，采用hash shard key还会浪费掉一个索引，浪费不少空间。
21、副本数也不用太多
如果你的副本数量超过了12个（MongoDB3.0.0超过了50个），那么就要选择使用 master-slave ，但这样会失去故障自恢复功能，主节点故障时，需要手动去切换到无故障节点。
22、mongos的config server配置信息中不要使用localhost、127.0.0.1
启动mongos时，config server的配置信息不得使用localhost、127.0.0.1，否则添加其它机器的shard时，会出现错误提示："can&t use localhost as a shard since all shards need to communicate. either use all shards and configdbs in localhost or all in actual IPs host: xxxxx isLocalHost"
以新的config server启动mongos，也需要重启config server，否则会有错误提示：&could not verify config servers were active and reachable before write&
如果改完后面又出现 &mongos specified a different config database string& 错误，那么还需要重启mongod，
修改了config server 几乎是要全部实例重启。另外，在配置replica set时也不得使用localhost、127.0.0.1。
23、shard key的选择跟update性能紧密关联
分布式MongoDB，shard key的选择跟update性能，甚至是update可用性有很大关系，需要注意。
1、在对文档个别字段update时，如果query部分没有带上shard key，性能会很差，因为mongos需要把这条update语句派发给所有的shard 实例。
2、当update 的upsert参数为true时，query部分必须带上 shard key，否则语句执行出错，例子：
mongos& db.test.update({"_id":".A92327A89ABCD70D46AD5"},
{"$set":{"P": "aaa"}, "$setOnInsert":{"TEST":"a"}}, true)WriteResult({ "nMatched" : 0, "nUpserted" : 0, "nModified" : 0, "writeError" : { "code" : 61, "errmsg" : "upsert { q: { _id: \".A92327A89ABCD70D46AD5\" },
u: { $set: { P: "aaa" }, $setOnInsert: { TEST: \"a\" } },
multi: false, upsert: true } does not contain shard key for pattern { _: 1.0, B: 1.0 }" }})
这是因为如果没有shard key，mongos既不能在所有shard实例上执行这条语句（可能会导致每个shard都插入数据），也无法选择在某个shard上执行这条语句，于是出错了。
另外，需要特别注意，如果使用pymongo引擎，它不会告诉你出错了，只是函数调用陷入不返回，在shell下执行才能看到错误信息。
It's actually not clear to me that this is something we can support - problem is this:
& db.coll.update({ _id : 1 }, { }, true);& db.coll.find(){ "_id" : ObjectId("bc4d46c176f14a") }
Upserts generate new _ids in response to this operation, and therefore we can't actually target this correctly in a sharded environment. The shard on which we need to perform the query may not be the shard on which the new _id is placed.
意思是说，upsert产生了新的_id，_id就是shard key，但是如果query里没有shard key，它们不知道要到哪个shard上执行这个命令，upsert产生的shard key可能并不是执行这条命令的shard的。
另外，如果_id不是shard key我们的例子也是不能成功的，因为没有shard key，这条upsert要在哪个shard上执行呢？不能像普通update那样给所有的shard去做，否则可能导致插入多条。
24、通过repairDatabase提高性能
从db.stats()中可以看到几个跟碎片相关的关键字段，dataSize，表示数据的大小，它包含了padding的空间；storageSize，表示这些数据存储占用的空间，包含了dataSize和被删除数据所占空间，可以认为storageSize/dataSize就是磁盘碎片比例，当删除、update文档比较多后，它会变大，考虑做repairDatabase，以减少碎片让数据更紧凑，在实践中，这对提高CURD性能极其有用。repairDatabase时需要注意：它是把数据拷贝到新的地方，然后再做处理，所以repair之前在DB目录所在磁盘需要预留一倍的空闲磁盘空间，如果你发现磁盘空间不足，可以停止服务，然后增加一块新磁盘，再执行实例级别的repair，并指定--repairpath为新磁盘路径，eg：mongod --dbpath /path/to/corrupt/data --repair --repairpath /media/external-hd/data/db，实例的数据会拷贝到/media/external-hd/data/db上做处理。
25、索引字段的长度不能大于1024字节
索引字段的长度不能大于1024字节，否则shell下会有插入错误提示："errmsg" : "insertDocument :: caused by :: 17280 Btree::insert: key too large to index&。
使用pymongo的&continue_on_error&参数，不会发出错误提示，要注意。
参考：http://docs.mongodb.org/manual/reference/limits/#Index-Key-Limit
26、修改索引的expireAfterSeconds之后，负载均衡失败
修改索引的expireAfterSeconds之后，负载均衡失败，出现错误提示
&T09:59:49.056+0800 [migrateThread] warning: failed to create index before migrating data.
idx: { v: 1, key: { _: -1 }, name: "__-1", ns: "cswuyg_test.cswuyg_test",
expireAfterSeconds: 5227200 } error: IndexOptionsConflict Index with name: __-1 already exists with different options
检查发生moveChunk的两个shard，并没有发现不一致，怀疑存在缓存，重启所有shard解决。
27、config DB无法写入
因config DB无法修改，只可读，导致drop、enablesharding失败：
config server 相关日志：T16:51:19.078+0800 [replmaster] local.oplog.$main Assertion failure isOk() src/mongo/db/storage/extent.h 80
mongos 相关日志： [LockPinger] warning: pinging failed for distributed lock pinger 'xxx:1234/xxx:544:'. : : caused by :: isOk()
重启、configdb做repair均无法解决。
最后通过dump、restore解决：
（1）把旧configdb dump出来；
（2）restore到新的configure server；
（3）mongos采用新的configure server；
（4）重启全部mongod。
阅读(...) 评论()}