Mr_dar的博客

引言大部分应用中性能的瓶颈是磁盘 IO，所以新型数据库的设计都以降低磁盘 IO 为主要设计目标。压缩可减少 I/O 的时间，提升性能，8a 也不例外。压缩是提高性能的主要技术之一，8a 并行执行器已经能够从上层并行调度解压，因此使解压的适用性得到了很大的提升，很多场景下（尤其是针对超大数据量的场景），使用压缩数据的方式都可以获得比不压缩更好的性能。压缩方式【86 版本】gbase_compression_num_method=<num_method>gbase_compres

网卡降速集群部分节点性能差，查看 nmon 等看到外发和收取速度明显低于其它节点。再查看 ethtools 网卡， 看到网速不是正常的千兆或万兆。比如万兆网，显示千兆，甚至百兆。这种情况一般是网线或者网卡不稳定。解决方案可以尝试重启网卡或者换其它正常的网口以及维修或更换网卡、检测网线。SSH 不通集群部分节点性能差，查看 nmon 等看到外发和收取速度明显低于其它节点。再查看 ethtools 网卡， 看到网速不是正常的千兆或万兆。比如万兆网，显示千兆，甚至百兆。这种情况一般是网线或者网

磁盘损坏查询报错 Disk I/O Error。去磁盘目录，无法cd以及ls列表等。查看/va/log/messages日志中有 I/O Error 字样。这种问题属于磁盘物理损坏，如果是 RAID5，则损坏有多块。需要维修和更换磁盘，重做 raid，文件系统。磁盘故障修复后对故障服务器做节点替换。磁盘扇区损坏查询报错或卡住，耗时超长。查看/var/log/messages 日志中错误举例：Nov 1 09:03:48 statcp1 kernel: [17707947.372267

问题现象现场进行多个 insert...select 的操作，多个任务一起操作的时候，insert 后跟对应的字段名，执行插入后报错 get cluster task id fail。问题排查（1）排查gcware 日志得到报错：corosync [IPC ]coroipcs create thread error with errno 11（2）排查dmesg 日志得到报错：[1871111.282609] cgroup: fork rejected by pids contr

情景描述NUMA 参数 zone_reclaim_mode 在设置为 1 时，内核将要求多路 CPU 尽量从距离较近的系统内存节点（服务器的整体内存在 numa 架构下将被分成若干个节点）分配内存而不是在整个服务器可访问内存的范围内进行内存分配，因此在较高内存占用压力下内存申请会触发内存频繁回收整理的机制严重影响了系统整体性能（长期处于内核态 sys 很高）。另 外 还 会 发 生 部 分 SQL 夯 住 ， 从 dmesg 日 志 的 堆 栈 信 息 中 表 现 为 出 现kmem_zone_allo

在Gbase 8a V95 版本进行数据加载和导出操作时需要的最小权限如下加载的最小权限File 权限：属于全局权限(*.*)grant file on *.* to u;insert 权限：具体要加载的表的 insert 权限grant insert on db.tb to u;导出的最小权限File 权限：属于全局权限(*.*)grant file on *.* to u;select 权限：具体要加载的表的 select 权限grant select on db

问题现象脱敏功能下执行 sql 或存储过程报错，甚至 gcluster 宕机，需要检查 unmask 权限。解决方法：Unmask 是面向脱敏控制的权限，对于脱敏数据，拥有 unmask 权限的普通用户可以看到原始数据，没有 unmask 权限的普通用户只能看到脱敏后的数据。权限是针对普 通 用 户的全局权 限， 不属于某 一个 VC 或 库 表， 在 gbase.user 表中Unmask_priv 列可以查看用户的 unmask 权限。Alter table tb alter col mas

HeapUsed(40316342048,97627136,8491566256) 和 SystemUsed(212425116840,0,0)代表什么？解释说明：HeapUsed(40316342048,97627136,8491566256)表示各堆内使用了的内存大小，相当于 show status 里的 heap used size；SystemUsed(212425116840,0,0)指各堆在系统里 malloc 的大小；顺序就是 cell(或者 dc)、large、temp。.

淘汰 unlock 状态的热数据 DC 参数设置_gbase_cache_drop_hot_data_gbase_cache_drop_hot_data 参数为开关参数，增加了一种 DC Cache 淘汰管理策略，允许释放 unlock 状态的 DC 数据而不用考虑该数据是否属于热数据（被多次使用的数据）。该参数默认取值为 0，建议设置为 1，即允许清除 unlock 状态的热数据。表缓存table_definition_cache用于保存表定义，也就是 frm 内容，是 table_s

insert select 申请内存大小参数_gbase_insert_malloc_size_limit_gbase_insert_malloc_size_limit 是控制 insert select 场景下一次申请内存的大小。默认值为 10240，为较优配置。如果 insert select 中涉及较长的 varchar 字段如包含多个 varchar(2000)的字段，会导致每行或每几行数据申请一次内存，内存频繁的申请就造成了 sys cpu 占用，影响性能。推荐取值为最大字符串

问题现象select * from (select count(1) into @c from t1 ) t limit 0,1000 错误： You have an error in your SQL syntax; check the manual that corresponds to your GBase server version for the right syntax to use near 'into @c from t1) t limit 0,1000' at line 1问题

结果集传输参数调整避免写文件失败gcluster_send_client_data_timeoutgcluster_send_client_data_timeout 参数为集群向客户端发送结果集数据时的超时参数，取值范围[0,100000]，单位秒，默认为 30 秒。当参数设置为 0 时表示不设置超时，结果集发送无限等待，只有发送成功或失败才返回。在网络环境较差场景下，或通过 JDBC 等开发接口获取结果集时增加了处理逻辑造成耗时较长时，如 JAVA 程序遍历 RESULT 后再将结果写到文件中

在GBase 8a中有多种方式优化加载，本章节讲解的参数可以很好的优化加载性能。提升加载性能参数gcluster_loader_max_data_processorsgcluster_loader_max_data_processors 为单个数据加载任务中最大加载机的个数，默认取值为 16。通常建议 gcluster_loader_max_data_processors 取值为 4~8。在使用 sftp 加载时，需要特别关注 ssh 连接个数限制，可能因为加载需要连接 sftp的加载机个数太多

说明线程池并行度参数在采用默认值的情况下，可能会因服务的线程池较小而单个 SQL任务的并行度太高，造成并发场景下后发起的任务无法获得充足的线程池而单线程执行。严重情况下，会造成较多的 sys cpu 占用。可以根据实际情况适当调整。gcluser_max_thread_in_pool参数含义为集群层连接集群内各节点 gnode 的连接池中连接线程的数量，即全局连接线程池大小，默认设置为 600。全局线程池使用较少，主要逻辑都走异步 API，通常保持默认值即可。当集群规模较大、SQL 并发

首先说一下round函数：ROUND(X)返回参数 X 四舍五入到最近的整数后的值。ROUND(X,D)返回的 X 值，保留到小数点后 D 位（第 D 位的保留方式为四舍五入）。问题现象对 double 类型数值进行 round 取舍，结果不是四舍五入。问题复现gbase> create table t(c1 double);Query OK, 0 rows affected (Elapsed: 00:00:00.55)gbase> insert into t valu

问题现象同样的 sql 在 gccli 中执行不报错，但是在企业管理器中执行报错。gccli -ugbase -p -Dtestcreate table t1(c1 int,c2 varchar(10));create table t2(c1 int,c2 varchar(10));企业管理器中执行 sql：select * from t1 left join t2 on t1.c1=t2.c2;报错信息为：select * from (select * from t1 lef

问题来源在项目现场，业务员反馈在创建存储过程、存储函数时，注释内容没有存进系统的元数据库，导致show create命令无法显示出注释。问题复现创建存储过程并用show命令显示，在创建的过程中加入注释gccli -uroot -DtestGBase client 9.5.3.27.88ef4e28. Copyright (c) 2004-2022, GBase. All Rights Reserved.gbase> delimiter //gbase> drop p

审计策略用来控制审计日志记录的策略，可以设置审计日志只记录某些指定的操作或者某些固定用户的操作。本篇将介绍创建、修改、删除审计策略。

在使用Gbase 8a时，遇到需要记录用户执行SQL的场景时，可以通过打开审计日志的方式

在大数据环境下，有的业务场景需要释放磁盘空间，最有效的手段是释放被删除的数据文件所占的磁盘空间。语法格式ALTER TABLE [vc_name.][database_name.]table_nameSHRINK SPACE [FULL] | [FULLBLOCK_REUSE_RATIO= num]FULL：行级回收，按行级原始顺序对 DC 内有效数据进行整理，重新落盘写seg文件。只要有删除的数据，删除数据的空间就会被回收。有效行的顺序跟回收前保持一致，效率较低。 FULL BLOC..

GBase 8a删除加载日志loader_logs方法

作用查看指定表占用的数据空间，最后更新时间等。提醒：如下方案在某些86版本里，当磁盘表和列特别多时，需要消耗大量的磁盘操作来统计数据库真实占用的磁盘空间。建议测试后如果发现无法接受，请自行使用df 数据库所在分区的方案来进行统计。注意：此功能在部分V95早期版本不可用，大部分V86和新的V9版本均可用。 必须同时提供库名和表名。 如想查看整个zxvmax库占用的空间，建议 以磁盘df 的/opt/gbase目录估算。 或者du -sh /opt/gbase/gnode/userdat

GBase 8a 目前版本都是采用一个库一个目录，表是库下面的子目录的方式保存数据，本文提供了一些查看一个库或schema占用磁盘空间方法以供参考。文件系统级估算直接从文件系统，找到该库所在的目录，计算其占有的空间。该才做仍然会消耗大量的磁盘资源，表越多，列越多，消耗越大。du -sh 安装目录/gnode/userdata/gbase/库名影响程度建议在实际环境测试后，再决定是否使用。比如100万个表，预计可能要几分钟到几十分钟的磁盘消耗，换SSD等高速盘会极大改善影响程度。需要计算

GBase 8a在创建用户以及授权时，可以指定该用户的主机IP，只有该IP才可以通过该用户进行连接和操作，从而实现了主机白名单功能。注意本机是localhost,如果不授权的话，默认就必须指定IP来连接本机。 其中主机名%表示所有的IP，支持匹配。通过create user创建用户gbase> create user testdb2@10.0.2.101 identified by 'testdb2';Query OK, 0 rows affected (Elapsed: 00:00:

报错样例注意，当这类参数错误时，在system.log里可能没有任何输出，此时可以在操作系统gbase用户下，手工执行gbased 看报错信息。[gbase@gbase100 gbase]$ gbasedUnknown suffix '.' used for variable 'gbase_heap_data' (value '0.8G')220304 14:31:45 [ERROR] gbased: Error while setting value '0.8G' to 'gbase_hea

问题描述：集群从8节点扩至16节点，扩容后出现一个报错（主副分片不一致），可以正常创建与原库一样的表，但在表中插入数据就会报主备分片不一致的报错报错信息：ERROR 1705（HY000）：gcluster DML error (IP:5050)(GBA-02AD-0005)Failed to query in gnode;DETAIL: (GBA-01EX-700) Ggase general error: (gns_host：IP) source table and destinatio

问题简述：在进行节点替换之后，所替换的节点重启之后无法启动。报错信息：【gcadmin 报错】Could not initialize CRM instance error: [6]->IGC AIS ERR TRY AGAIN]【管理节点状态】corosync is stoppedgclusterd is stoppedrecover (pid 127432) is running..【停止管理节点报错】Stopping GCMonit fail! Info: [

报错信息：[EXECTR][ERROR][S:397404][Q:3131072]<DispatchTasks|3247>:Async task error:[IP:5050](GBA-02AD-0005)Failed to query in gnode:DETAIL: gbase_forward_result failed to write result for client【具体信息】解决方案：（1）调大jvm内存可解决问题分析：failed to write .

问题版本：GBase 8a V8.6.2-43 R20问题简述：在进行迁移工作的数据导入之后，启动集群所有管理节点一直不能正常启动，通过命令service gcware stop 也不能停止。报错信息：【gcadmin 报错】Could not initialize CRM instance error: [6]->IGC AIS ERR TRY AGAIN]【管理节点状态】corosync is stoppedgclusterd is stoppedrecover (

GBase 8a V95版本在安装时，对安装目录必须有写入权限。新版本自动检测了该目录，如果无写入权限，将报这个错判。解决方案就是该目录有dbaUser的写入权限。报错样例 Dir '/opt',dbaUser 'gbase' doesn't have write and privilege to this dirctory '/opt'原因安装配置文件里的安装目录， 没有dbaUser, 一般是gbase，的写入权限。解决方案将所有安装节点的安装目录，增加dbaUser的写入权限

在虚拟机上安装GBase 8a MPP V953时，初始化安装后，gbase 组件不能启动。具体情况见下图：gcware与gcluster组件正常开启，gnode却关闭。通过【gcluster_services gbase infor】语句查看gbase组件的信息，组件信息为stop通过【gcluster_services gbase start】语句手动启动也失败，具体报错如下：期初怀疑是网络问题，应检查防火墙，如果没关闭则要关闭防火墙。操作系统为Cent OS7.2，查看防火墙语

简单查询类的内存配置建议主要应用场景为电信行业的话单查询业务。针对该类型场景的内存评估，主要依赖于热数据的比例和数据量。热数据的总量即为内存需求量。以某运营商的云话单为例，以月表方式存储6+1个月的历史数据；每天的数据量为600GB；全数据生命周期内的总数据量为600GB/天 * 30天/月 * 7个月 = 126T；云话单查询主要以当月数据查询为主，可定义当月的话单数据即为热数据，假设话单查询的字段个数只占总字段个数的1/3，则热数据的总量约为18TB/3=6TB，即在最理想情况下GBas

复杂应用的内存配置建议从以下几个方面考量数据库运算过程中单个GBase集群节点（gnode）各算子的内存需求（假定10节点集群）：参与运算的数据量以一个2亿行的表与3千万行的表进行join运算，并对join运算结果进行group by聚集，最终得到的结果行数为1.5亿行的场景为例，参与运算的数据量为2.3亿行，超过100GB（不含不参与运算的字段），得到的结果集也超过80GB；对于10节点集群，每节点承载的运算数据量超过10GB。sql执行过程中的中间结果集大小如两表join生成的has

磁盘配置建议，一方面是保障磁盘的高可用性，另一方面是为了保证更高的I/O性能来满足磁盘I/O需求。磁盘I/O性能需求的评估方法以举例形式说明如下：某电信运营商的营销分析系统，其用户数（电话号码）为3000万，每用户的数据为10k，每次即席复杂查询时内存可过滤90%的数据，需要I/O读取的数据量为3000万*10k*10%=30G。该营销分析系统的磁盘I/O需求计算依赖以下几个方面：数据库并发数为20； 平均单位即席复杂查询需访问的数据量为30G； 平均单位即席复杂查询耗时180秒

按照业务系统的数据量大小、压缩算法的选择、集群副本数的选择进行GBase集群存储空间需求的计算。业务系统数据量通常包括以下几个方面：历史数据量； 增量周期及每周期的增量大小； 数据存储周期，及全周期的数据总量； 数据量增长率及存储空间预留；充分考虑上述几个方面的情况，假设某业务系统的全周期的总数据量为30TB。GBase集群物理磁盘容量的计算方法为：最小磁盘空间需求MDSR (Minimum Disk Space Requirements) = 总数据量×数据库及相关工作

服务器catch参数设置建议建议设置操作系统趋向于回收catch，避免catch满后进行内存分配（malloc内存）性能差的问题：修改方式1：echo 1024 >/proc/sys/vm/vfs_cache_pressureecho 8388608 >/proc/sys/vm/min_free_kbytes修改方式2，编辑/etc/sysctl.conf配置文件：vm.vfs_cache_pressure = 1024vm.min_free_kbytes = 83.

为提高GBase RTSync同步工具的同步性能，建议对如下参数进行优化参数名 参数含义 建议值 cacheMaxSize 事务缓存在内存中的最大数据量，单位为Byte，默认大小为100MB。 超过该大小的事务会落地到磁盘中。 在服务器性能允许的情况下，增加该值可以避免数据落地，从而提高同步性能。 2147463480 transMaxCount 大事务拆分功能，如果事务条数超过

V95扩容报错：Error: execute cmd [ssh -o UserKnownHostsFile=/dev/null -o StrictHostkeyChecking=no gbase@*.*.*.* ‘rm -rf /tmp/gnode_sys_tbl/ /opt/*.*.*.*/gnode/userdata/gbase/testdb --exclude=gbase/adult_log.* ./gbase;mv ./gbase.tar /tmp/gnode_sys_tbl/’]failed,

GBase RTSync通过对不同数据库的日志解析，将需要同步的信息上传至kafka消息队列后，需要GBase 8a对其进行消费完成数据同步。GBase 8a Consumer 是 GBase8a mpp 自带的消费组件，用来同步消费 Kafka 数据到 8a MPP Cluster 数据库中。备注：目前由其它源库同步到 GBase8a MPP 时，采用的都是：GBase RTSync（管理、读） +GBase 8a Consumer（写）的方式进行环境部署。配置步骤如下：步骤一：修改 8.

今天到了RTSync配置专题的最后一章，同步的表配置，如果不配置该部分，那么就会自动进行库级别所有表的同步。详细的配置样例如下：<tables isInclude="true"> <table topicname="topicname1" isContinueSyncWhileError="false" deleteMode="NORMAL" sourceTableName="t1" sourcePkColName="" targetTableName="t1" ta