MongoDB 3.4 中的兼容性更改

在本页面

以下 3.4 更改可能会影响与旧版本 MongoDB 的兼容性。

另请参见MongoDB 3.4 发行说明。

分片群集更改

shardsvr Requirement

对于 3.4 分片群集，必须通过配置文件设置sharding.clusterRole或通过命令行选项--shardsvr，将**的mongod个实例显式指定为shardsvr。

Note

具有shardsvr角色的mongod个实例的默认端口是27018。要使用其他端口，请指定net.port设置或--port选项。

3.4 mongos 和 mongod 的早期版本

3.4 版mongos实例无法连接到mongod实例的早期版本。

删除配置选项

MongoDB 3.4 从mongos中删除了以下配置选项：

sharding.chunkSize配置文件设置和--chunkSize命令行选项
sharding.autoSplit配置文件设置和--noAutoSplit命令行选项

取消对 SCCC Config 服务器的支持

3 .4 分片群集不再支持将镜像(SCCC)mongod实例用作配置服务器。 3.2 版本中弃用的 SCCC 配置服务器的使用不再有效。而是将您的配置服务器部署为副本集(CSRS)。

要将分片群集升级到版本 3.4，配置服务器必须作为副本集运行。

要将现有的配置服务器从 SCCC 转换为 CSRS，请参见 MongoDB 3.4 手册将配置服务器升级到副本集。

初始同步并重命名集合

如果在运行initial sync时在同步源上重命名了集合，则初始同步过程将失败并重新启动，以避免可能的数据损坏。参见SERVER-26117。

重命名集合的操作包括：

renameCollection命令和db.collection.renameCollection()方法。
$out阶段的聚合(db.collection.aggregate()方法或aggregate命令)。
使用out选项进行 Map-reduce(db.collection.mapReduce()方法或mapReduce命令)。
convertToCapped command.

因此，从 3.2.11 或更早版本升级到 3.4 时，如果初始同步遇到renameCollection操作，则可能会开始失败。

在 MongoDB 版本 3.2.11 或更早版本中，遇到renameCollection操作(可能会损坏数据)时，将进行初始同步过程。参见SERVER-4941。

Deprecated Operations

group

Mongodb 3.4 不赞成使用以下命令和mongo shell 方法：

group命令和db.collection.group()。请改用db.collection.aggregate()或db.collection.mapReduce()。

聚合(无光标)

除非该命令包含explain选项，否则 MongoDB 3.6 将无需使用aggregate命令而无需使用cursor选项。除非包含explain选项，否则必须指定游标选项。

要指示具有默认批处理大小的光标，请指定cursor: {}。

要使用非默认批处理大小指示光标，请使用cursor: { batchSize: <num> }。

严格验证集合和索引规格

收集选项的更严格验证

MongoDB 3.4 在create和db.createCollection()操作期间对收集选项进行了更严格的验证；即，指定的选项必须是create和db.createCollection()支持的有效选项。

例如，以下操作不再有效：

db.createCollection( "myCappedCollection", { cappedtypo: true, size: 5242880 } )

更严格地验证索引规格

MongoDB 3.4 在createIndexes和db.collection.createIndex()操作期间强制执行更严格的索引规范验证。强制不适用于现有索引。

更严格的验证包括以下内容：

确保索引键样式key: value中的值有效。具体来说，值可以是：

Value	Description
大于 0 的数字	对于升序
小于 0 的数字	对于降序索引
字符串“文本”，“ 2dsphere”，“ 2d”或“哈希”	对于特殊索引类型

例如，以下操作不再有效：

db.collection.createIndex( { x: 0 } );
db.collection.createIndex( { y: "text2d" } );
db.collection.createIndex( { z: NaN } );
db.collection.createIndex( { x: 1, unique: true } )

确保指定的index options有效。以前的版本忽略无效的选项。例如，以下操作不再有效：

db.collection.createIndex( { y: 1 }, { uniques2: true} );
db.collection.createIndex( { z: 1 }, { expireAfterSec: 350 } )

通用兼容性更改

更新了名称空间限制：在 MongodDB 3.4 中，数据库名称不再支持$字符。

Important

升级到 MongoDB 3.4 之前，必须删除名称中包含$的所有数据库。

删除不推荐使用的textSearchEnabled参数。从 2.6 版开始，MongoDB 默认情况下启用文本搜索功能。
删除mongosniff。在 MongoDB 3.4 中，mongosniff替换为mongoreplay，它提供了mongosniff功能的更灵活的超集。
更新为$project规范行为：$project规范中的空文档会产生错误。
如果对集合中的所有文档执行count()时(即查询谓词为空)，当您包含hint()时指定sparse index时，即使稀疏索引导致计数错误，也会使用稀疏索引。

db.collection.insert({ _id: 1, y: 1 } );
db.collection.createIndex( { x: 1 }, { sparse: true } );

db.collection.find().hint( { x: 1 } ).count();

为了获得正确的计数，在对集合中的所有文档进行计数时，请勿使用sparse index hint()。

db.collection.find().count();

db.collection.createIndex({ y: 1 });
db.collection.find().hint({ y: 1 }).count();

如果使用稀疏索引会导致计数不完整，则以前的版本会忽略该提示。

用户角色更改

以下内置角色的特权不再适用于local和config数据库：

readAnyDatabase	从 3.4 开始，要在`local`数据库上提供`read`特权，请在`admin`数据库中创建一个用户，该用户在`local`数据库中具有read角色。另请参见clusterManager和clusterMonitor角色以访问`config`和`local`数据库。
readWriteAnyDatabase	从 3.4 开始，要在`local`数据库上提供`readWrite`特权，请在`admin`数据库中创建一个用户，该用户在`local`数据库中具有readWrite角色。另请参见clusterManager和clusterMonitor角色以访问`config`和`local`数据库。
userAdminAnyDatabase
dbAdminAnyDatabase	从 3.4 开始，要在`local`数据库上提供`dbAdmin`特权，请在`admin`数据库中创建一个用户，该用户在`local`数据库中具有dbAdmin角色。另请参见clusterManager和clusterMonitor角色以访问`config`和`local`数据库。

相应地，以下内置角色包括对local和config数据库的其他读取和写入特权：

向后不兼容的功能

以下 3.4 功能保留了 MongoDB 早期版本无法正确处理的数据，并要求将featureCompatibilityVersion设置为"3.4"：

Views
排序规则和不区分大小写的索引
Decimal Type
索引版本v: 2。 v:2索引增加了对排序规则和十进制数据类型的支持。早期的索引版本既不支持排序规则也不支持十进制数据类型。

如果为featureCompatibilityVersion: "3.4"，则在 MongoDB 3.4 中创建的索引默认为v: 2。否则，新索引默认为v: 1。

要设置featureCompatibilityVersion，请参见setFeatureCompatibilityVersion命令。

Warning

启用这些向后不兼容的功能可以降级过程复杂化。有关详细信息，请参见删除 3.4 不兼容的功能。

建议升级后，允许您在不启用这些功能的情况下运行部署，并且要在预热期内确保降级的可能性最小。如果您确信降级的可能性很小，请启用这些功能。

3 .4 部署具有以下默认featureCompatibilityVersion值：

3.4 Deployments	`featureCompatibilityVersion`
对于新部署	`"3.4"`
对于部署从 3.2 升级	`"3.2"`，直到您setFeatureCompatibilityVersion到`"3.4"`为止。

如果数据库包含视图，排序规则规范或v:2索引，则 MongoDB 的早期版本将无法启动。如果数据包含十进制数据类型，则对这些文档的操作可能会失败。有关详情，请参见将 MongoDB 3.4 降级到 3.2。如果需要降级，则必须在降级二进制文件之前从数据库中删除与这些不兼容功能相关的数据。

驱动程序兼容性更改

要将各种新功能(例如，新的Decimal Type和Collation)与 MongoDB 驱动程序一起使用，必须升级到支持这些功能的驱动程序版本。

单元素$ in，带 upsert

当upsert操作找不到匹配的文档时，它会基于查询中的等式语句创建要插入的文档，然后将 update 修饰符应用于该种子文档。例如：

db.c.drop()
db.c.update( { a : 3, b: "foo" }, { $set : { c : 15 } }, { upsert : true } )
db.c.find()
{ "_id" : ObjectId("59c03009529946822d0afb8c"), "a" : 3, "b" : "foo", "c" : 15 }

在 3.4 之前的版本中，单元素$ in 查询没有为upsert文档提供种子。在下面的示例中，由于此行为，$addToSet更新表达式成功：

db.c.drop()
db.c.update( { a : { $in : [1] } }, { $addToSet : { a : 2 } }, { upsert : true } )
db.c.find()
{ "_id" : ObjectId("58bdb00eb39e8f87607e9222"), "a" : [ 2 ] }

但是，在 3.4 及更高版本中，单元素$in的行为类似于 upserts 的相等声明。如果查询在字段上包括此条件，则将字段值设置为元素。

由于此行为，某些向上插入操作可能在 3.4 中失败。在上面的示例中，$addToSet upsert 将失败，因为a字段将使用单个值作为种子，并且$addToSet无法应用于标量字段。为避免此错误，您必须将$in表达式包装在$elemMatch表达式中：

db.c.drop()
db.c.update(
   { a : { $elemMatch : { $in : [ 2 ] } } },
   { $addToSet : { a: 3 } },
   { upsert: true } )
db.c.find()
{ "_id" : ObjectId("..."), "a" : [ 3 ] }

Docs

Docs4dev

Title here