上一篇介绍了GBASE 8a 的技术特点，本篇主要介绍其安装及使用。
首先这个安装需求就有点蛋疼，
同一网段？大规模的集群系统还真是没见过有这种要求的，同一网段应该还是出于进行机器间广播通信的考虑？但是要求同一网段就事实上限制了集群的规模，对集群的扩展和维护造成麻烦。
同样的操作系统？？这个和集群有何关系？应该是要求集群上各台机器应用程序版本一致吧。如果安装包和操作系统版本相关，应提示用户根据系统版本选择不同的安装包，更妥当的是安装程序根据操作系统版本自动选择。
各台机器的root密码一致，这个更晕，如果是使用动态密码等的肿么办，业界上也只是要求各个用户配好机器间信任，做好无密码互访即可，貌似是出于方便用户的考虑，提供root密码就可以自动安装，但是实际部署中还是会遇到问题。
要求各节点关闭防火墙？？与其这样不如公布需要开放的端口，关闭防火墙是对企业安全策略的彻底挑战，如此设计其实也体现了对数据安全问题的不重视。
要求节点上不存在gbase用户？？程序还绑定用户名，不允许自定义安装用户？？程序里面写死了？但是其实在后面的安装步骤中，gbase的用户又是可配置的，文档又出现不一致。
上面这些问题看着都不大，但是魔鬼总在细节中，这些细节就体现了产品的开发风格，而且现在总写文档是低级的事情，都是让初级人员写，但是注意细节也是实力的体现。
安装很简单，设置好配置文件，我打算安装在3台机器上。
[root@RHELDN1 gcinstall]# cat demo.options
authkey_file_name = authkey.demo
gcluster_dba_group = gbase
gcluster_dba_user = gbase
gcluster_dba_user_password = gbase
hosts = 172.16.130.227,172.16.130.223,172.16.130.231
mcast_addr = 226.94.1.99
mcast_port = 5479
root_password = root123
source = 172.16.130.227
skip_network_test = true
然后执行 ./gcinstall.py –silent=demo.options 就开始安装了。过程很简单，等着就好。
安装完后发现配置系统内核参数的/etc/sysctl.conf 被整个替换了，我原先的内核参数配置全没了，这个真是有点狂汗。重要的系统内核参数必须让用户来修改，用户的是生产系统，而且很可能是与其他服务共用的服务器。如果内核参数不满足需求可以提示用户修改，整个文件用安装包中的无声无息覆盖的做法这个就有点过度了。而且文档中或者安装过程中没有任何的说明或者警告，要不是我看见了，就要等到其他应用莫名报错才知道了。
节点安装完毕后，下一步是建立safegroup，因为安全组之内的服务器为主备，所以我打算3个节点，分成3个安全组。这样比较能发挥出性能的优势。
gcadmin addsg –nodes 172.16.130.227 –names node1
gcadmin addsg –nodes 172.16.130.231 –names node2
gcadmin addsg –nodes 172.16.130.223 –names node3
ok，3个节点，3个safegourp，服务一切正常，现在可以开始使用数据库啦。
使用gbase用户，执行一下命令就可以登录到数据库
/opt/gcluster/server/bin/gbase -ugbase -pgbase20110531 -h127.0.0.1 -P5258
文档中特地注明，用户名固定为gbase，密码固定为gbase20110531，在安装的时候不让人设置用户名和密码就算了，居然连密码都不让改，头一次见。翻遍文档也没看见改密码说明，这是赤裸裸的数据不设防啊。数据安全如何保证？？
界面看着很眼熟？没错，这就是mysql的界面，只是mysql替换成gbase了，再看看下面两张图，熟悉mysql的同志一看就明白哈。
言归正传，不管gbase与mysql渊源如何，还是回到我们测试上，下一步是建立用户自己的database pocdb，并建立一张分布表，先熟悉下操作。
gbase> create database pocdb;
Query OK, 0 rows affected (Elapsed: 00:00:00.18)
gbase> use pocdb;
Query OK, 0 rows affected (Elapsed: 00:00:00.01)
gbase> CREATE TABLE hive_test (id int, name varchar(200)) DISTRIBUTED BY(‘id’);
Query OK, 0 rows affected (Elapsed: 00:00:00.16)
gbase> exit
Bye
下面准备利用自带的工具进行文本入库，按照文档要去建立了配置文件
[test_t]
disp_server=172.16.130.227:6666
file_list=/home/gbase/part-m-00000
format=0
node_list=node1,node2,node3
disp_type=1
hash=CRC32
hash_column=0
db_user=gbase
db_name=demodb
table_name=hive_test
delimiter=’\001′
socket=/tmp/gbase_8a_5050.sock
extra_loader_args=–parallel=3
我最近在做hadoop测试的时候生成了一个文本，刚好拿来做测试，字段的分隔符是hive的默认分隔符\001 也就是ctrl+A那个符号。在加载前需要先启动分发服务器
./dispserver –log-file=/root/gb8a/dispatch_server.log –port=6666
这个又有个蛋疼的地方，端口不可修改。。。软件的一切设置都需要配置化，这个不是很基本的要求么？动不动就写死的做法是在不可取。
[gbase@RHELDN1 ~]$ ./dispcli t.tpl
[2012-09-26 14:33:36] ERROR: “disp_type” is NOT a valid argument! (/home/gbase/dispserver/dispcli/dispcli_app.cpp:114)
刚一执行就报错，我很确信我没写错，我是copy过来的。。
#分发类型：0 为复制；1 为分布
disp_type=1 #
这个有点囧，既然报不认识自家参数，那我就注释掉这个好了。注释后继续执行。。
[gbase@RHELDN1 ~]$ ./dispcli t.tpl
Start mission [test_t] in dispatch mode…
[172.16.130.223] [START TIME: 1970-01-01 7:0:0] [100.00%] [RATE: 0.00/s] [ERROR] [BAD REC: 0] [ETA: 0 sec] [ELAPSED: 15609 days 6 hours 38 min 6 secs]
[172.16.130.227] [START TIME: 1970-01-01 7:0:0] [100.00%] [RATE: 0.00/s] [ERROR] [BAD REC: 0] [ETA: 0 sec] [ELAPSED: 15609 days 6 hours 38 min 6 secs]base/disp
[172.16.130.231] [START TIME: 1970-01-01 7:0:0] [100.00%] [RATE: 0.00/s] [ERROR] [BAD REC: 0] [ETA: 0 sec] [ELAPSED: 15609 days 6 hours 38 min 6 secs]
[gbase@RHELDN1 ~]$ echo $?
0
两G多的文件，不到5秒钟就完了，而且这个提示，看看开始时间，和耗时。。。瀑布汗啊，中间闪过一个提示说出错了，需要看gbloader的日志，日志在哪？？？路径也没提示，而且程序退出的时候连那个出错提示都没了？屏幕上的那日期是怎么回事，而且程序报错了程序的返回码还是0？这让作业调度程序情何以堪。去数据库看了看，果然，文件没有加载进去。
哪报错了，为什么，完全没头绪，当前文件下是空的，没有任何日志文件，/var/log下面也没有，后来在/tmp下找到一个日志文件dispcli.log，
2012-09-26 14:38:02 INFO: DONE (/home/gbase/dispserver/dispcli/loader_agent.cpp:252) 2012-09-26 14:38:03 Sending 37 : get_progress dispatch_id=8 vfile_id=0 (/home/gbase/dispserver/dispcli/disp_server_agent.cpp:556)
2012-09-26 14:38:03 Received 4 : +OK (/home/gbase/dispserver/dispcli/disp_server_agent.cpp:603)
2012-09-26 14:38:04 Sending 37 : get_progress dispatch_id=8 vfile_id=0 (/home/gbase/dispserver/dispcli/disp_server_agent.cpp:556)
2012-09-26 14:38:04 Received 4 : +OK (/home/gbase/dispserver/dispcli/disp_server_agent.cpp:603) 2012-09-26 14:38:04 We read from 172.16.130.227 [STDERR]: (/home/gbase/dispserver/dispcli/loader_agent.cpp:347)
2012-09-26 14:38:04 Parameter error. Delimiter input error. (/home/gbase/dispserver/dispcli/loader_agent.cpp:348)
我截取了日志文件中的一段，这个日志应该是给开发人员调试看的，完全不像一个产品面向用户的日志。里面都是一些对终端用户毫无价值的东西。终于从其中的（Parameter error. Delimiter input error. ）看出点门道，应该是分隔符的问题，估计是不支持ctrl+a这种特殊字符转义。把文本改成逗号分隔，修改配置文件后重新开始。
[gbase@RHELDN1 ~]$ ./dispcli t.tpl
Start mission [test_t] in dispatch mode…
[172.16.130.223] [START TIME: 2012-09-26 14:52:34] [N/A] [RATE: 1.83M/s] [LOADING] [BAD REC: 0] [ETA: N/A] [ELAPSED: 45 secs]
[172.16.130.227] [START TIME: 2012-09-26 14:52:34] [N/A] [RATE: 4.13M/s] [LOADING] [BAD REC: 0] [ETA: N/A] [ELAPSED: 45 secs]
[172.16.130.231] [START TIME: 2012-09-26 14:52:34] [N/A] [RATE: 2.34M/s] [LOADING] [BAD REC: 0] [ETA: N/A] [ELAPSED: 45 secs]
[gbase@RHELDN1 ~]$ ./dispcli t.tpl
[2012-09-26 14:53:50] ERROR: Can’t start load while anchor offline. (/home/gbase/dispserver/dispcli/dispcli_app.cpp:341)
开始加载以后我发现拷过来的数据文件不完整，ctrl+c中断，而后继续执行，然后发现运行不了了，出错的错误完全看不懂。。。。日志不光是给开发人员看的，一个运维友好的日志会同时写出问题可能的原因和简要处理方法。尝试重启dispatch server ，还是不行。用gcadmin看看服务器状态，有点晕，怎么宕机了一台
我在node1上按了下ctrl+c把node3的服务搞挂了？去223上面找日志看看。没找到原因，corosync的进程没了，日志里面没有任何记录。不琢磨了，先手工重启223上面的服务吧。重启后正常了。
2.6G的文件，5分多加载完毕。大约8MB/s。应该说还是没达到预期，文件是存储在227上面，本地节点加载速度不受网络限制，2个外部节点网络占用也才2MB多。但是这个性能不好比较，一个是我们测试机器不太好，网络也是百兆的网络。我用oracle单机sqlldr加载耗时 6m15.485s。也是通过百兆网络加载。
加载完以后到各台服务器/opt/gnode/userdata/gbase/pocdb/sys_tablespace/hive_test_n[1-3]的目录下看。
每台机上大约780MB的数据，3台机加起来就有2.3G，相对与我2.6G的文件大小，压缩比不算高，oracle未压缩的表存储用了2.4G，两者相差不大，几乎相当于没压缩？？
再用greenplum试试，greenplum只有两个节点，对比下有点不太公平。greenplum也使用列式存储并开启压缩。
gpfdist -d /home/gpadmin -p 8081 >> gpfdist.log 2>&1 &
CREATE EXTERNAL TABLE ext_hive_test ( id int, name varchar ) LOCATION (‘gpfdist://172.16.130.226:8081/*.txt’) FORMAT ‘TEXT’ (DELIMITER ‘,’) ;
CREATE TABLE hive_test (id int, name varchar )with (appendonly=true,orientation=row,compresstype=quicklz,COMPRESSLEVEL=1) DISTRIBUTED BY (id);
insert into hive_test select * from ext_hive_test;
耗时6分42秒数据加载完成。
做了下简单的测试，hive_test 是124,113,600行的数据,执行dc已经预先计算好（count,sum,avg,isnull,max,min)的操作时非常快。都在零点几秒就能返回结果。这个就不和oracle比了，绝对秒杀oracle。
尝试一下group by的性能
gbase> create table hive_t1 as select id,count(id) cnt from hive_test group by id;
ERROR 1707 (HY000): GCluster DML&DDL proxy error: gcluster DML error: EXECUTE FAILED [127.0.0.1:5258], I/O operation on ./pocdb/metadata/hive_t1.GED/table.des failed with error – No space left on device File name ./pocdb/metadata/hive_t1.GED/table.des
报错了，磁盘空间满，上面写着是127.0.0.1 也就是本机，可是df查看以后本机磁盘空间完全没问题，只好每台机找过去，原来是223那台机满了，错误提示里面写出具体主机名这个应该不难吧？？这要是机器多了，真要每台机器找过去？？清理完空间，继续。。
gbase> drop table hive_t1; Query OK, 0 rows affected (Elapsed: 00:00:00.26)
gbase> create table hive_t1 as select id,count(id) cnt from hive_test group by id; ERROR 1707 (HY000): GCluster DML&DDL proxy error: gcluster DML error: EXECUTE FAILED [127.0.0.1:5258], NODE(HOST(172.16.130.223:5050), USER(root), DB(pocdb)):[GNODE(172.16.130.223:5050) execute error: Can’t execute the given command because you have active locked tables or an active transaction]
又是错误。。退出gbase客户端，重新登录就又好了。
gbase> create table hive_t1 as select id,count(id) cnt from hive_test group by id;
Query OK, 124113600 rows affected (Elapsed: 00:01:54.84)
奇怪的是我在oracle上执行同样操作只花了57秒？？当然我这个只是熟悉操作的例子，有点特例，数据只有两个字段，但是我只用了其中一个字段，按理gbase读取的数据量只有oracle的一半，两台机配置其实是大致相同的。测试的想起来，直接和oracle比有点不公平，gbase上数据是压缩的，而我oracle上没压缩，于是我启用的oracle上的表压缩。发现表只占了1.7G的空间？？上文提到了GBASE是占了2.3G，是gbase的压缩没生效？？还是3个节点上的780MB其实就是完整数据了？不需要乘以3 。那就可以理解，但是如果单节点上的就是完整副本的话，每个节点上的表的数据文件大小应该是完全一致的，可是实际上并不是。所以我只能理解为gbase的压缩根本就没生效。
将oracle表压缩后，oacle重新执行上文中的group by语句只花了44秒。相对于未压缩前有了13秒的提升，由于瓶颈一般还是在I/O上面。而压缩后数据从2.4G下降到1.7G。oracle的表现很正常。
greenplum 花了6分37秒，这有点让我没想到。当然还是不排除是机器或者配置未经调整的原因，虽然这三个数据库都是默认参数未调整。
对sql的操作的熟悉先简单到这里，具体复杂的案例评测放在下一篇。
GBASE系统介绍中提到safegroup的有个很重要的功能是failover，这也是任何系统必备的功能了。而我目前每个safegroup只有一台机，很明显没办法做这个测试了，上文中也提到，任意一台服务宕机会立刻导致集群不可用。所以打算在新增一台机器，加入到其中一个safegroup中，这样停掉safegroup中的一台机集群应该还是正常服务。
翻手册的时候又郁闷了，只有新增，或者删除整个safegroup，没有往已有的safegroup中新增或者删除节点的命令。删除整个safegroup，再重新创建？手册上又说删除后数据有丢失，重新创建也不一定能找回，那分布表的数据怎么在safegroup删除前转移？手册中无解。。。这个应该是实际运维中的合理需求吧？难道要手工改集群配置文件？？这其实是研发项目的普遍问题，考虑问题的时候理想化，对实际运维考虑不足。
鉴于管理员手册中对此无解，我只好尝试删除掉一个safegroup，而后使用两个node进行重建，数据丢失也不管了，反正我只是在测试，大不了重新加载。
因为没机器，只是临时新建一台虚拟机，做HA的测试，测试完后恢复到每个safegroup单节点运行。
gcadmin removesg sg03
gcadmin addsg –nodes 172.16.130.223,172.16.130.226 –names node3,node4
再用gcadmin看看服务一切正常。不错，没有了恼人的错误，是个良好的开始，
gbase> SELECT count(id) FROM pocdb.hive_test;
+———–+
| count(id) |
+———–+
| 82725725 |
+———–+
1 row in set (Elapsed: 00:00:00.10)
糟糕，数据果然少三分之一，这个验证了两个事情，一是数据确实按照id均匀分布在3个safegroup了，二是重建safegroup的方法是不行地。没关系。咱什么场面没见过，哥重新加载。。重新加载的时候莫名报错，看看gcadmin的状态，有问题，223的datastate变成2了，2是什么意思？不知道。文档中说要执行gcadmin sync 命令进行数据同步，为什么不同步了？不知道。反正就按照文档上同步吧。
执行gcadmin sync 172.16.130.223 进行数据同步，好，继续加载。。还是报错，
说到gcadmin sync 这个命令，要多说一句，在sync的有个步骤是将safegroup上的数据文件用scp 复制到另外一台上，这如果文件上百GB以后，还是很耗时间的，再说有必要全量复制么？其中还有个步骤是将集群状态设为readonly，这个可以理解，使用scp的话不这么来数据无法保持一致，这又对集群可用性造成了影响，所以sync这个功能还是设计的不够优秀。作为生产运维管理员，你敢随便sync么？
[root@rhel231 /]# cat ./home/gbase/hive_test_n2.gbl_report
2012-09-26 22:52:12.926 Reading from the input file error: Resource temporarily unavailable
2012-09-26 22:52:12.948 Error: kill by signal.
2012-09-26 22:52:12.968 Loader error exit: Operation cannot be accomplished in current state
2012-09-26 22:52:12.968 rollback done…
这个报错是啥意思？增加了网络超时时间，还是不管用，我drop掉表，重建试试，如果还不行，我只好重建数据库了。结果重建表以后直接Segmentation fault 了。只好使出大招，重建数据库。
gbase> drop database pocdb;
ERROR 1707 (HY000): GCluster DML&DDL proxy error: gcluster database error: Cluster at risk, more than 2 safegroup the node number is equal to 1,EXECUTE FAILED [172.16.130.227:5258], gcluster database error: EXECUTE FAILED [127.0.0.1:5050], Unknown table ‘hive_test_n1’
gbase> show databases;
+——————–+
| Database |
+——————–+
| information_schema |
| gbase |
| gctmpdb |
| pocdb |
+——————–+
4 rows in set (Elapsed: 00:00:00.00)
gbase> drop database pocdb;
ERROR 1707 (HY000): GCluster DML&DDL proxy error: gcluster database error: Cluster at risk, more than 2 safegroup the node number is equal to 1,EXECUTE FAILED [172.16.130.223:5258], gcluster database error: EXECUTE FAILED [127.0.0.1:5050], Can’t drop database ‘pocdb’; database doesn’t exist
好了。熟悉的错误又来了，也懒得drop database了，直接创建个新的吧。结果新的还是报错，伤不起的测试。。。
注意到日志里面提示
2012-09-26 23:04:17.663 Reading from the input file error: Resource temporarily unavailable
根据经验应该是虚拟机的资源不够所致，我只是测试HA，于是减少了测试数据量，head 一万行出来加载入库。果然就成功了。但是count一下却有九千多万行，应该是之前加载报错的时候没有回滚所致，这个问题在生产上很可能就导致数据重复加载，处理起来就麻烦了。
而后我停掉safegroup3中的一台机223，却登录不上数据库了。
gbase> use pocdb2;
ERROR 1707 (HY000): GCluster DML&DDL proxy error: Can’t connect to GBase server on ‘172.16.130.223’ (115) gbase>
我启动223，关掉226，却又执行sql成功了？？是223作为safegroup的主服务器？所以关掉226没关系，但是不能关223？单独启动223的时候执行sql正常，而后启动226，手工做数据同步，再次关掉223，再次出现同上错误，无法连接数据库。但是已经连接上的绘画还是可以执行一些select操作，但是无法进行ddl，
gbase> create table pocdb2.t3 as select id,count(id) cnt from pocdb2.hive_test group by id;
ERROR 1708 (HY000): gcluster command error: Current operation is denied when the cluster is locked.
gcadmin命令显示集群状态为LOCKED
所以我觉得safegroup的failover还是不够完善，没有起到应有的作用。
本章节告一段落，对数据库的安装配置有了简单认识，下一篇将按照我们日常中实际应用编写测试案列分别在gbase，oracle，greenplum上运行，而后进行TPC-H 以及和datastage的集成测试。
