返回顶部
首页 > 资讯 > 数据库 >Mongodb延迟复制节点配置
  • 285
分享到

Mongodb延迟复制节点配置

2024-04-02 19:04:59 285人浏览 安东尼
摘要

背景:  我们一般配置的mongoDB主从,或者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的系统时间必须一致,否则会造成延迟复制异常,导致在规定同步时间到了之后不进行同步操作。




您可能感兴趣的文档:

--结束END--

本文标题: Mongodb延迟复制节点配置

本文链接: https://lsjlt.com/news/36607.html(转载时请注明来源链接)

有问题或投稿请发送至: 邮箱/279061341@qq.com    QQ/279061341

猜你喜欢
  • Mongodb延迟复制节点配置
    背景:  我们一般配置的Mongodb主从,或者Mongodb复制集,数据同步都是实时的。但如果在主节点上进行了错误的数据操作,这时候就会导致整个集群的数据都出错。因此,我们可以在一个集群中,挑选...
    99+
    2024-04-02
  • MySQL 5.7 延迟复制配置
    --相关参数 master_delay 指定Slave节点延迟应用Master节点的事件变更时间,单位是秒,默认值是0。 --Slave节点,配置延迟应用时间为10秒 change master t...
    99+
    2024-04-02
  • MongoDB中怎么监控复制延迟
    可以通过以下几种方式来监控MongoDB的复制延迟: 使用rs.status()命令:在MongoDB的shell中输入rs.s...
    99+
    2024-04-19
    MongoDB
  • MongoDB中怎么修复config配置节点
    这期内容当中小编将会给大家带来有关MongoDB中怎么修复config配置节点,文章内容丰富且以专业的角度为大家分析和叙述,阅读完这篇文章希望大家可以有所收获。修复流程如下:# 登录到config库,查看c...
    99+
    2024-04-02
  • Mongodb被动(passive)节点配置
      将一个mongodb的普通数据节点修改为passive节点,也就是能同步数据、投票,但是不能成为primary节点。  除了仲裁节点,其他每个节点都有个代表优先权priority的值...
    99+
    2024-04-02
  • mongodb 复制集各节点概述
    默认情况:primary节点负责数据读写,secondary节点备份primary节点上的数据,但是arbiter节点不会从primary节点同步数据arbiter作用:当primary节点故障,能够从se...
    99+
    2024-04-02
  • MySQL 5.7复制延迟之sync_relay_log
    一、描述MySQL 5.7版本主从复制,批量时候显示延迟上万秒。 二、现象 1、io使用率高 #iostat -dxm 1 1000 Device: rrqm/s wrqm/s ...
    99+
    2024-04-02
  • mysql主从复制延迟问题
    在一般生产环境,普遍通过MySQL的主从复制进行读写分离,从而减轻主服务器的压力,提高数据的读写效率。通常情况下,主从复制基本上能做实时同步。由于服务器实际运行过程中,客户端的连接服务器,读写数据不可能是均...
    99+
    2024-04-02
  • mysql主从复制延迟原因
    造成 mysql 主从复制延迟的原因包括:网络问题、硬件限制、重复事件、慢查询、并发冲突、特定数据库引擎限制、日志文件大小、临时表、lock_timeout 变量和并行复制滞后。 My...
    99+
    2024-08-01
    mysql 网络问题
  • mongodb主从复制配置
    主从复制是mongodb最常用的复制方式,这种方式很灵活.可用于备份,故障恢复,读扩展等.最基本的设置方式就是建立一个主节点和一个或多个从节点,每个从节点要知道主节点的地址. 我们用两种方式来实现主从.这里...
    99+
    2024-04-02
  • MySQL主从复制之延迟型数据复制
       让MySQL拓扑中的从节点延迟适当的时间,可以帮助避免在主节点上发生的灾难性的错误。    MASTER_DELAY这个属性指定SQL_THREAD会在从节点...
    99+
    2024-04-02
  • 主从复制延迟原因剖析!
    写在前面:之前在维护线上主从复制架构的时候,遇到了一些主从延迟问题,笔者呢,也是比较好学的,哈哈!所以,查阅了诸多资料,然后去其糟粕,根据自己的理解和查阅的资料整理成了本文,在此申明,本文内容是笔者自己的理...
    99+
    2024-04-02
  • MySQL从库复制延迟的原因
    本篇内容介绍了“MySQL从库复制延迟的原因”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!一、从库复制延迟问题可能的原因如下(1)主从服务器...
    99+
    2023-06-06
  • 主从延迟复制 -- 数据恢复测试!
    写在前面:    设想一下,你的线上环境使用了主从复制架构,如果不小心执行了,如:drop database db1、drop table tb1,或者说delete,update不加wher&#...
    99+
    2024-04-02
  • MongoDB中怎么搭建延时节点从库
    这篇文章给大家介绍MongoDB中怎么搭建延时节点从库,内容非常详细,感兴趣的小伙伴们可以参考借鉴,希望对大家能有所帮助。  MongoDB搭建延时节点从库【概念说明】    ...
    99+
    2024-04-02
  • Mysql怎么配置从库延迟应用
    本篇内容主要讲解“Mysql怎么配置从库延迟应用”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“Mysql怎么配置从库延迟应用”吧! ...
    99+
    2024-04-02
  • MySQL5.7复制延迟有什么办法解决
    不知道大家之前对类似MySQL5.7复制延迟有什么办法解决的文章有无了解,今天我在这里给大家再简单的讲讲。感兴趣的话就一起来看看正文部分吧,相信看完MySQL5.7复制延迟有什么办法解决你一定会有所收获的。...
    99+
    2024-04-02
  • MySQL主从延迟复制的方法总结
    本篇内容主要讲解“MySQL主从延迟复制的方法总结”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“MySQL主从延迟复制的方法总结”吧!方法介绍1.percona...
    99+
    2024-04-02
  • MySQL主从复制延迟原因是什么
    本篇内容主要讲解“MySQL主从复制延迟原因是什么”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“MySQL主从复制延迟原因是什么”吧! ...
    99+
    2024-04-02
  • mongodb主从复制_动力节点Java学院整理
    从这一篇开始我们主要讨论mongodb的部署技术。 我们知道sql server能够做到读写分离,双机热备份和集群部署,当然mongodb也能做到,实际应用中我们不希望数据库采用单点部署,如果碰到数据库宕机...
    99+
    2024-04-02
软考高级职称资格查询
编程网,编程工程师的家园,是目前国内优秀的开源技术社区之一,形成了由开源软件库、代码分享、资讯、协作翻译、讨论区和博客等几大频道内容,为IT开发者提供了一个发现、使用、并交流开源技术的平台。
  • 官方手机版

  • 微信公众号

  • 商务合作