hbase 跨机房热切换实战总结
前一阶段，艰苦卓绝的机房搬迁终于结束了。趁着今天因病在家休息，写一个总结吧。
?
最关键的一个业务是一个实时读写的系统。读写比是1：4。 最后和业务方谈下来，可以允许短时间的停写（4~6小时），不能停止读业务。
?
凌晨的请求量很低，负载较轻。
?
方案PK
?
1. 改造业务方，改成同时双写。 同时向新旧两个机房写数据。这个方法自然很好。但是由于机房交付的问题，交给我们搬迁的时间太紧张了。业务方没有能力在这么短的时间内改造成双写模式。
?
2. 搭建新的集群，在切换当天将数据distcp过去，然后用hbase 自带的add_table.rb的工具拉起。这个方案，需要在拷贝期间停止表的写入。我们采用了这个方案。
?
问题：
?
切换过程中，需要哪些操作？
?
?因为客户端的zookeeper配置成域名，所以，理论上只需要将域名映射关系修改即可，将域名指向新机房的IP。
?
之后呢？?
?
因为客户端之前是直接和regionserver联系的。所以，即使zookeeper域名切换过去之后，只要不断开原来的connection，客户端依然连接旧的集群。
?
所以，想当然的办法自然是关闭旧的连接。
?
有两种办法：
?
1. 关闭旧的HBase集群。让client端connection中断，这样，client 重试时会通过zookeeper建立新的connection。因为zookeeper的地址变化了，新的connection就会到新的集群。
?
2. 重启客户端。
?
第一种方法貌似很诱人。但是却存在着几个问题。
?
1. 客户端缓存的更新时间较长。因为客户端存在着regionserver的缓存，所以他总是会出错重连，整个缓存完全更新的时间却会变得漫长。也会增加前段的出错量
?
2. 这个原因是致命的，以至于我们放弃了这个方案。因为https://issues.apache.org/jira/browse/HBASE-4893 ，也就是说，在hbase 0.90.6之前的客户端，都会复用哪些被close的connection。 导致根本不能切换到新的机房，而是不断的抛错?
?
?
所以，我们采用了重启客户端的办法。因为业务方有200台客户端机器。重启其中的一台不会影响读。
?
?
?
distcp 拷贝的时候，需要注意
?
1. 提前做好qos，因为该过程会占满带宽，必须保证其他业务不受影响
?
2. map可以多开几个。在做好qos的前提下，加快拷贝的速度。
?
问题
?
1. 内存中的数据怎么办？
?
主动flush到磁盘中。该过程的漫长出乎我们的意料。flush一个2T的表，用了半个小时。hbase 这块的性能真是弱爆了。
?
?
2. distcp本质是hdfs层的拷贝，对于一个实时写的系统，如何保证distcp过程中数据文件不发生变化？
?
1. 关闭自动split。 我们在2天前就关闭了split。保证拷贝过程不会出现split现象。
2. 关闭major compaction。 major compaction也改成手动触发。
?
此外，scan每个region的storefile个数和大小。保证都不到触发minor compaction的条件。
?
?
此外，在拷贝之前，可以调用下metacheck.jsp这个工具。开发提供的这个工具，可以检测哪些哪些残留在hdfs上的无用的region信息。将他放在master 机器${hbase-home}/hbase-webapps/master下面，访问就可以。
?
?
?
?
?
?
1 楼 youjianbo_han_87 2012-05-29 楼主都搞病了，辛苦啊。。。。 2 楼 wshyj18 2012-05-29 是不是因为机房的空调太冷了 3 楼 杨俊华 2012-06-05 wshyj18 写道 是不是因为机房的空调太冷了