标签: wiredtiger
MongoDB 使用过多内存
我们已经使用 MongoDB 几个星期了，我们看到的总体趋势是 mongodb 使用太多内存（远远超过其数据集 + 索引的整个大小）。
我已经通读了这个问题和这个问题，但似乎没有一个能解决我一直面临的问题，他们实际上是在解释文档中已经解释过的内容。
以下是htop和show dbs命令的结果。
我知道 mongodb 使用内存映射 IO，所以基本上操作系统处理内存中的缓存内容，当另一个进程请求空闲内存时，mongodb理论上应该释放其缓存的内存，但从我们所见，它没有。
OOM 开始杀死其他重要进程，例如 postgres、redis 等。（可以看出，为了克服这个问题，我们将 RAM 增加到 183GB，现在可以工作但非常昂贵。mongo 使用了 ~87GB 的 ram，几乎是整个数据集大小的 4 倍）
所以，
- 这么多内存使用真的是预期的和正常的吗？（根据文档，WiredTiger 最多使用约 60% 的 RAM 作为其缓存，但考虑到数据集大小，它甚至有足够的数据来占用 86GB 的 RAM 吗？）
- 即使内存使用是预期的，为什么 mongo 不会释放其分配的内存，以防另一个进程开始请求更多内存？在我们增加 RAM 之前，Linux oom 不断杀死各种其他正在运行的进程，包括 mongodb 本身，这使系统完全不稳定。
谢谢 ！
推荐指数
解决办法
查看次数
如何将 .wt 备份文件恢复到本地 MongoDB？
这是之前有人问过的问题，但我已经尝试了所有解决方案，但根本无法解决问题。在发布这个问题之前，我已经花了很多时间进行研究。我看过官方的 MongoDB 文档和许多其他博客。
如何将 .wt MongoDB 备份文件还原到本地 MongoDB 数据库？
推荐指数
解决办法
查看次数
MongoDB / WiredTiger：从文档中删除属性后减少存储大小
推荐指数
解决办法
查看次数
通过 --repair 和 WiredTiger 恢复 mongoDB
我们不小心删除了rm -rf /data/db
我们的MongoDB 路径目录，多亏了
extundelete，我们恢复了它并得到了目录/data/db。
这是我们在目录中的文件，文件是在 MongoDB 3.4 版本下生成的。
文件夹diagnostic.data：
文件夹journal：
第 1 步：尝试正常运行 mongod
a)我们运行mongod --port 27017 --dbpath /data/db --bind_ip_all和mongo，并期望应该有一个用户定义的数据库wecaXX，但是，它没有出现。
> show dbs
admin 0.000GB
config 0.000GB
local 0.000GB
在 Robo3T 中
b)然后我尝试运行mongod --port 27017 --dbpath /data/db --bind_ip_all --repair. 结果是：
2019-03-25T14:10:02.170+0800 I CONTROL [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'
2019-03-25T14:10:02.191+0800 …推荐指数
解决办法
查看次数
Ubuntu 上的“mongod 有线老虎”？
我不能wiredTiger用作MongoDB.
我遵循了这个分步指南；
http://docs.mongodb.org/manual/release-notes/3.0-upgrade/
第 1 步：启动 3.0 mongod。好的，我做到了。
步骤 2：使用 mongodump 导出数据。OK
Step-3：为WiredTiger创建数据目录。OK - 用户权限已调整。
第 4 步：使用 WiredTiger 重新启动 mongod。好的
mongod --storageEngine wiredTiger --dbpath <newWiredTigerDBPath>
是的，mongod工作了。但是Step-5说“使用mongorestore上传导出的数据”。但是，我的控制台仍然很忙，并显示“正在等待端口 27017 上的连接”，因为最后一个命令不包括像service mongod start.
然后我尝试编辑我的/etc/mongod.conf文件以作为服务运行。但我不能。我添加了wiredTiger 目录作为dbpath，但我想我需要编辑/etc/init/mongod.conf文件，因为它包含一些更改db 目录权限的代码。
花了8个小时后，我认为没有足够的文档可以提供帮助，所以我想问一下；
我应该怎么做才能在 MongoDB 中使用wiredTiger？
我想知道是否有人设法实现了这一目标？
安慰
2015年 4 月 1 日编辑： 我尝试了文档中的change-storage-engine-to-wiredtiger部分。
推荐指数
解决办法
查看次数
WiredTiger 后 Mongodb 崩溃无法分配内存错误
我将MongoDB (3.2.6)其用作我的应用程序的存储，因为几周后 MongoDB 通常每 1 或 2 周就开始崩溃。崩溃似乎来自WiredTiger内存分配期间的问题，这里是stacktrace上次崩溃的全部内容：
2016-10-09T18:25:36.389+0200 E STORAGE [thread1] WiredTiger (12) [1476030336:325695][993:0x7f559c19a700], file:index-1108-8065571460375661294.wt, WT_SESSION.checkpoint: memory allocation of 18624 bytes failed: Cannot allocate memory
2016-10-09T18:25:36.547+0200 E STORAGE [thread1] WiredTiger (12) [1476030336:422567][993:0x7f559c19a700], file:index-1108-8065571460375661294.wt, WT_SESSION.checkpoint: checkpoints cannot be dropped when in-use: Cannot allocate memory
2016-10-09T18:25:37.347+0200 I COMMAND [conn10793] command admin.$cmd command: ping { ping: 1 } keyUpdates:0 writeConflicts:0 numYields:0 reslen:37 locks:{} protocol:op_query 208ms
2016-10-09T18:25:37.386+0200 E STORAGE [thread1] WiredTiger (12) [1476030337:254969][993:0x7f559c19a700], checkpoint-server: checkpoint server error: …推荐指数
解决办法
查看次数
MongoDB后台索引构建块二级
我们最近在 MongoDB 3.2 集群中遇到了与索引创建相关的破坏性事件。设想：
- 使用background: true在主数据库上创建了几个索引。
- 索引是在主数据库上完成后由 MongoDB 在辅助数据库上自动创建的，也是在后台创建的。
- 这最终导致多个后台索引操作在辅助节点上并行运行。到目前为止，一切都或多或少地按预期发生。
- 当 4 个索引器线程最终并行运行时，辅助节点上的所有读取操作似乎都阻塞了（编辑：澄清一下，这甚至包括对未构建索引的数据库的读取操作，根据文档，这甚至不应该发生用于前台构建）。我们使用 secondaryPreferred 选项执行一些读取，这些读取最终完全挂起（见下文）。
- 我们立即中止了进一步的索引创建以及仍在主服务器上运行的后台索引器线程。但是，在所有后台索引线程完成后，辅助节点上的读取操作才开始再次运行。总而言之，我们在 20 分钟内完全无法从二级读取。
什么可以解释这一点，特别是对辅助节点的读取操作最终完全阻塞的事实？索引创建会显着影响性能这一事实众所周知，我们正在考虑这一点。
但是，我们能够找到的文档中没有任何内容解释了在索引创建完成之前完全挂起的二级挂起。我们也无法在主要或次要的日志中发现任何可疑的内容：日志条目仅显示单个索引构建的创建和进度，但没有任何内容可以解释读取操作的阻塞。
这种情况给我们带来了一些重大问题，因为我们使用 Java 驱动程序的 ReadPreference.secondaryPreferred 选项执行某些读取。这些操作没有回退到从主服务器读取，而是在等待辅助服务器时没有超时地挂起，因此在我们的应用程序服务器上迅速建立了一个正在运行（但挂起）请求的大队列。
如果有人能对这种情况有所了解，我们将不胜感激。
技术细节：
- MongoDB 版本：3.2.16（不是最新的，但 .17/.18 更改日志中没有任何内容听起来可能会对此产生影响）
- 引擎：有线老虎
- 资源：主服务器虚拟机和辅助服务器虚拟机均配置有 6 个 CPU 和 128 GB 内存，两者之间有 1 GBit 链接。
- 数据集：约。总共 2 TB，其中约 100 GB 特别活跃。
推荐指数
解决办法
查看次数
MongoDB 从 RocksDB 迁移到 WiredTiger
我们使用 RocksDB 作为我们的引擎已经有一段时间了，现在我们正在尝试迁移到 WiredTiger。我们有一些相当大的数据库，大约有 4~12 TB 的数据，根据文档中描述的过程，我们添加了一个带有 WiredTiger 的新节点，并尝试让它从头开始复制。
对于数据量，复制时间非常长，很多时候我们遇到的情况是 WiredTiger 节点决定更改它从中复制的节点，只是删除所有数据并重新从头开始。只有一次我们成功完成了复制，但与 oplog 相比，节点最终落后了很多。
同样，对于如此大量的数据，拥有足够大的 oplog 来保存数周的事务变得令人望而却步，并且该过程也非常脆弱、单线程、缓慢且容易失败。
所以我的问题如下：
是否有更好的方法来进行此迁移？
有没有办法加速复制（即多线程复制）？
有没有办法告诉新的 WiredTiger 节点在发生事故时停止丢弃所有数据？
我们正在使用 Percona MongoDB 3.4.13 版的 3 和 5 个节点副本集，并尝试迁移到开源 MongoDB 3.4.13（我们的想法是在 WiredTiger 中升级到 4.x 并完全放弃 RocksDB 和 Percona） .
推荐指数
解决办法
查看次数
标签 统计
mongodb ×8
wiredtiger ×8
mongodb-3.2 ×2
memory ×1
mongo-repair ×1
percona ×1
recovery ×1
ubuntu ×1