启动HBase后遇到的一个问题-Mongo服务器集群配置学习一—...-Mongo服务器集群配置学习二——副本集

当前位置: 数据库>nosql

本页文章导读:

▪启动HBase后遇到的一个问题　　有好几次，启动Hadoop和HBase之后，执行jps命令，已经看到有HMaster的进程，　　但是进入到HBase的shell，执行一个命令，会出现下面的错误：ERROR: org.apache.hadoop.hbase.MasterNotRunningException: Retried.........

▪Mongo服务器集群配置学习一——主从复制主从复制是MongoDB最常用也是最简单的复制操作。常用于数据备份和故障修复等。下面这个图就是最简单的主从复制的服务器架构我将以实验的方式来实现MongoDB的主从复制实验环境：w.........

▪Mongo服务器集群配置学习二——副本集所谓副本集就是有自动故障恢复功能的主从集群，学习一中的主从复制和副本集最大的区别就是：副本集没有固定的“主节点”，整个集群结构会动态选举出一个“主节点”，当.........

[1]启动HBase后遇到的一个问题

来源: 发布时间: 2013-10-18

　　有好几次，启动Hadoop和HBase之后，执行jps命令，已经看到有HMaster的进程，

　　但是进入到HBase的shell，执行一个命令，会出现下面的错误：

ERROR: org.apache.hadoop.hbase.MasterNotRunningException: Retried 7 times

　　进入到logs目录查看master的日志：发现一直显示下面的内容：

2013-04-13 17:13:17,374 INFO org.apache.hadoop.hbase.util.FSUtils: Waiting for dfs to exit safe mode...2013-04-13 17:13:27,377 INFO org.apache.hadoop.hbase.util.FSUtils: Waiting for dfs to exit safe mode...2013-04-13 17:13:37,386 INFO org.apache.hadoop.hbase.util.FSUtils: Waiting for dfs to exit safe mode...2013-04-13 17:13:47,393 INFO org.apache.hadoop.hbase.util.FSUtils: Waiting for dfs to exit safe mode...2013-04-13 17:13:57,395 INFO org.apache.hadoop.hbase.util.FSUtils: Waiting for dfs to exit safe mode...2013-04-13 17:14:07,409 INFO org.apache.hadoop.hbase.util.FSUtils: Waiting for dfs to exit safe mode...

　　原来是Hadoop在刚启动的时候，还处在安全模式造成的。

[coder@h1 hadoop-0.20.2]$ bin/hadoop dfsadmin -safemode getSafe mode is ON[coder@h1 hadoop-0.20.2]$

　　可等Hadoop退出安全模式后再执行HBase命令，或者手动退出Hadoop的安全模式

[coder@h1 hadoop-0.20.2]$ bin/hadoop dfsadmin -safemode leaveSafe mode is OFF[coder@h1 hadoop-0.20.2]$

　　现在再执行HBase的命令就没有问题了：

[coder@h1 hbase-0.90.5]$ bin/hbase shellHBase Shell; enter 'help<RETURN>' for list of supported commands.Type "exit<RETURN>" to leave the HBase ShellVersion 0.90.5, r1212209, Fri Dec  9 05:40:36 UTC 2011hbase(main):001:0> listTABLE                                                                                                                          student                                                                                                                        user                                                                                                                           2 row(s) in 0.7530 secondshbase(main):002:0>

本文链接

[2]Mongo服务器集群配置学习一——主从复制

来源: 发布时间: 2013-10-18

主从复制是MongoDB最常用也是最简单的复制操作。常用于数据备份和故障修复等。

下面这个图就是最简单的主从复制的服务器架构

我将以实验的方式来实现MongoDB的主从复制

实验环境：windows操作系统（一台机器启动多个MongoDB数据库），MongoDB 2.4

说明：

1.MongoDB以配置文件的形式启动

2.以执行保存的bat文件代替每次输入CMD中输入命令

步骤：

1.配置主节点并启动，端口为10001，下图为配置的文件结构

其中config.cnf的内容为

dbpath=D:\mongodb\test\copy\10001\Data
bind_ip=127.0.0.1
port=10001
master=true

用startup.bat启动主节点：mongod -f config.cnf

用shell.bat启动shell：mongo 127.0.0.1:10001

其中master参数为true说明这台是主节点

2.配置从数据库，端口为10002

config.cnf的内容为

dbpath=D:\mongodb\test\copy\10002\Data
bind_ip=127.0.0.1
port=10002
slave=true
source=127.0.0.1:10001

用startup.bat启动从节点：mongod -f config.cnf

用shell.bat启动shell：mongo 127.0.0.1:10002

slave参数设置从节点，source从数据库对应的主节点的地址

3.下面就来做下验证，在10001主节点上的person数据库添加集合baseinfo，并添加一条文档

这个时候再来10002从节点查询，就可以看到这条同样的数据已经复制过来了。

4.其他参数

--only 从节点配置，只复制特定某个数据库

--autoresync 从节点配置，如果主节点与从节点数据不同，则自动重新同步。配置这个节点可以给运行了一段时间的主节点加上一个新节点，则这个新节点会把之前的主节点数据全部同步过来，而不是从现在这个时间同步。

--slavedelay 从节点配置，从数据库延迟同步主数据库的时间

--fastsync 从节点配置，以主节点的数据库快照启动从节点，可以加快启动速度。

--oplogsize 主节点配置，主节点oplog大小，主节点会把数据库操作的日志写在oplog中，从节点参考oplog做复制操作，可以根据自身情况调节日志大小。如果不指定oplogsize大小，mongod将指配5%的可用磁盘空间给他，32位机最小是50M，64位机最小是1G。

动态添加删除主从节点

先看看从节点的对于主节点的配置在哪，在从节点的local数据库的sources集合中，查看信息如下：

现在再启动一台普通的节点，不设置任何主从，端口设为10003

dbpath=D:\mongodb\test\copy\10003\Data
bind_ip=127.0.0.1
port=10003
slave=true

启动后，动态的把10003加入到主从架构中，形成如下的结构

在10003的shell中执行下面脚本即可。

use local

db.sources.insert({"host":"127.0.0.1:10001"})

这样10003就作为10001的从节点了

删除主从关系就用db.sources.remove({"host":"127.0.0.1:10001"})

主节点往从节点转移

永久的转移一个损坏的和不可用的主节点A到从节点B，有以下步骤：

1.关闭A节点

2.停止B节点的Mongod

3.对B节点的dbpath目录下的文件进行备份和移动

注：删除local.*是不可撤销的。执行此步骤非常谨慎。

4.在B节点上用--master参数重启Mongod

调换主节点和从节点

有一个主节点A和一个从节点B，如果想调换他们的角色，请按下面的步骤，这里假设A是健康的，可更新的可用的

如果A是不是健康的，但硬件是好的（停电，服务器崩溃等），跳过步骤1和2，并在第8步用B的文件取代所有的文件。

如果A是不是健康的，硬件是不好的，将A替换为一台新机器。可以按照上段中的说明。

1.暂停在A上使用fsync命令

2.确定B是在同步节点A

3.关闭B节点

4.从B的DBPATH目录备份和移动的所有数据文件，并删除现有的数据local.sources。

5.用master选项启动B

6.往B中写入数据，用oplog设置新的同步开始时间点

7.关闭B，当重启时B就有新的一组本地数据

8.关闭A，用备份B的dbpath目录文件复制到A的dbpath中

9.用master选项启动B

10.用通常slave选项启动A，但要包括fastsync参数

本文链接

[3]Mongo服务器集群配置学习二——副本集

来源: 发布时间: 2013-10-18

所谓副本集就是有自动故障恢复功能的主从集群，学习一中的主从复制和副本集最大的区别就是：副本集没有固定的“主节点”，整个集群结构会动态选举出一个“主节点”，当其坏掉，则会动态变更到其他节点，而主从复制又要人为的去切换。副本集的节点称为活跃节点和备份节点。

想配置如下图的副本集集群，很简单一个活跃节点，一个备份节点，当然由于活跃节点是动态推选出来的，不能指定，配置完之后可以看看哪台是活跃点，我希望是A。

对于副本集，需要指定一个副本集的名称，本例为replicademo，用来确定该名称的副本集集群都有哪些主机

下面对A和B进行配置，配置文件如下

A：

dbpath=D:\mongodb\test\replicaSet\A\Data
bind_ip=127.0.0.1
port=11111
replSet=replicademo/127.0.0.1:22222

B：

dbpath=D:\mongodb\test\replicaSet\B\Data
bind_ip=127.0.0.1
port=22222
replSet=replicademo/127.0.0.1:11111

replSet参数为“副本集名称”/主机地址：端口号，注意“/”必须要有

然后分别启动A和B

随便在其中一台节点上进行副本集初始化配置，首先切换到admin库，并执行下面脚本

db.runCommand({"replSetInitiate":
    {
        "_id":'replicademo',
        "members":[
               {
                "_id":1,
                "host":"127.0.0.1:11111"
               },
               {
                "_id":2,
                "host":"127.0.0.1:22222"
               }
        ]
    }
})

脚本中各字段代表的含义是

1. “_id” ： “replicademo”，这个键指明了副本集的名称

2. “members” ：[...]，这个键指明服务器列表，我们以后还可以往副本集中加入服务器

3. “_id” : N，内嵌文档的键，用于唯一标示副本集中的某一台服务器

4. “host”：host address，指明服务器的主机和端口号

这样我们再来看A和B两台的shell

B：

由此看来A这台是活跃节点，在活跃节点上进行状态查询

rs.status()

展示如下图信息

可以清楚的看到副本集集群中各节点的状态。

状态查询之所以要在动态节点上进行，是因为备份节点默认不支持查询操作，可以做下面的实验。在A上插入数据，并可以在A查到

replicademo:PRIMARY> use person
switched to db person
replicademo:PRIMARY> db.person.info.insert({name:"tom"})
replicademo:PRIMARY> db.person.info.find()
{ "_id" : ObjectId("516a629b91dee924cc38e01a"), "name" : "tom" }

在备份节点上进行这条数据的查询，很显然报错了。

默认情况下SECONDARY不能读写，如果想进行读取操作，可以执行rs.slaveOk()，就可以从SECONDARY读取了。

replSet里只能有一个Primary库，只能从Primary写数据，不能向SECONDARY写数据

replicademo:SECONDARY> use person
switched to db person
replicademo:SECONDARY> db.person.info.find()
error: { "$err" : "not master and slaveOk=false", "code" : 13435 }

副本集故障切换

当A不能工作了，会发生什么情况，我先把A关掉，A和B的shell也关闭，再重新启动B的shell。会发现B并没有变成活跃节点，仍然是备份节点。

原因如下：当SECONDARY Down掉,剩下一个PRIMARY,此时副本集运行不会出问题,因为不用选择PRIMARY节点，当PRIMARY Down掉,此时副本集只剩下一个SECONDARY,它只有1票,不超过总节点数的半数,它不会选举自己为PRIMARY节点。

所以副本集中只有2台备份服务器是不合理的。

添加删除节点

上面的情况已经看到只有2个备份节点是不合理的，解决方案是要不就再加一台备份节点，使得投票能正常选出活跃节点，另一种方法是增加仲裁节点。

先说下副本集中有3中节点：

standard：常规节点，也就是我上个例子中用到的A和B都是常规节点，它既存储完整的数据副本又参加投票，可以成为活跃节点

passive：副本节点，它虽存储完整的数据副本又参加投票，但是不可以成为活跃节点

arbiter：仲裁节点，只参与投票，不接受数据的复制，不可以成为活跃节点

1.副本集replicademo中添加一个常规节点

启动另一台节点服务器C

dbpath=D:\mongodb\test\replicaSet\C\Data

bind_ip=127.0.0.1
port=33333
replSet=replicademo/127.0.0.1:11111,127.0.0.1:22222

在活跃节点上执行rs.add("127.0.0.1:33333")

执行完成之后查询配置如下，可以看到C已经加入到副本集。

如果要删除某一个节点可以执行rs.remove("主机名:端口号")

执行之后查看配置，发现节点已经被删除

2.副本集replicademo中添加一个仲裁节点

在活跃节点上执行rs.add("127.0.0.1:33333",true)

此时在查询状态，如下图，节点C的stateStr="ARBITER",已经变为仲裁节点。

本文链接