GBase8a加载数据故障处理

    GBase 8a Cluster数据加载是由数据分发服务器(dispserver)、数据分发客户端(dispcli)和集群节点上的gbloader工具共同完成原始数据文件切分，数据文件下发到各节点然后导入的加载过程。经常出现的故障可能是命令参数错误、网络错误、集群错误等，下面将一一说明。

1．参数错误

(1)任务名称错误

现象：

    加载时出现如下错误：

    ERROR: Duplicated section name: 'xxxxxx'

原因：

    加载控制文件中包含多个相同名称的任务名称（使用中括号括起的[xxxxxx]的为任务名称）时，出现此错误。

对策：

    改变任务名称使其互不相同。

举例说明：

    在加载控制文件中包含两个相同的任务头[test_dwdate],当执行dispcli命令时会报错：

$ cat lst/lineorder.lst

[test_lineorder]

disp_server=192.168.11.214:6666

file_list=/home/gbase/testSpace/data/ssbm/1s/lineorder.tbl

format=3

sg_list=sg01,sg02,sg03

db_name=test

table_name=lineorder

delimiter='|'

socket=/tmp/gbase_8a_5050.sock

extra_loader_args=--parallel=4

$ ./dispcli -t 300 lst/lineorder.lst

[2012-07-17 8:14:4] ERROR: Duplicated section name: 'test_lineorder'

(/home/gbase/dispserver/dispcli/dispcli_app.cpp:112)

(2)gcluster连接参数错误

现象：

    加载时出现如下错误：

    ./dispcli -h192.168.9.234 ~/data/lineorder.lst

    ERROR: Couldn't connect to gcluster : Can't connect to GBaseserver on '192.168.9.234'(113)

原因：

    不能连接到集群，这是由于dispcli -h 参数中给定的目标集群节点IP地址错误造成。

对策：

    给定正确的连接集群参数，连接gcluster 需要用到下面这些参数：

-h, --host Host name or ip address of a gcluster node

-u, --user User name for login to gcluster

-p, --password Password for login to gcluster

-S, --socket Unix socket file to use for connect to gcluster

-P, --port Port number to use for connect to gcluster

    这些参数与gbase 客户端程序完全相同。

(3)disp_server错误

现象：

    加载时出现如下错误：

    加载控制文件lineorder1.lst：

    [ssbm_lineorder]

    disp_server=192.168.9.234:6666

    …

执行命令：

    ./dispcli -h192.168.9.72 ~/data/lineorder1.lst

显示：

    [2012-07-03 15:44:47] ERROR: Failed to receive reply forcommand: 'get_connect' (Resource temporarily unavailable)

原因：

    这是由于控制文件中的disp_server错误造成。

对策：

    改为正确的IP 地址和端口号。

(4)file_list错误

现象：

加载时出现如下错误：

ERROR: Create dispatch failed (+ERR FATAL INVALID_ARGS (File :'/home/gbase/data/lineorder.tbl.101' does NOT exists or can NOT be read.)

原因：

由于给定的file_list中包含不存在或者无法读取的文件造成的。

对策：

修改file_list 参数值，保证所有数据文件都存在并且都可以被dispserver 读取。

(5)delimiter错误

现象：

分隔符设置错误，此错误不会造成加载出错退出，但是会造成正常的原始数据无法被导入到数据库中，同时出现大量错误数据，可能会看到如下的状态显示：

[192.168.9.70] [START TIME: 2012-07-03 14:26:50] [N/A]

[RATE: 4.43M/s] [TIMEOUT] [BAD REC: 6767869] [ETA: N/A]

[ELAPSED: 11 secs]

原因：

当分隔符设置错误时，节点上的gbloader会由于无法正确地对文本行进行切分而认为此行数据为错误数据，并将所有错误数据重新上传到dispserver上的错误数据日志文件中，所以当有大量错误数据上传时，gbloader从dispserver读取原始数据的速度也会相应变慢，进而可能造成加载超时。

对策：

根据数据文件的内容改为正确的delimiter参数值。

(6)format错误

现象：

出现大量错误数据，导致加载错误或超时。

原因：

这个参数目前有四个值：0，(文本文件)；2，(gbase 二进制)；3，无转义的文本文件；4，定长文本文件。如果这个参数设置错误的话，会导致原始数据被按照错误的方式解析，所以极有可能出现所有数据都被认为是错误数据的情况发生。

对策：

根据文件格式设置正确的format参数，值为0、2、3、4。

(7)db_name&table_name错误

现象：

加载时出现如下错误：

ERROR: Table 'ssbm1'.'lineorder' does not exist.

原因：

db_name或table_name错误造成程序无法在目标集群中找到指定的数据表的元信息

对策：

改为正确的数据库名和表名。

(8)extra_loader_args错误

现象：

这个参数如果设置错误的话，会导致节点上的gbloader无法正常启动或无法正常工作。

原因：

这个参数的值会被原样传递给节点上的gbloader，所以这个参数包含错误的话会导致所有gbloader都出现问题。

对策：

保证参数的正确，同时要注意gbloader不允许长参数名和参数值之间（即等号两边）包含空格。

(9)single_node_mode错误

现象：

不能像预期的那样向一个数据分片表中导入所有数据，而是仍然向一个safegroup的所有数据分片表中导入。

原因：

此参数的目的是只向一个数据分片表中导入数据，需要注意的是，这个参数需要配合dispcli的命令行参数–single-node来使用，否则就会被忽略。

对策：

确认控制文件中含有single_node_mode参数，并且其参数值为1，同时dispcli也要给定—single-node（或-s）参数。

2. 网络错误

(1)端口无法绑定

现象：

启动dispserver不成功，并且log中显示如下内容：

2012-07-04 13:46:53 Can't start dispserver server: Bind on

TCP/IP port: Address already in use

原因：

这是由于指定端口（默认为6666）已经被其他程序占用导致的。

对策：

通过--port 参数指定其他端口。

3. gcluster错误

在加载过程中如果集群出现异常，例如节点出现故障，会导致加载不能正常进行或者加载后同组中节点数据不一致，此类错误比较严重，要重点解决，以免影响后续使用。

(1)节点offline

现象：

启动加载失败。

原因：

在导入开始之前集群中已经有某些节点处于offline状态，加载机会判断offline状态节点是否是当前集群anchor节点（即分发节点），如果是anchor节点offline的话，则加载无法开始即加载失败；但如果是非anchor节点，加载机会跳过已经offline的节点进行加载，把offline状态节点的数据状态设置为LOCKED。

对策：

如果加载未进行就失败，说明offline节点是anchor节点，则需要重新启动所有集群上的节点的gcware服务，使得集群处于正常状态，不应有offline状态的节点，然后重新进行加载。如果加载进行了，只有offline 节点上的数据状态为>0 的值(即为LOCKED状态)，则需要重新启动此节点的gcware服务，使其恢复到Online状态。然后在同一个safegroup组的另一个节点上执行数据同步命令，这样此节点的数据就能正常了，而且数据状态自动恢复成0（VALID 状态）。

(2)节点locked

现象：

加载开始时跳过了某个目标节点，即并未在某节点上启动gbloader，此节点数据未导入。

原因：

该节点正处于locked状态，所以加载程序会自动跳过这些节点，并对其同组节点执行正常的加载操作。

对策：

手动进行数据同步，使locked 节点的数据跟组内其他节点一致。在组内另一台好的节点上执行同步程序手动同步locked 的节点。

命令为：gcadmin sync <locked 节点IP>

同步完数据之后，locked节点的状态自动变成正常状态。

(3)safegroup 被lock

现象：加载时出现如下错误信息：

ERROR: Can’t start load while target safegroup locked.

原因：

某个目标safegroup中所有的节点都已经LOCKED，导致整个safegroup被LOCKED。

对策：

需要人工介入查找故障原因，safegroup 组恢复后可再次启动导入。

4. gbloader错误

    gbloader的错误信息会被记录到dispcli.log文件中，此log文件的默认位置是/tmp/dispcli.log，也可以使用--log-file参数指定位置。由于log 文件中记录的内容较多，所以在确定gbloader 错误的时候通常需要采用关键字查找并结合log 时间戳的方式来进行。一般来说，当有gbloader 错误发生时，可先将log 文件内容定位到最后，然后反向查找关键字“STDERR”，这样就能找到gbloader 最后一次出现错误时打印在标准错误上的信息了。如：

2012-07-04 12:59:36 We read from 192.168.9.70 [STDERR]:

2012-07-04 12:59:36 Error: kill by signal.

     得到gbloader的错误信息后即可参照gbloader的使用说明进行排错。如果想知道gbloader的返回码，可以搜索“EXIT:”，为了更好地显示loader的退出状态，gbloader的返回码被赋予了两种不同的含义，一种是loader本身返回的值，一种是导致loader退出的系统信号(signal)。如果返回码等于0 或大于100 则表明这是gbloader自身返回的值，否则即为系统信号值，由此可以判断出gbloader是由于接收到系统信号而退出还是执行结束退出，如：2012-07-04 12:59:36 192.168.9.71 EXIT: 0 bytecount: 0

    其中的IP 地址(192.168.9.71）表示这个返回码是来自于 192.168.9.71这个节点上执行的gbloader。

    gbloader 的返回码定义如下：

    其他值则表示gbloader 收到的导致其退出的系统信号，信号列表如下：

/* Signals. */

SIGHUP 1 /* Hangup (POSIX). */

SIGINT 2 /* Interrupt (ANSI). */

SIGQUIT 3 /* Quit (POSIX). */

SIGILL 4 /* Illegal instruction (ANSI). */

SIGTRAP 5 /* Trace trap (POSIX). */

SIGABRT 6 /* Abort (ANSI). */

SIGIOT 6 /* IOT trap (4.2 BSD). */

SIGBUS 7 /* BUS error (4.2 BSD). */

SIGFPE 8 /* Floating-point exception (ANSI). */

SIGKILL 9 /* Kill, unblockable (POSIX). */

SIGUSR1 10 /* User-defined signal 1 (POSIX). */

SIGSEGV 11 /* Segmentation violation (ANSI). */

SIGUSR2 12 /* User-defined signal 2 (POSIX). */

SIGPIPE 13 /* Locked pipe (POSIX). */

SIGALRM 14 /* Alarm clock (POSIX). */

SIGTERM 15 /* Termination (ANSI). */

SIGSTKFLT 16 /* Stack fault. */

SIGCLD SIGCHLD /* Same as SIGCHLD (System V). */

SIGCHLD 17 /* Child status has changed (POSIX). */

SIGCONT 18 /* Continue (POSIX). */

SIGSTOP 19 /* Stop, unblockable (POSIX). */

SIGTSTP 20 /* Keyboard stop (POSIX). */

SIGTTIN 21 /* Background read from tty (POSIX). */

SIGTTOU 22 /* Background write to tty (POSIX). */

SIGURG 23 /* Urgent condition on socket (4.2 BSD). */

SIGXCPU 24 /* CPU limit exceeded (4.2 BSD). */

SIGXFSZ 25 /* File size limit exceeded (4.2 BSD). */

SIGVTALRM 26 /* Virtual alarm clock (4.2 BSD). */

SIGPROF 27 /* Profiling alarm clock (4.2 BSD). */

SIGWINCH 28 /* Window size change (4.3 BSD, Sun). */

SIGPOLL SIGIO /* Pollable event occurred (System V). */

SIGIO 29 /* I/O now possible (4.2 BSD). */

SIGPWR 30 /* Power failure restart (System V). */

SIGSYS 31 /* Bad system call. */

    在网络出现严重拥塞或者连接断开的情况下，节点上的gbloader可能会因为长时间无法从dispserver读取到数据而导致操作超时，dispcli可能会有如下的显示：

[192.168.9.70] [START TIME: 2012-07-04 11:15:50] [N/A]

[RATE: 1.43M/s] [TIMEOUT] [BAD REC: 0] [ETA: N/A] [ELAPSED: 5 mins 33

secs]

    这时首先应该检查超时节点和dispserver所在节点之间的网络是否畅通，dispserver是否工作正常（如进程是否还在、端口是否还可以连接等），如dispserver工作正常，而网络拥塞确实比较严重，但仍然可以联通，且短时间内无法恢复的话，可以使用gbloader的--timeout 参数指定一个较大的超时值，设置为0 则表示永不超时。同时对dispcli 也要相应增加超时值。

    另外，需要注意的是，由于dispcli的log是追加模式，所以长时间运行时会导致产生大量log信息，对侦错工作会产生一定影响。因此建议每次启动dispcli时都使用—log-file参数指定不同的log文件（例如可使用时间戳：data +%F_%T），这样可有效地加快侦错速度。