Replica sets架构复制集(2)详解
接上文,我们已经搭建成功了,下面是我们查看日志等详细解读
我们可以通过执行“db.printCollectionStats()”命令查看到操作日志的一些基本信息,如大小,日志启动时间等,查看primary 的oplog.rs表的元信息,代码如下:
PRIMARY> db.printCollectionStats()
oplog.rs
{
}
---
system.replset
{
}
---
PRIMARY>
复制集搭建之后,需要做的第一件事就是要查看复制集的同步状态,因为如果复制集数据不同步,mongodb的复制集是不会起到任何效果的,通过执行“db.printSlaveReplicationInf
PRIMARY> db.printSlaveReplicationInf
source:
source:
PRIMARY>
字段说明:
1, source :从库的IP及端口
2,syncedTo: 目前的同步情况,以及最后一次同步时间等信息。
主从配置信息
PRIMARY> db
local
PRIMARY> show collections
oplog.rs
system.replset
PRIMARY> db.system.replset.find()
{ "_id" : "rs1", "version" : 1, "members" : [
{
{
PRIMARY>
在本例中,字段ID存储复制集的名字,本例中的值是rs1,字段“members”存储复制集成员的IP及端口信息。
管理Replica Sets
1,主从切换
端口
28010
28011
28012
在本例中,端口28010对应的是主库,现在要将主库放到28012的端口上,下面逐步引导大家完成配置
步骤1:除了现有的主实例(端口28010)和目标主实例(端口28012)以外,其他的实例群全部设置为“冰冻”(freeze)状态,即(非主状态);
本实例中将端口28011“冰冻”,代码如下
PRIMARY> exit
bye
[root@dota ~]# /usr/local/mongodb/bin/mongo --port 28011
MongoDB shell version: 2.0.4
connecting to: 127.0.0.1:28011/test
SECONDARY> rs.freeze(30)
{ "ok" : 1 }
SECONDARY>
通过执行“rs.freeze(30)”命令,将端口在28011上的实例“冰冻”,其中30的单位是秒,说明30秒内这个实例不会参与primary的内部选举工作,即30内此实例不会变成primary角色,那么就充分利用三十秒的时间完成切换工作。
步骤2,将当前主库的实例降级,
[root@dota ~]# /usr/local/mongodb/bin/mongo --port 28010
MongoDB shell version: 2.0.4
connecting to: 127.0.0.1:28010/test
PRIMARY> rs.stepDown()
Fri Jul 25 11:25:20 DBClientCursor::init call() failed
Fri Jul 25 11:25:20 query failed : admin.$cmd { replSetStepDown: 60.0 } to: 127.0.0.1:28010
Fri Jul 25 11:25:20 Error: error doing query: failed shell/collection.js:151
Fri Jul 25 11:25:20 trying reconnect to 127.0.0.1:28010
Fri Jul 25 11:25:20 reconnect 127.0.0.1:28010 ok
步骤3,查看操作之后的状态
通过rs.status()查看操作后的状态
SECONDARY> rs.status()
{
}
SECONDARY>
读写分离
步骤一:先向主库插入一条测试数据,代码如下
------我们前面做了主从切换,28010不是 主,28012才是主,搞清楚实验环境
[root@dota ~]# /usr/local/mongodb/bin/mongo --port 28012
MongoDB shell version: 2.0.4
connecting to: 127.0.0.1:28012/test
PRIMARY> db
test
PRIMARY> db.c1.insert({age:30})
PRIMARY> db.c1.find()
{ "_id" : ObjectId("53d1ed7cb017538f84368f95
步骤二:在从库中执行查询操作,代码如下
------切换到从库
[root@dota ~]# /usr/local/mongodb/bin/mongo --port 28011
connecting to: 127.0.0.1:28011/test
SECONDARY> show dbs
admin
local
test
SECONDARY> db
test
SECONDARY> show collections
Fri Jul 25 13:40:36 uncaught exception: error: { "$err" : "not master and slaveok=false", "code" : 13435 }
步骤三,使从库可以读,以分担主库的压力,代码如下
SECONDARY> db.getMongo().setSlaveOk()
not master and slaveok=false
SECONDARY> show dbs
admin
local
test
SECONDARY> show collections
c1
system.indexes
SECONDARY> db.c1.find()
{ "_id" : ObjectId("53d1ed7cb017538f84368f95
SECONDARY>
故障转移
将主库的端口28012的mongodb进程杀掉,在看看复制集的状态
步骤一:杀掉28012端口的mongodb进程,代码如下
[root@dota ~]# ps aux | grep mongod
root
root
root
root
root
[root@dota ~]# kill -9 27967
[root@dota ~]#
步骤2,查看复制集状态,代码如下:
[root@dota ~]# /usr/local/mongodb/bin/mongo --port 28011
MongoDB shell version: 2.0.4
connecting to: 127.0.0.1:28011/test
SECONDARY> rs.status()
{
}
SECONDARY>
上面们可以看到,通过执行rs.status命令查看复制集状态,28012端口mongodb出现异常,状态信息是not reaschable/healthy,说明他已经是一个无效的复制集成员,而系统经过自动选举之后,选举28010端口作为主库,28011端口任然为从库,则有的故障处理机制,能将系统的稳定性和连续性大大提高,解决了藏剑的单点故障问题。
免责声明:
① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。
② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341