GBase 8a数据库通过LOAD方式加载时，如果出现功能报错，如何排查

前提参数设置

// 默认值是3，这个是session级别的，无需恢复

gbase> set gcluster_log_level=7;

Query OK, 0 rows affected (Elapsed: 00:00:0000)

// 默认值是0，建议先show一下原始值，排查完了记得改回去。

gbase> set global gbase_sql_trace_level=15;

Query OK, 0 rows affected (Elapsed: 00:00:0012)

// 默认值是0，这个是session级别，无需恢复

gbase> set gbase_sql_trace=1;

Query OK, 0 rows affected (Elapsed: 00:00:0001)

执行语句

gbase> load data infile ‘ftp://gbase:gbase1234@192168163100/t1txt’ into table testdbt1;

Query OK, 4 rows affected (Elapsed: 00:00:0035)

Task 394392 finished, Loaded 4 records, Skipped 0 records

查看日志

/opt/gbase/gcluster/log/gcluster/expresslog

# SQL处于check permission状态

# 获得表的锁

# 如果长时间无法拿到锁，通过gcadmin showlock 看看对应的表的锁在哪个节点哪个ID持有

2019-07-03 15:02:41352 [LOCK][INFO ][S:2108][Q:13221]:acquired WRITE lock: testdbt1580D5F90-B287-4199-B057-E6FBD44B5BFA, lwp:35693

2019-07-03 15:02:41352 [LOCK][INFO ][S:2108][Q:13221]:acquired READ lock: testdbt1, lwp:35693

2019-07-03 15:02:41353 [LOCK][INFO ][S:2108][Q:13221]:acquired READ lock: testdbt1rsync, lwp:35693

# 读取数据源ftp文件信息

# 检查数据库和FTP之间的性能问题，包括网络和FTP服务器的设置

2019-07-03 15:02:41354 [LOAD][INFO ][S:2108][Q:13221]:Start cluster load

2019-07-03 15:02:41358 == Information : Trying 192168163100

2019-07-03 15:02:41362 == Information : Connected to 192168163100 (192168163100) port 21 (#0)

2019-07-03 15:02:41370 <= Recv header : 220 (vsFTPd 302)

2019-07-03 15:02:41371 => Send header : USER gbase

2019-07-03 15:02:41371 <= Recv header : 331 Please specify the password

2019-07-03 15:02:41371 => Send header : PASS gbase1234

2019-07-03 15:02:41419 <= Recv header : 230 Login successful

2019-07-03 15:02:41419 => Send header : PWD

2019-07-03 15:02:41419 <= Recv header : 257 "/home/gbase"

2019-07-03 15:02:41419 == Information : Entry path is '/home/gbase'

2019-07-03 15:02:41419 => Send header : TYPE I

2019-07-03 15:02:41419 == Information : ftp_perform ends with SECONDARY: 0

2019-07-03 15:02:41420 <= Recv header : 200 Switching to Binary mode

2019-07-03 15:02:41420 => Send header : SIZE t1txt

2019-07-03 15:02:41420 <= Recv header : 213 8

2019-07-03 15:02:41420 => Send header : REST 0

2019-07-03 15:02:41420 <= Recv header : 350 Restart position accepted (0)

2019-07-03 15:02:41421 == Information : Remembering we are in dir ""

2019-07-03 15:02:41421 == Information : Connection #0 to host 192168163100 left intact

2019-07-03 15:02:41422 == Information : Trying 192168163100

2019-07-03 15:02:41422 == Information : Connected to 192168163100 (192168163100) port 21 (#0)

2019-07-03 15:02:41424 <= Recv header : 220 (vsFTPd 302)

2019-07-03 15:02:41424 => Send header : USER gbase

2019-07-03 15:02:41425 <= Recv header : 331 Please specify the password

2019-07-03 15:02:41425 => Send header : PASS gbase1234

2019-07-03 15:02:41465 <= Recv header : 230 Login successful

2019-07-03 15:02:41465 => Send header : PWD

2019-07-03 15:02:41465 <= Recv header : 257 "/home/gbase"

2019-07-03 15:02:41465 == Information : Entry path is '/home/gbase'

2019-07-03 15:02:41465 => Send header : TYPE I

2019-07-03 15:02:41465 == Information : ftp_perform ends with SECONDARY: 0

2019-07-03 15:02:41465 <= Recv header : 200 Switching to Binary mode

2019-07-03 15:02:41465 => Send header : SIZE t1_2txt

2019-07-03 15:02:41466 <= Recv header : 213 8

2019-07-03 15:02:41466 => Send header : REST 0

2019-07-03 15:02:41466 <= Recv header : 350 Restart position accepted (0)

2019-07-03 15:02:41466 == Information : Remembering we are in dir ""

2019-07-03 15:02:41466 == Information : Connection #0 to host 192168163100 left intact

#准备分派任务

2019-07-03 15:02:41467 [LOAD][INFO ][S:2108][Q:13221]:AddNodeLoadFileNum host[::ffff:192168163101]add num [1]

2019-07-03 15:02:41474 [LOCK][INFO ][S:2108][Q:13221]:unlocked: testdbt1

2019-07-03 15:02:41474 [LOCK][INFO ][S:2108][Q:13221]:acquired WRITE lock: testdbt16ef6f8a9-87f0-4d6c-8043-899367d02df3, lwp:35693

2019-07-03 15:02:41475 [LOAD][INFO ][S:2108][Q:13221]:AddNodeLoadFileNum cur node state:[ip:::ffff:192168163100:num:0][ip:::ffff:192168163101:num:1]

# 此时SQL已经在loading状态，

# 开始下发任务。一般是某个节点性能导致，或者数据非常倾斜。

# a) 可以测试从每个数据库的数据节点，用ftp直接获取数据文件的性能

# 比如 curl ftp://XXXXX/XXcsv > 1txt

# 多跑几次，看看哪个节点比较慢

# b) 排查机器的内存是否出现SWAP, *** 作系统/var/log/messages是否有磁盘报错

# c) 查看CPUINFO是否有异常降频

# d) 用top、iotop、nmon等工具观察一段时间系统资源，是否有资源紧张

#

2019-07-03 15:02:41476 [SQLDISP][INFO ][S:2108][Q:13221]:Target:::ffff:192168163101, SQL:set scn = 395447

2019-07-03 15:02:41521 [SQLDISP][INFO ][S:2108][Q:13221]:Target:::ffff:192168163101, SQL:LOAD DATA INFILE 'ftp://gbase:@192168163100/t1txt#offset=0&length=8&firstblock&ffsize=8,ftp://gbase:@192168163100/t1_2txt#offset=0&length=8&firstblock&ffsize=8' INTO TABLE `testdb``t1_n1` DATA_FORMAT 3 FILE_FORMAT UNDEFINED HOST '::ffff:192168163101' CURRENT_TIMESTAMP 1562137361 SCN_NUMBER 395447 GCLUSTER_PORT 5258 INTO SERVER (HOST '::ffff:192168163100, ::ffff:192168163101', PORT '5050', USER 'root', DATABASE 'testdb', TABLE 't1_n1, t1_n2', COMMENT 'table_host 0 1 0 # 1 0 1, scn 395447, group -1')

2019-07-03 15:02:42004 [LOAD][INFO ][S:2108][Q:13221]:ReduceNodeLoadFileNum host[::ffff:192168163100] reduce num [0]

2019-07-03 15:02:42004 [LOAD][INFO ][S:2108][Q:13221]:ReduceNodeLoadFileNum host[::ffff:192168163101] reduce num [1]

2019-07-03 15:02:42004 [LOAD][INFO ][S:2108][Q:13221]:ReduceNodeLoadFileNum cur node state:[ip:::ffff:192168163100:num:0][ip:::ffff:192168163101:num:0]

2019-07-03 15:02:42004 [LOAD][INFO ][S:2108][Q:13221]:Task 395447 finished, Loaded 8 records, Skipped 0 records

# 拿到排它锁，要切换版本了。

2019-07-03 15:02:42008 [LOCK][INFO ][S:2108][Q:13221]:acquired WRITE lock: testdbt109B5BEEC-1EF7-4FA6-9850-C4217A781E0F, lwp:35693

# 设置SCN

2019-07-03 15:02:42008 [SQLDISP][INFO ][S:2108][Q:13221]:Target:::ffff:192168163101, SQL:SET SELF SCN = 395447

2019-07-03 15:02:42009 [SQLDISP][INFO ][S:2108][Q:13221]:Target:::ffff:192168163100, SQL:SET SELF SCN = 395447

2019-07-03 15:02:42009 [SQLDISP][INFO ][S:2108][Q:13221]:Target:::ffff:192168163100, SQL:SET SELF SCN = 395447

2019-07-03 15:02:42009 [SQLDISP][INFO ][S:2108][Q:13221]:Target:::ffff:192168163101, SQL:SET SELF SCN = 395447

# 以指定的SCN来刷新数据

2019-07-03 15:02:42011 [SQLDISP][INFO ][S:2108][Q:13221]:Target:::ffff:192168163100, SQL:flush commit "testdb""t1_n1" scn_number 395447

2019-07-03 15:02:42011 [SQLDISP][INFO ][S:2108][Q:13221]:Target:::ffff:192168163100, SQL:flush commit "testdb""t1_n2" scn_number 395447

2019-07-03 15:02:42019 [SQLDISP][INFO ][S:2108][Q:13221]:Target:::ffff:192168163101, SQL:flush commit "testdb""t1_n2" scn_number 395447

2019-07-03 15:02:42055 [SQLDISP][INFO ][S:2108][Q:13221]:Target:::ffff:192168163101, SQL:flush commit "testdb""t1_n1" scn_number 395447

# 验证SCN

2019-07-03 15:02:42060 [SQLDISP][INFO ][S:2108][Q:13221]:Target:::ffff:192168163101, SQL:select scn from information_schematables where table_schema = 'testdb' and table_name = 't1_n1'

2019-07-03 15:02:42061 [SQLDISP][INFO ][S:2108][Q:13221]:Target:::ffff:192168163100, SQL:select scn from information_schematables where table_schema = 'testdb' and table_name = 't1_n1'

2019-07-03 15:02:42061 [SQLDISP][INFO ][S:2108][Q:13221]:Target:::ffff:192168163100, SQL:select scn from information_schematables where table_schema = 'testdb' and table_name = 't1_n2'

2019-07-03 15:02:42061 [SQLDISP][INFO ][S:2108][Q:13221]:Target:::ffff:192168163101, SQL:select scn from information_schematables where table_schema = 'testdb' and table_name = 't1_n2'

2019-07-03 15:02:42063 [SQLDISP][INFO ][S:2108][Q:13221]:Target:::ffff:192168163101, SQL:set autocommit=1

2019-07-03 15:02:42063 [SQLDISP][INFO ][S:2108][Q:13221]:Target:::ffff:192168163100, SQL:set autocommit=1

2019-07-03 15:02:42063 [SQLDISP][INFO ][S:2108][Q:13221]:Target:::ffff:192168163100, SQL:set autocommit=1

2019-07-03 15:02:42063 [SQLDISP][INFO ][S:2108][Q:13221]:Target:::ffff:192168163101, SQL:set autocommit=1

# SQL处于commit阶段 或者 rollback阶段

# 提交commit成功

2019-07-03 15:02:42067 [COMMIT][INFO ][S:2108][Q:13221]:commit table(testdbt1) success for scn:395447

2019-07-03 15:02:42068 [LOAD][INFO ][S:2108][Q:13221]:successful to cluster load

# 释放锁

2019-07-03 15:02:42068 [LOCK][INFO ][S:2108][Q:13221]:unlocked: testdb

2019-07-03 15:02:42069 [LOCK][INFO ][S:2108][Q:13221]:unlocked: testdbt109B5BEEC-1EF7-4FA6-9850-C4217A781E0F

2019-07-03 15:02:42070 [LOCK][INFO ][S:2108][Q:13221]:unlocked: testdbt1rsync

2019-07-03 15:02:42071 [LOCK][INFO ][S:2108][Q:13221]:unlocked: testdbt1580D5F90-B287-4199-B057-E6FBD44B5BFA

2019-07-03 15:02:42072 [LOCK][INFO ][S:2108][Q:13221]:unlocked: testdbt16ef6f8a9-87f0-4d6c-8043-899367d02df3

加载工具具备如下一些特性和优点：

1）与集群高度集成，方便部署；

2）支持 SQL 及外部工具的加载方式；面向用户的 SQL 接口方式使集群和单机加载方式统一，更符合用户的使用习惯；

3）支持单表多数据源并行加载，支持多加载机对单表的并行加载，最大化加载性能；

4）支持从通用数据服务器拉取数据，支持 ftp/>

Gbase8s 提供了Fan-in(扇入）和Fin-out（扇出）的并行机制，在数据库只有一个物理CPU的情况下，同时有多个客户端请求服务器时，扇入机制可以将多个客户端请求并行运行在一个VP上，从而实现成千上万的并发的客户请求，而不需要太多的物理CPU，而且不会随着并发用户数上升出现性能下滑的情况。

1、gbase在与其他传统的关系型数据库在sql上是否有区别？还是支持标准的sql语言，只是增加了部分内置函数？或者多数sql体系都不一样？

//支持 ansi标准sql，扩展部分功能。

2、gbase与oracle或mysql在实现上有什么不同？物理层面？逻辑层面？日志的读写、归档、检查点等？

//数据库实现的方式都差不多。作为成熟的数据库产品均会考虑数据的完整性，一致性，可恢复性等特性。

3、gbase在锁方面是如何实现的？

//锁的产生是因为并发访问控制。先访问数据的会话对其加锁，以防后访问的会话对其修改，造成数据异常。

4、HDR方案，在网络中断的情况下，是怎样进行处理的？网络恢复或有gap的情况下与Oracle Dataguard的处理有和区别？主库宕机切换后是否会造成数据丢失，丢失的数据能否估算？

//起决于参数DRAUTO的配置(0，1，2，3)，保持不动/备机切换成标准模式/备机切换成主用模式/由连接管理器控制。

主机宕机后，可能会有数据丢失，丢失的数据起决于最后一次检查点以及备机的 *** 作。一般来说在DRAUTO 为2，检查点间隔为30秒的环境中，数据仅丢失逻辑日志缓冲区中未提交到备机的事务。

5、同城异地灾备应使用HDR还是RSS，主备都数据都应放置在存储上，或者不使用存储，普通的PC亦可？

//建议使用RSS，HDR对网络要求高。

普通PC机也可，只是不建议。

6、对于集群对于闹裂的情况，gbase是否也使用仲裁机制或有其他不同？及其节点的故障恢复情况。负载均衡也是通过轮询机制，还是判断节点的负载情况而定？

//由连接管理器控制。负载也可以使用连接管理器控制。连接管理器专干接入、转发、负载控制这些事。

7、gbase含有双引擎，在使用中应如何选择，或是根据存储数据的不同gbase自动切换引擎？？

// 没听过。。。你说的是gbase 8a

8、如果使用gbase数据库，必然是逐步替换系统，那gbase是否可以直接与目前的主流关系型数据库进行相互访问，或是否有第三方的中间件可以提供？

// 有相应的迁移方案。

9、最后当然是最关心的价格

以上就是关于GBase 8a数据库通过LOAD方式加载时，如果出现功能报错，如何排查全部的内容，包括:GBase 8a数据库通过LOAD方式加载时，如果出现功能报错，如何排查、Gbase 8a 数据加载工具有什么优点、南大通用的GBase8s数据库如何实现高并发的OLTP业务系统的等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！