MongoDB升级用户授权数据到2.6格式

寂寞大萝卜

　　MongoDB升级用户授权数据到2.6格式
　　
　　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版本的.system.users集合。
　　参考：
　　http://docs.mongodb.org/manual/release-notes/2.6-upgrade-authorization/