发布于 2015-09-14 15:13:00 | 213 次阅读 | 评论: 0 | 来源: 网络整理
This document answers common questions about database replication in MongoDB.
If you don’t find the answer you’re looking for, check the complete list of FAQs or post your question to the MongoDB User Mailing List.
Frequently Asked Questions:
MongoDB supports master-slave replication and a variation on master-slave replication known as replica sets. Replica sets are the recommended replication topology.
Primary and master nodes are the nodes that can accept writes. MongoDB’s replication is “single-master:” only one node can accept write operations at a time.
In a replica set, if a the current “primary” node fails or becomes inaccessible, the other members can autonomously elect one of the other members of the set to be the new “primary”.
By default, clients send all reads to the primary; however, read preference is configurable at the client level on a per-connection basis, which makes it possible to send reads to secondary nodes instead.
Secondary and slave nodes are read-only nodes that replicate from the primary.
Replication operates by way of an oplog, from which secondary/slave members apply new operations to themselves. This replication process is asynchronous, so secondary/slave nodes may not always reflect the latest writes to the primary. But usually, the gap between the primary and secondary nodes is just few milliseconds on a local network connection.
It varies, but a replica set will select a new primary within a minute.
It may take 10-30 seconds for the members of a replica set to declare a primary inaccessible. This triggers an election. During the election, the cluster is unavailable for writes.
The election itself may take another 10-30 seconds.
注解
Eventually consistent reads, like the ones that will return from a replica set are only possible with a write concern that permits reads from secondary members.
Yes.
For example, a deployment may maintain a primary and secondary in an East-coast data center along with a secondary member for disaster recovery in a West-coast data center.
也可以参考
Yes, but not without connection failures and the obvious latency.
Members of the set will attempt to reconnect to the other members of the set in response to networking flaps. This does not require administrator intervention. However, if the network connections between the nodes in the replica set are very slow, it might not be possible for the members of the node to keep up with the replication.
If the TCP connection between the secondaries and the primary instance breaks, a replica set the set will automatically elect one of the secondary members of the set as primary.
1.8 新版功能.
Replica sets are the preferred replication mechanism in MongoDB. However, if your deployment requires more than 12 nodes, you must use master/slave replication.
1.6 版后已移除.
Replica sets replaced replica pairs in version 1.6. Replica sets are the preferred replication mechanism in MongoDB.
Journaling facilitates faster crash recovery. Prior to journaling, crashes often required database repairs or full data resync. Both were slow, and the first was unreliable.
Journaling is particularly useful for protection against power failures, especially if your replica set resides in a single data center or power circuit.
When a replica set runs with journaling, mongod instances can safely restart without any administrator intervention.
注解
Journaling requires some resource overhead for write operations. Journaling has no effect on read performance, however.
Journaling is enabled by default on all 64-bit builds of MongoDB v2.0 and greater.
Yes.
However, if you want confirmation that a given write has arrived at the server, use write concern. The getLastError command provides the facility for write concern. However, after the default write concern change, the default write concern acknowledges all write operations, and unacknowledged writes must be explicitly configured. See the 驱动程序和客户端 documentation for your driver for more information.
Some configurations do not require any arbiter instances. Arbiters vote in elections for primary but do not replicate the data like secondary members.
Replica sets require a majority of the original nodes present to elect a primary. Arbiters allow you to construct this majority without the overhead of adding replicating nodes to the system.
There are many possible replica set architectures.
If you have a three node replica set, you don’t need an arbiter.
But a common configuration consists of two replicating nodes, one of which is primary and the other is secondary, as well as an arbiter for the third node. This configuration makes it possible for the set to elect a primary in the event of a failure without requiring three replicating nodes.
You may also consider adding an arbiter to a set if it has an equal number of nodes in two facilities and network partitions between the facilities are possible. In these cases, the arbiter will break the tie between the two facilities and allow the set to elect a new primary.
也可以参考
Arbiters never receive the contents of a collection but do exchange the following data with the rest of the replica set:
If your MongoDB deployment uses SSL, then all communications between arbiters and the other members of the replica set are secure. See the documentation for 使用SSL连接MongoDB for more information. Run all arbiters on secure networks, as with all MongoDB components.
See
The overview of Arbiter Members of Replica Sets.
All members of a replica set, unless the value of votes is equal to 0, vote in elections. This includes all delayed, hidden and secondary-only members, as well as the arbiters.
也可以参考
Yes.
Factors including: different oplog sizes, different levels of storage fragmentation, and MongoDB’s data file pre-allocation can lead to some variation in storage utilization between nodes. Storage use disparities will be most pronounced when you add members at different times.