我的编程空间,编程开发者的网络收藏夹
学习永远不晚

Mongodb延迟复制节点配置

短信预约 -IT技能 免费直播动态提醒
省份

北京

  • 北京
  • 上海
  • 天津
  • 重庆
  • 河北
  • 山东
  • 辽宁
  • 黑龙江
  • 吉林
  • 甘肃
  • 青海
  • 河南
  • 江苏
  • 湖北
  • 湖南
  • 江西
  • 浙江
  • 广东
  • 云南
  • 福建
  • 海南
  • 山西
  • 四川
  • 陕西
  • 贵州
  • 安徽
  • 广西
  • 内蒙
  • 西藏
  • 新疆
  • 宁夏
  • 兵团
手机号立即预约

请填写图片验证码后获取短信验证码

看不清楚,换张图片

免费获取短信验证码

Mongodb延迟复制节点配置

背景:

  我们一般配置的Mongodb主从,或者Mongodb复制集,数据同步都是实时的。但如果在主节点上进行了错误的数据操作,这时候就会导致整个集群的数据都出错。因此,我们可以在一个集群中,挑选一个mongodb实例,用作复制延迟。当在主节点上误操作的时候,集群中有一个实例是不受影响的。这时候就可以利用这台不受影响的实例进行数据恢复。

  以上就是mongodb的延迟复制节点的功能,当主节点进行一次数据操作后,延迟复制节不立马进行数据同步操作,而是在一段时间后,才同步数据。


配置:

  以我的实验环境为例,以下为我的mongodb复制集:

cmh0:PRIMARY> rs.status()
{
        "set" : "cmh0",
        "date" : ISODate("2016-08-22T02:43:16.240Z"),
        "myState" : 1,
        "members" : [
                {
                        "_id" : 1,
                        "name" : "192.168.52.128:27017",
                        "health" : 1,
                        "state" : 1,
                        "stateStr" : "PRIMARY",
                        "uptime" : 82,
                        "optime" : Timestamp(1470581983, 1),
                        "optimeDate" : ISODate("2016-08-07T14:59:43Z"),
                        "electionTime" : Timestamp(1471833721, 1),
                        "electionDate" : ISODate("2016-08-22T02:42:01Z"),
                        "configVersion" : 1,
                        "self" : true
                },
                {
                        "_id" : 2,
                        "name" : "192.168.52.135:27017",
                        "health" : 1,
                        "state" : 2,
                        "stateStr" : "SECONDARY",
                        "uptime" : 71,
                        "optime" : Timestamp(1470581983, 1),
                        "optimeDate" : ISODate("2016-08-07T14:59:43Z"),
                        "lastHeartbeat" : ISODate("2016-08-22T02:43:15.138Z"),
                        "lastHeartbeatRecv" : ISODate("2016-08-22T02:43:14.978Z"),
                        "pingMs" : 0,
                        "lastHeartbeatMessage" : "could not find member to sync from",
                        "configVersion" : 1
                },
                {
                        "_id" : 3,
                        "name" : "192.168.52.135:27019",
                        "health" : 1,
                        "state" : 2,
                        "stateStr" : "SECONDARY",
                        "uptime" : 75,
                        "optime" : Timestamp(1470581983, 1),
                        "optimeDate" : ISODate("2016-08-07T14:59:43Z"),
                        "lastHeartbeat" : ISODate("2016-08-22T02:43:15.138Z"),
                        "lastHeartbeatRecv" : ISODate("2016-08-22T02:43:15.138Z"),
                        "pingMs" : 0,
                        "configVersion" : 1
                }
        ],
        "ok" : 1
}

  这时还未配置延迟复制节点,所以数据是实时同步的:

cmh0:PRIMARY> use cmhtest
switched to db cmhtest
cmh0:PRIMARY> db.cmh.insert({"name":"ChenMinghui"})
WriteResult({ "nInserted" : 1 })
cmh0:PRIMARY> rs.printReplicationInfo()
configured oplog size:   990MB
log length start to end: 195secs (0.05hrs)
oplog first event time:  Mon Aug 22 2016 10:51:22 GMT+0800 (CST)
oplog last event time:   Mon Aug 22 2016 10:54:37 GMT+0800 (CST)
now:                     Mon Aug 22 2016 10:55:00 GMT+0800 (CST)
cmh0:PRIMARY> rs.printSlaveReplicationInfo()
source: 192.168.52.135:27017
        syncedTo: Mon Aug 22 2016 10:54:37 GMT+0800 (CST)
        0 secs (0 hrs) behind the primary 
source: 192.168.52.135:27019
        syncedTo: Mon Aug 22 2016 10:54:37 GMT+0800 (CST)
        0 secs (0 hrs) behind the primary

  可以看到两个Secondary节点都在同一时间实时同步了数据。


  配置192.168.52.135:27017为延迟复制节点:

cmh0:PRIMARY> cfg=rs.conf();
{
        "_id" : "cmh0",
        "version" : 1,
        "members" : [
                {
                        "_id" : 1,
                        "host" : "192.168.52.128:27017",
                        "arbiterOnly" : false,
                        "buildIndexes" : true,
                        "hidden" : false,
                        "priority" : 1,
                        "tags" : {
                        },
                        "slaveDelay" : 0,
                        "votes" : 1
                },
                {
                        "_id" : 2,
                        "host" : "192.168.52.135:27017",
                        "arbiterOnly" : false,
                        "buildIndexes" : true,
                        "hidden" : false,
                        "priority" : 1,
                        "tags" : {
                        },
                        "slaveDelay" : 0,
                        "votes" : 1
                },
                {
                        "_id" : 3,
                        "host" : "192.168.52.135:27019",
                        "arbiterOnly" : false,
                        "buildIndexes" : true,
                        "hidden" : false,
                        "priority" : 1,
                        "tags" : {
                        },
                        "slaveDelay" : 0,
                        "votes" : 1
                }
        ],
        "settings" : {
                "chainingAllowed" : true,
                "heartbeatTimeoutSecs" : 10,
                "getLastErrorModes" : {
                },
                "getLastErrorDefaults" : {
                        "w" : 1,
                        "wtimeout" : 0
                }
        }
}
cmh0:PRIMARY> cfg.members[1].priority=0
0
cmh0:PRIMARY> cfg.members[1].slaveDelay=30
30
cmh0:PRIMARY> rs.reconfig(cfg);
{ "ok" : 1 }
cmh0:PRIMARY> rs.conf()
{
        "_id" : "cmh0",
        "version" : 2,
        "members" : [
                {
                        "_id" : 1,
                        "host" : "192.168.52.128:27017",
                        "arbiterOnly" : false,
                        "buildIndexes" : true,
                        "hidden" : false,
                        "priority" : 1,
                        "tags" : {
                        },
                        "slaveDelay" : 0,
                        "votes" : 1
                },
                {
                        "_id" : 2,
                        "host" : "192.168.52.135:27017",
                        "arbiterOnly" : false,
                        "buildIndexes" : true,
                        "hidden" : false,
                        "priority" : 0,
                        "tags" : {
                        },
                        "slaveDelay" : 30,
                        "votes" : 1
                },
                {
                        "_id" : 3,
                        "host" : "192.168.52.135:27019",
                        "arbiterOnly" : false,
                        "buildIndexes" : true,
                        "hidden" : false,
                        "priority" : 1,
                        "tags" : {
                        },
                        "slaveDelay" : 0,
                        "votes" : 1
                }
        ],
        "settings" : {
                "chainingAllowed" : true,
                "heartbeatTimeoutSecs" : 10,
                "getLastErrorModes" : {
                },
                "getLastErrorDefaults" : {
                        "w" : 1,
                        "wtimeout" : 0
                }
        }
}

  可以看到192.168.52.135:27017节点出现了"slaveDelay":30的值,说明该节点的同步时间向后推迟了30秒。

  具体大家可以测试一下,延迟复制时间大概会在30秒左右。有一点要注意,mongodb的系统时间必须一致,否则会造成延迟复制异常,导致在规定同步时间到了之后不进行同步操作。




免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

Mongodb延迟复制节点配置

下载Word文档到电脑,方便收藏和打印~

下载Word文档

猜你喜欢

MongoDB中怎么监控复制延迟

可以通过以下几种方式来监控MongoDB的复制延迟:使用rs.status()命令:在MongoDB的shell中输入rs.status()命令可以查看复制集的状态信息,其中包括每个成员的复制延迟信息。可以通过该命令查看每个成员的optim
MongoDB中怎么监控复制延迟
2024-04-19

MySQL主从复制配置要点

MySQL主从复制是一种数据同步技术,它允许将一台MySQL服务器(主服务器)的数据复制到另一台或多台MySQL服务器(从服务器)上。这种架构可以实现负载均衡和读写分离,提高系统的性能和可用性。以下是MySQL主从复制配置的要点:主从复制
MySQL主从复制配置要点
2024-10-20

解决MongoDB技术开发中遇到的数据复制延迟问题的方法研究

解决MongoDB技术开发中遇到的数据复制延迟问题的方法研究引言:在现代应用程序开发中,数据库复制是确保数据高可用性和容错性的重要组成部分。MongoDB作为一种流行的NoSQL数据库,提供了一种名为复制集的机制来实现数据复制和故障转移。然
2023-10-22

编程热搜

目录