replica set

Replication provides redundancy and increases data availability. With multiple copies of data on different database servers, replication protects a database from the loss of a single server. Replication also allows you to recover from hardware failure and service interruptions. With additional copies of the data, you can dedicate one to disaster recovery, reporting, or backup.

使用RS，主要为了实现读写分离、HA、容灾等目的

The primary accepts all write operations from clients. Replica set can have only one primary. Because only one member can accept write operations, replica sets provide strict consistency. To support replication, the primary logs all changes to its data sets in its oplog.

只有primary可写

An arbiter will always be an arbiter. A primary may step down and become a secondary. A secondary may become the primary during an election.

Most deployments, however, will keep three members that store data: A primary and two secondary members.

Only add an arbiter to sets with even numbers of members. If you add an arbiter to a set with an odd number of members, the set may suffer from tied elections.

只有当replica set有偶数个节点时，才添加仲裁节点;如果replica set有奇数个节点（比如1个primary，2个secondary），不要添加仲裁节点

Do not run an arbiter on systems that also host the primary or the secondary members of the replica set.

The standard replica set deployment for production system is a three-member replica set. These sets provide redundancy and fault tolerance. Avoid complexity when possible, but let your application requirements dictate the architecture.

Replica sets use elections to determine which set member will become primary. Elections occur after initiating a replica set, and also any time the primary becomes unavailable.

From the perspective of a client application, whether a MongoDB instance is running as a single server (i.e. “standalone”) or a replica set is transparent.

rs.initiate()
rs.conf()
rs.add()
rs.status()

by default, read from secondary server is not allowed. for example, if try "show collections", you will see the following information:
{ "$err" : "not master and slaveOk=false", "code" : 13435 }

to solve this problem, execute

rs.slaveOK()

first

尝试将primary停止，一台secondary自动升级为primary。重新启动原来的primary后，它会降级为secondary。通过这种方式，实现了failover。数据库确实是始终保持可用的，但是目前还不清楚为何对于app来说是透明的。因为毕竟每一个节点的IP都是不同的，如果app中写死了primary的ip地址，那么虽然有了新的primary，app也不知道应该将请求地址切换到新的primary上

猜测应该是在driver中提供了这个能力，即创建连接时指定的不是ip地址，而是replica set的name，由driver来决定primary的地址。明天需要写一个demo验证一下