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版本的<database>.system.users集合。
参考:
http://docs.mongodb.org/manual/release-notes/2.6-upgrade-authorization/