备份
1. 禁用均衡器(balancer process)
使用mongo 链接到mongos, 然后在config数据库上运行sh.stopBalancer()
use config
sh.stopBalancer()
2. 锁定每个副本集的secondary member
在每个分片集群上Lock副本集的secondary member, 以及config server 副本集中的一个secondary member.
确保oplog有足够的容量在主服务器完成备份后能同步这期间的操作。可以参考oplog大小
锁定某个分片集合的secondary member:
用mongo的shell,链接到这个secondary member, 然后运行:db.fsyncLock():
db.fsyncLock()
请保持该链接,以便之后运行: db.fsyncUnlock()
锁定confIg server某一个secondary member:
首先, 链接到primary上,运行如下命令:
use config
db.BackupControl.findAndModify(
{
query: { _id: 'BackupControlDocument' },
update: { $inc: { counter : 1 } },
new: true,
upsert: true,
writeConcern: { w: 'majority', wtimeout: 15000 } }
}
);
该命令将返回,一条插入或更新操作:
{ "_id" : "BackupControlDocument", "counter" : 1 }
用mongo shell链接到secondary member, 运行如下命令:
rs.slaveOk();
use config;
db.BackupControl.find(
{ "_id" : "BackupControlDocument", "counter" : 1 }
).readConcern('majority');
如果查询出来的结果有最新的control document, 就可以安全的进行锁定,否则要等待同步到最新的control document, 或者选择另一个server.
之后运行锁定:
db.fsyncLock()
请保持该链接,以便之后运行: db.fsyncUnlock()
3. 本分某一个config server
使用mongodump 来备份某一个(且只需要一个)config server. 在被锁定的server上运行:
mongodump --oplog
之后解锁该server:
db.fsyncUnlock()
4. 备份每一个被锁定的分片服务器
mongodump --oplog
5. 然后解除每一个被锁定的分片服务器:
db.fsyncUnlock()
6. 重启均衡器
用mongo 连接上 mogons, 然后运行如下的命令:
use config
sh.setBalancerState(true)
集群的备份时间安排(原文链接)
概述
在 sharded cluster 中,均衡过程用来在集群中分配数据,使得每个 shard 都保存大致相同的数据量.
不过,在对集群进行备份时,关闭均衡过程以防止对备份的数据造成影响是很重要的.参见 Disable the Balancer 可以暂时关闭均衡过程.也可以通过设置均衡运行的时间范围来保证在自动备份期间均衡是不运行的.
过程
如果你有自动备份的时间,可以在这个时间范围内关闭集群的均衡过程.可以参考以下命令:
use config
db.settings.update( { _id : "balancer" }, { $set : { activeWindow : { start : "06:00", stop : "23:00" } } }, true )
这个配置使得集群只在6:00am到11:00pm之间运行均衡过程.安排你的备份计划,使其 整个流程时间 都不在这个范围内.这样均衡与备份才不会相互干扰.
恢复集群
停止所有的 mongos 和所有的 mongod 进程,包括所有的分片 和 所有的配置服务器.
1. 为每一个分片(shard)部署一个副本集
- 为副本集中每个成员启动一个mongod,包含 –shardsvr 和 –port参数,
- 使用 mongo 链接其中一成员, 运行:
a. rs.initiate()
b. 使用rs.add() 添加其他成员
2. 部署一个新的config servers
3.开启一个mogos 实例
4. 将分片加入
用mongo链接mogos, 使用sh.addShard()将加入每个副本集
5. 关闭mogos服务
一旦分片集合运行起来, 关闭(shutdown)所有的mogos实例
6. 恢复分片数据
在每个分片的主节点上,运行如下命令:
mongorestore --drop --oplogReplay /data/dump/shardA --port <port>
当所有分片都恢复时, 关闭所有的分片的服务实例
7.恢复config server 数据
mongorestore --drop --oplogReplay /data/dump/configData
8. 开启一个mogos实例
启动一个mogos, 使用 –configdb 传递 config server副本集的名字和成员的参数
9. 如果分片的主机名变化了,更新config server的信息
使用mongo链接mogos,更新config database中shards collection中的主机名
10. 重启所有的shard 进程
在 3.4 版更改:包括 –shardsvr 参数
11. 重启其他的mogos实例
12. 检验集群的运行情况
用mongo链接到一个mogos实例,运行db.printShardingStatus()来检查集群运行情况。
db.printShardingStatus()
show collections