MongoDB实战-分片集群的管理

1.监控

       分片集群是整个体系中比较复杂的一块，正因此，你应该严格监控它。在任何mongos上都可以运行serverStatus和currentOp（）命令，命令的输出能反映所有分片的的聚合统计信息。除了聚合服务器统计信息，你还希望能监控块的分布和各个块的大小。正如在示例集群中看到的那样，所有的信息都保存在config数据库里。如果发现不平衡的块或者未经确认的块增长。可以通过split和moveChunk命令处理这些情况。或者，也可以查看日志，检查均衡操作是否处于某些原因被停止了。

2. 手动分区

     在有一些情况下，希望手动对线上分片集群的块进行拆分和迁移。例如，自MongoDB V2.0开始，均衡器并不会直接考虑某个分片的负载。很明显，一个分片写的越多，它的块就越大，最终会造成迁移。但是，不难想象你可以通过迁移来减轻分片的负载。moveChunk命令在这种情况下同样很有帮助。

3. 增加一个分片

      如果你决定要增加更多容量，可以使用与先前一样的方法向现有集群添加新的分片：

sh.addShard("shard-c/rs1.example.net:27017,rs2.example.net:27017")

    使用这种方式增加容量时，要注意向新分片迁移数据所花费的时间。如前所述，预计的迁移速度是每分钟100-200MB。这意味着如果需要向分片集群增加容量，你应该早在性能下降之前就开始行动。要决定何时添加新分片，考虑一下数据集的增长速率。很明显，你希望将索引和工作集保持在内存里。因此，最好在索引和工作集达到现有分片内存90%之前的几个信息就开始计划添加新分片。

    如果你不愿意采用此处描述的安全途径，那么就会将自己置身于痛苦之中，一旦内存里容纳不下索引和工作集，应用程序就会终止运行，尤其是那些要求很高读写吞吐量的应用程序。问题在于数据库需要在磁盘和内存之间置换分页，这会降低读写速度，后台日志操作无法放入读写队列。从这点来看，增加容量是件困难的事，因为分片之间的块迁移会增加现有分片的读负载。很明显，在数据库已经超载之时，你最后想做的还是增加负载。这里说明你要监控集群，在真正需要之前就增加容量。

4 删除分片

    在一些比较少见的情况下，你可能想要删除一个分片。你可以通过removeshard命令进行删除。

use admin
db.runCommand({removeshard:"shard-1/arete:30100,arete:30101"})

命令执行后，会将分片从集合中移除，它们将重新分配到其他分片上。可以再次运行该命令检查删除过程的状态。

    一旦分片被清空，你还要确认将要删除的分片是不是数据库的主分片。可以通过查询config.databases集合的分片成员进行检查

use config
db.databases.find()

执行结果如下：

可以看出cloud-docs数据库属于shard-b。若要删除shard-b，所以需要修改cloud-docs数据库主节点，为此，可以使用moveprimary命令：

db.runCommond({moveprimary:"cloud-docs",to:"shard---test-rs"})

对于每个主节点是将要删除的分片的数据库，执行该命令。随后，再次对每个已清空的分片运行removeshard命令

一旦看到删除完成，就可以完全地将已删除的分片下线了。

5. 集合去分片

   虽然可以删除一个分片，但是没有正式的途径去除集合的分片。如果真的需要这么做，最好的选择时导出集合，再用一个不同的名字将数据库恢复到一个新的集合中。然后就能把已经导出数据的分片集合删除掉了。例如，假设foo是一个分片集合，你必须使用mongodump连接mongos来导出foo集合的数据。

mongodump -h arete -port 40000 -d cloud-docs -c foo

   该命令能把该集合导出到一个foo.bson的文件里，随后再用mongostore来恢复该文件：

mongostore -h arete -port 40000 -d cloud-docs -c bar

将数据分片移动到未分片集合之后，就可以随意删除旧的分片集合foo了

6. 备份分片集群

     要备份分片集群，你需要配置数据以及每个分片数据的副本。有两种途径来获得这些数据。第一种是使用mongodump工具，从一个配置服务器导出数据，随后再从每个单独的分片里导出数据。此外，你可以通过mongos路由器运行mongodump，一次性导出整个分片集合的数据，包括配置数据库。这种策略的主要问题是分片集合的总数据可能太大了，以至于无法导出到一台机器上。

      另一种常用的备份分片集群的方法时从每个分片的一个成员里复制数据文件，再从一台配置服务器中复制数据文件。你只要在每个分片和一台配置服务器上执行这个过程就可以了。

     无论选择哪种备份方式，都需要确认在备份系统时没有块在移动过程中。也就是说要停止均衡器进程。

（1）停止均衡器

     到目前为止，禁用均衡器就是直接通过sh.setBalancerState(false)进行操作

 这里一定要小心：更新了配置之后，均衡器可能仍在工作。在备份数据集之前，你还需要再次确认均衡器完成了最后一轮均衡。最好的方法就是检查locks集合，找到_id为balancer的条目，确认它的状态为0。

    任何大于0的状态值都说明均衡器仍然在工作。process字段显示了负责组织协调均衡的mongos所运行在的计算机的主机名和端口。如果在修改配置前后，均衡器始终没有停止，你应该可以检查负责均衡的mongos的日志，查找错误。

   在均衡器停止之后，就可以安全地开始备份了。备份完成后，不要忘记重启均衡器。

  可以通过sh.getBalancerState()获取当前均衡器的状态。通过这种方式可以一直使用sh.isBalancerRunning()，直到均衡器停下为止。

7. 故障转移与恢复

     虽然我们已经讲过了一般的副本集故障，但还是有必要提一下分片集群的潜在故障点和恢复的最佳实践。

    （1）分片成员故障

       每个分片都由一个副本集组成。因此，如果这些副本集中的任意一个成员发生故障。从节点就会被选举为主节点，mongos进程就会自动连接到该节点。如果发现副本集在故障转移后有什么不正常的表现，可以通过重启所有mongos进程重置系统，这能保证适当连接都指向新的副本集。此外，如果发现均衡器不工作了，就检查config数据库的locks集合，找到process子弹指向之前节点的条目。如果有这样的条目，锁文档已经旧了，你可以安全地手动删除该文档。

（2）配置服务器故障

      一个分片集群要有三台配置服务器才能正常工作，其中最多能有两台发生故障。无论何时，当配置服务器数量少于三台，剩余的配置服务器就会变为只读状态，所有的拆分和均衡操作都会停止。请注意，这对整个集群没有负面影响，集群的读写仍能正常进行，当所有三台配置服务器都恢复之后，均衡器将从它停止的地方重新开始工作。要恢复配置服务器，从现有的配置服务器把数据文件复制到发生故障的机器上，随后重启服务器。

（3）mongos故障

     要是mongos进程发生故障，没什么好担心的。如果mongos运行在应用服务器上，他发生故障了，那么很有可能你的应用程序服务器也发生故障了。这是的恢复就是简单地恢复服务器。无论mongos出于什么原因发生故障，进程本身没有状态，这意味着恢复mongos就是简单地重启进程，在配置服务器上指向它自己。