MongoDB 数据迁移和同步

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 
 

参考文章

  1. Master Slave Replication
  2. mongodb复制
  3. mongodb复制原理
  4. MongoDB 备份(mongodump)与恢复(mongorerstore)
时间: 2024-12-10 07:36:11

MongoDB 数据迁移和同步的相关文章

mongodb3.0集群部署及数据迁移

本文主要介绍mongodb3.0新特性.集群部署及从mongodb2.6中数据迁移到mongodb3.0. mongodb3.0介绍 一.mongodb3.0新特性 引入了插件式存储引擎API 新增WiredTiger存储引擎 支持文档级别的锁 二.WiredTiger存储引擎特性介绍 文档级别锁 WiredTiger通过MVCC实现文档级别的并发控制,即文档级别锁.这就允许多个客户端请求同时更新一个集合内存的多个文档,再也不需要在排队等待库级别的写锁.这在提升数据库读写性能的同时,大大提高了系

完美数据迁移-MongoDB Stream的应用

一.背景介绍 最近微服务架构火的不行,但本质上也只是风口上的一个热点词汇. 作为笔者的经验来说,想要应用一个新的架构需要带来的变革成本是非常高的. 尽管如此,目前还是有许多企业踏上了服务化改造的道路,这其中则免不了"旧改"的各种繁杂事. 所谓的"旧改",就是把现有的系统架构来一次重构,拆分成多个细粒度的服务后,然后找时间 升级割接一把,让新系统上线.这其中,数据的迁移往往会成为一个非常重要且繁杂的活儿. 拆分服务时数据迁移的挑战在哪? 首先是难度大,做一个迁移方案需

由数据迁移至MongoDB导致的数据不一致问题及解决方案

本文是"我和MongoDB的故事"MongoDB征文比赛的二等奖得主杨庆麟的文章.下面我们一起来欣赏下. 故事背景 企业现状 2019年年初,我接到了一个神秘电话,电话那头竟然准确的说出了我的昵称:上海小胖. 我想这事情不简单,就回了句:您好,我是小胖,请问您是? "我就是刚刚加了你微信的 xxx 啊" 哦--他只是把我的微信昵称报出来了-- 随着深入沟通,了解到对方是某央企保密单位的大数据部门技术负责人,因为目前整个集团在进行数字化转型.在决策过程中,遇到了几个阻

MongoDB -> kafka 高性能实时同步(采集)mongodb数据到kafka解决方案

写这篇博客的目的 让更多的人了解 阿里开源的MongoShake可以很好满足mongodb到kafka高性能高可用实时同步需求(项目地址:https://github.com/alibaba/MongoShake,下载地址:https://github.com/alibaba/MongoShake/releases).至此博客就结束了,你可以愉快地啃这个项目了.还是一起来看一下官方的描述: MongoShake is a universal data replication platform b

Kettle+MongoDB 数据同步到MySQL

Kettle+MongoDB 数据同步到MySQL 1.前言: MongoDB中的date类型以UTC(Coordinated Universal Time)存储,isodate类型,就等于GMT(格林尼治标准时)时间.而北京所处的是+8区,所以mongo shell会将当前的GMT+0800时间减去8,存储成GMT时间. 2.抽取作业概述 3.组件选择: 4.增量处理: 在MongoDB中查询如下是正确的: > db.xamessages.find({created_at:{$gte:ISOD

#研发解决方案#数据移山:接入、迁移、同步一站式

数据中心赵兴申 最后更新于2018/8/7 关键词:数据接入,数据迁移,实时同步,数据库变更订阅中心 提纲: 1.      移山产生背景 2.      技术栈 3.      移山数据处理能力 4.      小结 移山 是数据中心推出的异构数据源之间的数据迁移自动化平台,它旨在解决第三方ISV数据接入.实时数据(单向/双向)同步.大数据集群间的数据迁移等问题. 移山 前台部分由刘永飞,后台由赵兴申.谭清勇等同学开发完成.2018年3月9日移山(YiShan)一期上线运行. 0x00 移山产

SQL Server GUID 数据迁移至MongoDB后怎样查看?

关键字:SQL Server NEWID():BSON:MongoDB UUID 1.遇到的问题和困惑 SQL Server中的NEWID数据存储到MongoDB中会是什么样子呢?发现不能简单的通过此数据查询了. 例如我们将SQL Server 数据库中的QQStatements2019表迁移至MongoDB 中,集合命名也为QQStatements2019. 在SQL Server中选择4个OrderId,数据作为演示实例,查看如下: 经过程序转换后,在mongodb的客户端工具nosqlbo

Django模型修改及数据迁移

Migrations Django中对Model进行修改是件麻烦的事情,syncdb命令仅仅创建数据库里还没有的表,它并不对已存在的数据表进行同步修改,也不处理数据模型的删除. 如果你新增或修改数据模型里的字段,或是删除了一个数据模型,你需要手动在数据库里进行相应的修改或者使用South.Django 1.7中已经集成了South的代码,提供了3个新命令: migrate: 用于执行迁移动作,具有syncdb的功能 makemigrations: 基于当前的model创建新的迁移策略文件 sql

Redis数据迁移方案

场景 Redis实例A ---> Redis实例B,整库全量迁移 方案一: mac环境 brew install npm npm install redis-dump -g 针对RedisA: redis-dump -h host1 -p 6379 -d 1 --json > mydb.json针对RedisB: cat mydb.json | redis-dump --convert | redis-cli 方案二:参考: http://www.zlovezl.cn/articles/mig