mongodb主从同步、数据一致性和高可用分析

一、副本集（一个主，多个从，而且高可用）

1.  读操作可指定从主节点读取还是从从节点读取；写操作只写主节点，由主节点同步操作到从节点，可指节写多少个节点成功后才认为成功。

2.  主从复制和选主

（1）如果主挂了，mongodb保证只有操作序列为最大的从才能成为新的主，这只保证了数据尽可能地少丢，如果写操作是写1个节点以上成功才认为成功，可保证不丢数据

（2）如果新的主丢了老的主的部分操作，而且老的主又重新加入副本集，这时老的主会回滚操作以保证与新的主状态一致。回滚日志会被记录到文件里，通过工具可手动将回滚操作来新的主上执行，以恢复数据。另外，如果需要的回滚数据超过300M，老的主不会进行回滚，并log异常；如果要强制回滚到300M之前，可采用重新同步数据的方法来保证与新主状态一致，但不能恢复这300M数据了。

（3）mongodb可保证优先级最高的从节点变为主；

（4）优先级为0的从节点不进行选主，即不能成为主；

（5）除了主从节点，还有仲裁者节点，不保存副本数据，只用于选主投票

1.副本集支持手动变更主从关系吗？支持的话，变更会不会出现数据丢失呢？可对比下redis cluster

  （1）You can force a replica set member to become primary by giving it a higher priority value than any other member in the set.（所以是支持的）

  （2）变更不会出现数据丢失，因为mongodb会停止原主的更新操作，直到新主追上最新的plog后并成功变为主，才恢复更新操作（跟redis cluster的no force变更策略一样）。

2.shard 的config server

(1) 数据一致性保证？

    Config servers are special mongod instances that store the metadata for a sharded cluster.  All config servers must be available to deploy a sharded cluster or to make any changes to cluster metadata. Config servers do not run as replica sets. Each sharded cluster must have its own config servers. 

    When writing to the three config servers, a coordinator dispatches the same write commands to the three config servers and collects the results. Differing results indicate an inconsistent writes to the config servers and may require manual intervention. Once the config servers become inconsistent, the balancer will not perform any chunk migration and mongos will not perform auto-splits of chunks.（从这里看，config server是不保证数据一致性的，如果出现不一致，需要人工干预）

(2) 可用性

   The cluster have three config servers. 

   If one or two config servers become unavailable, the cluster’s metadata becomes read only. You can still read and write data from the shards, but no chunk migrations or splits will occur until all three servers are available.

   If all three config servers are unavailable, you can still use the cluster if you do not restart the mongos instances until after the config servers are accessible again. If you restart the mongos instances before the config servers are available, the mongos will be unable to route reads and writes.

   If the name or address that a sharded cluster uses to connect to a config server changes, you must restart every mongod and mongos instance in the sharded cluster. Avoid downtime by using CNAMEs to identify config servers within the MongoDB deployment.

（3）数据大小

   主要保证db的chunk与shard的映射关系，数据量很小，mongos会缓存一份数据，配置数据有变化时，应该是全量同步，因为数据量小。

3.shard的负载匀衡是由mongos的两个后台进程完成的：split和balancer

4.shard 的chunk分裂：chunk达到最大size时，进行对半分裂为两个chunk，这时不进行真正的数据迁移；

   （1）As chunks grow beyond the specified chunk size a mongos instance will attempt to split the chunk in half. 

5.shard 的balance:如时需要对某个shard的chunks进行迁移？如何保证迁移时数据不丢失？

   （1）the balancer will not begin balancing until the distribution of chunks for a sharded collection has reached certain thresholds. The thresholds apply to the difference in number of chunks between the shard with the most chunks for the collection and the shard with the fewest chunks for that collection。（针对单个collection的chunk数量，而不是单个shard，可能会导致单个shard的chunk数量过多）

   （2）When adding a shard, you may set a “maximum size” for that shard. This prevents the balancer from migrating chunks to the shard when the value of mapped exceeds the “maximum size”. Use the maxSize parameter of the addShard command to set the “maximum size” for the shard.

    The value of mapped provides the amount of mapped memory, in megabytes (MB), by the database. Because MongoDB uses memory-mapped files, this value is likely to be to be roughly equivalent to the total size of your database or databases.

   （3）the destination shard starts a synchronization process to ensure that it has the changes to the migrated documents that occurred during the migration. MongoDB briefly pauses all application writes to the source shard before updating the config servers with the new location for the chunk, and resumes the application writes after the update. The migration process ensures consistency and maximizes the availability of chunks during balancing.

   （4）During chunk migration, if the chunk exceeds the specified chunk size or if the number of documents in the chunk exceeds Maximum Number of Documents Per Chunk to Migrate, MongoDB does not migrate the chunk. Instead, MongoDB attempts to split the chunk. If the split is unsuccessful, MongoDB labels the chunk as jumbo to avoid repeated attempts to migrate the chunk.

7. mongodb的副本集，对于网络分区产生的多主问题

  the replica set has no primary and cannot accept writes and all remaining members become read-only. f a majority of the replica set is inaccessible or unavailable, the replica set cannot accept writes and all remaining members become read-only.（可见对于多主的问题的解决方法跟redis cluster是一样的，不会出现多主的问题。）

8. 副本集里的数据同步是采用同步消息队列的方式，而且只有一条消息队列(可控制大小)，这里的消息是oplog，而且oplog里的操作是幂等的。从节点可从其他从节点获取oplog，不一定从主节点获取。

9. shard key可以是有序key，或hash key，都支持排序和游标操作

10、请求和连接

       数据库会为每个MongoDB数据库连接创建一个队列，存放这个连接的请求，客户端新发送的请求会被放到队列的末尾。只有队列中的请求都执行完毕，后续的请求才会执行。即对于单个连接来说，请求都是顺序执行不存在并发问题，所以它总能读到自己写的东西。但对于不同的连接就有可能出现读取和写入不一致的问题，在驱动程序使用连接池时要特别注意此行为。

11. 三个config server，当挂掉一个config server时，挂掉一个主mongod，还可以进行主从切换，不影响数据读写功能。这说明主从切换功能，不需要config server支持或写config server