GBase 8a通过LOAD方式加载时，如果有报错或者加载错误数据，会将加载日志和数据记录到连接节点的load_logs目录下。因为是用户数据，当前版本尚没有配置自动删除功能，而是建议用户在LOAD语句里将错误数据导出到用户自己指定的ftp/sftp目标服务器，自行管理。本文介绍在默认情况下，如何通过rsync命令快速清理这些日志。
GBase 8a集群加载的错误数据导出到指定ftp/sftp/服务器目录下
GBase 8a 集群加载数据LOAD的方法
目录导航
环境
构造加载错误日志
弄了一个表结构和数据不一致的情况。
gbase> load data infile 'sftp://gbase:gbase1234@10.0.2.101/home/gbase/aggr_loc_peersigip_srvapp_hour_week_202211.csv' into table t1 fields terminated by '\t';
Query OK, 0 rows affected (Elapsed: 00:00:04.86)
Task 14 finished, Loaded 0 records, Skipped 276008 records
gbase> load data infile 'sftp://gbase:gbase1234@10.0.2.101/home/gbase/aggr_loc_peersigip_srvapp_hour_week_202210.csv' into table t1 fields terminated by '\t';
Query OK, 0 rows affected (Elapsed: 00:00:01.25)
Task 15 finished, Loaded 0 records, Skipped 559 records
gbase> load data infile 'sftp://gbase:gbase1234@10.0.2.101/home/gbase/aggr_loc_peersigip_srvapp_hour_week_202210.csv' into table t1 fields terminated by '\t';
Query OK, 0 rows affected (Elapsed: 00:00:01.31)
Task 16 finished, Loaded 0 records, Skipped 559 records
gbase> load data infile 'sftp://gbase:gbase1234@10.0.2.101/home/gbase/aggr_loc_peersigip_srvapp_hour_week_202210.csv' into table t1 fields terminated by '\t';
Query OK, 0 rows affected (Elapsed: 00:00:01.27)
Task 17 finished, Loaded 0 records, Skipped 559 records
gbase>
查看加载日志
加载日志(有错误数据时产生)默认放在加载连接节点的gcluster/log/gcluster/loader_logs下面。按照加载load的taskid号创建目录，内部是1个加载结果和有错误的各个分片的错误日志和对应错误数据。
[gbase@gbase_rh7_001 loader_logs]$ pwd
/opt/gbase/gcluster/log/gcluster/loader_logs
[gbase@gbase_rh7_001 loader_logs]$ ll
total 0
drwx------. 2 gbase gbase 140 Apr 1 10:30 14
drwx------. 2 gbase gbase 140 Apr 1 10:30 15
drwx------. 2 gbase gbase 140 Apr 1 10:30 16
drwx------. 2 gbase gbase 140 Apr 1 10:30 17
[gbase@gbase_rh7_001 loader_logs]$ ll 14
total 58988
-rw-------. 1 gbase gbase 272 Apr 1 10:30 14_loader_result.log
-rw-------. 1 gbase gbase 26264424 Apr 1 10:30 14_testdb_t1_n1_10.0.2.101_20220401103041.err
-rw-------. 1 gbase gbase 34128469 Apr 1 10:30 14_testdb_t1_n1_10.0.2.101_20220401103041.trc
[gbase@gbase_rh7_001 loader_logs]$ ll 15
total 124
-rw-------. 1 gbase gbase 264 Apr 1 10:30 15_loader_result.log
-rw-------. 1 gbase gbase 51650 Apr 1 10:30 15_testdb_t1_n1_10.0.2.101_20220401103051.err
-rw-------. 1 gbase gbase 67596 Apr 1 10:30 15_testdb_t1_n1_10.0.2.101_20220401103051.trc
[gbase@gbase_rh7_001 loader_logs]$
通过Rsync清理日志
一般如果文件不多，可以用
rm -fr *来清理，如果再多，可以用
ls | xargs rm -fr来清理，如果极多，或者如上的方法耗时很长，可以考虑用rsync的方法清理大量的目录和文件
语法
rsync --delete-before -d -a -H -v --progress --stats SOURCE TARGET其中有关参数
- -delete-before 传输前进行删除操作，而不是传输中(--delete-during)
- -d 不递归的传输目录
- -a 归档，表示以递归方式传输文件
- -H 保持硬链接的文件
- -v 详细模式，输出些日志
- --progress 同步的过程中可以看到同步的过程状态，比如统计要同步的文件数量、 同步的文件传输速度等
- --stats 每个文件的传输状态
- SOURCE 源文件
- TARGET 目标文件
因为本文是介绍删除，那么源文件就是个空目录
创建空目录
如下在/tmp目录创建一个空目录，名字随意。
mkdir /tmp/BLANKRsync删除loader_log目录
因为是删除，所以不需要那些过程之类的参数，只使用--delete-before。同时是否递归目录，需要指定-d不递归，我们只有1级目录
注意，SOURCE使用的是/tmo/BLANK/ 代表是这个目录下的内容， 如果不带最后的/，会导致将BLANK目录同步到目标，而不是BLANK目录下的内容。
[gbase@gbase_rh7_001 gcluster]$ rsync --delete-before -d -v /tmp/BLANK/ /opt/gbase/gcluster/log/gcluster/loader_logs
building file list ... done
deleting 17/17_testdb_t1_n1_10.0.2.101_20220401103055.trc
deleting 17/17_testdb_t1_n1_10.0.2.101_20220401103055.err
deleting 17/17_loader_result.log
deleting 17/
deleting 16/16_testdb_t1_n1_10.0.2.101_20220401103053.trc
deleting 16/16_testdb_t1_n1_10.0.2.101_20220401103053.err
deleting 16/16_loader_result.log
deleting 16/
deleting 15/15_testdb_t1_n1_10.0.2.101_20220401103051.trc
deleting 15/15_testdb_t1_n1_10.0.2.101_20220401103051.err
deleting 15/15_loader_result.log
deleting 15/
deleting 14/14_testdb_t1_n1_10.0.2.101_20220401103041.trc
deleting 14/14_testdb_t1_n1_10.0.2.101_20220401103041.err
deleting 14/14_loader_result.log
deleting 14/
sent 22 bytes received 12 bytes 68.00 bytes/sec
total size is 0 speedup is 0.00
[gbase@gbase_rh7_001 gcluster]$ ll loader_logs/
total 0
[gbase@gbase_rh7_001 gcluster]$
总结
实际测试，通过rsync删除目录的速度，远高于rm的方式。网上找到的资料，是rsync是多线程处理，而rm是单线程的。其中rm耗时40分钟的场景，用rsync只需要 18秒。