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

在本页面

• Considerations

• Requirements

• Procedure

• Result

MongoDB 2.6 对授权模型进行了重大更改，这要求更改 MongoDB 存储用户凭据的方式。因此，除了升级 MongoDB 进程以外，如果您的部署使用身份验证和授权，则在将所有 MongoDB 进程升级到 2.6 之后，您还必须升级授权模型。

Considerations

完成所有其他升级要求

在升级授权模型之前，您应该首先将 MongoDB 二进制文件升级到 2.6. 对于分片群集，请确保所有群集组件均为 2.6. 如果在任何数据库中都有用户，则在升级 MongoDB 二进制文件之前，请确保至少有一个userAdminAnyDatabase角色的用户在admin数据库中。

Timing

由于升级用户授权模型后降级更加困难，因此，一旦将 MongoDB 二进制文件升级到 2.6 版，就可以让您的 MongoDB 部署运行一两天而无需升级用户授权模型。

这允许 2.6 的时间“老化”，并降低了在用户特权模型升级后发生降级的可能性。用户身份验证和访问控制将 continue 像 2.4 中那样工作，但是，**，除非您运行授权升级，否则将无法创建或修改用户或使用用户定义的角色。

如果您决定立即升级用户授权模型，而不是 await 建议的“预烧”期，那么对于分片群集，必须在分片群集升级后至少 await10 秒才能运行授权升级脚本。

Replica Sets

对于副本集，只需在primary上运行升级过程，因为更改将自动复制到辅助副本。

Sharded Clusters

对于分片群集，请连接到mongos并运行升级过程以升级群集的授权数据。默认情况下，该过程还将升级分片的授权数据。

要覆盖此行为，请使用附加参数upgradeShards: false运行 upgrade 命令。如果选择覆盖，则必须先在mongos上运行升级过程，然后在每个分片的primary成员上运行该过程。

对于分片群集，请不要对config servers直接运行升级过程。而是使用一个mongos实例执行升级过程，以与配置数据库进行交互。

Requirements

要升级授权模型，您必须在admin数据库中具有角色userAdminAnyDatabase的用户。

Procedure

连接到 MongoDB 实例。

以角色userAdminAnyDatabase的admin数据库用户身份连接到单一部署的mongod实例并为分片群集的mongos进行身份验证。

升级授权架构。

在admin数据库中使用authSchemaUpgrade命令通过mongo Shell 更新用户数据。

运行 authSchemaUpgrade 命令。

db.adminCommand({authSchemaUpgrade: 1 });

如果发生错误，您可以安全地重新运行authSchemaUpgrade命令。

分片群集 authSchemaUpgrade 注意事项。

对于分片群集，authSchemaUpgrade也会升级分片的授权数据，并且升级已完成。但是，您可以通过在命令中包含upgradeShards: false来覆盖此行为，如以下示例所示：

db.adminCommand({authSchemaUpgrade: 1,
upgradeShards: false });

如果您覆盖了该行为，则在mongos实例上运行authSchemaUpgrade之后，您将需要为每个分片连接到主数据库，并在mongos上进行升级后重复升级过程。

Result

2.6 系统中的所有用户都存储在admin.system.users集合中。要操纵这些用户，请使用用户 Management 方法。

升级过程将版本 2.4 admin.system.users集合复制到admin.system.backup_users。

升级过程使版本 2.4 <database>.system.users集合保持完整。