Tag Info

New answers tagged

0

Have you searched the Internet for answers? Note: I am not personally interested in migrating to MongoDB, but ... MSSQL To MongoDB Tool - Home https://mssql2mongo.codeplex.com/ Also, an experience not necessarily related to the above tool: http://blog.mongodb.org/post/84424711763/betting-the-farm-on-mongodb And there are companies that provide non-free ...


0

You can reverse the sort direction to get the minimum instead of the maximum value: # Sort by myfield (ascending value) and return first document collection.find_one(sort=[("myfield", 1)])["myfield"] This example assumes that: myfield is a numeric value (so the sort order makes sense to determine a minimum or maximum) myfield exists in the matching ...


0

From http://docs.mongodb.org/manual/reference/ulimit/ : limit fsize unlimited unlimited # (file size) limit cpu unlimited unlimited # (cpu time) limit as unlimited unlimited # (virtual memory size) limit nofile 64000 64000 # (open files) limit nproc 64000 64000 # (processes/threads)


0

Solution: the two different machanisms need to be added in the configuration. Like: authenticationMechanisms=PLAIN,MONGODB-CR After that, it's necessary to create the users which should be authenticated via LDAP as followed: db.getSiblingDB("$external").createUser({ user : "syranno", roles: [ { role: "readWrite", db: "testdb" } ] } ) By adding the user ...


0

PostgreSQL and MySQL will also be able to sustain this import, provided the Staging table to which you import should be simple with out indexes and all so as to speed up the import. Unless we get to know about the Transformation logic involved during the import, no good solution can be offered.


1

Easiest way to find the storage engine being used currently in linux. Inside mongo console type db.serverStatus().storageEngine It returns the storage engine being used currently { "name" : "wiredTiger" } Once it is confirmed that wiredTiger is being used then type db.serverStatus().wiredTiger to get all the configuration details of wiredTiger.


2

Original Answer (leaving for people that might hit this because of the simple explanation): The clusterAdmin role only applies when you authenticate against the admin database, so unless you specify the --authenticationDatabase option to be admin when you are running mongodump/mongorestore I suspect you are getting a lesser privilege when authing against ...


2

As an answer to your first question, both tools (by default) will just walk the _id index to fetch the data and then write it out to disk. So, yes, both tools will similarly impact your working set which is why I would generally recommend running them against a secondary (preferably a hidden secondary if possible). I'll echo Stennie in the comments here ...


2

(sorry, dunno) --query will select or exclude entire documents, not fields. It would be a good idea though : --query '{datetime:{$gt:ISODate("2014-01-01T00:00:00.000Z")}},{_id:0,name:1,address:1,interests:1}'* ) Mongodump uses bson file structure and preserves the data types. Mongoexport will lose data type of the values. Such as ...


0

Expanding on what @mustaccio said, the answer for me was the SELinux context on the new logpath and dbpath. I ran the following commands and all was well: sudo chcon -Rv --type=mongod_log_t $logpath sudo chcon -Rv --type=mongod_var_lib_t $dbpath (this was on RHEL 7.1 btw)


0

To query two collections with related data the common approach (as at MongoDB 3.0) is to find a list of matching _id values from the first collection which can used with a $in query on the second. Here's an example using the mongo shell: // Find _ids for matching locations based on some criteria (eg. "abbrev") var matches = db.locations.find({ "abbrev": ...


2

I think I found my answer from the mongoDB manual: In general, use embedded data models when: you have “contains” relationships between entities. See Model One-to-One Relationships with Embedded Documents. you have one-to-many relationships between entities. In these relationships the “many” or child documents always appear with or are viewed in the ...


0

Using "ReadPreference.SECONDARY_PREFERRED" does not provide any such guarantee to read from a node in the same region. I'm not familiar with Mongoose but the first thing I would do is prove this via the Mongo shell first. Second I would remove the redundancy you acknowledged above. If it shouldn't be there, get rid of it. Via the shell; try using a read ...


0

In order for data to be distributed across multiple shards, you need to have multiple chunks for a given sharded collection. A chunk is a contiguous range of shard key values representing approximately 64 megabytes of data by default. Chunk ranges are normally created automatically based on observation of the shard key values and size of documents being ...


1

This is the same issue as described here (for MySQL): High CPU usage from MySQL with no queries at all running sudo date -s now Caused by leap second and a bug in the kernel.


0

Based on the comments I have received the following actions seem to address my concerns: Migrate existing collections to power of 2 sizes. Run repair or compress periodically to optimize the free list search so that default allocation of new disk space on timeout is avoided. Only capped collections should be considered "100% maintenance-free".


-1

Check the config file there will be bind-ip and port pass that value while connecting to client mongo <ip.add.re.ss>:<port>/<dbname> assume ip is 10.10.10.2 and port is 27017 mongo 10.10.10.2:27017/test


0

If your base document with all the data is 300 bytes, and worst case scenario for storage usage scenario, your indexes are all 300 bytes each but just sorted differently, would get you 900 bytes of memory used per document for indexes and 300 bytes for the base. 1440 events * 1200 bytes (Base document + 3 indexes each at 300 bytes) = 1728000 bytes ...


0

You will need to study the BSON specs to create your own functions, or use one of the available libraries that others made already: http://bsonspec.org/implementations.html


1

To migrate data between different storage engines in MongoDB 3.0 you will need to perform an initial sync to the new replica set node or use mongorestore to seed a new replica set with your data. If you want to add a node with a new storage engine to a live production replica set, rs.add() is the correct approach. To ensure a smooth upgrade I would also ...


1

You are not using the correct index. The current index will bring the results sorted but it have to perform a full collection scan. You need an index like: {"category_memberships.node":1,"ships_to_australia":1,"ps":1,"salesRate":-1} that limits the search and sorts at the same time. The query execution variation has to do with the hotset and collection ...


0

Yes definitely, NoSQL database better suits storing timeseries data than traditional RDBMS. Yes MongoDB is exceptionally adapted to this use case. -How should you structure the database? One document = one time series input VS multiple time series. The answer is to store in one document multiple timeseries. Having less documents will help the performance ...


1

MongoDB (as at 3.0) only supports a single primary per replica set. Replica sets can have up to 50 members, with up to 7 voting members. The 2-node replica sets you have described should have a third member (either a data-bearing secondary node or a voting-only arbiter) to allow for failover. Replica sets require a strict majority of votes (n/2+1) in order ...



Top 50 recent answers are included