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集合。

 

参考：