MongoDB的备份和恢复
发布日期:2016-4-24 23:4:6
本文主要介绍的是MongoDB备份的方式与恢复的办法。 MongoDB将所有的数据存在数据目录文件夹下,默认是C:\data\db,我们也可以通过dbpath来自由配置。若只是简单的备份,我们只需要将文件夹复制即可。在这种情况下我们需要关闭服务器,避免数据不同步。 MongoDB在不需要关闭服务器的情况下进行备份一共有三种方式,分别是
一、mongodump mongodump是一种能够在运行时备份的方法,mongodump对运行的MongoDB做查询,然后将所查到的文档写入磁盘。由于mongodump是区别于MongoDB的客户端,因此在处理其他请求时也没有问题。 但mongodump采用的是普通的查询机制,所以产生的备份不一定是服务器数据的实时快照。 下面让我们来看如何使用mongodump来备份数据库。 首先启动mongodump,如图1所示: 图1 效果如图2所示: 图2
就可以到指定的位置找到备份的文件夹了,如图3所示: 打开就可以看到数据,如图4所示:
需要注意一点的是,mongodump备份时的查询会对其他客户端的性能产生影响。 更多的操作我们可以通过mongodump –help来查询 二、mongorestore 下面我们来介绍如何用mongorestore来恢复数据。 mongorestore获取mongodump 的输出结果,并将备份的数据插入运行的MongoDB实例中。和mongodump一样,mongorestore也是一个独立的客户端,如图6所示: 使用该方法,将刚才备份的lf集合放到新的数据库testNew中去,如图7所示:
查看数据库: show dbs use testNew db.lf.find()
上面所示的说明数据恢复成功 可以使用mongorestore –help获得帮助信息 需要注意的是,这两个命令操作的都是bson格式的数据,当数据量很大,超过几百G的时候,几乎是不能使用的,因为bson极其占用空间,(与mssql类似) 三、fsync锁 说到mongodump备份,就不能不提到fsync和锁了。我们刚刚提到过,使用mongodump备份可以不关闭服务器,但却失去了获取实时数据视图的能力。而MongoDB的fsync命令能够在MongoDB运行时复制数据目录还不会损坏数据。 其工作原理就是强制命令服务器将所有缓存区写入磁盘,通过上锁阻止对数据库的进一步写入操作,直到释放锁为止。写入锁是让fsync在备份时发挥作用的关键。 在shell中,强制执行fsync并获得写入锁,如下面所示: db.runCommand({"fsync":1,"lock":1}) 这时,数据目录的数据就是一致的,且为数据的实时快照.由于上了锁,可以安全的将数据目录副本作为备份。要是数据库运行在有快照功能的文件系统上时,比如LVM,EBS,这个很有用,因为拍个数据库目录的快照很快。 备份好了,解锁,如下所示: db.$cmd.sys.unlock.findOne() db.currentOp() 运行db.currentOp()是为了确保已经解锁了(初次请求解锁会花点时间)。 有了fsync命令,就能非常灵活的备份,不用停掉服务器,也不用牺牲备份的实时性能。要付出的代价就是一些写入操作被暂时阻塞了。 四、主从复制 上面提到的备份方式很灵活,但是还是没有从服务器上备份好,当复制的方式运行MongoDB,前面的提到的备份技术就不仅能用在主服务器上,也可用在从服务器上。主从复制是MongoDB最常用的复制方式,这种方式很灵活,可以用于备份、故障恢复与读扩展等。 最基本的设置方式:建立一个主节点和一个或多个从节点,每个从节点要知道主节点的地址。 我们通过mongod --master启动主服务器,通过运行mongod --slave --source master_address启动从服务器,其中master_address的主节点的地址。 这里我们用一台机器的不同端口来做测试: 首先,给主节点建立数据目录,如下所示: mongod --dbpath "D:\MongoDB\data\dbs " --port 10000 --master 创建成功后,如图12所示: 然后,我们设置从节点,如下所示: mongod --dbpath "D:\MongoDB\data\dbs\slave " --port 10000 --slave --source 127.0.0.1:10000 创建后,其自动开始监听主节点的端口,如图14所示: 连接到主数据库: db = connect(“127.0.0.1:10000/master”) 向主节点服务器添加数据,如图16所示: 再连接从节点,从节点查询数据.如图17所示: 注意如果报错,需要使用rs.slaveOk()方法。 从节点中数据与主节点一致,说明备份成功。所有的从节点都会和主节点保持同步,一个集群中最好不要超过12个从节点。 五、选项 主从复制的过程中有一些配置选项,如下所示: –only 在从节点上指定只复制特定的某个数据库(默认是复制所有数据库),如下所示: –slavedelay 用在从节点上,当应用主节点的操作时,从节点增加延时复制(单位秒)。这样就能轻松设置延时从节点,这种节点对用户无意中删除重要文档或者插入垃圾数据等有防护作用,这些不良操作都会被复制到所有的从节点上,通过延时执行操作,可以有个恢复的时间差。如下所示: –fastsync 以主节点的数据快照为基础启动从节点。如果数据目录一开始是主节点的数据快照,从节点用这个选项启动要比做完整的同步快的多。如下所示: –autoresync 如果从节点与主节点不同步了,则自动重新同步,如下所示: –oplogsize 主节点oplog的大小(单位MB)如下所示: 六、副本集 最后来说说副本集,副本集就是有自动故障恢复功能的主从集群。副本集合主从集群的区别就是副本集中没有固定的主节点。 整个集群会选举出一个活跃节点,当其不能工作时,就会使其他备份节点变为活跃节点。也即是说,副本集总会有一个活跃节点(primary)和一个或多个备份节点(secondary)。 七、初始化 设置副本集比设置主从集群稍微复杂一点,因为它需要初始化。还得给副本集取一个名称,区别于其他副本集(如mssql)。这里取名lf。 首先启动一个节点: mongod --dbpath "D:\MongoDB\Server\3.0\bin\master" --port 10000 --replSet lf/127.0.0.1:10001 这里的–replSet的作用是让服务器知道这个lf副本集还有别的同伴位置在 lf/127.0.0.1:10001 接下来以同样的方式启动另一台,如下所示: mongod --dbpath "D:\MongoDB\Server\3.0\bin\slave" --port 10000 --replSet lf/127.0.0.1:10000 如果想要添加第三台,两种方式,如下所示: mongod --dbpath " D:\MongoDB\Server\3.0\bin\slave 1" --port 10002 --replSet lf/127.0.0.1:10000 或是 mongod --dbpath " D:\MongoDB\Server\3.0\bin\slave1" --port 10002 --replSet lf/127.0.0.1:10000,127.0.0.1:10001 两种方式都可以是由于副本集有自动检测功能,在其中指定单台服务器后,MongoDB就会自动搜索并连接其余的节点。 然后就是初始化操作了,在shell脚本中初始化副本集,如下所示: use admin db.runCommand( { "replSetInitiate": { "_id":"lf",//副本集的名称 "members"://副本集中的服务器列表 [ { "_id":1,//每个服务器的唯一id "host":"127.0.0.1:10000"//指定服务器的主机 }, { "_id":2, "host":"127.0.0.1:10001" } ] } } )
初始化成功后,会处于活跃节点,我们可以通过rs.status()来查看各节点状态,如图19所示: 接下来我们在活跃节点中添加数据进行测试,如图20所示: 然后连接备份节点并进行数据查询: 成功查询到数据,说明备份成功。 如果在备份节点查询,会出现 error: { “$err” : “not master and slaveok=false”, “code” : 13435 }错误. 执行如下所示的语句: db.getMongo().setSlaveOk() 八、节点 副本集的功能可不仅仅是备份这么简单噢。有以下几种不同类型的节点可以存在与副本集中: 1. passive 被动结点 存储了完整的数据副本,参与投票,不能成为活跃节点 2.standard 标准节点 这是常规节点,它存储一份完整的数据副本,参与选举投票有可能成为活跃节点 3. arbiter 仲裁者 仲裁者只能参与投票,不接收复制的数据,也不能成为活跃节点 我们可以在节点配置中修改priority键来设置节点的优先级别,如下所示: >members.push({"_id":3,"host":"127.0.0.1:10002","priority":40}) 默认优先级为1,可以是0-1000。 我们也可以通过arbiterOnly键来指定仲裁节点,如下所示: >members.push({"_id":4,"host":"127.0.0.1:10003","arbiterOnly":true}) 当活跃节点出现故障,其余节点会选举一个新的活跃节点,选举由任何非活跃节点发起。仲裁节点的加入是为了避免僵局,因为其自身不会参与竞选。新的活跃节点将是优先级最高的节点,优先级相同的,数据较新的节点获胜。
|