网易乐得DBA
猪场/数据库/中间件
MongoDB Sharding Cluster支持水平扩展，集群自动将数据切分到不同的MongoDB实例上，做负载均衡，这种分布式集群架构的备份，与传统单机数据库的备份是有一些差别的，下面对MongoDB Sharding Cluster的备份做一下介绍。
1 MongoDB Sharding Cluster简介
MongoDB Sharding Cluster的架构如下图所示，由三部分组成：
shard: 集群的数据节点，分别存储集群中的部分数据，shard可以创建为副本集。
config server: 存储集群的元数据和配置信息，3.2后可以配置为副本集。
mongos: 路由节点，应用可以连接一个或多个mongos来访问集群。
MongoDB根据shard key对数据进行分片，每个分片的集合都要指定shard key，分片后不能修改shard key。
MongoDB的分片数据分布在不同的chunks上，如下图示例，shard key定义为x，x的值从minKey到-75之间在第一个chunk，-75到25在第二个chunk，25到175之间在第三个chunk，175到maxKey在第四个chunk。即MongoDB根据shard key值的范围分成了多个chunks，每个shard存储不同的chunks，需要做数据迁移时，通过迁移chunks实现的。
chunks的实际分布，可以在mongos执行sh.status()查看，如下图，collection post使用自动生成的主键_id进行hashed分片，集群有shard1、shard2、shard3三个shard，目前每个shard上有6个chunks，每个chunks下的数据范围是通过_id划分的。
2 MongoDB Sharding Cluster的备份
数据库的备份，主要有需要关注以下两点：
a) 备份的可用性，即备份能够恢复出来，并且恢复出的数据是准确可用的。
b) 数据的一致性，即恢复出的数据能对应某个时间点，例如不能部分是1:00的数据，另一部分是1:01的数据。
在传统单机数据库中，我们一般不需要额外关注b)，备份工具会处理、保证备份完成时的一致性（例如通过记录备份期间的日志），然而MongoDB Sharding Cluster存在shard、configserver多个节点，获取备份数据的一致性，会受以下因素影响：
a) chunks迁移。
MongoDB存在一个balancer进程，监控各shard中chunks数量，如果shard间chunks的数量差异超过了阈值，balancer会自动迁移chunks以减少shard之间chunks数量的差异。将某个shard移出集群，或者使用ShardTag，也会引起chunks迁移。
如果备份期间发生了chunks迁移，恢复后有可能造成数据的重复保存，即某个chunk存在两个shard上，也可能造成数据的丢失，即config server记录的信息与chunks实际所在shard不一致。对于这个问题，解决方法是禁用balancer，等备份完成后再开启，可以避免chunks迁移带来的影响。
b) 数据的写入。
MongoDB Sharding Cluster中，各shard和config server是独立运行的，如果在某个时间点同时开始备份，结束的时间无法确保一致，另外如果在Secondary节点停止同步后再做备份，也很难保证停止同步的时间点是完全一致的。
3 mongodb-consistent-backup工具
为了实现MongoDB Sharding Cluster的一致性备份，主要关注了MongoDB文档提到的备份方式、Ops Manager和开源工具：
a) MongoDB文档
官方文档提到了两种备份方式（https://docs.mongodb.com/manual/administration/backup-sharded-clusters/），文件系统快照和mongodump的方式，文件系统快照和硬件环境有关，通用性较差；mongodump方式的主要步骤是停止Balancer、在副本集的Secondary节点执行fsyncLock后进行备份，这种方式的问题是由于存在多个副本集，很难保证所有副本集在同一个时间点执行fsyncLock，如果执行的时间有间隔，是无法保证数据一致性的。
b) MongoDB Ops Manager
MongoDB Ops Manager(https://docs.opsmanager.mongodb.com/current/)可以管理、监控、备份MongoDB，能够为集群提供一致性备份，但是初次部署步骤较多，且恢复到新集群时，需要提前把新集群加入MongoDB Ops Manager，使用过程并不是很灵活。
c) mongodb-consistent-backup
该工具可以相对简单的实现备份需求，项目地址为https://github.com/Percona-Lab/mongodb_consistent_backup
如下图，该工具的实现原理是停止balancer后，对所有的shard同时开始备份，并且持续记录oplog，直到所有的shard备份完成后，再停止记录oplog。对于config server，3.2后可以配置为副本集，备份过程和shard是一样的，对于旧版本未使用副本集的config server，会使用fsyncLock直到shard的oplog记录进程结束。
mongodb-consistent-backup提供了很多参数来方便使用，这里介绍常用参数：
-H | 连接的IP，如果启用了多个mongos，可将多个mongos写入配置，备份进程会自动找到可用的mongos，避免单个mongos进程异常导致的备份失败。如配置两个：127.0.0.1:27011, 127.0.0.1:27012 |
-P | 端口，如果在-H指定了端口，此参数可以省略 |
-u | 开启了认证的用户名 |
-p | 开启了认证的密码 |
-l | 备份的保存路径 |
-n | 备份的目录，如果不指定，将创建default作为目录 |
--rotate.max_backups | 保存的备份数量，默认无限制 |
--rotate.max_days | 备份保留的最大天数，默认无限制 |
--archive.method | 备份保存方式，默认为tar，将备份保存为tar包 |
--backup.mongodump.compression | 备份的压缩方式，是指每个集合是否压缩，gzip或不压缩 |
最后在测试环境做备份，集群有3个shard、1个config server、3个mongos，其中3个shard和1个config server均配置为副本集，mongos的端口分别为25011、25012、25013，通过以下命令做多次备份：
完成后，备份文件如下图，我们设置了保留三份备份，可以看到最后的三个备份，其中latest和previous分别指向最近的备份和最近备份的上一个备份。
进入其中一个目录，可以看到config server和shard的备份，mongos不需要做备份，备份文件保存在各备份的dump目录下。
集群恢复到新环境，需要先搭建集群，如本例的备份恢复到其他环境时，需首先搭建包含一个config server和三个shard的集群，再将数据恢复到对应的副本集。
恢复时，使用对应目录下的dump路径，例如恢复config server到10.1.1.2的27011实例，执行:
mongorestore --oplogReplay --gzip /home/mongodb/backup/test/20180410_1031/configRS/dump/ --host 10.1.1.2 --port 27011
本文介绍了mongodb-consistent-backup工具，为MongoDB ShardingCluster提供一致性备份，如果有其他合适的方法，欢迎留言交流。
往期精彩文章
__________________________
网易乐得DBA组负责网易乐得电商、网易邮箱、网易技术部数据库日常运维
负责数据库私有云平台的开发和维护
负责数据库及数据库中间件的开发和测试等
分享最前沿实用数据库干货
关注网易乐得DBA
精深数据库神功
