mongodb
配置报错
debian8 jessi下的mongodb3安装：http://hut8.io/posts/mongodb-3-on-debian-jessie/
Install using the repository for wheezy
sudo apt-key adv –keyserver ‘keyserver.ubuntu.com’ –recv ‘7F0CEB10’
echo ‘deb http://repo.mongodb.org/apt/debian wheezy/mongodb-org/3.0 main’ | sudo tee ‘/etc/apt/sources.list.d/mongodb-org-3.0.list’
sudo apt-get update
sudo apt-get install -y mongodb-org
Do not start MongoDB yet if you want to use WiredTiger!
Replace the configuration
The new YAML configuration format is way better than the old format, but the Debian wheezy package ships with the old format. So edit /etc/mongod.conf and replace it with equivalent YAML options. This is what I came up with. The engine: “wiredTiger” part is what prompted me to switch to the new configuration format.
storage:
dbPath: “/var/lib/mongodb”
engine: “wiredTiger”
wiredTiger:
collectionConfig:
blockCompressor: snappy
systemLog:
destination: file
path: “/var/log/mongodb/mongodb.log”
logAppend: true
timeStampFormat: iso8601-utc
net:
bindIp: “127.0.0.1”
port: 27017
WiredTiger
Hopefully you’ve specified in the configuration file that you want to use the wiredTiger storage engine before MongoDB starts for the first time. I did not do this. This leaves the /var/lib/mongodb directory full of files compatible only with MMAPv1. The easiest ay to fix this is just to delete all the files in the data directory after stopping MongoDB:
Don’t do this if you have data loaded already
sudo systemctl stop mongod.service
sudo rm -rf /var/lib/mongodb/*
Then add the engine: “wiredTiger” option, as shown above. Restarting should work fine. If you choose to invoke MongoDB without the init script / systemctl (which is useful with debugging), make sure that you use:
sudo -u mongodb mongod [… options]
Otherwise, mongod will create necessary files owned by either root or yourself, depending on whether you used sudo or not, which will lead to tricky issues such as the log (where error messages go!) not being writable by the mongodb user.
知乎1
2
3> 写篇文章时，2.8版本还没有出。据我的生产实践，Mongodb占据的磁盘空间比MySQL大得多，可以理解文档数据如Json这种格式，存在许多冗余数据，但空间占用大得不正常，甚至是传统数据库的三四倍，不太契合工程实践，应该有改善的余地。 查阅了一些资料，
具体理下Mongodb的空间分配。1. MongoDB每个库逻辑上包含许多集合（collection）,物理上存储为多个数据文件，数据文件的分配是预先分配的，预分配的方式可以减少碎片，程序申请磁盘空间的时候更高效，但MongoDB预分配的策略可能导致空间的浪费。默认的分配空间的策略是：随着数据库数据的增加，MongoDB会不断分配更多的数据文件。每个新数据文件的大小都是上一个已分配文件的两倍( 64M, 128M, 256M, 512M, 1G, 2G, 2G, 2G )，直到预分配文件大小的上限2G。虽然2G的阀值可以调整，但一般运维等时候往往也不会去调整，就这点来说，可能导致空间的浪费。对于磁盘的空间的分配效率，我报以怀疑的态度，如果本身有IO瓶颈，预分配一个2G的文件，将可能导致服务出现严重性能问题。预分配文件，可以减少碎片，提高程序申请空间的效率，但有无必要一次分配初始化一个巨大的文件，这点值得商榷。 虽然预分配的机制，文档记载是可以关闭的，但一般使用NOSQL产品都是会使用默认配置，也建议使用默认的配置，因默认配置往往经历了长久的考验，没有那么多bug。2. MongoDB的文档在数据文件中是连续存储的，这点不同于一些关系数据库的做法（它们会把长记录拆分为两部分，溢出的那部分单独存放在另一处），如果没有预留足够的空间，那么更新可能导致原有空间放不下新的文档。当更新迫使引擎在BSON存储中移动文档时，存储碎片可以导致意外的延迟。对此MongoDB官方的解释是如下，“如果有足够的空间，在MongoDB中更新文档时，数据会在原地更新。如果更新后的文档大小大于已经分配的空间，那么文档会在一个新位置被重写。MongoDB最终会重用原来的空间，但这可能需要时间，而且空间可能会过度分配。在MongoDB 2.6中，默认的空间分配策略将是powerOf2Sizes，这个选项从MongoDB 2.2开始就已经提供了。该设置会将MongoDB分配的空间大小向上取整为2的幂（比如，2、4、6、8、16、32、64等等）。该设置会降低需要移动文档的几率，并使空间可以更高效地重用，结果是更少的空间过度分配和更可预测的性能。用户仍然可以使用精确匹配的分配策略，如果文档大小不增加，该策略更节省空间。”显然，这种策略又将导致空间的浪费，特别是对于导入只读类型的数据。3. MongoDB不支持数据文件的压缩，也不能回收空间。它所使用的碎片整理的策略，可能是在一个新的地方重写，而不是对旧的碎片进行整理、合并。4. 不校验数据页。页面校验对于数据库是非常重要的，有助于识别存储设备异常。就这点，MongoDB存储的数据是不安全的，也许哪天就起不来了。
知乎1
mongodb写入数据是靠操作系统的缓存来实现的，我们需要清楚这中间发生了什么？对于更新操作，可能存在以下两种状态。pre-fsync post-update state 对数据的变更已经写入journal日志，但日志并没有刷新（fsync)的磁盘上post-fsync post-update state 对数据的变更已经刷新到日志文件，这个时候，如果宕机，可以利用journal日志进行灾难恢复。那么在pre-fsync post-update state阶段，如果宕机了。很可能会丢失数据，因为连日志都没有刷新到磁盘。此时会出现这样一种情况，用户读取到了新的数据，然后宕机了，这个数据被丢失了。 用户读到了数据，但这个数据后来又不存在了，这种情况是否有问题呢？ 得看应用。mongodb提供了其他选项，写入操作可被block，直到从库应答后（具体机制我不记得了，可能和MySQL的半同步类似的道理）。但主库上面的读取操作也许仍然可以读取到新的值（不必等从库应答）注意：由于mmap的机制，如果只是mongod进程挂了。那么不会丢失数据，因为操作系统没有挂，操作系统会继续写入完数据的。还有一点需要留意，对于数据库来说，比如MySQL在读取和写入页块的时候，会对页块进行校验，但mongodb不会，对于重要的数据来说，这是不能接受的。很可能因为硬件的故障导致数据异常而DBA不知道。
