- 求职 : Linux运维
- 论坛徽章:
- 203
|
大家好，我是E叔。
经常有朋友向我咨询版本选型的问题。
受到老毕同学的启发，E叔决定为大家搬运+翻译+简单解释 MongoDB3.0.4+以后各个版本fixed的比较重要的jira issues。大家可以根据需求来决定版本选型。
今天是3.0.4篇。
Issues fixed in 3.0.4
以下均是3.0.4中修复了的jira issues。（比较重要的issues）
由于人肉整理，难免有遗漏，欢迎补充。
SERVER-18822
WT引擎的 shard在chunk migration的时候如果，在源chunk上有大量写，可能会造成migration后的chunk缺失部分数据。
SERVER-18646
如果handle在checkpoint start的时候繁忙（如在bluk load的时候），如果这时候的checkpoint 访问到这个handle，如强制drop，之类的，那么chekpoint就会failed
SERVER-18629
将journal 的fdatasync 错误的进行在了data数据目录中，原因是：The reason is because __wt_log_open initializes log->log_dir_fh by calling __wt_open(session, “journal”, …), which expands the path to “/mnt/db/journal” before passing it to __open_directory. But __open_directory appears to expect the path to a file in the directory rather than the path of the directory, as it strips the final component of the path and opens “/mnt/db”. The result is that the wt log system calls fdatasync on “/mnt/db” and not on “/mnt/db/journal”.
There are two consequences to this:
• Performance – the unnecessary fdatasync calls on /mnt/db can get stuck behind a lengthy call to fdatasync on a .wt file, or otherwise be hampered by i/o to .wt files; whereas an fdatsync call to /mnt/db/journal should be unimpeded by any activity in /mnt/db if the /mnt/db/journal has been placed on a separate drive, per our recommended best practices.
• Durability – I believe durability of journaled writes depends on the fdatasync of /mnt/db/journal, in order to ensure that newly created journal files are durable.
SERVER-18409
在标明一个node为down之前，再次尝试心跳检测
SERVER-18326
初始化同步的时候，reset了状态 清空了oplog，这时候可能会触发rollback logic to attempt and fail a rollback leading to a controlled shutdown.
The rollback logic should ignore an empty oplog during rollback to accommodate for initial/re-sync running at the same time.
SERVER-18316
WT引擎在系统意外crash后可能无法恢复启动（如果中断了checkpoint）
SERVER-18315
checkpoint提交时，吞吐量下降明显。
SERVER-18246
mongos保持着到所有shard的链接，但是不直接管理他们的lifetime，当mongos连接到recovering状态的复制集成员的时候可能出现error。
SERVER-18213
WT引擎在批量提交或者批量update的时候设置了upsert=true，且没有匹配到document，且update的item有唯一index，就可能会出现大量 WriteConflict
SERVER-18190
从上的读操作可能会block住复制。
因为当从压力大的时候在从上的一些长查询可能会不让出锁，不yield。
造成复制延时。
SERVER-17923
从节点在background模式下对同一个collection建立多个index的时候，这是时候该collection的元数据变动，可能会fatal error
SERVER-15225，SERVER-20139
执行计划cache的刷新问题，对同一种类查询，执行计划有cache就不去验证，同一种类查询但是条件不同可能的执行情况也不同。
可以通过internalQueryCacheReplanningEnabled参数的设置来解决
The query optimizer caches plans for each query shape and reuses these plans for a time. In situations where the performance of the cached plan is poor for a particular instance of the query shape, the optimizer may select a the plan with poor performance and fail to evict the cache entry. This behavior may impact deployments where two queries with the same shape have different performance characteristics if they have different selectivity.
This improvement makes the query planner evaluate the cost of the cached query plan, and if the cost of this plan is too high, the query planner switches to a more efficient plan. This more efficient plan is then cached for future use.
This improvement is not enabled by default. To enable by default set the internalQueryCacheReplanningEnabled parameter totrue using the setParameter command on a running system, or at start time using the setParameter commandline option orsetParameter in the configuration file.
For example, to enable using setParameter:
db.runCommand({setParameter: 1, internalQueryCacheReplanningEnabled: true})
This improvement can be disabled as follows:
db.runCommand({setParameter: 1, internalQueryCacheReplanningEnabled: false})
3.0.4可以使用这个参数，默认是关闭 |
|
免费注册
发表于 2016-01-15 18:37
发表于 2016-01-18 10:20