hypertable使用问题

苦逼了4，5天，稍微总结一下。

环境：

机器：5台 OS: redhat 5.4

内存：12G   磁盘：1 / 2T CPU:2*4( Intel(R) Xeon(R) CPU           E5504  @ 2.00GHz)

1：ssh的默认端口不是22

hadoop 可以通过配置vi /etc/profile 和 vi /opt/hadoop/etc/hadoop/hadoop-env.sh（export HADOOP_SSH_OPTS="-p 9922"）来解决，但是hp不行，尝试过修改Capfile，但是还是有很多问题。因此直接配置同时支持22和9922。（最后修改ssh client的默认端口解决了）

2. 官方的hadoop兼容性尝试

失败，，，dfsbroker启动失败，成功后又提示缺callid和status，应该是兼容性问题。

后面直接使用cdh4，配置用原来配置hadoop配置，启动成功

3. 日志满问题

在进行压测的时候master的日志增长非常快，导致磁盘满，master挂掉，导致其它的agent dfsborker或者thriftboker失败，当时还以为是代码写出问题，浪费了不少时间。

修改了log和data的目录。同时修改了hyperspace目录。

4. 配置问题

文件路径配置在cfg中，不能用引号来引用目录，，，否则莫名其妙问题（就hyperspace影响到了？）

5. hyperspace的元数据错误

导致hp master启动失败，报无法找到sys/master

关闭出错的hyperspace机器（启动成功，但是尝试去连接hyperspace leader的52346端口）启动master成功

从最新的hyperspace上拷贝数据，Replication完成后启动成功。

6. namenode无法进入active状态

a. zookeeper挂了

b. 进入了safemode

      命令行退出 hadoop dfsadmin -safemode leave

      修改配置：dfs.safemode.threshold.pct 0.5

c. 换了namenode,将name数据拷贝到新的机器，但是发现无法进入active

尝试：

I. /home1/hadoop/app/hadoop-2.2.0/bin/hdfs haadmin -failover --forceactive ns1n1 ns1n2
#forcefence and forceactive flags not supported with auto-failover enabled.
 II. /home1/hadoop/app/hadoop-2.2.0/bin/hdfs haadmin -failover ns1n1 ns1n2
/home1/hadoop/app/hadoop-2.2.0/bin/hdfs dfsadmin -safemode leave
还是不行

III. hdfs zkfc -formatZK
OK了。原因是fence里边登记的是老的nameno歇息信息

7. namenode无法启动

从整场的namenode拷贝name数据，重新启动成功

8. 磁盘满的情况下，会导致莫名错误，比如metalog写入hdfs失败

从本地恢复：

1. Stop Hypertable

2. log into the master machine

3. Remove the zero-lengthed MML file:

hadoop fs -rm /hypertable/servers/master/ log/mml/3

4. Copy the backup MML file in its place:

hadoop fs -copyFromLocal /opt/hypertable/current/run/log_backup/mml/master_38050/3 /hypertable/servers/master/log/mml/

5. Restart Hypertable

9. 其它不完整错误忽略配置
Hypertable.CommitLog.SkipErrors=true
Hypertable.MetaLog.SkipErrors=true

10.内存限制

Hypertable.RangeServer.MemoryLimit.Percentage=90

sysctl -w vm.swappiness=0

11. Hypertable.Failover.Quorum.Percentage
当系统中剩余的rangeserver达不到percentage里边的值，rangserver recover会失败，（这里的数据会暂时无法访问，知道对应的rsxx启动成功)。
中断后重启后失败，因为响应的rsxx已经标志删除，必须手工的删除 data/run/location重新启动。如果此时其他机器也还没启动，它先启动就可能占用其他机器的rsname，导致出现更多问题。

       A. hyperspace的异常切换，hyperspace有多太replicas,初次启动时，自动选举出一个master，其它的作为从机备份master的数据，但是master挂掉无法自动切换，整个集群将space过期，全部关闭（两个条件，机器挂掉，挂掉的刚好是Master space）。实际使用中，发生刚好Master失效的话，需要修改配置，把刚好的Master机器从配置中拿开启动集群。
     B. hyperMaster的HA切换，发生问题时备用的Master将启动监听38050自动接管Master角色。
     C. hyperRangerServer的Failover， 跟Hypertable.Failover.Quorum.Percentage配置有关，默认90。Hypertable.Failover.GracePeriod默认30秒，30秒不跟Master发生通讯将开始执行RangeServer的Failover流程。
        I. 如果存活的机器少于90%,将不会进行改rangeserver的数据转移，对应的失败服务器range范围内的读写将失败。 机器启动后这些key range的操作将正常。
        II. 如果存活的机器大于Percentage，将对失败的RangeServer中的数据进行接管，中间操作RangeServer Key Range返回内的数据仍然部分失败，但是接管完毕后一切工作正常。失效的RangeServer恢复启动后将启动失败，因为已经在集群中标志其已经被删除了，需要手工的删除其ID文件，重新启动进程，让系统重新分配名字给它。

12, 特性探索n
不支持纯mem无盘的表，但是可以要求表或者某些列数据全部加载在内存。
支持某字段的ttl或者表的ttl，但是这些都是表的元数据，不能针对某条记录进行优化。
对default的key增加了boomfilter特性。

总结很多时候master的启动失败一般跟hyperspace或者dfsbroker有关。

而dfsbroker一般跟namenode有关。

13. Master主备切换

两台都在线主备切换没问题，38050端口起来了代表切换成功了。
但是如果主Space（配置中的第一台）的38040没起来，其它space,master,rangeserver刚好挂掉，就启动不了了。需要修改配置文件（space要保证3台，否则会发生死锁）。

14. 3个Datanode，挂掉一个后出现的问题

A. 无法写入；默认在写操作时，如果需要写3个replica它会在pipeline中写3个机器，因为一台挂了，默认replace-datanode-on-failure.policy是DEFAULT,只有系统中的datanode大于等于3，它会找另外一个datanode来拷贝。目前机器只有两台，因此一直无法成功。

<property>
  <name>dfs.client.block.write.replace-datanode-on-failure.enable</name>
  <value>false</value>
</property>
<property>
  <name>dfs.client.block.write.replace-datanode-on-failure.policy</name>
  <value>NEVER</value>
</property>
B. Number of Under-Replicated Blocks,一直COPY不过去

修改拷贝的带宽1M=>100M, 2=>5,还是没有改善

<property>
  <name>dfs.balance.bandwidthPerSec</name>
  <value>104857600</value>
</property>
<property>
  <name>dfs.max-repl-streams</name>
  <value>5</value>
</property>

修改hdfs dfs -setrep 1 /,将多份成一份， Under copy为0，但是修改回来，还是Under COPY却没动静。

最后没有办法hdfs fsck /找出所有的块，拷贝到本地，然后删除，然后更新回线上，解决

原因分析：如果文件备用，你修改setrep没有用，（但是我们实际修改replic从3到2时已经重启过集群，所以这个有点不适用我们的情况）

C. hypertable配置修改

RangerServer failover时，一直狂报（真的很狂）:

1388052052 ERROR Hypertable.Master : (/root/src/hypertable/src/cc/Hypertable/Master/OperationRecoverRanges.cc:547) phantom commit at rs1 failed - DFS BROKER i/o error (Error appending 0 bytes to DFS fd 144052)

修复Hypertable.Failover.Quorum.Percentage=30 （60=》30,之前3变2，以为60就可以，发现必须改成30才可以 ）