记一次Mongodb中admin数据库导致的事故
前言
MongoDB副本集默认会创建local、admin数据库，local数据库主要存储副本集的元数据，admin数据库则主要存储MongoDB的用户、角色等信息。
Mongodb的gridfs一次插入数据的时候会自动创建几个索引，我们程序里面的账号没有createIndex权限，我需要手动创建一下。结果连接到mongo服务器之后忘记执行usexxxdb来切换数据库了，于是在admin数据库里面创建了一个索引，结果导出一边的程序报出来很多验证问题。
Mongo的admin数据库太脆弱了，只是创建一个索引就挂了。长个教训，以后千万不要手动修改它，更不要用admin保存数据。
反思一下，这次操作失误其实爆出我平时一些不好的习惯。
首先，连接mongo应该指定目标数据。而我之前都是连接到admin，然后用use切换到目标数据库。这样难免会忘记。
$#错误使用 $mongoourdomain.com/admin-utom-ptompass $#正确的使用 $mongoourdomain.com/mydb-utom-ptompass--authenticationDatabaseadmin
第二，错误的在admin数据库执行createIndex，返回的结果明确显示索引创建成功。
{
"createdCollectionAutomatically":true,
"numIndexesBefore":1,
"numIndexesAfter":2,
"ok":1,
...
}
但是我忽略了，继续在正确的数据库创建索引。不然可以早一些发现问题。
最后，创建索引应该自动化，比如gridfs这种对md5,filename创建索引的。
慎用admin数据库
当Mongod启用auth选项时，用户需要创建数据库帐号，访问时根据帐号信息来鉴权，而数据库帐号信息就存储在admin数据库下。
mongo-9551:PRIMARY>useadmin switchedtodbadmin mongo-9551:PRIMARY>db.getCollectionNames() ["system.users","system.version"]
- system.version存储authSchema的版本信息
- system.users存储了数据库帐号信息
- 如果用户创建了自定义的角色，还会有system.roles集合
用户可以在admin数据库下建立任意集合，存储任何数据，但强烈建议不要使用admin数据库存储应用业务数据，最好创建新的数据库。
admin数据库里的system.users、system.roles2个集合的数据，MongoDB会cache在内存里，这样不用每次鉴权都从磁盘加载用户角色信息。目前cache的维护代码，只有在保证system.users、system.roles的写入都串行化的情况下才能正确工作，详情参考官方issueSERVER-16092
从代码中我们可以看出，MongoDB将将admin数据库上的意向写锁(MODE_IX)直接升级为写锁(MODE_X)，也就是说admin数据库的写入操作的锁级别只能到DB级别，不支持多个collection并发写入，在写入时也不支持并发读取。如果用户在admin数据库里存储业务数据，则可能遭遇性能问题。
if(supportsDocLocking()||enableCollectionLocking){
if(supportsDocLocking()||enableCollectionLocking){
+
+//Thecheckfortheadmindbistoensuredirectwritestoauthcollections
+//areserialized(seeSERVER-16092).
+if(_id==resourceIdAdminDB&&!isRead){
+_mode=MODE_X;
+}
+
_lockState->lock(_id,_mode);
总结
以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对毛票票的支持。