PMXBOT Log file Viewer

Help | Karma | Search:

#mongodb logs for Monday the 4th of January, 2016

(Back to #mongodb overview) (Back to channel listing) (Animate logs)
[08:28:21] <robscow> does MongoDB still not support updating a batch of docs with values from their own fields? ie, update all docs, set field1 to the value of field2
[11:26:08] <Rumbles> hi, can anyone advise how long I can continue to use the olf config file format? We moved to 3.0 recently and I noticed that YAML is the current default format... but we're still using the old format...
[11:28:35] <Rumbles> s/olf/old
[12:04:59] <BurtyB> long live the old format :)
[12:05:47] <Derick> BurtyB: you probably should convert
[12:06:27] <Zelest> s/BurtyB/Rumbles/g
[12:06:40] <Derick> oh yes, I missed that
[12:07:00] <Zelest> :)
[12:09:55] <BurtyB> :(
[12:22:04] <Zelest> You've been replaced! :D
[12:23:51] <Rumbles> I'm reading up on the "correct" way to handle log rotation for mongo (in ubuntu) and I'm worried my config might do something undesired, I have the following config: http://fpaste.org/306903/
[12:24:32] <Rumbles> I am worried that with this config the mongo process will do the rotation after logrotate has rotated the log file (from the SIGUSR1 command) creating an extra empty rotated log file
[12:24:47] <Rumbles> is this the case? can anyone advise the correct way to handle rotation?
[12:30:44] <Rumbles> I was reading round on this and there is some varying advice, most of it seems to be pretty old
[12:31:07] <Rumbles> the manual describes how to use SIGUSR1, but doesn't mention any caveats
[13:17:47] <Rumbles> no one?
[13:18:01] <Zelest> Derick answered you :)
[13:18:50] <Rumbles> he answered about formats, I didn't see an answer to my question about rotation
[13:19:06] <Rumbles> maybe I missed it comehow?
[13:19:08] <Zelest> oh
[13:19:17] <Zelest> no, you're right, my bad
[13:19:24] <Rumbles> np :)
[17:08:57] <Rumbles> still no one? :(
[17:13:44] <BurtyB> Rumbles, it seems backwards to me too as it it should use a prerotate otherwise I'd imagine you'll potentially lose entries rather than end up with an empty file
[17:14:36] <BurtyB> tho after the kill it's going to have some crazy name :/
[17:18:11] <Rumbles> okay, do you have a recommended way of handling rotation?
[17:18:18] <Rumbles> currently we have ever exapnding logs files
[17:18:24] <Rumbles> which make me nervous :)
[17:21:46] <BurtyB> tbh I haven't set that part up yet either on my new db servers and on the old ones I just rotated and delted it which wasn't ideal either ;)
[17:22:02] <Rumbles> okay, thanks for your input :)
[17:22:09] <Rumbles> I'm going to test my config in dev tomorrow
[17:22:16] <Rumbles> I'll see if it works/what it breaks
[17:22:30] <Rumbles> now, it's time for home/beer
[17:22:47] <GothAlice> Mmm, legal intoxicants.
[17:23:21] <GothAlice> StephenLynx: We're starting to roll our data into WiredTiger today. :3
[17:23:30] <StephenLynx> noice
[17:27:36] <StephenLynx> endchan.xyz is using WT too afaik
[17:27:52] <StephenLynx> with my engine.
[17:28:04] <StephenLynx> they are soon running out of space, though :v
[17:28:14] <StephenLynx> because they allow uploads up to 50mb
[17:28:18] <GothAlice> BurtyB: Heh, that's some highly compressible data, right there!
[17:28:35] <GothAlice> StephenLynx: Using GridFS as the storage back-end?
[17:28:41] <StephenLynx> yes.
[17:28:51] <GothAlice> Did you customize the strip size? :3
[17:28:54] <StephenLynx> both standard data and file storage.
[17:28:55] <StephenLynx> no :v
[17:28:56] <StephenLynx> why
[17:29:41] <GothAlice> Because most people when they pick new stripe sizes tend to pick power of two sizes without thinking about the BSON overhead, resulting in stripes that are a few bytes over standard power-of-two allocations, leaving dead zones.
[17:29:42] <GothAlice> :P
[17:30:06] <StephenLynx> so if I didn't touch that I'm cool?
[17:30:09] <GothAlice> Yup!
[17:30:12] <StephenLynx> ok
[17:30:22] <GothAlice> You're not accidentally wasting space to excessive padding.
[17:30:54] <StephenLynx> I really saw no reason to bother with that, since most of the space used are on few and large files.
[17:31:00] <StephenLynx> what is the default?
[17:31:30] <GothAlice> 255 KB.
[17:31:35] <BurtyB> GothAlice, indeed - I think prefix compression helped quite a bit too :)
[17:31:41] <GothAlice> (Note: not 256 KB!)
[17:31:47] <StephenLynx> so if a file is smaller than that, it will use 255kb?
[17:32:09] <GothAlice> BurtyB: Ouch, yeah. I already do keyspace compression in the data access layer, so my own data doesn't benefit from that over-much.
[17:33:36] <GothAlice> StephenLynx: Well, no. It'll produce a single fs.chunks record for the file which will be whatever that file size happens to be + a few bytes of BSON overhead. It'll naturally scale to power-of-two sizes, so having lots of separate but exactly 1KB files is "bad".
[17:33:58] <StephenLynx> welp
[17:34:11] <GothAlice> But a large enough random set of files will average out that overhead quite nicely.
[17:34:11] <StephenLynx> so you only benefit if you can make it larger to fit files better?
[17:34:27] <StephenLynx> so you get less overhead?
[17:34:41] <GothAlice> Depends: do you need very fine-grained seeking within the files? Or do you want to minimize round-trips and getMore operations when streaming whole files?
[17:35:00] <StephenLynx> I think storage is the main issue here.
[17:35:09] <StephenLynx> the speed is not much of a concern.
[17:35:18] <StephenLynx> since bandwidth will always the slower.
[17:35:33] <GothAlice> There are trade-offs to larger and smaller chunk sizes, those two being the tip of the iceberg. Regardless of the chunk size, the last chunk will be the "remainder" of the file and whatever size (less than the chunk size) is required, hitting power-of-two padding.
[17:35:50] <StephenLynx> welp
[17:35:50] <GothAlice> The smaller the chunks, the more of them there are and thus a greater percentage of the storage and throughput will be overhead.
[17:36:23] <StephenLynx> so I guess that just leaving it be is the best. none of them and even I would know how to fine-tune that properly it seems.
[20:50:44] <soummyaah> Hello, I am new to mongodb and am currently dabbling with the problem of creating custom indexes. For example, is there any way possible to define my own indexing structure?
[21:05:51] <cheeser> depends on what that means to you
[21:06:10] <cheeser> https://docs.mongodb.org/manual/indexes/
[21:10:11] <StephenLynx> a bug on the driver got fixed because of a report of mine :3
[21:10:21] <StephenLynx> that I just found out of dumbassery and incorrect querying
[21:10:29] <StephenLynx> v:
[21:13:09] <soummyaah> I've read that document and what I understand from it is that there are specific indexes that already exist. And you can create them such as text or geospatial.
[21:13:32] <soummyaah> But none of these work for, what I want to do is design my own indexing structure which caters to my need.
[21:13:38] <cheeser> which is what?
[21:13:51] <cheeser> you can index any combination of fields you want...
[21:14:05] <soummyaah> I essentially need a structure which handles spatial and textual domain. That is a set of words and space.
[21:15:19] <soummyaah> Also, I'd like to ask, where can read up on how efficient these structures are and what they use internally? It's a black box for me right now. :/
[21:15:21] <StephenLynx> compound indexes.
[21:18:09] <soummyaah> Can I use compound indexes to give weightage to what I'm querying for? As in can I say that I wish to give 0.4 weightage to space and 0.6 weightage to words while searching for similar documents?
[21:19:25] <cheeser> weight only applies to text indexes, i believe
[21:20:56] <soummyaah> Okay. So, is there any way to create my own index? Would modifying the codebase make it possible?
[21:21:28] <cheeser> you want to modify mongodb to support your weird hybrid indexing?
[21:21:50] <cheeser> that's ambitious to say the least but try asking the mongodb-dev mailing list
[21:22:07] <soummyaah> Yeah :P
[21:22:18] <soummyaah> Okay, thanks!
[21:26:03] <brotatochip> hey guys, my prod replica set just shit the bed… had this displayed for my primary: "infoMessage" : "RS101 reached beginning of local oplog [2]",
[21:26:31] <brotatochip> That’s no longer showing up but my primary stateSTR is FATAL
[21:27:05] <brotatochip> I have a 3 member set - primary, secondary, and arbiter
[21:27:29] <cheeser> did you recently have an election?
[21:28:06] <brotatochip> Looks like it, but it seems to be triggered by the primary entering the bad state
[21:28:12] <brotatochip> The secondary has been elected as the new primary
[21:28:32] <brotatochip> And it’s staying that way. Looks like the optimes are different as well:
[21:28:37] <brotatochip> primary: "optime" : Timestamp(1451940564, 3),
[21:28:49] <brotatochip> secondary: "optime" : Timestamp(1451940687, 18811),
[21:28:59] <cheeser> most search results for that error are on older versions. what version are you running?
[21:29:38] <brotatochip> 2.6.11 cheeser
[21:31:20] <cheeser> hrm. that's newer than the search results suggest.
[21:31:45] <cheeser> try posting to mongodb-user and hopefully it'll catch the eye of the kernel devs
[21:31:57] <brotatochip> Where’s that?
[21:32:12] <brotatochip> Found it
[21:32:34] <brotatochip> The problem is cheeser I’ve got an app servicing ~3 million end users that’s down currently
[21:32:52] <cheeser> i understand.
[21:33:14] <cheeser> do you have a support contract?
[21:33:19] <brotatochip> No :(
[21:33:28] <cheeser> https://groups.google.com/forum/#!forum/mongodb-user
[21:33:35] <cheeser> doh
[21:34:08] <brotatochip> How screwed am I cheeser ?
[21:34:40] <jorsto> hai
[21:34:40] <brotatochip> I think I may need to do a full resync
[21:34:53] <joannac> do you have a recent backup?
[21:35:02] <joannac> otherwise, yeah, resync
[21:35:06] <brotatochip> Yeah, from this morning
[21:35:10] <brotatochip> I’d just rather not have data loss
[21:35:19] <brotatochip> Restoring to this morning’s backup will cause data loss
[21:35:35] <joannac> you can restore and then sync the rest
[21:35:53] <joannac> cheer up, this is why you have a replica set, so you have 2 copies of data
[21:35:54] <brotatochip> Ok
[21:36:12] <brotatochip> Nah just stressing as I’m under the gun to fix the broken app lol
[21:36:16] <cheeser> *fingers crossed*
[21:36:18] <jorsto> so i have an existing app on mongo already and want to add simple worker-based processing to it. I see some systems use findAndModify, but this only does 1 document at a time, are there any other ways I can have multiple workers find documents and "check them out" so that no workers select the same result-sets for processing?
[21:36:37] <cheeser> jorsto: yes, you can do that.
[21:37:07] <jorsto> i saw in other places to do a find, then update the found documents by id using $isolated, then do another find on those documents, process them, then unset the "processing" field with $isolated again
[21:37:14] <jorsto> seems like a lot of work for something which should be simple?
[21:37:22] <brotatochip> jorsto: how do I sync the rest after restoring from the backup?
[21:38:42] <joannac> brotatochip: also for the record, if you had a support contract you would almost certainly have someone on the phone walking you through this
[21:39:15] <brotatochip> I’m sure I would, don’t think that’s in our budget
[21:40:54] <brotatochip> Can’t even seem to find the cost of support anywhere
[21:41:40] <jorsto> @cheeser what method would work the best to ensure workers don't cross each other and get in fights and brawl eachother out
[21:42:40] <cheeser> findAndModify() is atomic
[21:43:38] <jorsto> just afraid that if i commit to find and modify, when there are 100s of thousands of items that need processing, it'll freak out
[21:44:16] <cheeser> this why we build prototypes
[21:44:22] <jorsto> lol
[21:47:34] <jorsto> i can just get all crazy and over-engineer the crap out of it using hash rings followed by misery and sadness
[22:01:29] <brotatochip> I rebooted mongodb from a backup, it rebuilt all the journals, but now my connection attempts are timing out…
[22:02:01] <brotatochip> Ah shit, I got it and I’m seeing the “RS101 reached beginning of local oplog” error
[22:02:17] <brotatochip> :/
[22:02:45] <brotatochip> Doesn’t seem to be any other option than a resync
[22:07:42] <cheeser> hopefully your secondary is up to date
[22:08:09] <cheeser> is your backup a nightly mongodump?
[22:56:43] <brotatochip> cheeser nope, it’s a volume snapshot
[22:56:51] <brotatochip> looks like I may have experienced something similar to this http://grokbase.com/t/gg/mongodb-user/11aeq6s30p/clarification-on-rollback-and-opslog-coverage
[22:57:04] <brotatochip> cheeser i had to disable replication for now to get the site back up and running
[22:58:37] <brotatochip> Oh, yeah, looks like the secondary fell too far behind