6 ms·
This is true, in the Ubuntu packages this is printed to the default log at /var/log/mongodb/mongodb.log. It is also abundantly clear from the documentation. I s
by werkshy 14y ago
This is true, in the Ubuntu packages this is printed to the default log at /var/log/mongodb/mongodb.log. It is also abundantly clear from the documentation. I struggle to understand how one could deploy a new datastore in production without reading the "getting started" level of documentation or looking in the log at some point.
The 2GB 32-bit limit of MongoDB seems like a complete non-issue to me.
Wed Sep 19 17:29:21 [initandlisten] MongoDB starting : pid=3765 port=27017 dbpath=/var/lib/mongodb 32-bit host=deepthought
Wed Sep 19 17:29:21 [initandlisten]
Wed Sep 19 17:29:21 [initandlisten] ** NOTE: when using MongoDB 32 bit, you are limited to about 2 gigabytes of data
Wed Sep 19 17:29:21 [initandlisten] ** see http://blog.mongodb.org/post/137788967/32-bit-limitations
Wed Sep 19 17:29:21 [initandlisten] ** with --journal, the limit is lower
Wed Sep 19 17:29:21 [initandlisten]
Wed Sep 19 17:29:21 [initandlisten] db version v2.2.0, pdfile version 4.5
Wed Sep 19 17:29:21 [initandlisten] git version: f5e83eae9cfbec7fb7a071321928f00d1b0c5207
Wed Sep 19 17:29:21 [initandlisten] build info: Linux domU-12-31-39-01-70-B4 2.6.21.7-2.fc8xen #1 SMP Fri Feb 15 12:39:36 EST 2008 i686 BOOST_LIB_VERSION=1_49
Wed Sep 19 17:29:21 [initandlisten] options: { config: "/etc/ mongodb.conf", dbpath: "/var/lib/mongodb", journal: "true", logappend: "true", logpath: "/var/log/mongodb/mongodb.log" }
Wed Sep 19 17:29:21 [initandlisten] journal dir=/var/lib/mongodb/journal
Wed Sep 19 17:29:21 [initandlisten] recover : no journal files present, no recovery needed
Wed Sep 19 17:29:21 [initandlisten] waiting for connections on port 27017
Wed Sep 19 17:29:21 [websvr] admin web console waiting for connections on port 28017
- gaius 14y agoThe issue is not the limit; it's the silent failure. 32-bit Oracle doesn't do that, it tells you it can't extend the tablespace by raising an exception.
- pooriaazimi 14y agoI'm not trying to defend Mongo, but the reason it doesn't tell you is because you didn't ask for it. If you care about the data (i.e. it's not a log or something that's not very important), you ought to always use "getLastError" to see if your data was actually stored or not (some drivers, like mongoose (for Node.js), just let you specify a simple flag ("safe:true") that does this automatically). A shitty default, no doubt. But it can be changed easily. And "most" drivers offer that. And you usually connect to MongoDB using a driver. http://www.mongodb.org/display/DOCS/getLastError+Command http://www.mongodb.org/display/DOCS/getLastError+Command
- PeterisP 14y agoShitty defaults are 90% as bad as hardcoded unfixable settings. Defaults usually don't get changed, convention over configuration, etc.
- taligent 14y agoThe default for the Java driver changed recently to the Safe mode. So it does happen.
- rdtsc 14y ago> If you care about the data (i.e. it's not a log or something that's not very important), you ought to always use "getLastError" Wait they are promoting this as a database. It is right there in black on yellow "database". I don't know about you but I suspect most people expect databases to try their hardest to protect data. That means also having safe default. As in when I install it and put data in it, by default it should try hardest to make sure that data doesn't get corrupted. If it doesn't, it doesn't deserve to call itself a database. > A shitty default, no doubt. This is not a "oopsie" this is a deliberate lie and misinformation in order to produce fast benchmarks.
- diego 14y agoNormally people look at logs when things go wrong. Do you look at the log anytime something starts successfully and seems to be working? You must spend lots of time looking at logs. This is a message that MUST be displayed on the console when you install the server for the first time. It's too important. Also, you learn a tool before going into production. I never went into "production" with mongodb. All I did was experiment with a toy project. I never needed to look at the log.
- brown9-2 14y agoDo you look at the log anytime something starts successfully and seems to be working? When I first install something new that I'm going to rely on - yes.
- diego 14y agoHow do you know that you're going to rely on it if it's new? I install something new. I kick the tires. It takes a long time until I decide I'm going to rely on it. I'll look at the log at some point, but not necessarily the first time I install something. There are better things to do at that point.
- jeremyjh 14y agoMaybe you should learn something from your failure.
- diego 14y agoMaybe you should make constructive comments instead of making assumptions about what people learn or don't (or what they know or don't, or what has worked for them or hasn't). There are some really disrespectful people in this community.
- jeremyjh 14y agoI didn't say you didn't learn anything. But you seem to be making excuses for why you shouldn't know some very basic things about MongoDB. It uses a memory-mapped file. How can that be larger than 2GB in 32-bit system? It has async writes...this is pretty well documented by 10gen and is also something noted by a lot of tutorials, blog articles etc. You should have known something this basic about a database so important to your business. None of that would bother me in the slightest if you were not still here defending such basic mistakes and blaming them on 10gen.