参考 > 发行说明 > MongoDB 3.6发布说明 > MongoDB 3.6中的兼容性更改
以下3.6更改可能会影响与旧版MongoDB的兼容性。
从MongoDB 3.6,MongoDB二进制文件mongod
和开始
mongos
,默认情况下绑定到localhost。如果
为二进制net.ipv6
文件设置了
配置文件设置或--ipv6
命令行选项,则二进制文件还会绑定到本地IPv6地址。
以前,从MongoDB 2.6开始,默认情况下,只有正式的MongoDB RPM(Red Hat,CentOS,Fedora Linux和衍生产品)和DEB(Debian,Ubuntu和衍生产品)的二进制文件才绑定到localhost。
当仅绑定到本地主机时,这些MongoDB 3.6二进制文件只能接受来自mongo
在同一台计算机上运行的客户端(包括Shell,副本集中部署的其他成员和分片群集)中的连接。远程客户端无法连接到仅绑定到本地主机的二进制文件。
要覆盖并绑定到其他IP地址,可以使用
net.bindIp
配置文件设置或
--bind_ip
命令行选项来指定主机名或IP地址的列表。
例如,以下mongod
实例绑定到localhost和My-Example-Associated-Hostname
与ip地址关联的主机名198.51.100.1
:
为了连接到该实例,远程客户端必须指定主机名或其关联的IP地址198.51.100.1
:
要绑定到所有IPv4地址,可以指定的绑定IP地址
0.0.0.0
。要绑定到所有IPv4和IPv6地址,可以指定的绑定ip地址,::,0.0.0.0
也可以使用新
net.bindIpAll
设置或新的命令行选项
--bind_ip_all
。
MongoDB 3.6删除了MongoDB弃用的HTTP接口和REST API。
配置设定 | mongod/mongos 选项 |
---|---|
net.http.enabled net.http.JSONPEnabled net.http.port net.http.RESTInterfaceEnabled |
httpinterface nohttpinterface jsonp rest |
MongoDB 3.6删除了不推荐使用的mongooplog
工具。
$type: "array"
行为改变¶开始在3.6,和表达式匹配包含任何元素类型阵列的字段。$type: "array"
$type: 4
在早期版本中,仅匹配包含嵌套数组的数组字段。$type : "array"
例如,一个名为的集合c
包含两个文档:
以下操作按字段类型查询a
:
从3.6开始,查询将返回集合中的两个文档,因为$type
查询现在可以检测到该字段a
本身就是数组。
在3.4和更低版本的MongoDB中,查询仅返回那些其中array字段a
包含BSON type 元素的
文档array
。
如果从包含部分索引(partialFilterExpression
包括或
表达式)的MongoDB 3.4.x部署中升级,则
必须在升级后重建这些索引,以避免语义冲突
。$type : "array"
$type : 4
$type : 'array'
有关表达式的更多信息,请参见
按数组类型查询。$type: "array"
从3.6开始,在对包含数组的字段进行排序时,MongoDB会将字段的值最低的数组排在前,升序排序,数组的值最高的数组在降序。选择要用作排序键的数组元素时,排序不再考虑查询谓词 。此行为更改适用于 find命令和 聚合管道。
由于此更改,当前按数组字段排序的应用程序可能会经历不同的排序顺序。
重要
由于MongoDB 3.6中对数组字段的排序行为发生了变化,因此在对使用多键索引建立索引的数组上进行排序时 ,查询计划包括一个阻塞的SORT阶段。新的排序行为可能会对性能产生负面影响。
在阻塞式SORT中,必须在排序步骤中使用所有输入,然后才能产生输出。在非阻塞或索引排序中,排序步骤扫描索引以按请求的顺序产生结果。
find
方法排序¶甲排序关键字是阵列元件中的排序过程MongoDB使用比较并最终包含数组顺序的文件。在升序排序中,包含具有最低排序键值的数组的文档首先被排序。同样,在降序排序中,包含具有最高排序键值的数组的文档将首先排序。
在MongoDB 3.4和更早版本中,按数组字段进行排序时,在确定排序键时会考虑查询谓词。
例如,一个集合coll
具有以下文档:
考虑a
对集合的数组字段进行以下排序操作:
在MongoDB 3.6中,排序操作在确定其排序键时不再考虑查询谓词。因此,排序键是每个文档中价值最低的元素:
-3
使用和的文档_id: 0
-4
的文档。_id: 1
该操作按以下顺序返回文档:
以前的MongoDB版本使用与查询谓词匹配的最低值数组元素作为排序键:{$gte: 0}
2
使用和的文档_id: 0
5
对于带有的文档,_id: 1
并将按以下顺序返回文档:
aggregate
方法排序¶在MongoDB 3.6中,使用该db.collection.aggregate()
方法对数组字段进行排序时
,仅单个数组元素用作排序键。
考虑以下示例:
对于降序排序,将数组中的最新时间用作排序键:对于带有和
的文档。由于排序是降序排列,因此这些键的排序顺序是从最新到最近,从而使文档的排序先于。3:31 PM on July 21
_id: 0
5:31 PM on July 21
_id: 1
_id: 1
_id: 0
在3.6之前的版本中,整个数组都用作聚合排序的排序键。数组排序键在元素方面进行比较,以确定结果集的排序顺序。
例
在3.6之前的版本中,排序键分别为[3,1,5]和[3,4,0]。由于第一个数组元素相等,因此第二个数组元素将打破领带,并首先对文档进行排序。_id: 0
aggregate
在MongoDB 3.6中,当在聚合管道中进行排序时 ,MongoDB不能再对正在排序的字段中包含并行数组的文档进行排序。如果数组是BSON对象的兄弟元素,则认为它们是并行的。涉及嵌套数组的排序键不被认为是并行的,与前缀共享同一数组的排序键也不被视为。
例
集合包含以下文档:
以下聚合成功,因为排序是在嵌套数组上执行的:
例
同样,如果集合包含以下文档:
以下聚合成功,因为排序键与前缀共享同一数组:
例
但是,在包含以下文档的集合中:
以下排序操作失败:
MongoDB无法同时对a
和b
字段进行排序,因为在带有的文档中,同级字段和
均为数组。结果,MongoDB在排序键生成期间遇到了并行数组,并返回错误。_id : 1
a
b
从MongoDB 3.6开始,通过update
操作添加的新字段将按字典顺序附加。
例如,一个集合coll
具有以下文档:
以下更新操作向文档中添加了两个新字段:
从3.6开始,MongoDB以字典顺序附加新字段。更新后的文档为。{_id : 0, x: 0, a: 0, b: 0}
MongoDB的早期版本按更新文档中出现的顺序附加新字段。更新后的文档为。{_id : 0, x: 0, b: 0, a:
0}
arrayFilters
标识符¶从MongoDB 3.6开始,与arrayFilters
标识符冲突的字段将无法再更新。
例如,一个集合coll
具有以下文档:
以下更新在MongoDB的早期版本中成功进行:
在MongoDB 3.6中,更新失败,因为字段名“ $ []”与arrayFilters
标识符语法冲突
。有关更多信息,
arrayFilters
请参见为数组更新操作指定arrayFilters。
注意
仅当featureCompatibilityVersion
设置为3.6 时,新的更新行为才适用。
从MongoDB 3.6开始,仲裁员具有优先级0
。将副本集升级到MongoDB 3.6时,如果现有配置具有优先级1
较高的仲裁程序,则MongoDB 3.6会将仲裁程序重新配置为具有优先级0
。
MongoDB 3.6不赞成使用主从复制。
--nojournal
WiredTiger的选项¶在版本3.6中,
使用WiredTiger存储引擎--nojournal
为副本集成员弃用了该选项
。
使用WiredTiger存储引擎的副本集成员不应使用该--nojournal
选项。有关日记的更多信息,请参见管理日记。
aggregate
命令和结果¶MongoDB 3.6删除了该aggregate
命令以将其结果作为单个文档返回的选项。
如果运行aggregate
命令,则必须包括cursor
选项或explain
选项。
aggregate
大多数用户应该使用db.collection.aggregate()
mongo shell中提供的帮助程序或驱动程序中的等效帮助程序,而不是直接运行命令。除非使用该explain
选项,否则这些助手将返回一个光标。
从3.6开始,在聚合表达式中强制转换为字符串的日期将包含毫秒,并附加字母'Z'。
例
在3.6之前,它将分别返回日期和
。在3.6中,结果包括毫秒和字母“ Z”:和。d: "2017-10-18t20:04:27"
d: "2017-10-18t20:04:28"
d: "2017-10-18t20:04:27.978z"
d:
"2017-10-18t20:04:28.192z"
该更改适用于以下聚合运算符:
MongoDB 3.6删除了不推荐使用的diagLogging
命令和
选项。而是使用
捕获,重播和分析发送到您的MongoDB部署的命令。mongod
--diaglog
mongoreplay
validate
操作¶从MongoDB 3.6开始,对于WiredTiger存储引擎,只有
full
验证过程才会强制执行检查点并将所有内存中数据刷新到磁盘,然后再验证磁盘上的数据。
在以前的版本中,WT存储引擎的数据验证过程始终强制执行检查点。
有关验证操作的更多信息,请参见
validate
命令和
db.collection.validate()
方法。
以下3.6功能要求将
featureCompatibilityVersion
其设置为"3.6"
:
$jsonSchema
文件验证3.6部署具有以下默认值
featureCompatibilityVersion