返回首页

gbase数据、南大通用产品文档:GBase8s

更新日期:2024年09月11日

Invalid subprotocol
当前有效的子协议是 gbasedbt-sqli。

dcf_rep_append_thread_num
参数说明:DCF 日志复制线程数量,参数重启生效。
该参数属于POSTMASTER 类型参数,请参考表15-1 中对应设置方法进行设置。
取值范围:整型,1~1000
默认值:2

system 日志,也称错误日志,默认开启,记录数据库服务启动、停止等重要操作,
并可记录数据库服务宕机等异常情况的程序堆栈,可辅助开发人员查错。
说明
GCluter 层和GNode 层分别记录gclusterd 服务和gbased 服务的启动、停止等信息,
当有服务崩溃时,可查看当时的程序堆栈,辅助开发人员查错。
日志文件存储路径
$GCLUSTER_BASE/log/gcluster/system.log
$GBASE_BASE/log/gbase/system.log
日志内容说明

日志文件名称可通过设置log_error 参数修改。默认为$GCLUSTER_BASE/log/g
cluster/system.log;

当有服务崩溃时,system 日志会记录下崩溃时的程序调用堆栈,出现此类情
况可将system.log 发回公司,由相关开发人员排查,这时log 中记录的内
容类似于core 文件的作用,可用于分析产生错误的原因,至少可以获知程
序崩溃的代码点;

运行过程中出现crash 时,system.log 中记录了宕机的堆栈信息,core 文件中
记录了宕机的详细的堆栈信息,查看详细的堆栈信息,方法如下:
1.
集群管理节点层面:
在每台集群节点机器的$GBASE_BASE/config 路径下,
找到配置文件gbase_8a_gcluster.cnf,将文件中的core-file 参数去掉参数
前的注释符号“#”;
2.
集群数据节点层面:
在每台集群节点机器的$GBASE_BASE/config 路径下,
找到配置文件gbase_8a_gbase.cnf,将文件中的core-file 参数去掉参数前
的注释符号“#”。完成上述步骤后,运行gcluster_services all restart
命令,重新启动集群服务,使上述配置文件的设置生效。
示例
为用户展示system.log 文件中的crash 信息。
system.log 中包含有crash 信息,如下:

GBase 8a MPP Cluster 产品手册
6 附录
文档版本953(2022-04-10)
南大通用数据技术股份有限公司
1615
120323
0:18:09 [Note] Event Scheduler: Purging the queue. 6 events
120323
0:18:09 - gbased got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.
key_buffer_size=8384512
read_buffer_size=131072
max_used_connections=6
max_threads=5000
threads_connected=0
It is possible that gbased could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 10950336 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd: 0x675a560
Attempting backtrace. You can use the following information to find out
where gbased died. If you see no messages after this, something went
terribly wrong...
stack_bottom = (nil) thread_stack 0x40000
gclusterd(my_print_stacktrace+0x2e) [0xea49fd]
gclusterd(handle_segfault+0x32e) [0x6e6b36]

GBase 8a MPP Cluster 产品手册
6 附录
文档版本953(2022-04-10)
南大通用数据技术股份有限公司
1616
/lib64/libpthread.so.0 [0x361300eb70]
gclusterd(ExpressChannel::lock(unsigned int)+0x130) [0xb68746]
gclusterd(DMLLog(int, std::string, char const*)+0xbf) [0x9308ff]
gclusterd(GCQueryExecutorStatement::UnionTableHandler::Execute()+0x14d0) [0x8f5ec0]
gclusterd(GCQueryExecutorStatement::TaskThread::ExecuteUnionTableTask(char*, unsigned
int)+0x93) [0x8dd23f]
gclusterd(GCQueryExecutorStatement::TaskThread::execute()+0x100) [0x8df976]
gclusterd(CGCThreadPool::GCThreadDispatchFunc(void*)+0x17) [0x92b5b1]
gclusterd(wrapper_fn(void*)+0x28) [0x92cafe]
/lib64/libpthread.so.0 [0x361300673d]
/lib64/libc.so.6(clone+0x6d) [0x36124d44bd]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at (nil) is an invalid pointer
thd->thread_id=0
thd->killed=NOT_KILLED
Writing a core file