I have two mongod instances without replication each having same collection name but different data.Now initialized replication between them.Secondary machine copies all data from primary machine and looses it's original data.Can I recover original data present in secondary machine ?
This is the expected behaviour with MongoDB replica sets: data from the primary is replicated to the secondaries. When you add a server as a new secondary, it does an "initial sync" which copies data from the primary. The replica sets are designed for failover and redundancy; your secondary nodes should have data consistent with the primary and their current replication lag.
If you have overwritten your previous database, your only option is to restore from a backup.
See also:
Backup and Restoration Strategies
Replica Set Internals Part V: Initial Sync
Related
MongoDB replication, it has 3 servers(Server1, Server2, Server3). Due to any reason, Server1 goes down and Server2 acts as Primary and Server3 as Secondary mode.
Query: As Server1 is down and after 2-3 hours we made it up(running). The 3 hrs gap between Server1 data and Server2 data, how it will be sync up?
The primary maintains an oplog detailing all of the writes that have been done to the data. The oplog is capped by size, the oldest entries are automatically removed to keep it below the configured size.
When a secondary node replicates from the primary, it reads the oplog and creates a local copy. If a secondary is offline for a period of time, when it comes back online, it will ask the primary for all oplog entries since the last one that it successfully copied.
If the primary still has the entry that the secondary most recently saw, the secondary will begin applying the events it missed.
If the primary no longer has that entry, the secondary will log a message that it is too stale to catch up, and manual intervention will be required. This would usually require a manual resync
What is the consistency of Postgresql HA cluster with Patroni?
My understanding is that because the fail-over is using a consensus (etc or zookeeper) the system will stay consistent under network partition.
Does this mean that transaction running under the serializable Isolation Level will also provide linearizability.
If not which consistency will I get Sequential Consistency, Causal Consistency .. ?
You shouldn't mix up consistency between the primary and the replicas and consistency within the database.
A PostgreSQL database running in a Patroni cluster is a normal database with streaming replicas, so it provides the eventual consistency of streaming replication (all replicas will eventually show the same values as the primary).
Serializabiliy guarantees that you can establish an order in the database transactions that ran against the primary such that the outcome of a serialized execution in that order is the same as the workload had in reality.
If I read the definition right, that is just the same as “linearizability”.
Since only one of the nodes in the Patroni cluster can be written to (the primary), this stays true, no matter if the database is in a Patroni cluster or not.
In a distributed context, where we have multiple replicas of an object’s state, A schedule is linearizable if it is as if they were all updated at once at a single point in time.
Once a write completes, all later reads (wall-clock time) from any replica should see the value of that write or the value of a later write.
Since PostgreSQL version 9.6 its possible to have multiple synchronous standy node. This mean if we have 3 server and use num_sync = 2, the primary will always wait for write to be on the 2 standby before doing commit.
This should satisfy the constraint of linearizable schedule even with failover.
Since version 1.2 of Patroni, When synchronous mode is enabled, Patroni will automatically fail over only to a standby that was synchronously replicating at the time of the master failure.
This effectively means that no user visible transaction gets lost in such a case.
I need to set up a MongoDB cluster with two shards. Each shard contains 3 replica member: primary, secondary and arbiter. I already open firewall rules for mongos to talk to primary and secondary nodes but not the arbiters. I try to connect to mongos, do sh.addShard() and see that it is working properly.
My question then is do we really need to allow mongos to interact with arbiters as well?
From this link we know that mongos doesn't talk to hidden members, but nothing was mentionned about arbiters.
mongos needs to see all nodes including arbiters in order to provide transparent failover.
In normal circumtances when all 3 replica nodes (primary, secondary and arbiter) are up, mongos doesn't need to see arbiter. But when there are only one primary and one arbiter, mongos needs to check arbiter to make sure there is no network partition error in election process.
Arbiters are there just to elect the new primary depending upon the priorities set in mongod.conf. Arbiter themselves don't store any data but they do maintain heartbeat from all the mongod servers of a replica set, and arbiters are the first ones to know if any of mongod servers of a replica set is down.
Silly question, when we talk about secondaries in the context of failover behaviour, with regards to master-master/multi-master, is that basically any node other than the one that we are currently reading from or writing to?
In master-master replication both the nodes are primary and secondary. In multi master replication every node is secondary but some or all are primary.
Multi master means there many database servers over which write can perform. In order to sync with other data nodes or database server we have to read all other writes and It behaves as secondary. In master slave replication we have only one master and many slaves. Master ensures that he is only write enabled and no one can writes so no need to read any one. and it behave as primary only.
For example- mysql 5.6 replication has support master-master replication but doesn't support multi master replication. But in mysql 5.7 replication it also support multi master replication. In mongoDB It only support master - slave replication.
I am handling with Autosharding,and i had questioned about Whether the data in the shard "A" Will be available in shard "B".They have answered as Data in the shard "A" Will not be available in shard "B".In this scenario,how the automatic failover works? For example i have 3 Shards one of my shards gets failed, Then we can access data from the other shards right?. If the data is different in each shard then how can we access data?...Anyone can explain about this..Plz..
Sharding is not about failover but rather about scalability. Failover achieved with replica sets. I.e. each shard is running as replica set with multiple nodes, when the master node fails new master node is elected among slave ones.
Here how it looks: http://www.infoq.com/resource/news/2010/08/MongoDB-1.6/en/resources/mongodb2.png