[09:22:42] <fontanon> Hi everybody, I got something wrong with the balancer ... perhaps somebody could help .... Failed with error 'could not acquire collection lock for podsystem.pwcdr to migrate chunk [{ : MinKey },{ : MaxKey }) :: caused by :: Lock for migrating chunk [{ : MinKey }, { : MaxKey }) in podsystem.pwcdr is taken.', from shard0001 to shard0000
[10:19:30] <fontanon> Hi everybody, I got something wrong with the balancer ... perhaps somebody could help .... Failed with error 'could not acquire collection lock for podsystem.pwcdr to migrate chunk [{ : MinKey },{ : MaxKey }) :: caused by :: Lock for migrating chunk [{ : MinKey }, { : MaxKey }) in podsystem.pwcdr is taken.', from shard0001 to shard0000
[11:05:03] <joannac> fontanon: still seeing balancing? or not?
[11:06:31] <fontanon> joannac, well now is not balancing and the error stills appearing
[11:06:54] <fontanon> balancer: Currently enabled: yes Currently running: no
[11:07:01] <fontanon> 1 : Failed with error 'could not acquire collection lock for podsystem.pwcdr to migrate chunk [{ : MinKey },{ : MaxKey }) :: caused by :: Lock for migrating chunk [{ : MinKey }, { : MaxKey }) in podsystem.pwcdr is taken.', from shard0001 to shard0000
[11:07:01] <fontanon> 1082 : Failed with error 'moveChunk failed to engage TO-shard in the data transfer: can't accept new chunks because there are still 1 deletes from previous migration', from shard0001 to shard0000
[13:55:26] <vagelis> Hello, i use python and pymongo. Is it possible to store data or the mongo database in memory(or something like that) so unit tests can run faster? Im not familiar with this i learn it 5' ago cause my tests take too long and i asked if there was a way to make them run faster.
[13:57:24] <StephenLynx> you can always store data in RAM, but then I don't think your tests will represent the actual scenario they should be testing in the first place.
[14:01:15] <vagelis> The other guy told me that he uses postgres and in every test he resets the database so he doesnt create it every time. Does mongo/pymongo have something like that? :S
[14:10:06] <ekristen> I had a collection that had grown over the months to be millions of entries, since then we’ve pruned it back down to around 10k entries, but in that time the database went from 50gb to 860gb, can I run compact to gain some of that space back?
[14:11:35] <ekristen> the size is now 100MB but the storage size is 680gb
[14:19:30] <fontanon> joannac, sorry for bothering ... did you have some time to have a look at my sharding status here? http://pastebin.com/rdB4SssW
[14:24:18] <bigblind> Can someone tell me what the documentation here means by sub-collection? http://api.mongodb.org/python/current/api/pymongo/collection.html#pymongo.collection.Collection
[14:25:22] <bigblind> is that the collection of al the embedded documents for the given key in each document in the collection?
[14:25:45] <cheeser> the wording is weird but i think it's saying just the name of the collection rather than its fully qualified name of <database>.<collection>
[14:29:31] <bigblind> cheeser: Sorry, I'm not talking about the constructor, but the c[name] (or c.name) definition below that.
[14:30:06] <StephenLynx> vagelis no. you don't have to create anything, though.
[14:30:22] <StephenLynx> collections and databases are created automatically once you write anything to them.
[14:30:34] <StephenLynx> I just suggest you use ensureIndex at every boot.
[14:30:55] <vagelis> StephenLynx yea i completely forgot about removing everything from colections after every test(teardown) but now im searching how to create the database only once :|
[14:31:15] <StephenLynx> I just drop the database when I want to.
[14:31:31] <StephenLynx> it doesn't change anything to me if the database is there or not.
[14:31:36] <StephenLynx> I ensure the indexes and boot.
[14:32:19] <vagelis> how could i create the database only once? I mean i know the setup,teardown methods but then what? :S
[14:32:39] <StephenLynx> you dont create databases.
[14:32:40] <ekristen> question, if I have an index that has had millions of entries and on disk has grown to 860gb, but it is currentl only 100mb, will compact give that back to me, or would it just be easier to backup the documents that are currently in it, delete the collection, and re-add the collection and restore the documents? it only has a few thousand right now in it ...
[14:32:44] <StephenLynx> it is created when necessary.
[14:42:17] <GothAlice> ekristen: Compact won't free allocated disk space, it'll just rearrange the data within that disk space to have fewer "holes" (depending on how often you update and grow record sizes, delete records, etc.)
[14:42:32] <ekristen> GothAlice: that is what I thought
[14:42:37] <GothAlice> ekristen: A full repair, which writes out new data files, then moved them in place over the originals, _will_ free on-disk stripes.
[14:43:18] <StephenLynx> GothAlice is it possible to shard gridfs, right?
[14:43:57] <StephenLynx> I got a person that displayed interest in my project that has this issue,
[14:44:03] <ekristen> GothAlice: in a replicaset, is the best way to do a full repair by doing it on a secondaries first?
[14:44:21] <StephenLynx> it constantly has to add new hard drives to the system to accommodate static files.
[14:44:26] <GothAlice> Depending on your tasks, it's generally a good idea to keep file stripes for the same file together, but that'll depend on usage. If random seeking in very large files is desireable (i.e. to support multiple streaming users) then spreading the chunks around may become a better idea.
[14:45:12] <lqez> ekristen: http://docs.mongodb.org/manual/reference/command/compact/#disk-space says as like as GothAlice
[14:45:20] <lqez> compact requires up to 2 gigabytes of additional disk space while running. Unlike repairDatabase, compact does not free space on the file system.
[14:45:28] <GothAlice> ekristen: Doing it on a secondary first is generally a good idea both as a "test run" and because the secondary will become primary when you bring the primary down to --repair it, so it'll save some time going back and forth if you do the secondaries first.
[16:55:50] <ksmtk> and trying to setup auth mongo db
[17:34:53] <LauraG> Hello, I've a question, let's say I have semi-huge collection with an indexed INT field, if I want to start using "strings" instead, do I have to reindex my collection? And do I have to make separate queries to fetch the documents with the "int" field and the ones with the "string" field?
[17:36:31] <cheeser> no, you don't. though your queries will probably need a look.
[17:36:55] <cheeser> yes, to the second part: you'd have to do one query per field type
[17:44:00] <LauraG> Thanks cheeser!, so technically I could use something like this for my query: {"$or": [{"field": 1}, {"field": "1"}]}, and still get an indexed query
[17:44:59] <cheeser> you'd probably want to migrate your data at some point, though.
[17:45:04] <crazydip> from what I've read, WiredTiger in MongoDB 3.0.5 is not supported in PPC64, but what about PPC64LE?
[17:49:20] <LauraG> cheeser: is there an "update" operator to transform my data (ints to string) or do I have to do this manually, as in write a forEach function instead that updates the type.
[17:50:34] <cheeser> you can $set the value after converting, sure.
[17:51:01] <cheeser> search using $type on that field then in forEach() $set them to the new converted type.
[17:53:25] <saml> isn't canonical way to migrate data with zero downtime mongo-connector?
[18:06:21] <RWOverdijk> Something I've never quite understood about mongo is how to manage associated data (joins). I know mongo doesn't have joins, that's the confusing part. Say I have addresses and activities. I want to be able to query both. I also want to be able to fetch activities, and also get their associated addresses. Would I have to query address for every activity?
[18:33:44] <RWOverdijk> But you did give me an idea.
[18:41:16] <ksmtk> RWOverdijk: btw your doc is v2.4, I'm using v3.0
[19:10:32] <RWOverdijk> ksmtk, more or less same thing
[19:10:46] <RWOverdijk> I googled your question and gave you back the first result
[19:11:13] <shortdudey123> i am using the mongodb 3.0.4 rpm install from the mongo repo on CentOS 7.1, when i start the mongo service, it complains about soft process limits being 4096. The default init file that the package drops has
[19:11:22] <shortdudey123> anyone seen this before?
[19:17:00] <RWOverdijk> StephenLynx, Another idea! Fetch all activities, then fetch all addresses where id in []. Then loop the activities and replace the ids with the address objects
[19:17:12] <RWOverdijk> That'd only be two queries, and very optimized code execution
[19:17:36] <RWOverdijk> (id in would be the address ids as collected from the activity results)
[19:18:02] <RWOverdijk> btw if you want me to stop asking you directly, let me know. I can imagine it's getting a bit annoying.
[19:41:22] <StephenLynx> if I am busy I just ignore and keep working :V
[19:41:46] <StephenLynx> and if you can perform just two queries, then its ok.
[20:38:32] <mrmccrac> trying to setup RBAC within a sharded environment, turned on authorization on my config servers and my shard, when i restart everything mongos has the following error:
[20:38:43] <mrmccrac> 2015-08-03T20:33:35.141+0000 E SHARDING [mongosMain] could not verify that config servers are in sync :: caused by :: no config servers successfully contacted :: caused by :: not authorized on config to execute command { dbhash: 1, collections: [ "chunks", "databases", "collections", "shards", "version" ] }
[20:39:05] <mrmccrac> created a root user that belongs to the root role
[20:39:30] <mrmccrac> i think i need to tell what credentials mongos needs to use when talking to the config servers..?
[21:21:52] <shortdudey123> i am using the mongodb 3.0.4 rpm install from the mongo repo on CentOS 7.1, when i start the mongo service, it complains about soft process limits being 4096. The default init file that the package drops has ulimit -u 64000. Anyone seen this happen before?
[23:10:40] <EllisTAA> i’m trying to install mongo but how do i set permissions?
[23:45:05] <cheeser> doh! left two minutes too soon.