MongoDB 数据迁移和同步

MongoDB的数据同步

复制

mongodb的复制至少需要两个实例。其中一个是主节点master，负责处理客户端请求，其余的都是slave，负责从master上复制数据。

master写处理：
master负责接收写请求，具体的流程为：

如果开启journal功能，则先将写请求记录到journal中，然后批量执行，同时将操作记录到oplog中；
如果未开启journal功能，则对每个写请求进行单独操作，然后写入oplog。

注：oplog是幂等的，当有累加操作inc时，会记录成set操作，从而无论重复执行多少次操作获得的结果都是一样的。

从节点同步：

如果是一个新的从节点，首先先从master的数据库文件进行复制，同时记录起始时间；当从节点从master的复制完成后，会根据复制的起始时间开始追oplog，进而与master进行同步。
初始化同步完成后的slave定期从master的oplog中获取最新的操作，然后对自己的数据副本执行这些操作，从而保证slave的数据与master最终一致性。

注意：当slave同步的速度赶不上master更新的速度时，oplog会因为追加了过多的操作而发生将旧记录覆盖掉，这样slave可能无法保证同步所有的数据，这时，slave会开始从头重新同步。

MongoDB的主从同步

原理

主从复制是MongoDB最常用的复制方式，这种方式很灵活，可用于备份、故障恢复和读扩展等。需要在启动进程时指定master和slave，slave要指定master的地址，这种方式没有自动故障转移功能。

默认情况下，slave既不能写也不能读，但可以通过配置将slave改为可读模式，从而做到读写分离，提高系统性能。

操作

操作可以选择两种方式：命令行和配置文件。

命令行

master启动命令

# mongod --config /etc/mongodb.conf --master

slave启动命令

# mongod --config /etc/mongodb.conf --slave --autoresync --slavedelay=10 --source master-ip:master-port

配置

master配置：
master = true

slave配置：
slave = true
autoresync = true
slavedelay = 10

选项

-only
在从节点上指定只复制特定的某个数据库(默认是复制所有数据库)。
-slavedelay
用在从节点上，当应用主节点的操作时，从节点增加延时复制(单位秒)。这样就能轻松设置延时从节点，这种节点对用户无意中删除重要文档或者插入垃圾数据等有防护作用，这些不良操作都会被复制到所有的从节点上，通过延时执行操作，可以有个恢复的时间差。
-fastsync
以主节点的数据快照为基础启动从节点。如果数据目录一开始是主节点的数据快照，从节点用这个选项启动要比做完整的同步快的多。
-autoresync
如果从节点与主节点不同步了，则自动重新同步。
-oplogsize
主节点oplog的大小(单位MB)。默认的oplog大小是剩余磁盘空间的5%。

MongoDB副本集

原理

副本集(Replica Set)就是有自动故障恢复功能的主从集群。主从集群和副本集最明显的区别是副本集没有固定的”主节点”，整个集群会选举出一个”主节点”，当其不能工作时则变更到其他节点.副本集总会有一个活跃节点(primary)和一个或多个备份节点(secondary)。

副本集可以在活跃节点有问题时自动切换。

节点类型

任何时间，集群中只有一个活跃节点，其他的都是备份节点.活跃节点实际上是活跃服务器，指定的活跃节点可以随时间而改变。

有几种不同类型的节点可以存在与副本集中:

standard 标准节点
这是常规节点,它存储一份完整的数据副本，参与选举投票有可能成为活跃节点。
passive 被动结点
存储了完整的数据副本,参与投票，不能成为活跃节点。
arbiter 仲裁者
仲裁者只能参与投票，不接收复制的数据，也不能成为活跃节点。

优先级

每个参与节点(非仲裁)有优先权，优先权按照优先值从大到小，默认优先级为1,可以是0-1000(含)。
在节点配置中修改priority键,来配置标准节点或者被动节点。

> members.push({"_id":3,"host":"127.0.0.1:10002","priority":40})

“arbiterOnly”键可以指定仲裁节点

> members.push({"_id":4,"host":"127.0.0.1:10003","arbiterOnly":true})

备份节点会从活跃节点抽取oplog,并执行操作，就像活跃备份系统中的备份服务器一样.活跃节点也会写操作到自己的本地oplog.oplog中的操作包含严格递增的序号，这个序号来判定数据的时效性。

选举策略

如果活跃节点出现故障，其余节点会选一个新的活跃节点.选举过程可以由任何非活跃节点发起,新的活跃节点由副本集中的大多数选举产生。其中仲裁节点也参与选举，避免出现僵局。新的活跃节点将是优先级最高的节点，优先级相同则数据较新的节点获胜。

不论活跃节点何时变化，新的活跃节点的数据就被假定为系统的最新数据。对其他几点(原来的活跃节点)的操作都会回滚，即便是之前的活跃节点已经恢复工作了。为了完成回滚，所有节点连接新的活跃节点后重新同步。这些节点会查看自己的oplog，找出活跃节点没有的操作，然后向活跃节点请求这些操作影响的文档最新副本。正在执行重新同步的节点被视为恢复中，在完成这个过程之前不能成为活跃节点的候选者。

操作

命令行初始化操作

设置副本集比设置主从集群稍微复杂一点。

先给副本集起个名称，是为了易于与别的副本集区分，也是为了方便将整个集合视为一个整体,这里取名：refactor

启动服务器–replSet的作用是让服务器知道这个“refactor”副本集还有别的同伴，位置在 refactor/127.0.0.1:10001

# mongod --dbpath /data1/mongodb --port 10000 --replSet refactor/127.0.0.1:10001 --logpath /data1/log/mongodb/mongodb.log --rest

以同样的方式启动另一台:

# mongod --dbpath /data1/mongodb --port 10001 --replSet refactor/127.0.0.1:10000 --logpath /data1/log/mongodb/mongodb.log --rest

如果想要添加第三台,两种方式:

# mongod --dbpath /data1/mongodb --port 10002 --replSet refactor/127.0.0.1:10000 --logpath /data1/log/mongodb/mongodb.log --rest

注：副本集有自动检测功能：在其中指定单台服务器后，MongoDB就会自动搜索并连接其余的节点。

mongo内部命令初始化操作

> use admin

> db.runCommand(

　　{

　　　　"replSetInitiate":

　　　　{

　　　　　　"_id":"refactor",//副本集的名称

　　　　　　"members"://副本集中的服务器列表

　　　　　　[

　　　　　　　　{

　　　　　　　　　　"_id":1,//每个服务器的唯一id

　　　　　　　　　　"host":"127.0.0.1:10000"//指定服务器的主机

　　　　　　　　},

　　　　　　　　{

　　　　　　　　　　"_id":2,

　　　　　　　　　　"host":"127.0.0.1:10001"

　　　　　　　　}

　　　　　　]

　　　　}

　　}

)

>

MongoDB的数据迁移

mongodump & mongorestore

MongoDB数据备份

在Mongodb中我们使用mongodump命令来备份MongoDB数据。该命令可以导出所有数据到指定目录中。
mongodump命令可以通过参数指定导出的数据量级转存的服务器。
语法
mongodump命令脚本语法如下：

# mongodump -h dbhost -d dbname -o dbdirectory

-h：
目标MongDB所在服务器地址，例如：127.0.0.1，当然也可以指定端口号：127.0.0.1:27017
-d：
需要备份的数据库实例，例如：test
-o：
备份的数据存放位置，例如：/data/mongodb/backup，当然该目录需要提前建立，在备份完成后，系统自动在dump目录下建立一个test目录，这个目录里面存放该数据库实例的备份数据。

MongoDB数据恢复

mongodb使用 mongorerstore 命令来恢复备份的数据。
语法
mongorestore命令脚本语法如下：

# mongorestore -h dbhost -d dbname --directoryperdb dbdirectory

-h：
MongoDB所在服务器地址
-d：
需要恢复的数据库实例，例如：test，当然这个名称也可以和备份时候的不一样，比如test2
-directoryperdb：
备份数据所在位置，例如：c:\data\dump\test，这里为什么要多加一个test，而不是备份时候的dump，读者自己查看提示吧！
-drop：
恢复的时候，先删除当前数据，然后恢复备份的数据。就是说，恢复后，备份前添加修改的数据都会被删除，慎用!

日志

系统日志

系统日志在Mongdb数据中很中重要，它记录mongodb启动和停止的操作，以及服务器在运行过程中发生的任何异常信息。

配置路径：

# mongod --logpath='/data/db/log/server.log' -logappend

journal日志

Jouranl日志通过预写入的redo日志为mongodb增加了额外的可靠性保障。开启该功能时候，数据的更新就先写入Journal日志，定期集中提交（目前是每100ms提交一次），然后在正式数据执行更改。

打开方式：

# mongod --journal

oplog日志

Mongodb的高可用复制策略有一个叫做Replica Sets.ReplicaSet复制过程中有一个服务器充当主服务器，而一个或多个充当从服务器，主服务将更新写入一个本地的collection中，这个collection记录着发生在主服务器的更新操作，并将这些操作分发到从服务器上。这个日志是Capped Collection。

注：Capped Collections 是性能出色的有着固定大小的集合，以LRU(Least Recently Used 最近最少使用)规则和插入顺序进行 age-out(老化移出)处理，自动维护集合中对象的插入顺序，在创建时要预先指定大小。

# mongod --oplogSize=1024 #单位是M

slow日志

慢查询记录了执行时间超过了所设定时间阀值的操作语句。慢查询日志对于发现性能有问题的语句很有帮助，建议开启此功能并经常分析该日志的内容。

要配置这个功能只需要在mongod启动时候设置profile参数即可。例如想要将超过5s的操作都记录，可以使用如下语句：

# mongod --profile=1 --slowms=5

参考文章