MongoDB 2.6包含重要的授权模式修改，它会改变MongoDB存储用户凭据的方式。因此，除了升级MongoDB进程，如果你的应用程序使用了验证和授权，在升级所有的MongoDB进程到2.6之后，你必需也升级授权模式。
考量
完成所有其他升级需求
在升级授权模式前，你必须首先升级MongoDB二进制文件到2.6。对于分片集群，确保所有的集群组件是2.6。如果有用户在任意数据库，在升级MongoDB二进制文件前，确保至少有一个用户在admin数据库。
时机
因为在你升级用户授权模式后，降级更加困难，一旦你升级MongoDB二进制文件到2.6，允许MongoDB应用程序运行1到2天，而不用升级用户授权模式。
这给了2.6一些时间来预热，并减小了在用户权限模型升级后的降级可能性。
用户授权和访问空值将继续以2.4的方式来工作。但是将不能创建和修改用户、或使用用户定义角色，直到你运行授权升级。
如果你立刻决定升级用户授权模型，而不等待推荐的预热期，那么对于分片集群，在升级分片集群之后你必须等待至少10秒钟来运行授权升级脚本。
副本集
对于副本集，只需要在主成员运行升级进程，因为修改将会自动复制到辅助成员。
分片集群
对于分片集群，连接到mongos，运行升级过程来升级集群的授权数据。默认情况下，该过程也将会升级分片的授权数据。
为了覆盖这个行为，使用额外的参数upgradeShards:false运行升级命令。如果你选择覆盖，你必须首先在mongos运行升级过程，然后在每个分片的主成员运行该过程。
对于一个分片集群，对于配置服务器不直接运行升级进程。而是通过mongos实例实施升级进程来与配置数据库交互。
需求
为了升级授权模型，你必需有userAdminAnyDatabase角色的用户在admin数据库。
过程
1. 连接到MongoDB实例。
以userAdminAnyDatabase角色的admin数据库用户身份，对于单实例部署，连接和验证mongod实例，对于分片集群，连接和验证mongos。
2. 升级授权架构。
使用mongo shell，在admin数据库使用authSchemaUpgrade命令来更新用户数据。
运行authSchemaUpgrade命令：
db.getSiblingDB("admin").runCommand({authSchemaUpgrade: 1 });
当有错误时，可以安全返回authSchemaUpgrade命令。
分片集群authSchemaUpgrade考量：
对于分片集群，authSchemaUpgrade也将升级分片的授权数据，升级是完整的。然而，你也可以通过在命令中使用upgradeShards:false参数覆盖该行为，像如下示例：
db.getSiblingDB("admin").runCommand({authSchemaUpgrade: 1, upgradeShards: false });
如果你覆盖了该行为，当你在mongos实例上运行authSchemaUpgrade之后，在mongos上升级之后你将需要连接到每个分片的主成员，重复升级进程。
结果
2.6系统中的所有用户都存储在admin.system.users集合中。为了操作这些用户，使用用户管理方法。
升级过程拷贝2.4版本的admin.system.users集合到admin.system.backup_users。
升级过程原封不动保留2.4版本的<database>.system.users集合。
参考：
http://docs.mongodb.org/manual/release-notes/2.6-upgrade-authorization/
基于CentOS 6.5操作系统搭建MongoDB服务 http://www.linuxidc.com/Linux/2014-11/108900.htm