I have a replica setup with 1 Arbiter and 3 Mongo Databases.
2 of the databases (db1 and db2) I have given an equal priority of becoming primary, and the third one (db3) I have a priority of 0.
I am trying to take db3 offline to copy the data to another server, but every time I run db.shutdownServer() in db3, it causes db1 and db2 to become secondaries, and they remain stuck in this configuration.
It's my understanding that reelection only takes place when Primaries become unavailable.
Am I missing something??
So what was actually happening was I had added 3 other databases (shutdown) in hidden mode which were going to become my next replica set. Apparently Mongo has a setting where if the number of shutdown dbs > running dbs, the replica set goes into read-only mode, so obviously every time I would shutdown db3 this would trigger this to take place.
Related
Postgres and the default location for its storage is at my C-drive. I would like to restore a backup to another database but to access it via the same Postgres server instance - the issue is that the size of the DB is too big to be restore on the same c-drive ...would it be possible to tell Postgres that the second database should be restore and placed on another location/drive (while still remaining the first one)? Like database1 at my C-drive and database2 at my D-drive?
Otherwise the second best solution would be to install 2 separate Postgres instances - but that also seems a bit overkill?
That should be entirely achievable, if you've used the postgres pg_dump command.
The pg_dump command does not create the database, so you create it yourself first. Use CREATE TABLESPACE to specify the location.
CREATE TABLESPACE secondspace LOCATION 'D:\postgresdata';
CREATE DATABASE seconddb TABLESPACE secondspace;
This creates an empty database on the D: drive.
Then the standard restore from a pg_dump should work:
psql seconddb < dumpfile
Replication
Sounds like you need database replication.
There are several ways to do this with Postgres, one built-in, and other approaches using add-on libraries.
Built-in replication feature
The built-in replication feature is likely to suit your needs. See the manual. In this approach, you have an instance of Postgres running on your primary server, doing reads and writes of your data. On a second server, an entirely separate computer, you run another instance of Postgres known as the replica. You first set up the replica by doing a full backup of your database on the first server, and restore to the second server.
Next you configure the replication feature. The replica needs to know it is playing the role of a replica rather than a regular database server. And the primary server needs to know the replica exists, so that every database change, every insert, modification, and deletion, can be communicated.
WAL
This communication happens via WAL files.
The Write-Ahead Log (WAL) feature in Postgres is where the database writes all changes first to the WAL, and only after that is complete, then writes to the actual database. In case of crash, power outage, or other failure, the database upon restarting can detect a transaction left incomplete. If incomplete, the transaction is rolled back, and the database server can try again by seeing the "To-Do" list of work listed in the WAL.
Every so often the current WAL is closed, with a new WAL file created to take over the work. With replication enabled, the closed WAL file is copied to the replica. The replica then incorporates that WAL file, to follow the same "To-Do" list of changes as written in that WAL file. So all changes are made to the replica database exactly as they were made to the primary database. Your replica is an exact match to the primary, except for a slight lag in time. The replica is always just one WAL file behind the progress of the primary.
In times of trouble, the replica serves as a warm stand-by. You can shutdown the primary, then tell the replica that it is now the primary. You can even configure the replica to be a hot stand-by, meaning it will automatically take-over when the primary seems to have failed. There are pros and cons to hot stand-by.
Offload read-only queries
As a bonus feature, the replica can be used for read-only queries. If your database is heavily used, you can offload some of the work burden from your primary to the replica. Any queries that do not require the absolute latest information can be shifted by connecting to the replica rather than the original. For example, a quarterly sales report likely does not need the latest data stored in the active WAL file that has not yet arrived on the replica.
Physical replication means all databases are copied
Caveat: This built-in replication feature is physical replication. This means all the changes to the entire Postgres installation (formally known as a cluster, not to be confused with a hardware cluster) is copied to the replica. If you use one Postgres server to server multiple databases, all those databases must be replicated – you cannot pick and choose which get copied over. There may be alternative replication features in the future related to logical replication.
More to learn
I am being brief here. The topics of replication, high-availability, and disaster-recovery are broad and complex, too much for an Answer on Stack Overflow.
Tip: This kind of Question might have been better asked on the sister site, DBA.StackExchange.com.
Is there any ways or methods to start mongodb replication directly when mongod service start? I don't want to enter to shell and ON the replication?
Thanks!
You can create a mongod service which starts automatically when server starts.
First you need to create a configuration file(mongodb.conf) which will include configuration settings such as replicaSet name etc. Then create a service and install it using following command
mongod -f c:\mongod.conf --install
Then start the service using
net start mongodb
Read about configuration file here and
How to install mongo as service here
When you create a valid replica set in mongodb, your data will be asynchronously from the primary member to the secondary members in replica set
Having said that, you're not required to do extra efforts manually to get data replication done
When you do rs.slaveOk() on secondary, that allows you to query data from secondary members in the replica set.
It's a provision. It allows you to read from secondary provided that you're can tolerate the possible eventual consistent data. The replication does not happen when you do rs.slaveOk() on secondary
I'm not sure to understand. Your question was about service start. On my part, I install mongo on ubuntu and the service is not started with replicatet mode.
Finally, I disabled the first one and I created another service with the option --replSet myReplicat .
When you have only 2 servers, there is a problem with majority votes. On my part, I had 2 secondary after I stopped the primary and it was difficult to comeback with 1 primary and 1 secondary.
Effectively, the replication is always active. By default, all connections should go to the Primary. If you want to readonly from a secondary, you first enter the commande rs.slaveOk(). This command is active at session level. If you reconnect, you have to pass it again. It is not possible to put it at server side.
I have created 3 AWS instances for mongodb. One for primary, one for secondary and one arbiter. My application is pointing to the Primary node. So when the Primary goes down and becomes Secondary no data is posted on it. How can I enable write operations for a secondary node. Mongodb's write concern (w:"majority") didnt work for me.
Can anyone please give a work around ?
You cannot write on a secondary node.
If you primary goes down, it will become a secondary which will receive the writes through the replication mechanism from the new elected primary (only one machine of yours can be as the other member is an arbiter which doesn't hold data).
Write concern is not about writing to secondaries directly. It is about how many replica set member (primary, secondaries...) have to acknowledge the write for you application to receive the ok from the driver.
Seems like it will work if you don`t connect on the primary direction, but with the name of the replica set as a prefix. If the primary has been restarted and is a secondary now, it will redirect you to the new primary.
If your primary is mongo1 and your replica set is named rs you don`t use
mongo --host mongo1:27017
but
mongo --host rs/mongo1:27017
Suppose I have a Mongo replica set (a primary and few secondaries) with two databases: db1 and db2. One secondary Mongo crashed and lost its data. Now when this Mongo restarts it will recover and copy both db1 and db2 from the primary.
Since such recovery takes a lot of time I would like this secondary Mongo to copy only db1 (but not both db1 and db2) upon recovery. Can I do it with Mongo 2.4.6 ?
MongoDB does not yet have the capacity for selective replication.
Feel free to open a JIRA: https://jira.mongodb.org/secure/Dashboard.jspa there is probably already one but a Google search by me can't bring it up.
Of course, one option here, to sped things up, is to actually physically copy the data from one location to the other without waiting for MongoDBs replication to take hold.
As #Stennie mentions, this is actually the JIRA for selective replication: https://jira.mongodb.org/browse/SERVER-1559
For development reasons, I need to backup a production replica set mongodb and restore it on a stand alone, different machine test instance.
Some docs are talking about the opposite ( standalone 2 replica-set ), but I cannot find his downgrade/rollback way.
What's the way to go, in this case ?
No matter how many nodes you have in a replica set, each of them holds the same data.
So getting the data is easy - just use mongodump (preferably against the secondary, for performance reasons) and then mongorestore into a new mongod for your development stand-alone system.
mongodump does not pick up any replication related collections (they live in database called local). If you end up taking a file system snapshot of a replica node rather than using mongodump, be sure to drop the local database when you restore the snapshot into your production stand-alone server and then restart mongod so that it will properly detect that it is not part of a replica set.