I have a MongoDB running with 3 member replica set. All the members are up & running.
I have one database with 4-5 collections and I want to delete that database.
What is the best way to do it. Can I just use db.dropDatabase() on primary?
Do I need to stop secondary before I drop the database? After I drop the database will secondary members sync automatically to primary? What about the memory, will it get free after I delete the database?
Yes. Just drop the database using the command db.dropDatabase() in the primary and the changes will be propagated to secondaries as well. You don't need to shutdown the secondaries.
as Anand Jayabalan said, you just need to drop the database on primary node. The replication do the rest reading the oplog for the secondaries.
From Reference links and official documentation.
The primary is the only member in the replica set that receives write operations. MongoDB applies write operations on the primary and then records the operations on the primary’s oplog. Secondary members replicate this log and apply the operations to their data sets.
Reference:
https://docs.mongodb.org/manual/core/replication-introduction/
https://docs.mongodb.org/manual/core/replica-set-primary/
Related
Does oplog play a role in replication ,recovery or both.
If we are looking to only recover certain 'non-temporal' collections in our database - in case of a node recover - is it possible to do so selectively.
ie For a particular collection or data operation on a collection,is it possible to flag to omit the operation/collection from oplog.
Is it possible to create a capped collection in a read only mode at a single replica in MongoDB? There is a main database with replica set and I need to use a capped collection with a AWS queue to listen for new insertions. In order to avoid possible listening overloads in the main database, I was wonder whether is possible to create a capped in one of the replicas.
This is not possible as at now. Also keep in mind that replication's main purpose it to have similar data through out the replica set.
Is the data for same timestamps ( i.e. pairs: [timestamp:number_of_operation] -- [operation] ) between oplogs:
on primary server;
on secondary server;
in oplog, formed by mongodump (mongodump --oplog ...);
are identical?
Some my checks displays that are the same, but i can`t find this fact in official documentation.
Thanks in advance!
The entries in the oplogs for a MongoDB replicaset are identical everywhere. The entries are created on the primary and then copied everywhere else - either via replication by reading from the local.oplog.rs collection or by being copied via mongodump with the --oplog option.
From the documentation:
Replica Set Oplog
The oplog (operations log) is a special capped collection that keeps a
rolling record of all operations that modify the data stored in your
databases. MongoDB applies database operations on the primary and then
records the operations on the primary’s oplog. The secondary members
then copy and apply these operations in an asynchronous process. All
replica set members contain a copy of the oplog, in the local.oplog.rs
collection, which allows them to maintain the current state of the
database.
Keep in mind that each entry may be copied a few times, if your replicaset is chaining it's replication, from primary to secondary to secondary for example. In each case however it's an identical copy of what came from the primary. The entries are created there and not updated.
http://docs.mongodb.org/manual/core/replica-set-oplog/
This is a follow-up to my previous question:
Suppose I want to replicate only part of the databases in Mongo. I know that Mongo does not provide selective replication. I am thinking over the following workaround:
Export (I do not know how to do it in mongo) only the databases I want to replicate in primary;
Remove the secondary instance I want to recover from the replica set;
Import data to the secondary instance;
Add the secondary instance to the replica set.
Will it work ?
I am afraid that the secondary instance will copy the rest of the databases once I added it to the replica set. Is it correct ?
This will not work, also not a good idea. A replica set uses an oplog to propagate changes made to any database running on a given mongod instance.
Have you considered running a separate mongod instance containing the collection you wish to replicate?
MongoDB 2.2 has a write lock per database as opposed to a global write lock on the server in previous versions. So would it be ok if i store each collection in a separate database to effectively have a write lock per collection.(This will make it look like MyISAM's table level locking). Is this approach faulty?
There's a key limitation to the locking and that is the local database. That database includes a the oplog collection which is used for replication.
If you're running in production, you should be running with Replica Sets. If you're running with Replica Sets, you need to be aware of the write lock effect on that database.
Breaking out your 10 collections into 10 DBs is useless if they all block waiting for the oplog.
Before taking a large step to re-write, please ensure that the oplog will not cause issues.
Also, be aware that MongoDB implements DB-level security. If you're using any security features, you are now creating more DBs to secure.
Yes that will work, 10gen actually offers this as an option in their talks on locking.
I probably isolate every collection, though. Most databases seem to have 2-5 high activity collections. For the sake of simplicity it's probably better to keep the low activity collections grouped in one DB and put high activity collections in their own databases.