mongodb 副本集的维护(1)

一、修改副本集中各成员的优先级：

shard1:PRIMARY> conf=rs.conf()

{

"_id" : "shard1",

"version" : 3,

"protocolVersion" : NumberLong(1),

"members" : [

{

"_id" : 0,

"host" : "mongo01-jp:27027",

"arbiterOnly" : false,

"buildIndexes" : true,

"hidden" : false,

"priority" : 1,

"tags" : {

"slaveDelay" : NumberLong(0),

"votes" : 1

{

"_id" : 1,

"host" : "mongo02-jp:27027",

"arbiterOnly" : false,

"buildIndexes" : true,

"hidden" : false,

"priority" : 1,

"tags" : {

"slaveDelay" : NumberLong(0),

"votes" : 1

{

"_id" : 2,

"host" : "mongo03-jp:27027",

"arbiterOnly" : true,

"buildIndexes" : true,

"hidden" : false,

"priority" : 1,

"tags" : {

"slaveDelay" : NumberLong(0),

"votes" : 1

}

"settings" : {

"chainingAllowed" : true,

"heartbeatIntervalMillis" : 2000,

"heartbeatTimeoutSecs" : 10,

"electionTimeoutMillis" : 10000,

"catchUpTimeoutMillis" : 2000,

"getLastErrorModes" : {

"getLastErrorDefaults" : {

"w" : 1,

"wtimeout" : 0

"replicaSetId" : ObjectId("5850deb0205cd94104cd9a38")

}

shard1:PRIMARY> conf.members[0].priority=100

100

shard1:PRIMARY> conf.members[1].priority=90

shard1:PRIMARY> rs.reconfig(conf)

{ "ok" : 1 }

shard1:PRIMARY> rs.conf()

{

"_id" : "shard1",

"version" : 4,

"protocolVersion" : NumberLong(1),

"members" : [

{

"_id" : 0,

"host" : "mongo01-jp:27027",

"arbiterOnly" : false,

"buildIndexes" : true,

"hidden" : false,

"priority" : 100,

"tags" : {

"slaveDelay" : NumberLong(0),

"votes" : 1

{

"_id" : 1,

"host" : "mongo02-jp:27027",

"arbiterOnly" : false,

"buildIndexes" : true,

"hidden" : false,

"priority" : 90,

"tags" : {

"slaveDelay" : NumberLong(0),

"votes" : 1

{

"_id" : 2,

"host" : "mongo03-jp:27027",

"arbiterOnly" : true,

"buildIndexes" : true,

"hidden" : false,

"priority" : 1,

"tags" : {

"slaveDelay" : NumberLong(0),

"votes" : 1

}

"settings" : {

"chainingAllowed" : true,

"heartbeatIntervalMillis" : 2000,

"heartbeatTimeoutSecs" : 10,

"electionTimeoutMillis" : 10000,

"catchUpTimeoutMillis" : 2000,

"getLastErrorModes" : {

"getLastErrorDefaults" : {

"w" : 1,

"wtimeout" : 0

"replicaSetId" : ObjectId("5850deb0205cd94104cd9a38")

}

shard1:PRIMARY>

关于优先级范围从0 至 1000 (3.2以上版本) ，优先级越大，越可能成为primary；若优先级为0，则该节点无资格参与primary的选举。

如果希望某节点不参与primary的选举有两种方法： 1、将该节点优先级设置为0；2、rs.freeze(30) 在cluster选举primary时，将该节点暂时冻结30S。

如果希望将本primary节点降为secondary状态，可以执行 rs.stepDown() 。

二、在副本集中删除成员、重新添加成员

shard2:PRIMARY> rs.status()

{

"set" : "shard2",

"date" : ISODate("2016-12-14T06:12:11.986Z"),

"myState" : 1,

"term" : NumberLong(1),

"heartbeatIntervalMillis" : NumberLong(2000),

"optimes" : {

"lastCommittedOpTime" : {

"ts" : Timestamp(1481695926, 1),

"t" : NumberLong(1)

"appliedOpTime" : {

"ts" : Timestamp(1481695926, 1),

"t" : NumberLong(1)

"durableOpTime" : {

"ts" : Timestamp(1481695926, 1),

"t" : NumberLong(1)

}

"members" : [

{

"_id" : 0,

"name" : "mongo02-jp:27028",

"health" : 1,

"state" : 1,

"stateStr" : "PRIMARY",

"uptime" : 1128,

"optime" : {

"ts" : Timestamp(1481695926, 1),

"t" : NumberLong(1)

"optimeDate" : ISODate("2016-12-14T06:12:06Z"),

"electionTime" : Timestamp(1481695445, 2),

"electionDate" : ISODate("2016-12-14T06:04:05Z"),

"configVersion" : 4,

"self" : true

{

"_id" : 1,

"name" : "mongo01-jp:27028",

"health" : 1,

"state" : 2,

"stateStr" : "SECONDARY",

"uptime" : 464,

"optime" : {

"ts" : Timestamp(1481695926, 1),

"t" : NumberLong(1)

"optimeDurable" : {

"ts" : Timestamp(1481695926, 1),

"t" : NumberLong(1)

"optimeDate" : ISODate("2016-12-14T06:12:06Z"),

"optimeDurableDate" : ISODate("2016-12-14T06:12:06Z"),

"lastHeartbeat" : ISODate("2016-12-14T06:12:10.206Z"),

"lastHeartbeatRecv" : ISODate("2016-12-14T06:12:11.202Z"),

"pingMs" : NumberLong(0),

"syncingTo" : "mongo02-jp:27028",

"configVersion" : 4

{

"_id" : 2,

"name" : "mongo03-jp:27028",

"health" : 1,

"state" : 7,

"stateStr" : "ARBITER",

"uptime" : 439,

"lastHeartbeat" : ISODate("2016-12-14T06:12:10.205Z"),

"lastHeartbeatRecv" : ISODate("2016-12-14T06:12:10.125Z"),

"pingMs" : NumberLong(0),

"configVersion" : 4

}

"ok" : 1

}

shard2:PRIMARY> rs.remove("mongo01-jp:27028")

{ "ok" : 1 }

shard2:PRIMARY> rs.remove("mongo03-jp:27028")

{ "ok" : 1 }

shard2:PRIMARY> rs.status()

{

"set" : "shard2",

"date" : ISODate("2016-12-14T06:13:18.227Z"),

"myState" : 1,

"term" : NumberLong(1),

"heartbeatIntervalMillis" : NumberLong(2000),

"optimes" : {

"lastCommittedOpTime" : {

"ts" : Timestamp(1481695994, 1),

"t" : NumberLong(1)

"appliedOpTime" : {

"ts" : Timestamp(1481695994, 1),

"t" : NumberLong(1)

"durableOpTime" : {

"ts" : Timestamp(1481695994, 1),

"t" : NumberLong(1)

}

"members" : [

{

"_id" : 0,

"name" : "mongo02-jp:27028",

"health" : 1,

"state" : 1,

"stateStr" : "PRIMARY",

"uptime" : 1195,

"optime" : {

"ts" : Timestamp(1481695994, 1),

"t" : NumberLong(1)

"optimeDate" : ISODate("2016-12-14T06:13:14Z"),

"electionTime" : Timestamp(1481695445, 2),

"electionDate" : ISODate("2016-12-14T06:04:05Z"),

"configVersion" : 6,

"self" : true

}

"ok" : 1

}

shard2:PRIMARY> rs.add("mongo03-jp:27028")

{ "ok" : 1 }

shard2:PRIMARY> rs.addArb("mongo01-jp:27028")

{ "ok" : 1 }

shard2:PRIMARY> rs.status()

{

"set" : "shard2",

"date" : ISODate("2016-12-14T06:39:40.718Z"),

"myState" : 1,

"term" : NumberLong(1),

"heartbeatIntervalMillis" : NumberLong(2000),

"optimes" : {

"lastCommittedOpTime" : {

"ts" : Timestamp(1481697576, 1),

"t" : NumberLong(1)

"appliedOpTime" : {

"ts" : Timestamp(1481697576, 1),

"t" : NumberLong(1)

"durableOpTime" : {

"ts" : Timestamp(1481697576, 1),

"t" : NumberLong(1)

}

"members" : [

{

"_id" : 0,

"name" : "mongo02-jp:27028",

"health" : 1,

"state" : 1,

"stateStr" : "PRIMARY",

"uptime" : 2777,

"optime" : {

"ts" : Timestamp(1481697576, 1),

"t" : NumberLong(1)

"optimeDate" : ISODate("2016-12-14T06:39:36Z"),

"electionTime" : Timestamp(1481695445, 2),

"electionDate" : ISODate("2016-12-14T06:04:05Z"),

"configVersion" : 9,

"self" : true

{

"_id" : 1,

"name" : "mongo03-jp:27028",

"health" : 1,

"state" : 2,

"stateStr" : "SECONDARY",

"uptime" : 1034,

"optime" : {

"ts" : Timestamp(1481697576, 1),

"t" : NumberLong(1)

"optimeDurable" : {

"ts" : Timestamp(1481697576, 1),

"t" : NumberLong(1)

"optimeDate" : ISODate("2016-12-14T06:39:36Z"),

"optimeDurableDate" : ISODate("2016-12-14T06:39:36Z"),

"lastHeartbeat" : ISODate("2016-12-14T06:39:38.838Z"),

"lastHeartbeatRecv" : ISODate("2016-12-14T06:39:39.594Z"),

"pingMs" : NumberLong(0),

"syncingTo" : "mongo02-jp:27028",

"configVersion" : 9

{

"_id" : 2,

"name" : "mongo01-jp:27028",

"health" : 1,

"state" : 7,

"stateStr" : "ARBITER",

"uptime" : 1128,

"lastHeartbeat" : ISODate("2016-12-14T06:39:39.053Z"),

"lastHeartbeatRecv" : ISODate("2016-12-14T06:39:36.708Z"),

"pingMs" : NumberLong(0),

"configVersion" : 9

}

"ok" : 1

}

时间： 2024-12-17 06:29:30

mongodb 副本集的维护(1)的相关文章

mongodb副本集维护

mongodb副本集维护主要工作: 1.查看副本集状态(集群状态.同步延迟.单个库的运行状态mongostate) 2.增删节点.停节点shutdown mongodb副本集集群同步机制数据复制的目的是使数据得到最大的可用性,冗余,避免单点故障. 副本集中同一时刻只有一台服务器是可以写的,primary主库上写,从库同步数据副本集主从复制也是异步同步的过程.slave从primary上获取日志,然后在自己身上完全顺序的执行日志记录的操作(该日志不记录查询操作,只记录更新操作).被同步的日志就

MongoDB副本集

简介 mongodb复制(replication)是将数据同步在多个服务器的过程.主节点记录在其上的所有操作oplog,从节点定期轮询主节点获取这些操作,然后对自己的数据副本执行这些操作,从而保证从节点的数据与主节点一致.复制提供了数据的冗余备份,并在多个服务器上存储数据副本,提高了数据的可用性,并保证数据的安全性.复制还允许您从硬件故障和服务中断中恢复数据. 而副本集(replica set)是从mongodb 1.6 提供的新功能,比复制功能要强大一些并增加了故障自动切换和自动修复成员节点,

mongodb副本集的内部机制（借鉴lanceyan.com）

针对mongodb的内部机制提出以下几个引导性的问题: 副本集故障转移,主节点是如何选举的?能否手动干涉下架某一台主节点. 官方说副本集数量最好是奇数,为什么? mongodb副本集是如何同步的?如果同步不及时会出现什么情况?会不会出现不一致性? mongodb的故障转移会不会无故自动发生?什么条件会触发?频繁触发可能会带来系统负载加重? Bully算法 mongodb副本集故障转移功能得益于它的选举机制.选举机制采用了Bully算法,可以很方便从分布式节点中选出主节点.一个分布式集群架构中一般

MongoDB副本集运维小结

前面的文章介绍了MongoDB副本集和分片集群的做法,下面对MongoDB集群的日常维护操作进行小总结: MongDB副本集故障转移功能得益于它的选举机制.选举机制采用了Bully算法,可以很方便从分布式节点中选出主节点. Bully算法是一种协调者(主节点)竞选算法,主要思想是集群的每个成员都可以声明它是主节点并通知其他节点.别的节点可以选择接受这个声称或是拒绝并进入主节点竞争.被其他所有节点接受的节点才能成为主节点.节点按照一些属性来判断谁应该胜出.这个属性可以是一个静态ID,也可以是更新

MongoDB副本集的常用操作及原理

下面的操作主要分为两个部分: 修改节点状态主要包括: 将Primary节点降级为Secondary节点冻结Secondary节点强制Secondary节点进入维护模式2.?修改副本集的配置添加节点删除节点将Secondary节点设置为延迟备份节点将Secondary节点设置为隐藏节点替换当前的副本集成员设置副本集节点的优先级阻止Secondary节点升级为Primary节点如何设置没有投票权的Secondary节点禁用chainingAllowed为Secondary节点显式指定复制源禁止S

MongoDB 副本集的常用操作及原理

本文是对MongoDB副本集常用操作的一个汇总,同时也穿插着介绍了操作背后的原理及注意点. 结合之前的文章:MongoDB副本集的搭建,大家可以在较短的时间内熟悉MongoDB的搭建和管理. 下面的操作主要分为两个部分: 1. 修改节点状态主要包括: 1> 将Primary节点降级为Secondary节点 2> 冻结Secondary节点 3> 强制Secondary节点进入维护模式 2. 修改副本集的配置 1> 添加节点 2> 删除节点 3> 将Secondary节

Mongodb副本集实现

MongoDB副本集概述以下图片摘自MongoDB官方文档:http://docs.mongodb.org/manual/core/replication-introduction/ Primary节点接收客户端所有的写操作,整个副本集只会有一个primary节点.MongoDB副本集提供严格的一致性.主节点将所有的操作写入一个叫oplog的capped collection(这个collection的大小一般为磁盘剩余空间的5%,不同的系统可能不一样,详见http://docs.mongod

zabbix使用Python实现监控MongoDB副本集状态

公司有 Windows 和 Linux 服务器,都搭建了 MongoDB 副本集,并且都要在 zabbix 平台中实现监控.Linux 系统直接使用 shell 脚本即可实现,但是 Windows 系统的不太好实现,我这里使用 Python 来实现.下面脚本同样适用于Linux系统(在 Windows server 2012 和 Centos7.3 系统都验证成功) 思路: 1.安装Python2.7 2.采用 Python 的 pymongo 模块来连接 mongodb 数据库,并认证授权 3

mongodb 副本集配置与说明

1,副本集的原理副本集的原理与主从很相似,唯一不同的是,在主节点出现故障的时候,主从配置的从服务器不会自动的变为主服务器,而是要通过手动修改配置.但是副表集就不用,它会自动选出一台服务器做为主节点,从而保障系统的稳定性. 2,副本集新的主节点是怎么选举出来的呢是通过bully算法来的,也就是一致性协议.具体如下 1):当主节点挂了后,副本集会获得其他从节点的最后更新时间与主服务做对比 2):如果所有从节点的最后更新时间都是很旧,那就选举停止 3):如果副本集中的大部分服务器挂了,包含主节点,