PMXBOT Log file Viewer

Help | Karma | Search:

#mongodb logs for Tuesday the 6th of September, 2016

(Back to #mongodb overview) (Back to channel listing) (Animate logs)
[00:05:25] <blizzzard> Thanks a lot earendel for taking the time!
[00:06:55] <blizzzard> Isn't there a consolidated way to do this say for example, for favorites I have an array of object ID's in schema?
[00:07:16] <blizzzard> I have to submit this task asap and I'm trying to cut corners from anywhere possible
[06:39:52] <hemangpatel> Hello there morning
[08:59:51] <cm13g09> morning all - Need to create a replica set out of an existing standalone instance with next to no downtime (a reload is fine, anything else probably isn't)
[09:00:15] <cm13g09> I have two new servers to add (one as a full instance, one as an Arbiter)
[09:00:34] <cm13g09> How can I instantiate a replica set without reloading all my data
[09:00:55] <cm13g09> The docs only seem to document the case of instantiating on a new install
[09:21:47] <kke> trying to use a TTL index. doesn't seem to work. i enabled TTLMonitor logs and see this : 2016-09-02T08:51:35.257+0000 D INDEX [TTLMonitor] TTL -- ns: dev20160906114743.tokenskey:{ deleted_at: 1 } query: { deleted_at: { $lt: new Date(1472806294257) } } <-- that date is about a week ago, my expireAfterSeconds is 1
[09:22:16] <kke> does it have some setting somewhere that i only want to clean up stuff that is over a week old already or what? :)
[09:46:00] <Derick> cm13g09: https://docs.mongodb.com/manual/tutorial/convert-standalone-to-replica-set/
[09:47:51] <cm13g09> Derick: I couldn't work out if that "just worked" or only worked on a new instance
[09:48:03] <Derick> that should just work
[09:48:14] <cm13g09> I love that word.... should....
[09:48:24] <Derick> heh, sorry -
[09:48:29] <Derick> let me rephrase: it worked for me
[09:48:32] <cm13g09> OK
[09:48:35] <cm13g09> Mongo 2.4?
[09:48:42] <cm13g09> (yes, I know it's old)
[09:48:50] <Derick> i would greatly recommend you do the following then:
[09:48:56] <Derick> convert to replicaset
[09:49:02] <Derick> start *new* node up as 2.6
[09:49:05] <Derick> add to replicaset
[09:49:08] <cm13g09> yes
[09:49:16] <cm13g09> this was my hope
[09:49:19] <Derick> add arbiter (at 2.6)
[09:49:36] <Derick> shut down 2.4 node, wipe its data (after verifying the 2.6 cluster works)
[09:49:45] <Derick> add it as 2.6 node
[09:49:48] <cm13g09> that going to 2.6 was just a case of adding 2.6 node + 2.6 arbiter then wipe and upgrade 2.4
[09:49:57] <Derick> then do the rolling upgrades to 3.0 and 3.2
[09:49:59] <Derick> right
[09:50:03] <cm13g09> OK
[09:50:07] <Derick> we have docs on how to do a rolling upgrade too
[09:50:16] <Derick> (the order makes things a bit tricky sometimes)
[09:51:02] <cm13g09> My boss' experience of Mongo to date hasn't exactly been stellar (we've had a few random mongodb just dieing for no obvious reason issues)
[09:51:13] <cm13g09> which is why I was very very cautious about things
[09:51:20] <Derick> sure - and do make a backup
[09:51:37] <cm13g09> OK, best way to get a consistent non-performance affecting backup?
[09:51:49] <tilerendering> I would SO like to run mongodb on android
[09:51:55] <cm13g09> mongodump with oplog?
[09:52:11] <cm13g09> (we're running on ext4... so)
[09:52:14] <Derick> that works, but it affects performance (you're doing full collection scans for all collection)
[09:52:24] <Derick> how much data are you at?
[09:52:42] <cm13g09> 85GB
[09:52:46] <Derick> tilerendering: plans are that MongoDB might run on ARM64 soon..., but I don't think that's android yet
[09:52:58] <tilerendering> too bad
[09:53:02] <Derick> cm13g09: if you think you can copy the files during down time, that might probably be better/faster
[09:53:06] <tilerendering> it´s the easiest to use obejct db I ever saw
[09:53:12] <Derick> tilerendering: it's the memory limitations of a phone
[09:53:12] <cm13g09> 85GB and something like 100-writes a second 24x7
[09:53:17] <tilerendering> Derick: hm ok
[09:53:24] <tilerendering> how much mem is typically required ?
[09:53:36] <Derick> cm13g09: you'll have a lot of run with the new WiredTiger then
[09:53:58] <cm13g09> oh?
[09:54:00] <Derick> cm13g09: would it be possible to *try* out doing the upgrades on some random extra VMS so that you're familiar with it? like a dry-run?
[09:54:10] <Derick> cm13g09: WT likes concurrent writes a lot more
[09:54:32] <cm13g09> Derick: I can in theory - but I'm a bit short on disk space
[09:54:44] <Derick> cm13g09: I meant on other nodes
[09:54:53] <cm13g09> this is the issue... what other nodes?
[09:55:09] <cm13g09> I'm short of VM hosts with disk space
[09:55:21] <Derick> other servers? For a replicaset set, the three nodes need to be on different VMs - otherwise, it's kinda pointless
[09:55:46] <Derick> tilerendering: a few GB
[09:55:49] <cm13g09> Derick: we're running 1 in DC1, 1 in DC2 and I'm not entirely sure where to put the arbiter.....
[09:55:55] <tilerendering> too bad. a mini-mongodb would suffice
[09:56:01] <cm13g09> (or we will be with the replica set
[09:56:21] <Derick> cm13g09: the best is DC3 - or at least a different region in DC1 or DC2
[09:56:32] <cm13g09> Derick: I thought you might say that
[09:56:33] <Derick> if you have regions like AWS does
[09:56:57] <cm13g09> In this case, we are running the VM hosts....
[09:57:03] <cm13g09> i.e. we're physically in the DCs
[09:57:39] <cm13g09> So we only have two sites
[09:57:41] <cm13g09> really
[09:58:32] <Derick> There is also "Major Version Upgrade" at https://www.mongodb.com/products/consulting
[09:59:49] <cm13g09> Derick: how much memory/disk do I need for an Arbiter...
[09:59:55] <cm13g09> surely it doesn't need much
[10:00:40] <cm13g09> Just wondering if I can run it on the tertiary NS we have that's not in any of our DC space
[10:01:47] <Derick> cm13g09: fast connection is more important
[10:02:05] <cm13g09> Derick: all of them have gig
[10:02:30] <cm13g09> doesn't help that my boss has left me to sort this out
[10:02:36] <cm13g09> and cleared off to Zambia for 6 weeks
[10:03:03] <Derick> haha
[10:03:16] <Derick> minimal memory
[10:03:22] <Derick> and disk
[10:03:24] <cm13g09> OK
[10:03:28] <Derick> it doesn't store a lot at all
[10:03:32] <cm13g09> so putting it on NS3 should be fine then
[10:03:41] <Derick> what do you have available there resource wise?
[10:04:46] <cm13g09> Machine specs are: 1 vCPU / 512MB RAM / 20GB disk. Currently running at ~50% memory usage, ~10% disk usage
[10:04:53] <cm13g09> I can bump the RAM up if needed
[10:04:55] <Derick> yeah, that should be fine
[10:05:23] <Derick> I'd check, but I'm not at home with my big machine today
[10:05:41] <cm13g09> the actual data instances are 4 vCPU / 8GB / 250GB
[10:06:46] <cm13g09> Derick: Basically the issue has come about because we need to fix the DC network in DC1, meaning we have to take the whole DC out for a day
[10:07:35] <Derick> ah
[10:07:51] <cm13g09> yeah
[10:08:04] <cm13g09> so I've been told to make the entire platform we have running in DC1, run in DC2
[10:08:14] <nalum> Hello all, has anyone ever gotten an Errno -3 from mongo-connector? I have it setup to sync data between two replica sets
[10:08:31] <nalum> I can't see anything online about that error
[10:08:38] <Derick> nalum: what is the full error message (in the logs, if you have)?
[10:08:41] <cm13g09> Derick: the words "err, OK" came out of my mouth when he asked for that....
[10:09:09] <nalum> mongo_connector.errors.ConnectionFailed
[10:10:29] <Derick> nalum: the connection failed?
[10:11:18] <nalum> Yeah, I was hoping to get a bit more info as to why it failed. I'm able to connect to the replica set without trouble usign the same connection string
[10:11:45] <Derick> nalum: strace it
[10:12:35] <nalum> I'll take a look at that, thanks Derick
[10:13:53] <cm13g09> Derick: I'm just conversing with the boss about it, he's asking why we shouldn't run the arbiter in either DC1 or DC2
[10:14:36] <cm13g09> Would I be right in thinking that if your site-to-site VPNs went down in the "wrong way", whichever site has the arbiter, wins?
[10:14:56] <Derick> cm13g09: if it runs in DC1, and DC1 goes down, you don't have a writeable set in DC2 as it needs to see the majority of the nodes
[10:15:01] <cm13g09> yeah
[10:15:01] <Derick> "it" being, the client
[10:15:07] <cm13g09> that's what I thought was the case
[10:16:33] <cm13g09> Derick: of course, I've got my own set of fun anyway, because the core application wasn't designed to be clustered....
[10:17:03] <Derick> yes, it would need some attention to deal with failovers
[10:17:07] <cm13g09> yeah
[10:17:25] <cm13g09> Presumably you can't write to a mongodb that's not master?
[10:17:32] <Derick> writes can (temporarily) fail when you have a failover
[10:17:38] <Derick> right - you can only write to the primary nodes
[10:17:45] <Derick> node*
[10:17:49] <cm13g09> oh this is going to be fun....
[10:18:08] <cm13g09> that said... it might be OK....
[10:18:16] <Derick> in 2.4, failover can be ~30 secs, it's a *lot* better in 3.2
[10:18:27] <cm13g09> is there an easy way of determining whether a node is primary or not?
[10:18:37] <Derick> the client does that for you
[10:18:47] <Derick> it detects failover and redirects write queries to the right node
[10:18:53] <cm13g09> ah
[10:19:00] <cm13g09> OK, so even if you connect to the wrong one
[10:19:08] <cm13g09> it'll send writes to the right place
[10:19:21] <Derick> cm13g09: your connection string will need the majority of the nodes listed though
[10:19:27] <cm13g09> OK
[10:19:38] <cm13g09> I'm just thinking then
[10:20:13] <cm13g09> Can you put the arbiter in connection string
[10:20:17] <Derick> yes
[10:20:20] <cm13g09> right
[10:20:27] <cm13g09> that's the solution in my case then
[10:20:39] <cm13g09> Arbiter + mongo node in the DC the app is running in
[10:21:48] <cm13g09> My other question (sorry for the deluge)
[10:22:01] <cm13g09> is that if Mongo fails over to DC2 because DC1 went down
[10:22:13] <cm13g09> is it possible to force it back to DC1 when it comes back up again?
[10:22:31] <cm13g09> presumably wait for DC1 to catch up, then shut down DC2 temporarily, forcing an election?
[10:22:32] <Derick> yes, you can set a priority on the data carrying node in DC1
[10:22:38] <cm13g09> ah, right
[10:22:42] <Derick> no need to shut down DC2 yourself
[10:22:53] <cm13g09> it'll do all the magic for me with priority
[10:22:54] <cm13g09> fine
[10:22:57] <Derick> yes
[10:23:08] <cm13g09> OK, this doesn't sound completely insane
[10:23:28] <cm13g09> equally, I don't much fancy reloading Mongo to enable replica sets in the middle of the day
[10:24:55] <Derick> sounds like a 4am job :)
[10:25:24] <Derick> I'd recommend you test it on your dev environment first if you haven't done it yet.
[10:25:25] <cm13g09> Derick: no....
[10:25:32] <cm13g09> not 4AM
[10:25:36] <cm13g09> 2AM on a Sunday
[10:25:49] <cm13g09> the only time writes stop for 15 mins
[10:25:49] <Derick> rather you than me :)
[10:26:24] <cm13g09> I am highly tempted to, as root "at 02:05 service mongodb reload"
[10:26:35] <cm13g09> and pray
[10:30:15] <Derick> a while...
[10:30:29] <cm13g09> few hours?
[10:30:39] <Derick> depends on the load
[10:31:05] <cm13g09> most of the load on that server is actually in redis
[10:31:20] <cm13g09> (using ~50% CPU)
[10:31:21] <Derick> you're sharing a node with two types of databases?
[10:31:34] <cm13g09> sigh.. yes
[10:31:37] <Derick> in this case, it's mostly IO of course that you need.
[10:31:46] <cm13g09> (another thing on the list that could do with being fixed)
[10:31:50] <Derick> cm13g09: I can not recommend that - they will fight for resources.
[10:32:06] <cm13g09> Oh, I wouldn't ever recommend it
[10:32:11] <cm13g09> I inherited this setup
[10:32:21] <cm13g09> and am now slowly untangling it
[10:32:43] <cm13g09> hence the major works at DC1 to sort out the network
[10:33:01] <cm13g09> (I ended up with a loop across a bridge thanks to my predecessor)
[10:33:09] <Derick> :)
[10:33:24] <cm13g09> If it was how we wanted it....
[10:35:58] <cm13g09> Derick: we're considering spinning up a brand new copy of the service in DC2 now, dumping the data out of DC1 and migrating it over later
[10:37:00] <cm13g09> It'd avoid an interruption of service, at the expense of history going slightly missing for a week or two
[10:37:01] <Derick> in that case, you can probably go straight to 3.2
[10:37:14] <Derick> you've nothing to lose anyway - if it doesn't work, you can try again?
[10:37:30] <cm13g09> it's the least likely method to fail
[10:38:07] <cm13g09> and yes, it doesn't touch DC1
[10:38:15] <Derick> (except for the dumping)
[10:38:29] <cm13g09> yes, but we can do that after DC2 is spun up and running
[10:38:39] <Derick> yes
[10:38:50] <cm13g09> it'll put additional load on DC2 for a bit
[10:38:57] <Derick> yes, absolutely
[10:38:59] <cm13g09> but that's not the end of the world
[10:43:49] <cm13g09> Derick: thanks so much for the help
[10:43:53] <cm13g09> really, really appreciated
[10:44:29] <Derick> you're welcome :)
[10:44:34] <Derick> say hi to stu :)
[10:45:16] <cm13g09> Stu?
[10:45:32] <cm13g09> I think you've possibly got me muddled with somebody else?
[10:46:06] <Derick> cm13g09: causality?
[10:46:45] <cm13g09> AH
[10:47:13] <cm13g09> Now it makes sense ;)
[10:47:25] <Derick> :)
[10:54:54] <cm13g09> Derick: just discovered "nojournal=true" in a production mongo....
[10:54:59] <cm13g09> (sigh)
[10:57:06] <Derick> makes it faster
[10:57:08] <Derick> :)
[10:57:19] <cm13g09> but not good practise, right?
[10:57:30] <Derick> no, not good practise
[10:57:32] <cm13g09> The response I got this end as to why it was turned off: "Space issues"
[10:58:02] <Derick> if you'd had a hard shutdown, you'd have had data corruption
[10:58:24] <cm13g09> quite
[10:59:53] <Derick> you won't get that with WT, but you might lose data in that case
[11:00:17] <cm13g09> mm
[11:00:26] <Derick> anyway, time for lunch :)
[11:00:30] <cm13g09> thanks Derick
[11:00:33] <cm13g09> really helpful
[11:08:05] <kke> asking again. i'm trying to use a TTL index and it doesn't seem to work. i enabled TTLMonitor logs and see this : 2016-09-02T08:51:35.257+0000 D INDEX [TTLMonitor] TTL -- ns: dev20160906114743.tokenskey:{ deleted_at: 1 } query: { deleted_at: { $lt: new Date(1472806294257) } } <-- that date is about a week ago, my expireAfterSeconds is 1 there's no other index on the same field
[11:09:40] <kke> so why is it trying to find entries that are over a week old only?
[11:41:38] <SimpleName> Does mongodb support left join inter
[11:41:55] <SimpleName> I just saw $loopup for left join outer
[11:46:53] <SimpleName> and it ’s just workon non-shard collection
[11:46:57] <SimpleName> ..what’s the fuck..
[11:47:04] <SimpleName> why
[11:49:11] <Tobsn> limitations of mongodb
[11:49:26] <Tobsn> if you want full join support you would need to pick a rational database...
[11:49:37] <Tobsn> every database has its own benefits and downsides
[13:01:42] <cheeser> SimpleName: no, it does not.
[13:03:36] <StephenLynx> it allows you to let the database relate relations, deathanchor
[13:03:48] <StephenLynx> and since RDBs are optimized for that, it makes sense in that context.
[13:09:04] <deathanchor> what db type is best for doing many <-> many <-> many with possible cyclical matches?
[13:11:06] <Derick> a graph database I'd say
[13:11:18] <StephenLynx> that
[13:11:37] <deathanchor> that's what I figured.
[13:11:37] <StephenLynx> even though I never used one, I'd look into them before anything else.
[13:12:52] <deathanchor> I read about neo4j, but since I left my last job which it would have been useful, I never followed up on it.
[13:18:20] <deathanchor> I'm just curious if you think if you would use graph DB soley or RDB or NoSQL, or hybrid for a "recommended items based on purchase" feature?
[13:19:57] <StephenLynx> e
[13:19:58] <StephenLynx> h
[13:20:09] <StephenLynx> i'd try to stick to the one that provides the most important features.
[13:20:28] <StephenLynx> unless I'd REALLY needed core features of another db.
[13:23:21] <cheeser> people build recommendation engines on mongo, fwiw.
[13:25:58] <deathanchor> cheeser: yeah, that's what I figured, but some the neo4j docs I read said graphing dbs are "better" for it, but I didn't see how it would efficient unless you precached it to something like mongo and updated the doc in mongo regularly.
[13:26:23] <deathanchor> eh, let me focus on real problems :D
[14:03:12] <amcsi> hi
[14:04:14] <amcsi> does Linux on the operating level cache the database in RAM so that read/writes happen at RAM speed if the db isn't too big?
[14:04:32] <StephenLynx> somewhat.
[14:04:44] <StephenLynx> with wired tiger it relies both on that and on its own cache.
[16:07:49] <suicidel> hey guys
[16:08:37] <suicidel> I'm trying to start up mongodb on ubuntu. I get Failed global init: FileNot Oepn failed to open the logfile. I checked the permissions and they are fine. Any ideas?
[16:09:20] <StephenLynx> did you try RHEL?
[16:09:35] <StephenLynx> ubuntu is crap and is not the main focus of mongo.
[16:10:12] <Derick> StephenLynx: that is not helpful.
[16:11:53] <Derick> suicidel: Your error message has typoes in it - can you share the full error in a pastebin.com ?
[16:11:58] <Derick> (and a few lines around it)
[16:17:31] <suicidel> yes
[16:19:28] <suicidel> http://pastebin.com/mxxu3z1B
[16:20:27] <Derick> does /var/log/mongodb exist as a directory? run: ls -ld /var/log/mongodb
[16:20:58] <suicidel> yes it does exist
[16:21:07] <Derick> show the output please
[16:23:35] <suicidel> drwxrwxrwx 2 mongodb mongodb 4096 Sep 6 11:12 /var/log/mongodb
[16:24:05] <Derick> but you're trying to start mongodb as user "tv"
[16:24:44] <Derick> can you pastebin: "ls -l /var/log/mongodb" too ?
[16:25:51] <suicidel> k
[16:26:01] <suicidel> sorry i have to retype because its in vm commandline, can't copy and paste
[16:26:15] <Derick> ssh in from your host then
[16:28:08] <suicidel> @Derick: got it working. It's true . I wasn't starting it as mongodb user, so no access ot log. As a test i chowned to tv and it worked
[16:29:11] <Derick> you should fix/restrict permissions to only start it as the mongodb user though
[16:29:22] <Derick> but glad it works :)
[16:29:43] <suicidel> Yes I will do that. Thanks Derick!
[16:49:13] <blizzzard> How do I go about making a favorite system in mongo?
[16:49:36] <blizzzard> so the user schema has a list of id's in his schema?
[16:49:45] <blizzzard> I want to avoid making another collection etc.
[16:50:14] <blizzzard> best case would be if we can just have username(string), password(string), favorites(whatnow?)
[16:56:37] <StephenLynx> embedded array with ids.
[16:56:43] <StephenLynx> or any unique field.
[16:57:29] <wwwd> I'm trying to start mongdb with a replSet in Ubuntu 16.04. When I issue this command "mongod --replSet zappa --dbpath data/1 --port 27001 --smallfiles --oplogSize 50" I get connection refused...Anyone know why?
[17:05:23] <jokke> hello
[17:06:12] <jokke> is there any performance benefit in using replace_one over update_one when replacing all fields?
[17:06:33] <jokke> oh wait
[17:06:41] <jokke> i think replace_one isn't what i need.
[17:06:54] <jokke> it probably actually creates a new doc with a new _id
[17:08:39] <StephenLynx> id argue that update is faster.
[17:29:03] <GitGud> GothAlice, hello are you here?
[17:29:29] <GothAlice> Sorta; I'm rather occupied at work at the moment, GitGud.
[17:30:08] <GitGud> GothAlice, i just had one question
[17:30:21] <GothAlice> Ask, don't ask to ask. There may be several able to answer. :)
[17:31:17] <GitGud> GothAlice, well its specific to you. because i was going to ask if you guys host your own work servers or if you do it remote. because i hear without proper equip, its bad to host it yourself
[17:32:26] <GothAlice> GitGud: We have physical servers managed by another company in a local DC, plus nodes managed in-house for offsite replication / backup purposes. For some clients we use MongoDB Inc.'s cloud services.
[17:32:47] <GitGud> oh i see
[17:32:48] <GothAlice> (On servers we own, rather than on AWS.)
[17:32:48] <GitGud> okay
[17:33:00] <GitGud> okay thanks for telling me. :)
[19:38:32] <n1colas> Hello
[20:37:16] <android6011> I have a collection and each record has a geojson point, i want to run a query that orders them by date_time, and computes distance between each record, to give me a total distance. Not really sure where to start
[20:38:21] <spacecrab> hello folks - i am new to mongodb and have a question about best practices, or rather simple designs... it seems there is a lot of different ways in which i can get off the ground with a database and start working.
[20:38:22] <spacecrab> i'm curious, is it preferred to work in the mongod.conf file, and have all changes defined from there, or should i have my scripts always calling mongod from bash and running with the parameters preferred? it seems they are one in the same but i am not sure which is preferred... any help/corrections/etc appreciated :p
[20:39:18] <spacecrab> essentially i'm simply working to create a 3-member replica set for the first time. i've been watching conference talks and reading documentation about it, but everyone seems to do it a little differently between bash and defining from .conf
[20:58:48] <spacecrab> or further yet, should i just be modifying the init script? i assume the conf should be used for all of this though
[20:58:55] <spacecrab> anyone out there willing to chime in? :)
[21:14:54] <GothAlice> spacecrab: Production environments should use .conf files; this better protects the security of the configuration itself, given proper file permissions.
[21:16:03] <GothAlice> spacecrab: Command-line arguments can sometimes be exposed via the process list. In other ways, this would let you do things like git-manage the config, ensure configurations are consistent and re-deployable with stock initialization scripts (since most will already look for a /etc/mongod.conf).
[21:16:21] <GothAlice> spacecrab: In development, running mongod through custom shell scripts or directly from a command line is entirely reasonable.
[21:23:13] <spacecrab> GothAlice: i'd rather learn and simply do it from the .conf file(s) then -- understanding the command line parameters was easy anyways it seemed, but the .conf file is actually very specific
[21:23:46] <spacecrab> i'll see if i can set up this replica set strictly through mongod.conf then :) thanks so much for the input! i'll let you know when i succeed
[21:23:53] <GothAlice> The options between command-line and configuration file are equivalent, from what I recall, FYI.
[21:23:59] <spacecrab> oh, even better
[21:24:02] <GothAlice> They might not have quite the same names, but they have the same meanings.
[21:24:48] <GothAlice> Compare https://docs.mongodb.com/manual/reference/program/mongod/ vs. https://docs.mongodb.com/manual/reference/configuration-options/ — they're very close.
[21:25:22] <GothAlice> The conf file is just semi-hierarchical.
[21:25:42] <spacecrab> GothAlice that's what i observed as well -- not 1:1, but the meanings themselves you can derive/associate with little effort
[21:26:16] <spacecrab> i'm reading this right now for the sake of reference/different sources -- is it normal to manually add replica systems via rs.add in the shell? http://www.serverlab.ca/tutorials/linux/database-servers/how-to-create-mongodb-replication-clusters/
[21:26:46] <GothAlice> spacecrab: Yes, or have automation to run that command for you, such as https://www.mongodb.com/cloud
[21:26:48] <spacecrab> i don't understand why someone would want to do that instead of defining it from source/conf... but it seems that everyone favors that option when it comes to tutorials/guides
[21:27:14] <GothAlice> The exact layout of your replica set is a runtime configuration, stored in the database itself, not in a configuration file.
[21:27:37] <GothAlice> spacecrab: ^ should help illuminate the issue. ;)
[21:27:55] <spacecrab> GothAlice: oh, interesting. so i should actually be maintaining it with my own bash/python deployment scripts, rather than being concerned about pre-start configuration changes
[21:27:57] <GothAlice> Similar to user accounts for authentication.
[21:28:16] <spacecrab> (or $cloud service, as you mentioned)
[21:29:02] <GothAlice> There is a free tier. ;)
[21:29:32] <spacecrab> i'll probably dig into it certainly -- but for now i'd like to learn this stuffs :p coming from a history of light oracle DBA stuffs it's very interesting
[21:29:59] <spacecrab> and in a "devops"-y role it's super relevant. haven't had an excuse to touch nosql yet, and from what i've learned so far it's very easy to find one!
[21:30:19] <GothAlice> MongoDB can be… refreshingly lightweight in terms of setup for things like high availability, which can be somewhat more difficult elsewhere.
[21:30:45] <AvianFlu> quick question, if I've got a TTL index on a field, and then update that field before the ttl expires, it resets the countdown, yeah?
[21:30:55] <GothAlice> spacecrab: "Set up three nodes… have them shake hands… and wait, I'm done?" ;)
[21:30:58] <AvianFlu> (assuming I updated it to "now")
[21:31:28] <GothAlice> AvianFlu: It's implemented similar to a cron, running once per minute. Any record with a time <= now is cleaned up, so altering the TTL field is a-OK.
[21:32:02] <AvianFlu> awesome, thanks
[21:32:15] <AvianFlu> so yeah I might lose the race if it's T-1 second when I update it, that makes sense
[21:32:20] <GothAlice> AvianFlu: There are caveats, however. Not all expired records might be cleaned up in a single sweep (it's optimistic), and since it's once per minute, records may easily be stale by up to 59.99 seconds.
[21:32:22] <AvianFlu> it also wouldn't matter for what I'm building right now
[21:32:36] <AvianFlu> yeah, that makes sense
[21:32:41] <AvianFlu> this is a 24 hour timeout, basically
[21:32:43] <GothAlice> (So any time you're using a TTL, also check the TTL field when loading data…)
[21:32:47] <AvianFlu> so if it's off by 60 seconds it's nbd
[21:32:53] <GothAlice> Even better. :)
[21:32:55] <cheeser> GothAlice: auth still stymies me...
[21:32:56] <cheeser> :(
[21:33:23] <GothAlice> cheeser: My crazy auth configs I leave to MMS/cloud. They're pretty… confusing at times, I will admit. T_T
[21:33:56] <spacecrab> GothAlice yeah i was watching some linuxconf talks from a couple years ago, and reading through the docs and i was actually over-thinking that at first... "wait it's that simple?"
[21:34:08] <GothAlice> spacecrab: A common issue. ^_^
[21:34:10] <spacecrab> thank you so much for the insight ^^ do you work with the project?
[21:34:34] <GothAlice> spacecrab: I've only been a vocal user and advocate until recently. Hopefully my patch will get in sometime in the next few weeks. :)
[21:34:48] <Derick> GothAlice: which patch is that again?
[21:34:56] <GothAlice> (Allowing negative $push $position indexes to allow insertion from the end of the array.)
[21:35:06] <GothAlice> It's a really trivial patch.
[21:35:23] <spacecrab> GothAlice: very cool. well rock on! i've been getting into a couple different projects and it's just as redeeming to see you reciprocating valuable information to new users and potential evangelists, as it is to help out myself!
[21:35:27] <GothAlice> Derick: https://github.com/mongodb/mongo/pull/1112
[21:35:58] <GothAlice> spacecrab: It never hurts to help.
[21:37:53] <GothAlice> Derick: Some silly bean decided to use size_t for $position offsets. Because a single document can totally store 2^64 array elements. (Hint: it can't. 2 million NULLs is about the limit of a 16MB document. ;)
[21:37:56] <Derick> GothAlice: the size_t to int change is probably not right
[21:38:31] <Derick> 16MB is a define, not hardcoded...
[21:38:39] <Derick> some customers do change it
[21:38:53] <GothAlice> True, but a 32-bit integer has headroom of 2.147 billion.
[21:38:57] <GothAlice> (Signed.)
[21:39:27] <Derick> I don't get the change to INT_MAX either (from std::numeric_limits<std::size_t>::max() )
[21:39:52] <GothAlice> I'm using int, not int_32 C++ mocked structure, so I'm using the C99 INT_MAX def.
[21:40:02] <GothAlice> Had some issues finding a std:: to go with int_32.
[21:40:26] <GothAlice> The default to "push to the end" relies on using the maximal value, there.
[21:42:05] <GothAlice> Derick: In my first local draft I accidentally set that to zero and all my $push w/o $position were suddenly head pushes, not tail pushes. ;P
[21:43:01] <Derick> oops
[21:45:19] <Derick> GothAlice: I am going to doubt it will make it into 3.4 :-/
[21:45:26] <Derick> But adding a comment
[21:45:29] <Derick> added*
[21:50:08] <GothAlice> Derick: An array of 2 billion NULLs would take up… a hair under 22.35 GiB — if my math is correct: (4+1+1+1+4+2000000000*(1+10+1)+1+1)/1024/1024/1024
[21:50:50] <GothAlice> (Each number in parens there represents an individual "field" from the BSON spec, e.g. int32 prefix size, CString nulls, etc., assuming a 1-character field name for the array.)
[21:51:36] <GothAlice> (A hair under since 9-digit indexes would take one byte less, 8-digit two, etc.)
[22:03:31] <Derick> GothAlice: I know :)
[22:04:20] <GothAlice> Derick: Honest question, then, what sizes do customers actually override the 16MB limit to? I'd like to keep that in mind with somewhat accurate figures in the future. ;)
[22:04:35] <Derick> I don't know
[22:04:38] <GothAlice> XP
[22:04:46] <Derick> I think I overhead 64MB or so
[22:04:57] <GothAlice> Okay, so not gigabytes, at least. ;P
[22:04:59] <Derick> they wanted to know how easy it is