Log file Viewer
#mongodb logs for Tuesday the 12th of May, 2015
[00:00:35] <joannac> godzirra: "what's wrong with it" is very vague. Do you see an error? Does it not return what you expect? What's your evidence that something is wrong with it?
[00:57:42] <godzirra> joannac: Sorry, I get an error when I run it, saying that "$near requires geojson point, given { type: \"Point\", coordinates: [ 36.0, -115.0 ] }
[00:59:23] <joannac> here are the docs: http://docs.mongodb.org/manual/reference/operator/query/near/
[01:03:48] <godzirra> joannac: Thanks for pointing out the obvious. (no, that wasn't sarcastic. I seriously mean thanks. :)
[01:08:20] <godzirra> Now I just have to figure out why node seems to hang after processing my inserts (and failing on all of them)
[02:05:38] <shlant> anyone using mms: is it possible to have a different instance type for arbiters? Can I deploy 2 members with one type and then an arbiter for the same replset with a t2.micro or something?
[02:21:17] <joannac> shlant: sure, you just need to deploy first, then distribute processes the way you want
[06:47:28] <amitprakash> Hi, i have a collection with 10m records on mongo 2.8 (mmapv1 engine).. what would be the fastest way to restore this to a mongo 3.0 instance(wiredTiger) ?
[06:48:04] <amitprakash> Currently I am syncing by adding the 3.0 instance as a replicaset member, however its taking over an hour to sync
[11:25:14] <bogn1> so nixstt, from looking at your disk IO graph, I suppose you're pushing time series data into hour documents. We're doing that and have those sawtooth query runtimes as well. Finding out why is on our list. Seek time shouldn't be that big of an issue with structured hashes having minutes on top-level und seconds below. That's only 59+59 jumps as per MongoDBs documentation. Another candidate is record moves due to padding not being available anylonger in 3.0.2.
[11:26:34] <nixstt> bogn1: yeah pushing data into hourly documents here, noticed this since testing 3.0.2 also having some memory usage issues it’s using way too much memory (much more than specified in the config file)
[11:28:55] <bogn1> we're looking at this: http://docs.mongodb.org/ecosystem/use-cases/pre-aggregated-reports/
[11:31:56] <bogn1> I will look into stored procedures for not having to send the bulky {0: {0: Infinity, ...}, ...} structures for every pre-allocation
[11:34:11] <nixstt> I’m actually using timestamps as keys in my subdocuments but that seems to be a really bad idea looking at that article
[11:39:46] <bogn1> are you using a schema similar to this one on slide 45: https://www.mongodb.com/presentations/mongodb-time-series-data
[11:43:41] <nixstt> it’s hard for me to preallocate all the data, i’m saving for example the disk IO statistics you saw in that image, sometimes a disk might be added/removed and the whole structure changes
[11:45:53] <nixstt> Yeah I like to just grab a document and have all the metrics in there instead of grabbing everything from different collections
[11:46:26] <nixstt> my application uses quite a bit of memory cause of that but it’s a dashboard type application so it’s not heavily used all the time
[11:47:00] <bogn1> wiredtiger might be interesting for you, it is for us as well, as that doesn't need to pre-allocate
[11:49:28] <bogn1> my not very informed impression is, that you should no longer $set, but instead $push
[11:49:34] <Naeblis> What should be the design for a field which can take multiple types of responses? I have a "discussion" model and a "response" model. Response is currently text only, but I'd like it to also include things like polls etc.
[11:56:01] <bogn1> and also this seems to be a mixture of the multiple metrics schema with the indexed time-slots: https://www.mongodb.com/presentations/webinar-internet-things-bosch-concept-code
[11:59:09] <bogn1> but I think the indexed time-slots approach doesn't mix well with WiredTiger but that's just an initial impression
[12:01:07] <bogn1> A question to the broader audience. Does anybody know, whether it's possible to see a graph of record moves (due to document growing) in MMS?
[14:12:41] <abyss> I'm reading about sharding and replication. For my requirements sharding is too much so I chose replica. I'm reading about replica: http://docs.mongodb.org/master/MongoDB-replication-guide.pdf and I have question, because that doc mentions about heartbeat.
[14:14:10] <abyss> if three nodes working: primary -> secondary -> secondary, then everything is ok, because I can add heartbeat between secondary nodes: secondary <-hearbeat-> secondary and put there reads... But when primary fall down then one of the secondary become primary... I'm right?
[14:15:09] <abyss> so... What happens with writes? How I can handle that I mean avoid doing writes to secondary node... I should handle this in heartbeat, or how?
[14:16:10] <lietu> I've been reading a bit on some practical aspects of mongodb replication .. apparently regardless of what we set write concern etc. values to, there is absolutely no way to say what data is in the database if you're running a replicaset? if you write with a write concern of e.g. 3 with 4 nodes out of which 2 are down .. it will write to the 2 that are up, and hang indefinitely until more are coming up .. if you set wtimeout it won't "hang"
[14:16:11] <lietu> but you have no idea if something was written or if it will eventually be written to the DB .. so is there a way to rollback the failing write, or kill the query and write the old data back, or how do people deal with this in practice?
[14:16:49] <lietu> and the indefinite hanging is of course not a very practical solution for .. well .. really any purpose
[18:06:58] <DragonPunch> Oh okay. I guess I have to put some data into collections and define it inside of the collection.
[18:07:50] <ChALkeR> Are there any problems that I should expect when using oldstable mongodb packages?
[18:13:38] <ChALkeR> http://repo.mongodb.org/apt/debian/dists/wheezy/mongodb-org/stable/main/binary-amd64/mongodb-org_3.0.3_amd64.deb
[18:14:05] <ChALkeR> Everything else is here: http://repo.mongodb.org/apt/debian/dists/wheezy/mongodb-org/stable/main/binary-amd64/
[18:37:27] <fxmulder> when rsyncing a replica over another do I need to keep anything on the new replica or can I just rsync the whole data directory
[20:09:17] <StephenLynx> works perfectly well, I am pretty sure the dev keeps an eye to io.js development to support it.
[20:13:35] <Nepoxx> removing Mongoose from my current project is going to be a PITA, however I'll try without on my next one. Or I might try Monk, that looks promising too
[20:15:38] <Nepoxx> https://github.com/mafintosh/mongojs or https://github.com/mongodb/node-mongodb-native?
[23:06:11] <StephenLynx> "Warning: The TTL index does not guarantee that expired data will be deleted immediately. There may be a delay between the time a document expires and the time that MongoDB removes the document from the database."
[23:13:19] <GothAlice> StephenLynx: Known thing, as you noticed. My use of MongoDB as a cache takes that into account when accessing cached values.
[23:14:04] <GothAlice> StephenLynx: https://github.com/marrow/cache/blob/develop/marrow/cache/model.py#L126-L128
[23:14:24] <GothAlice> Reminds me: I need to set a "to hell with reality" write concern on that delete.
[23:15:52] <StephenLynx> I am using it for flood control. I just added a gte:current date on the query and removed the unique key for ip.
[23:18:13] <GothAlice> I prefer throwing away invalid responses, rather than having MongoDB do the extra document/index scanning, as I'm looking up a unique key (I'm using _id, in fact), so it's less computational power needed overall, esp. if the delete is a fire-and-forget, which it is now.
[23:19:40] <GothAlice> (If the TTL index hasn't gotten to it, in the off chance that I hit the minute window for the entry *I'll* delete it.)