博客访问： 235444
博文数量： 65
博客积分： 0
博客等级： 民兵
技术积分： 1594
注册时间：
热衷技术，热爱交流
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： NOSQL
&副本集数据同步机制&
实例启动后，副本集成员首先通过一次初始化同步来复制数据，然后就开始利用oplog日志和主节点连续进行数据同步。如下日志反应这一过程
Wed Jul 17 13:18:39.473 [rsSync] replSet initial sync pending
Wed Jul 17 13:18:39.473 [rsSync] replSet syncing to: 192.168.69.44:10000
Wed Jul 17 13:18:39.476 [rsSync] build index local.me { _id: 1 }
Wed Jul 17 13:18:39.479 [rsSync] build index done. scanned 0 total records. 0.002 secs
Wed Jul 17 13:18:39.481 [rsSync] build index local.replset.minvalid { _id: 1 }
Wed Jul 17 13:18:39.482 [rsSync] build index done. scanned 0 total records. 0 secs
Wed Jul 17 13:18:39.482 [rsSync] replSet initial sync drop all databases
Wed Jul 17 13:18:39.482 [rsSync] dropAllDatabasesExceptLocal 1
Wed Jul 17 13:18:39.483 [rsSync] replSet initial sync clone all databases
Wed Jul 17 13:18:39.483 [rsSync] replSet initial sync cloning db: test
Wed Jul 17 13:18:39.485 [FileAllocator] allocating new datafile /mongodb/sh1/data/test.ns, filling with zeroes...0.001 secs
Wed Jul 17 13:18:39.497 [rsSync] build index test.test { _id: 1 }
Wed Jul 17 13:18:39.498 [rsSync] fastBuildIndex dupsToDrop:0
Wed Jul 17 13:18:39.498 [rsSync] build index done. scanned 1 total records. 0 secs
Wed Jul 17 13:18:39.498 [rsSync] replSet initial sync data copy, starting syncup
Wed Jul 17 13:18:39.498 [rsSync] oplog sync 1 of 3
Wed Jul 17 13:18:39.499 [rsSync] oplog sync 2 of 3
Wed Jul 17 13:18:39.499 [rsSync] replSet initial sync building indexes
Wed Jul 17 13:18:39.499 [rsSync] replSet initial sync cloning indexes for : test
Wed Jul 17 13:18:39.500 [rsSync] oplog sync 3 of 3
Wed Jul 17 13:18:39.500 [rsSync] replSet initial sync finishing up
Wed Jul 17 13:18:39.527 [rsSync] replSet set minValid=51e6290b:1
Wed Jul 17 13:18:39.527 [rsSync] replSet RECOVERING
Wed Jul 17 13:18:39.527 [rsSync] replSet initial sync done
Wed Jul 17 13:18:40.384 [rsBackgroundSync] replSet syncing to: 192.168.69.44:10000
Wed Jul 17 13:18:40.527 [rsSyncNotifier] replset setting oplog notifier to 192.168.69.44:10000
oplog：多机replication通过oplog来实现，primary向oplog写操作记录，每条记录包含了文档修改，删除，更新信息。secondary复制oplog并replay实现与primary的同步。oplog是capped collection，老的日志会被overwrite，如果secondary落后主节点数据量超过oplog大小，会被认为是stale node，它会进行全部primary sync操作，所以要根据实际情况预先设置好oplogSize。
oplog 在replica set中存在于local.oplog.rs集合，是一个capped collection，启动时候可以通过--oplogSize设置大小，对于linux 和windows 64位，oplog size默认为剩余磁盘空间的5%。
sh1:PRIMARY& db.printReplicationInfo()
configured oplog size: 23446.MB --配置的oplog日志大小
log length start to end: 23055secs (6.4hrs) --日志记录的文档的时间范围
oplog first event time: Wed Jul 17 2013 09:48:00 GMT+0800 (CST) --最早的日志时间
oplog last event time: Wed Jul 17 2013 16:12:15 GMT+0800 (CST) --最近一次的日志时间
now: Wed Jul 17 2013 16:12:18 GMT+0800 (CST)
下面命令展示的更为直观：
sh1:PRIMARY& db.getReplicationInfo()
"logSizeMB" : 23446.,
"usedMB" : 11.22,
"timeDiff" : 23521,
"timeDiffHours" : 6.53,
"tFirst" : "Wed Jul 17 :00 GMT+0800 (CST)",
"tLast" : "Wed Jul 17 :01 GMT+0800 (CST)",
"now" : "Wed Jul 17 :20 GMT+0800 (CST)"
节点之间数据同步方式有两种：Init sync和keep
Init sync同步在下面两种情况发生：
1. &secondary第一次加入，就会进行初始化同步，把所有的数据同步过来。
2. &Secondary被移出，重新移入后由于数据落后，也会进行init sync应用新的日志。如果节点落后的数量超过opolog大小，也就是说，oplog被覆盖过，那么他会启用一次全量备份，把所有数据复制过来。所以，已经有大量的数据时，加入一个新节点要注意全量复制带来的网络负担。应用高峰期时，不适合做这些操作。
Keep模式复制：
这种复制方式是持续性的，是主节点和副节点正常运行期间的数据同步方式。
Init sync过后，节点之间的复制方式就是实时同步了，一般情况下，secondaries从primary复制数据，但是secondary的复制对象可能会根据网络延时做出一些选择，也许会形成链式同步结构，参见/software-database/htm3_246718.shtml
如果两个副节点节在进行复制，那么要求设置相同的buildindex值(默认已经是true)。Secondaries不可能从延迟节点和隐藏节点复制数据。
手从修改syn target：
sh0:SECONDARY& db.adminCommand({replSetSyncFrom:"192.168.69.40:10000"})
& & & & "syncFromRequested" : "192.168.69.40:10000",
& & & & "prevSyncTarget" : "192.168.69.40:10000",
& & & & "ok" : 1
同步过程如下：
从数据源复制数据（源不一定非要primary），应用日志
建立相应索引
sh1:PRIMARY& db.printSlaveReplicationInfo()
source: & 192.168.69.45:10000
syncedTo: Wed Jul 17 :29 GMT+0800 (CST)
= 32 secs ago (0.01hrs)
source: & 192.168.69.46:10000
syncedTo: Wed Jul 17 :29 GMT+0800 (CST)
= 32 secs ago (0.01hrs)
可以使用调试命令观察secondary最后同步的一条日志信息：
sh1:SECONDARY& rs.debug.getLastOpWritten()
&&&&&&&&"ts" : {
&&&&&&&&&&&&&&&&"t" : ,
&&&&&&&&&&&&&&&&"i" : 1
&&&&&&&&},
&&&&&&&&"h" : NumberLong("7625437"),
&&&&&&&&"v" : 2,
&&&&&&&&"op" : "i",
&&&&&&&&"ns" : "test.test",
&&&&&&&&"o" : {
&&&&&&&&&&&&&&&&"_id" : ObjectId("51e7ee01b5ed8bdc9436becf"),
&&&&&&&&&&&&&&&&"name" : 5258
可通过db.oplog.rs.find().sort({$natural:-1})查看opolog日志：
{ "ts" : { "t" : , "i" : 1 }, "h" : NumberLong("7625437"), "v" : 2, "op" : "i", "ns" : "test.test", "o" : { "_id" : ObjectId("51e7ee01b5ed8bdc9436becf"), "name" : 5258 } }
oplog结构：
由7部分组成：{ts:{},h{},v{} op:{},ns:{},o:{},o2:{} }
ts：8字节的时间戳，由4字节unix timestamp + 4字节自增计数表示
h： 一个哈希值(2.0+)，确保oplog的连续性
op：1字节的操作类型
ns：操作所在的namespace。
o：操作所对应的document
o2：在执行更新操作时o只记录id而o2记录具体内容，仅限于update
op操作类型:
“i”：insert操作
“u”：update操作
“d”：delete操作
“c”：db cmd操作
"db"：声明当前数据库 (其中ns 被设置成为=&数据库名称+ '.')
"n": &no op,即空操作，定期执行以确保时效性&
阅读(2809) | 评论(0) | 转发(0) |
相关热门文章
给主人留下些什么吧！~~
请登录后评论。& & &从一开始我们就在讲如何使用一台服务器.一个mongod服务器进程,如果只用做学习和开发,这是可以的,但如果在生产环境中,这是很危险的,如果服务器崩溃了怎么办?数据库至少要一段时间不可用,如果是硬件出现问题呢?可能需要将数据迁移到另一台机器上.使用复制供功能可以将数据副本保存在多台服务器上,建议在生产环境中都要使用,使用mongodb的复制功能,即使一台或者多台服务器出错,也可以保证应用程序的正常运行和数据安全.
& & &MongoDB的数据库复制增加了冗余，确保了高可用性，简化了管理任务如备份，并且增加了读能力。
& & &在mongodb中 创建一个副本集之后就可以使用复制功能了,副本集是一组服务器,其中一个主服务器(primary['pra??m?ri, -m?ri]),用于处理客户端请求,还有多个备份服务器(secondary['s?k?n?d?ri]),用于保存主服务器的数据副本,如果主服务器崩溃了,备份服务器会自动将其中成员升级为新的主服务器,副本集中一个很重要的概念就是大多数(majority[m?'d??r?ti, -'d?ɑr-]) 选择主节点时需要由大多数决定 主节点只有在得到大多数成员支持时才能继续作为主节点 写操作被复制到大多数成员时这个写操作是安全的,这里的大多数被定义为副本中一半以上的成员,
& & &一个副本集可以最多支持12个成员，但是只有7个成员可以参与投票。
故障切换恢复
& & &副本集能够自动进行故障切换恢复。如果primary掉线或者无反应且多数的副本集成员能够相互连接，则选出一个新的primary。
在多数情况下，当primary宕机、不可用或者是不适合做primary时，在没有管理者干预的几秒后会进行故障切换。
如果MongoDB部署没有如预期那样进行故障切换，则可能是下面的问题：
剩余的成员个数少于副本集的一半
没有成员有资格成为primary
& & &多数情况下，回滚操作可以优雅的对不能进行故障切换恢复的情况进行恢复。
& & &Rollbacks操作发生在primary处理写操作，但其它成员没有成功的进行复制之前primary掉线时。当先前的primary恢复工作,开始复制时，则表现出rollback。如果操作复制到其它成员，该成员可用，并且可以和大多数的副本集连接，则没有rollback。
& & &Rollbacks删除了那些没有进行复制的操作，以保证数据集的一致性。
& & &当任意的故障切换发生，都会伴随着选举的出现，以此来决定哪个成员成为primary。
& & &选举提供了一种机制，用于副本集中的成员无需管理员的干预，自动的选出一个新的primary。选举可以让副本集快速和坚决的从故障中恢复。当primary变为不可达时，secondary成员发起选举，第一个收到大多数选票的成员成为新的primary。
& & &前提:每个成员自能要求自己被选举成为主节点,只能为申请成为主节点的候选人投票
& & &当一个备份节点无法与主节点联通时 她就行联系并请求其他成员将自己选举为主节点,其他成员做几项理性的检查
自身是否能够与主节点联通
希望被选举为主节点的备份节点的数据是否是最新
有没有其他更高优先级的成员可以被选举为主节点
& & &当一个成员无法到达主节点时,他就会申请被选举为主节点,希望成为主节点的成员会他能到达的所有成员发出通知,告诉他们我要发起一轮选举,然后其他成员开始检查你是否具备成为候选人的资格,依据就是上面那三条,如果一条不符,直接取消选举,注意:只要有一人发现候选人不具备资格 选举就被否决了,比如说:可能发起选举分成员 就他自己本身不能连接到主节点.
假如 没有反对的理由:那么选举就开始了,其他成员就开始对这个成员投票 如果他得到副本集中大多数赞成票 他就会选举成功 他就会转换到主节点状态 如果达不到大多数赞成 他就失败了 依然是备份节点,之后还可以继续发起选举 主节点会一直处于主节点状态 出非他由于不在满足大多数的要求或者挂了退位,另外副本集被重新配置的时候也会导致主节点退位.
只要能够得到大多数成员的投票 他就会成为主节点
希望成为主节点的成员候选人 必须使用复制将自己的数据更新为最新.副本集中的其他成员会对此进行检查 复制操作是严格按照时间排序的 所有候选人的最后一条操作要比他能两天的其他成员更晚或者与其他成员相等
假设候选人执行的最后一个复制操作是123 他能联通的其他成员中有一个的最后复制操作是124 那么这个成员就会否决候选人的选举,这时候候选人会继续进行数据同步 等他同步到124时 他会重新请求选举(如果那时整个副本集中依然没有主节点的话)
成员优先级([pra?'?r?ti, -'ɑr-)
在副本集中，每个成员都有优先级，它可以帮助决定选举出primary。默认情况下，所有的成员的优先级都为1。设置优先级:rs.add({"_id":4,"host":"iP:27017","priority":1.5});
选举仲裁者(arbiter)['ɑrb?t?]
& & &他的唯一作用就是参与选举,他不会保存数据,也不会为客户端提供服务.他只是为帮助副本集能够满足大多数条件 所以可以选择比较垃圾的服务器来担当.启动方式和启动普通的mongod相同 使用--replset 副本集名称 和空的数据目录,可以使用rs.addArb()辅助函数将仲裁者添加到副本集中 ts.addArb("server-6:27017"); 或者在成员配置中指定arbiterOnly选项 rs.add({"_id":4,"host":"iP:27017","arbiterOnly":true});&仲裁者和其他成员之间是不能相互转换的.
& & &客户端不会想隐藏成员发送请求,因此 许多人会将不够强大的服务器或者备份服务器隐藏起来 &
var config = rs.config();config.members[2].hidden = 0;config.members[2].priority = 0;rs.reconfig(config);
这样就会将副本集中的成员隐藏起来了, 用isMaster命令 是看不见隐藏成员的,
延迟备份成员([d?'le])
& & &数据可能会因为人为错误而遭受毁灭性破坏,可能是不小心删除了组数据库或者出现了一个严重的bug把所有数据变成了垃圾,为了防止这类问题 可以使用slaveDelay设置一个延迟备份节点, 他的数据会比主节点延迟指定的时间,这是有意为之的,
& & &slaveDelay要求成员的优先级是0,如果你的应用程序会将请求路由到备份节点,应该将它隐藏掉,
二、副本集架构和部署模式
副本集部署的架构对其容量和性能都有很大影响。大多数产品部署成包含3个优先级为1 的成员就足够了。
当开发一个副本集架构时要注意下面的因素：
确保副本集的成员总能选出一个primary。运行奇数个成员或者运行一个仲裁者（arbiter）+偶数个成员。
分布在不同地理位置的成员，知道“群体”的成员在任意网络分区中的情况。试图确保在主数据中心的成员中选举出primary。
考虑副本集中包含hidden或者delayed成员用于支持专用功能，如备份、reporting和测试。
考虑保留一或者两个位于其他数据中心的成员，同时通过配置确保其不会成为primary。
使用replica set tags[taegz]创建定制的写规则以确保应用能够控制写操作成功的门限值。使用写规则确保操作在返回成功之前将操作传递给指定的数据中心或不同功能的机器。
不存在一个理想的副本集架构可以满足任意部署环境。
最小的副本集推荐架构为三成员集合，其中一个为primary，另外两个为secondary，secondary在一定情况下可以成为primary。
如果副本集中的成员多于三个，则需要遵照下面的架构条件：
集合中有奇数个参与投票的成员。如果有偶数个投票成员，则部署一个仲裁者将个数变为奇数。
集合中同一时刻不多于7个参与投票的成员
如果不想让某些成员在故障切换时成为primary，则将它们的优先级设为0。
集合的多数成员运行在主要的数据中心
地理上的分布式集
一个基于地理的分布式副本集可以应对一个数据中心恢复失败的情况。这种集合至少包含了一个在备份数据中心的集合成员。
图：基于地理上的分布式副本集
如果primary掉线，则副本集选出一个新的primary；如果主数据中心和备数据中心连接失败，备数据中心的secondary不能成为primary。如果主数据中心失败，则需要人为的从备数据中心恢复数据。
值得注意的是，这种架构下，必须注意在主数据中心要保持奇数个参与投票的成员，上图中则需要在主数据中心添加一个仲裁者。
每个成员都需要知道其他成员的状态:哪个是主节点,哪个可以作为同步源 哪个挂掉了,为了维护最新视图.每个成员每个两秒就会向其他成员发送一条心跳请求 心跳请求信息量很小 用于检查每个成员的状态
心跳的最重要的功能之一 就是让主节点知道自己是否满足集合大多数的条件 如果主节点不再得到大多数服务器的支撑 他就会退位 变成备份节点.
& & &复制用于多台服务器hi见备份数据,mongodb的复制功能是使用操作日志oplog实现的,操作日志包含了主节点的每一次写操作,oplog是主节点的local数据库中的一个固定集合,备份节点通过查询这个集合就可以知道需要进行复制的操作
& & &每个备份节点都维护这自己的oplog,记录了每一次从主节点复制数据的操作,这样每个成员都可以作为同步源提供给其他成员使用.
处理陈旧数据
& & &如果备份节点远远落后与同步源当前操作,那么备份节点就会就是陈旧数据,陈旧的备份节点无法跟上同步源的节奏,因为同步源上的操作领先太多太多;如果继续同步,备份节点需要跳过一些操作,如果备份节点曾经停机过,发现写入量超过了自身处理能力,或者太多的读请求,这些情况都可能导致备份节点陈旧
& & &当一个备份节点陈旧之后,他会查看副本集中的其他成员,如果某个成员的oplog足够详细,可以用于处理那些落下的操作,就从这个成员处进行同步,如果任何一个成员的oplog都没有参考价值,那么这个成员上的复制操作就会中止,这个成员需要重新进行完全同步,
& & &为了避免陈旧被备份节点的出现,让主节点使用比较大的oplog保存足够多的操作日志很重要, 当然需要大的磁盘空间,通常来说这是一个比较好的折衷选择,因为磁盘会越来越便宜.
阅读(...) 评论()博客访问： 5422941
博文数量： 583
注册时间：
高山仰止http://my.csdn.net/wzy0623王工的博客
参加炼数成金培训输入 Dataguru培训优惠码 DR50，报名立减50%固定学费。
ITPUB论坛APP
ITPUB论坛APP
APP发帖 享双倍积分
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： NoSQL
MongoDB建议副本集成员为奇数。最多12个副本节点，最多7个节点参与选举。
限制副本节点的数量，主要是因为一个集群中过多的副本节点，增加了复制的成本，反而拖累了集群的整体性能。
太多的副本节点参与选举,也会增加选举的时间。而官方建议奇数的节点，是为了避免脑裂的发生。
考虑如下场景，一个MongoDB集群有4个节点。分布在两个网段。
如果两个网段的网络发生故障，则每个网段都有两个节点存活，他们查看自己的映射表,不能确定对方是否已死，也不能确定自己是否能成为主节点。
如果他们各自推选出主节点，则集群网络恢复的时候，就会有两个主节点，数据无法达成一致。所以这个时候，MongoDB会选择让所有的节点只读。
两个节点也是同样的问题，一旦出现故障，每个节点都不能判断是自己出了问题，还是对方出了问题。所以他们都会选择将自己设置为只读。
整个集群需要保持一定的通信才能知道哪些节点活着哪些节点挂掉。mongodb节点会向副本集中的其他节点每两秒就会发送一次pings包，如果其他节点在10秒钟之内没有返回就标示为不能访问。每个节点内部都会维护一个状态映射表，表明当前每个节点是什么角色、日志时间戳等关键信息。如果是主节点，除了维护映射表外还需要检查自己能否和集群中内大部分节点通讯，如果不能则把自己降级为secondary只读节点。
副本集同步分为初始化同步和keep复制。初始化同步指全量从主节点同步数据，如果主节点数据量比较大同步时间会比较长。而keep复制指初始化同步过后，节点之间的实时同步一般是增量同步。初始化同步不只是在第一次才会被触发，有以下两种情况会触发：
secondary第一次加入，这个是肯定的。
secondary落后的数据量超过了oplog的大小，这样也会被全量复制。
那什么是oplog的大小？前面说过oplog保存了数据的操作记录，secondary复制oplog并把里面的操作在secondary执行一遍。但是oplog也是mongodb的一个集合，保存在local.oplog.rs里，但是这个oplog是一个capped collection也就是固定大小的集合，新数据加入超过集合的大小会覆盖。所以这里需要注意，跨IDC的复制要设置合适的oplogSize，避免在生产环境经常产生全量复制。oplogSize 可以通过–oplogSize设置大小，对于linux 和windows 64位，oplog
size默认为剩余磁盘空间的5%。
同步也并非只能从主节点同步，假设集群中3个节点，节点1是主节点在IDC1，节点2、节点3在IDC2，初始化节点2、节点3会从节点1同步数据。后面节点2、节点3会使用就近原则从当前IDC的副本集中进行复制，只要有一个节点从IDC1的节点1复制数据。
设置同步还要注意以下几点：
secondary不会从delayed和hidden成员上复制数据。
只要是需要同步，两个成员的buildindexes必须要相同无论是否是true和false。buildindexes主要用来设置是否这个节点的数据用于查询，默认为true。
如果同步操作30秒都没有反应，则会重新选择一个节点进行同步。
阅读(6848) | 评论(0) | 转发(0) |
相关热门文章
给主人留下些什么吧！~~
请登录后评论。Mongodb 副本集搭建问题总结及解决办法
作者：生_若蜉蝣
字体：[ ] 类型：转载 时间：
这篇文章主要介绍了Mongodb 副本集搭建问题总结及解决办法的相关资料,在Mongodb 副本集搭建过程中会遇到很多问题，这里就对常见问题进行总结并提供解决办法，需要的朋友可以参考下
Mongodb 副本集搭建问题总结及解决办法
Mongodb数据库的副本集是由多台服务器组成，基中一台是主节点，其它为从节点，如果主节点宕机就自动切换到任意一个从节点。如果以前的主节点修复完成和正常运行就自动变成从节点，从节点不能查询数据。也可以在一台服务器装多个Mongodb端口不一样。
在我以往的认知中，一个系统一旦正式上线，多半不会轻易的迁移服务器，尤其是那种涉及到多个关联应用，涉及到多台硬件服务器的系统，因为这种迁移将是牵一发而动全身的。
但是，却仍然有这种情况存在，就如我这几天主要负责的事，就是一个系统的全部服务器迁移中的部分机器迁移，还有一部分由别人负责。
这个系统涉及到flume数据采集，storm数据分析，rabbitmq消息分发，ehcache缓存提升系统性能，MongoDB副本集存储数据，tomcat管理系统应用等，架构基本如下：
而这里我主要负责的是rabbitmq、tomcat、ehcache、mongodb，这里边tomcat、ehcache的安装和配置都比较简单，只是rabbitmq需要依赖于erlang。而erlang又需要依赖一些其他的东西，这些东西需要root权限执行yum，而我们没有root权限，于是稍微花了一点点功夫。
除此之外，mongodb副本集的再次搭建也稍微遇到了一点点问题，不过好在一切还是按照预料中发展的，以前没遇到过的问题也通过经验猜想完美解决。
之所以mongodb副本集搭建会遇到一些问题，大部分原因是因为这次并非亲自动手，而是由所带的新人操作。
首先，按照我给的文档他一步步的操作下去，结果在端口上，不知道是因为习惯还是因为什么，他所设置的端口并不是我们要求的端口。
那么这时候当我要求他改成要求的端口时，他有些茫然，不知道是应该把所有配置删了重配，还是要怎样。
由于时间关系，于是我给他提供了一个方案，就是直接使用配置优先级的方式改掉端口。之前我写过的副本集搭建的文档中应该有说过优先级怎么改，大体上是下边三步：
config=rs.conf()
config.members[0].priority=2
rs.reconfig(config)
那么根据这个，我们设想的改端口应该是下边这样(下边ip和端口只是随便假设的，生产环境自然不能随便透漏)：
config=rs.conf()
config.members[0].host="192.168.117.88:37017"
rs.reconfig(config)
但是结果呢，在第三步的时候抛出异常，遗憾的是当时只为了解决问题而没有截图，忘记具体是什么异常了，但大体意思是说这个端口的成员不存在。
于是，我又给他提供了第二个方案，那就是先把三个成员中非主服务的任意一个从成员中删除：
rs.remove("ip:port")
然后把这台机的端口改为我们需要的37017，之后再使用增加成员的命令添加进来：
rs.add("ip:port")
然后就这样操作三次后，三台服务器的端口都成功修改成要求的端口。
这个过程中，当修改到主服务的时候，因为一开始设置了最高优先级，因此需要把另外一台先设置成更高的优先级操作。
问题就这样解决了，只不过事后我又想了想，似乎这种方案并非是最优最简洁的，因为当时没有细想第一种方案中那个问题的原因，后来一想，多半是因为那台机还是原端口没有被重启。
如果我们先把非主服务机器的端口都改好重启，那么再次用第一种方案进行应该也是可行的，而且还会比第二种方案简单，有机会了一定要试试。
本以为这样就可以了，然后没想到的是，当我们都迁移完成后，被告知那些机器都是测试服务网段的，要改成生产网段。
于是乎，所有的机器ip全部变了，以至于我们的mongodb副本集又要重新配置。
但是这一次比较麻烦的是，之前那次改端口是因为我至少可以保证有两台机还是正常运行的，可以操作rs命令，但是这一次ip一变，我三台机都无法正常成为主服务，以至于rs命令失效。
几番折腾，始终没有想出好的方案，于是只好把data目录下的内容尽数删除，然后真正的重新配置一遍。
然而，在这位新手的操作下，配置的过程中，把本该是如下的命令：
config={_id:”reptest”,members:[{_id:0,host:”192.168.0.160:57017”},{_id:1,host:”192.168.0.211:57017”},{_id:,host:”192.168.0.213:57017”}]}
rs.initiate(config)
弄成了这样：
config={_id:”reptest”,members:[{_id:0,host:”192.168.0.160:57017”},{_id:1,host:”192.168.0.211:57017”},{_id:,host:”192.168.0.213:57017”}]}
rs.initiate()
也就是说这里他虽然给config赋值了，但是再加载的时候竟然没有使用，这也怪了忘了告诉他之前发现的一个问题。
通常我们在window系统上操作Linux上的应用，都会使用crt或者putty这些工具，这两个工具各有优劣，而我发现当我们进入mongo shell中操作时，这两个工具是有区别的，使用putty就可以回退，而crt就不能再mongodb shell中回退。
因此当他敲完rs.initiate()，想要回到括号里加上config时，已经没了回头路，只能硬着头皮回车。
而这时候，rs.initiate()只能执行一次，接下来和我文档中的操作不一样了，又该怎么办呢？
经过上一个问题，这个问题貌似就很好解决的，怎么办呢，我觉得还是可以使用rs.add和修改配置的方式解决，然后把这个想法告诉他，他照此操作后，果然一次搞定！
好了，这次的两个问题基本就这样解决了，不知其他朋友们，是否对这种情况还有更好的解决方案？欢迎留言解惑。
感谢阅读，希望能帮助到大家，谢谢大家对本站的支持！
您可能感兴趣的文章:
大家感兴趣的内容
12345678910
最近更新的内容
常用在线小工具}