翻译或纠错本页面

降级 3.4 分片集群到 3.2¶

本页内容

降级路径
创建备份
预先准备
流程

在您尝试任何降级之前，请熟悉本文档的内容。

降级路径¶

一旦升级到3.4，您就不能降级到 3.2.7 或者之前的版本。您只可以降级到 3.2.8 或者之后的版本。

创建备份¶

可选，但是推荐。 创建您数据库的备份。

预先准备¶

在降级二进制之前，您必须降级功能兼容版本，并且删除所有与 3.2 或者之前版本 3.4 features incompatible ，如下面列出的功能所示。仅在 featureCompatibilityVersion 被设置为 "3.4" 的情况下。这些步骤是必要的。

1. Downgrade Feature Compatibility Version¶

连接一个 mongo shell 到 mongod 实例。
将 featureCompatibilityVersion 降级到 "3.2" 。
```
db.adminCommand({setFeatureCompatibilityVersion: "3.2"})
```
这个命令必须执行写操作到内部系统集合。如果由于任何原因该命令没有成功完整执行，由于该操作是幂等的，您可以安全地在 mongos instance 上重试该命令。

2. Remove Views¶

如果您之前定义过任何视图，在将MongoDB 3.4 降级到 3.2 之前删除视图。

连接一个 mongo shell 到 mongod 实例。

为了查找视图，您可以在 mongo shell上运行下列命令：

db.adminCommand("listDatabases").databases.forEach(function(d){
   let mdb = db.getSiblingDB(d.name);
   mdb.getCollectionInfos({type: "view"}).forEach(function(c){
      print(mdb[c.name]);
   });
});

对于每一个包括视图的数据库，删除 system.views 集合，以删除该数据库中的所有视图。

3. Remove Collation Option from Collections and Indexes¶

如果您之前已经定义过集合或索引的任何非 “简单” collation，在将MongoDB 3.4 降级到 3.2 之前删除集合或索引。

连接一个 mongo shell 到 mongod 实例。

为了查找collation 规范的集合，您可以在 mongo shell 中运行下列命令：

db.adminCommand("listDatabases").databases.forEach(function(d){
   let mdb = db.getSiblingDB(d.name);
   mdb.getCollectionInfos( { "options.collation": { $exists: true } } ).forEach(function(c){
      print(mdb[c.name]);
   });
});

您可以将集合的内容迁移到一个没有collation规范的新集合（一个方式是通过聚合管道阶段 $out ）。

为了查找collation 规范的索引，您可以在 mongo shell 中运行下列命令：

db.adminCommand("listDatabases").databases.forEach(function(d){
   let mdb = db.getSiblingDB(d.name);
   mdb.getCollectionInfos().forEach(function(c){
      let currentCollection = mdb.getCollection(c.name);
      currentCollection.getIndexes().forEach(function(i){
         if (i.collation){
            printjson(i);
         }
      });
   });
});

删除collation规范的索引。在降级之后，重新创建删除的索引。

4. Convert Data of Type Decimal¶

连接一个 mongo shell 到 mongod 实例。
转化所有 decimal 类型的数据。在MongoDB 3.4 版本之前，在包含 decimal 类型上的文档操作有可能会失败。您可以查阅 货币数据建模 了解一些可能的转化选项。

为了检查十进制的存在，您可以在可能包含十进制数据的集合上运行 db.collection.validate(true) 。

只有在 featureCompatibilityVersion 为 "3.2" 的时候， db.collection.validate(true) 才会报告十进制数据。

5. Downgrade Index Versions¶

如果您有 v: 2 索引（例如，如果 featureCompatibilityVersion: "3.4" ， MongoDB 3.4 中创建的索引默认版本），在降级MongoDB之前， reindex the collection 重新创建集合中的所有索引为 v: 1。

您必须在分片和配置服务器上都执行该操作：

连接一个 mongo shell 到 mongod 实例。

为了查找 v: 2 的索引，您可以在 mongo shell 中运行下列命令：

db.adminCommand("listDatabases").databases.forEach(function(d){
   let mdb = db.getSiblingDB(d.name);
   mdb.getCollectionInfos().forEach(function(c){
      let currentCollection = mdb.getCollection(c.name);
      currentCollection.getIndexes().forEach(function(i){
         if (i.v === 2){
            printjson(i);
         }
      });
   });
});

如果一个分片是复制集，在分片的每个成员中都重复这个操作，因为重建索引操作不会传递到从节点。

建议

如果连接 mongo shell 到一个从节点成员，设置 rs.slaveOk() 。
在配置服务器复制集的每个人员中重复该流程。

流程¶

考量¶

降级进行的过程中，您不能修改集合元数据。例如，在降级过程中，千万不要执行下面的任何操作：

sh.enableSharding()
sh.shardCollection()
sh.addShard()
db.createCollection()
db.collection.drop()
db.dropDatabase()
任何创建数据库的操作
任何以任何方式修改集群元数据的操作。请查阅 分片参考文献 了解分片命令的完整列表。但是，注意：并且所有在 分片参考文献 页面上的命令都会修改集群元数据。

降级分片集群¶

1

Download the latest 3.2 binaries.¶

Using either a package manager or a manual download, get the latest release in the 3.2 series. If using a package manager, add a new repository for the 3.2 binaries, then perform the actual downgrade process.

一旦升级到3.4，您就不能降级到 3.2.7 或者之前的版本。您只可以降级到 3.2.8 或者之后的版本。

2

Disable the Balancer.¶

Turn off the balancer as described in Disable the Balancer.

3

Downgrade the `mongos` instances.¶

Downgrade the binaries and restart.

4

Downgrade each shard, one at a time.¶

Downgrade the shards one at a time. If the shards are replica sets, for each shard:

Downgrade the secondary members of the replica set one at a time:
1. Shut down the mongod instance and replace the 3.4 binary with the 3.2 binary.
2. Start the 3.2 binary with the --shardsvr and --port command line options.
```
mongod --shardsvr --port <port> --dbpath <path>
```
  Of if using a configuration file, update the file to include sharding.clusterRole: shardsvr and net.port and start:
```
sharding:
   clusterRole: shardsvr
net:
   port: <port>
storage:
   dbpath: <path>
```
  Include any other configuration as appropriate for your deployment.
3. Wait for the member to recover to SECONDARY state before downgrading the next secondary member. To check the member’s state, you can issue rs.status() in the mongo shell.
  
  Repeat for each secondary member.
Step down the replica set primary.

Connect a mongo shell to the primary and use rs.stepDown() to step down the primary and force an election of a new primary:
```
rs.stepDown()
```
When rs.status() shows that the primary has stepped down and another member has assumed PRIMARY state, downgrade the stepped-down primary:
1. Shut down the stepped-down primary and replace the mongod binary with the 3.2 binary.
2. Start the 3.2 binary with the --shardsvr and --port command line options.
```
mongod --shardsvr --port <port> --dbpath <path>
```
  Or if using a configuration file, update the file to specify sharding.clusterRole: shardsvr and net.port and start the 3.2 binary:
```
sharding:
   clusterRole: shardsvr
net:
   port: <port>
storage:
   dbpath: <path>
```
  Include any other configuration as appropriate for your deployment.

5

Downgrade the config servers.¶

If the config servers are replica sets:

Downgrade the secondary members of the replica set one at a time:
1. Shut down the secondary mongod instance and replace the 3.4 binary with the 3.2 binary.
2. Start the 3.2 binary with both the --configsvr and --port options:
```
mongod --configsvr --port <port> --dbpath <path>
```
  If using a configuration file, update the file to specify sharding.clusterRole: configsvr and net.port and start the 3.4 binary:
```
sharding:
   clusterRole: configsvr
net:
   port: <port>
storage:
   dbpath: <path>
```
  Include any other configuration as appropriate for your deployment.
3. Wait for the member to recover to SECONDARY state before downgrading the next secondary member. To check the member’s state, issue rs.status() in the mongo shell.
  
  Repeat for each secondary member.
Step down the replica set primary.
1. Connect a mongo shell to the primary and use rs.stepDown() to step down the primary and force an election of a new primary:
```
rs.stepDown()
```
2. When rs.status() shows that the primary has stepped down and another member has assumed PRIMARY state, shut down the stepped-down primary and replace the mongod binary with the 3.2 binary.
3. Start the 3.2 binary with both the --configsvr and --port options:
```
mongod --configsvr --port <port> --dbpath <path>
```
  If using a configuration file, update the file to specify sharding.clusterRole: configsvr and net.port and start the 3.4 binary:
```
sharding:
   clusterRole: configsvr
net:
   port: <port>
storage:
   dbpath: <path>
```
  Include any other configuration as appropriate for your deployment.

6

Re-enable the balancer.¶

Once the downgrade of sharded cluster components is complete, re-enable the balancer.

← 降级MongoDB 3.4 复制集到 3.2 Release Notes for MongoDB 3.2 →