南大通用GBase 8c分布式场景常见故障运维

原文链接:https://www.gbase.cn/community/post/4987

更多精彩内容尽在南大通用GBase技术社区,南大通用致力于成为用户最信赖的数据库产品供应商。

一、数据库故障与重启

1.1 故障描述

在数据库的使用过程中,可能由于操作不当或环境问题遇到数据库故障。常见的故障原因包括硬件故障、磁盘空间不足、进程内存溢出、操作系统问题等。

1.2 故障排查

查看日志文件: 首先需要查看数据库的错误日志文件(位于$GAUSSHOME/log目录下),其中包含了导致故障的详细信息。错误日志中通常会显示故障发生的时间、原因以及异常堆栈信息。

常用日志文件包括:

pg_log:PostgreSQL兼容层的日志文件,记录了SQL执行和数据库操作的信息。

查看日志示例:

tail -n 100 $GAUSSHOME/log

检查系统资源: 数据库故障可能是由于资源问题引起的(如内存、CPU、磁盘空间等)。可以使用如下命令查看系统的资源使用情况:

free -m:查看内存使用情况

df -h:查看磁盘空间使用情况

top:查看CPU和内存的实时使用情况

查看数据库状态: 在数据库出现问题后,执行以下命令检查数据库的状态:

gha_ctl monitor all -l dcs_list -HI

如果数据库处于停止状态,可以尝试重启数据库。

gha_ctl start all -l dcs_list

1.3 解决办法

(1)首先检查硬件环境是否正常,包括磁盘空间、内存等资源是否充足。如果资源不足,需要扩展硬件或清理无用文件。

(2)然后重启数据库服务:

gha_ctl stop all -l dcs_list

gha_ctl start all -l dcs_list

(3)及时备份数据,考虑从备份中恢复数据。GBase 8c数据库支持使用gha_ctl retore工具恢复数据库。

(4)为了避免此类问题再次发生,可以根据数据库日志中的错误信息调整数据库的配置参数。例如,可以调整shared_buffers、work_mem等参数,以避免内存溢出。

二、连接问题

2.1 故障描述

在使用数据库时,数据库连接问题是常见的故障类型。用户可能无法连接到数据库,或者在连接过程中遇到超时、认证失败等问题。

2.2 故障排查

检查数据库是否启动: 首先确认数据库是否已经启动,可以使用以下命令检查:

gha_ctl monitor all -l dcs_list -HI

如果数据库未启动,可以尝试启动数据库:

gha_ctl start all -l dcs_list

检查网络连接: 如果数据库已经启动,但仍然无法连接,可以检查网络是否通畅。使用ping命令测试数据库主机的连通性:

ping <database_host>

检查端口和防火墙设置: 数据库默认使用5432端口进行连接,如果防火墙配置错误或端口被阻塞,也会导致无法连接。使用telnet命令测试数据库端口是否开放:

telnet <database_host> 5432

检查认证配置: 数据库的连接需要通过认证,如果认证失败,将无法连接数据库。需要检查pg_hba.conf文件中的配置,确保允许来自客户端IP的连接。例如:

# Allow connections from all IPs

host    all            all            0.0.0.0/0              md5

查看数据库日志: 连接问题还可能与数据库配置或其他错误有关,查看pg_log目录中postgresql-xxx.log文件是否有与连接相关的错误信息。

2.3 解决办法

启动数据库:确保数据库已经启动,如果没有启动,请使用gha_ctl start all -l dcs_list命令启动。

检查防火墙和端口配置:确保防火墙没有阻止数据库端口的访问。如果存在防火墙限制,可以临时关闭防火墙进行测试:

systemctl stop firewalld

修正认证配置:如果认证配置有问题,修改pg_hba.conf文件,添加正确的认证规则

host    all    gbase    IP/32    trust

检查数据库用户权限:确保连接的数据库用户具备足够的权限,执行以下命令检查数据库用户权限:

SELECT * FROM pg_user;

三、性能瓶颈

3.1 故障描述

在生产环境中,数据库可能会出现性能瓶颈,导致数据库响应变慢。常见的性能问题包括查询延迟、写入性能差、锁竞争等。

3.2 故障排查

查看数据库资源使用情况: 使用top命令或htop命令查看CPU、内存使用情况。如果数据库的CPU或内存使用过高,可能会影响性能。

查看锁信息: 查询系统中的锁信息,查看是否存在锁竞争。执行以下SQL语句:

SELECT * FROM pg_locks;

查询执行计划: 如果查询性能较差,可以使用EXPLAIN ANALYZE来查看SQL查询的执行计划,找出查询瓶颈:

EXPLAIN ANALYZE SELECT * FROM my_table WHERE condition;

分析慢查询: 检查数据库是否存在慢查询,可以通过启用慢查询日志来获取相关信息:

###cn参数调整

gs_guc reload -N all -I all -Z coordinator -c "log_duration=on"

gs_guc reload -N all -I all -Z coordinator -c "log_min_duration_statement=5000"

gs_guc reload -N all -I all -Z coordinator -c "enable_stmt_track=on"

gs_guc reload -N all -I all -Z coordinator -c "track_stmt_stat_level='OFF,L1'"

gs_guc reload -N all -I all -Z coordinator -c "track_stmt_details_size=40960"

gs_guc reload -N all -I all -Z coordinator -c "instr_unique_sql_count=200000"

gs_guc reload -N all -I all -Z coordinator -c "track_stmt_parameter='on'"

###dn参数调整

gs_guc reload -N all -I all -Z datanode -c "log_duration=on"

gs_guc reload -N all -I all -Z datanode -c "log_min_duration_statement=5000"

gs_guc reload -N all -I all -Z datanode -c "enable_stmt_track=on"

gs_guc reload -N all -I all -Z datanode -c "track_stmt_stat_level='OFF,L1'"

gs_guc reload -N all -I all -Z datanode -c "track_stmt_details_size=40960"

gs_guc reload -N all -I all -Z datanode -c "instr_unique_sql_count=200000"

gs_guc reload -N all -I all -Z datanode -c "track_stmt_parameter='on'"

查询方式:

SELECT * FROM STATEMENT_HISTORY where  (finish_time - start_time)> interval '5s';

磁盘IO瓶颈: 如果数据库的磁盘IO非常高,可能会导致性能瓶颈。可以使用iostat命令查看磁盘IO情况:

iostat -xmt 1

3.3 解决办法

调整数据库配置: 根据系统资源和负载情况,调整数据库的配置参数,如shared_buffers、work_mem、maintenance_work_mem等,以提高数据库的性能。

优化查询语句: 针对查询性能较差的SQL语句,进行索引优化和查询重写,避免全表扫描,使用合适的索引提升查询性能。

增加硬件资源: 如果系统资源不足,可以考虑扩展硬件资源,如增加内存、CPU、磁盘空间等,来缓解性能瓶颈。

避免锁竞争: 对于锁竞争问题,可以通过合理的事务设计和锁粒度控制来减少锁冲突。

原文链接:https://www.gbase.cn/community/post/4987

更多精彩内容尽在南大通用GBase技术社区,南大通用致力于成为用户最信赖的数据库产品供应商。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 217,734评论 6 505
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,931评论 3 394
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 164,133评论 0 354
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,532评论 1 293
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,585评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,462评论 1 302
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,262评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,153评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,587评论 1 314
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,792评论 3 336
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,919评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,635评论 5 345
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,237评论 3 329
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,855评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,983评论 1 269
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,048评论 3 370
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,864评论 2 354

推荐阅读更多精彩内容