# 国产数据库运维避坑案例整理
> 整理自用户提供的《新炬运维避坑指南合集》41 篇离线文章。按案例涉及的主要技术归类，归纳原文中的现象、排查处置和建议；案例措施仅代表原文环境，执行前应按当前版本、拓扑和变更流程复核。
共整理 **95 个案例**。期数按专辑标题编号；来源链接取自离线文章元数据。
[查看或下载 Markdown 原稿](新炬运维避坑案例整理.md)
## 案例目录
- [第 41 期｜Gbase 消费kafka数据时卡住问题分析](#case-1)
- [第 41 期｜Panweidb 内存溢出，导致数据库进程重启问题分析](#case-2)
- [第 41 期｜Panweidb 版本升级失败问题分析](#case-3)
- [第 41 期｜Panweidb user_tables表查询不到业务表的信息问题分析](#case-4)
- [第 41 期｜Goldendb 执行DDL操作导致表被禁用问题分析](#case-5)
- [第 41 期｜Goldendb 新创建库建表报错问题分析](#case-6)
- [第 40 期｜antdb 流复制异常问题分析](#case-7)
- [第 40 期｜PanweiDB 升级异常问题分析](#case-8)
- [第 40 期｜PanweiDB dtp数据迁移问题分析](#case-9)
- [第 40 期｜GreatDB 内存无法释放问题分析](#case-10)
- [第 39 期｜GoldenDB CN内存溢出问题分析](#case-11)
- [第 39 期｜GoldenDB-MDS-JOB执行超时导致备份失败问题分析](#case-12)
- [第 39 期｜goldendb DN的慢SQL问题分析](#case-13)
- [第 39 期｜Gbase8c DN的慢SQL问题分析](#case-14)
- [第 38 期｜PanweiDB 宕机问题分析](#case-15)
- [第 37 期｜PanWeiDB 业务端无法连接数据库问题分析](#case-16)
- [第 37 期｜PanweiDB 备库以及备中心查询报错问题分析](#case-17)
- [第 37 期｜PanWeiDB 磐维数据库个人账号赋权后建表报错反馈无权限问题分析](#case-18)
- [第 36 期｜Goldendb数据库cdc复制关系异常](#case-19)
- [第 36 期｜Goldendb数据库RDB主备数据不一致](#case-20)
- [第 36 期｜Gbase8c异常问题分析](#case-21)
- [第 36 期｜Gbase8c异机备份报错问题分析](#case-22)
- [第 35 期｜PanweiDB 单个节点CPU使用率100%](#case-23)
- [第 35 期｜PanweiDB 数据库dtp反向迁移问题](#case-24)
- [第 35 期｜PanweiDB 数据库调整参数导致数据库hang死](#case-25)
- [第 35 期｜PanweiDB 数据库异构数据迁移数据变化不一致](#case-26)
- [第 35 期｜PanweiDB MySQL到磐维异构数据迁移bit数据类型不兼容](#case-27)
- [第 35 期｜PanweiDB MySQL到磐维异构数据迁移反向增量同步问题](#case-28)
- [第 33 期｜磐维数据迁移问题](#case-29)
- [第 33 期｜磐维数据库用户存在drop schema的权限问题](#case-30)
- [第 33 期｜antdb的ddl语句问题](#case-31)
- [第 32 期｜goldendb主键唯一索引问题](#case-32)
- [第 32 期｜goldendb无法连接cn](#case-33)
- [第 32 期｜GOLDENDB数据库集群安装过程问题](#case-34)
- [第 32 期｜teledb(mysql)主库线程数高](#case-35)
- [第 31 期｜磐维数据库wal apply的操作与query冲突](#case-36)
- [第 31 期｜磐维数据库CMServer状态异常](#case-37)
- [第 31 期｜磐维数据库句柄不释放](#case-38)
- [第 30 期｜磐维数据库dtp迁移问题分析](#case-39)
- [第 30 期｜磐维数据库迁移乱码问题分析](#case-40)
- [第 30 期｜磐维数据库互信失效问题分析](#case-41)
- [第 27 期｜磐维数据库长会话僵死](#case-42)
- [第 27 期｜磐维分布式数据库不支持自定义dcs组件数据目录](#case-43)
- [第 27 期｜goldendb数据库业务响应慢](#case-44)
- [第 27 期｜gbase8c数据库执行计划不能下推dn](#case-45)
- [第 26 期｜磐维数据库SQL执行不一致问题分析](#case-46)
- [第 26 期｜磐维数据库同步归档删除异常问题分析](#case-47)
- [第 26 期｜磐维数据库python3版本导致数据库预安装失败分析](#case-48)
- [第 24 期｜磐维数据库连接数限制问题分析](#case-49)
- [第 24 期｜磐维数据库字符集不兼容问题分析](#case-50)
- [第 23 期｜某系统的teledb数据库内存使用过高，占满主机内存](#case-51)
- [第 23 期｜行云数据库重启管理节点的XEA服务后，进程启动失败](#case-52)
- [第 22 期｜磐维数据库安装时密码输入不一致](#case-53)
- [第 22 期｜磐维目录使用率暴增，导致主节点hang住](#case-54)
- [第 22 期｜行云namenode节点服务重启后很快宕掉](#case-55)
- [第 22 期｜行云数据库集群同步数据有时会报错](#case-56)
- [第 21 期｜磐维数据目录使用率97%问题分析](#case-57)
- [第 21 期｜磐维数据库探活告警提示数据库无法链接](#case-58)
- [第 19 期｜goldendb 部分计算节点偶发性连接失败](#case-59)
- [第 19 期｜goldendb备库主备DN切换后备dn宕机](#case-60)
- [第 18 期｜ANTDB误删etcd的数据目录问题处理](#case-61)
- [第 18 期｜ANTDB数据库主机cpu突增问题分析](#case-62)
- [第 17 期｜goldendb 长时间执行sql导致cn断连](#case-63)
- [第 17 期｜goldendb 存储过程调用失败](#case-64)
- [第 17 期｜teledb 某系统数据库连接数过高引起的问题](#case-65)
- [第 14 期｜磐维集群节点状态unkown报错处理](#case-66)
- [第 14 期｜磐维2.0数据库安装问题](#case-67)
- [第 13 期｜antdb安装部署后检查报错](#case-68)
- [第 13 期｜goldendb 镜像分片数据与源端不一致](#case-69)
- [第 13 期｜goldendb cn断连](#case-70)
- [第 12 期｜磐维数据库主节点呈现readonly状态处置](#case-71)
- [第 12 期｜磐维2.0版本数据库添加数据库白名单出现白名单覆盖的情况](#case-72)
- [第 12 期｜ANTDB数据库复制主库性能抖动处理](#case-73)
- [第 12 期｜ANTDB数据库监控节点丢失处理](#case-74)
- [第 12 期｜GreatDB数据库主机开启防火墙导致节点通信故障](#case-75)
- [第 11 期｜磐维数据库使用一段时间后，无法正常启动](#case-76)
- [第 11 期｜磐维数据库高可用组件cm选主异常处理](#case-77)
- [第 11 期｜磐维数据库安装完成后无法启动](#case-78)
- [第 10 期｜Gbase DDL recover影响到其他的用户insert](#case-79)
- [第 10 期｜goldendb nsight界面无法查看主备延迟](#case-80)
- [第 10 期｜goldendb DB备机回放期间，备机服务器断电重启，start slave出现异常](#case-81)
- [第 10 期｜panweidb不支持序列+大序列问题](#case-82)
- [第 9 期｜Gbase版本V9.5.2存在产品缺陷](#case-83)
- [第 9 期｜gaussdb200数据库无法使用](#case-84)
- [第 8 期｜磐维数据库修改参数后无法拉起](#case-85)
- [第 8 期｜GOLDENDB通过CN节点无法查询到新增的分区](#case-86)
- [第 7 期｜goldendb日志集解析时间边长处置](#case-87)
- [第 7 期｜goldendb迁移过程问题分析](#case-88)
- [第 6 期｜磐维数据库预安装报错](#case-89)
- [第 6 期｜Goldendb在线创建索引导致业务堵塞](#case-90)
- [第 5 期｜行云数据库目录使用节点不平衡处置](#case-91)
- [第 5 期｜Greatdb](#case-92)
- [第 5 期｜万里开源数据库添加字段报错异常处置](#case-93)
- [第 3 期｜磐维数据库主机重启后cmserver无法启动](#case-94)
- [第 1 期｜kingbase数据库无法连接问题处置](#case-95)
## 第 41 期｜Gbase 消费kafka数据时卡住问题分析
- 专辑文件：`01.html`，第 2 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247568126&idx=1&sn=5c70643df2d7921483070f36dfc24fa2&chksm=f88d5afc1c9d4ff2e8d61031f12da621c29e3d27be34c690bf1fa4fe8a3b8cb6840422f97ffb#rd)
- **现象：** gbase消费kafka数据时卡住，偏移量停滞不动，经原厂工程师分析原因是线程池被占据完了导致死锁。
- **处置过程：** 重启整个集群；全局修改参数gbase_parallel_degree默认0改成8；后续集群升级patch16.10修复
- **运维建议：** 将 gbase_parallel_degree 参数全局调整为 8（或根据集群规模适配），合理控制线程并行度，避免线程池过载。；及时将 Gbase 集群升级至 patch16.10 及以上版本，彻底修复线程死锁缺陷，从根源规避问题。；新增 Kafka 消费偏移量、Gbase 线程池使用率监控，偏移量停滞、线程池占满时触发告警，提前干预。
## 第 41 期｜Panweidb 内存溢出，导致数据库进程重启问题分析
- 专辑文件：`01.html`，第 3 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247568126&idx=1&sn=5c70643df2d7921483070f36dfc24fa2&chksm=f88d5afc1c9d4ff2e8d61031f12da621c29e3d27be34c690bf1fa4fe8a3b8cb6840422f97ffb#rd)
- **现象：** 内存溢出，导致数据库进程重启，主节点漂移。
- **处置过程：** 接收到数据库无法连接告警，登录主机查看日志，大量断链告警，数据重启切换备库告警。；查看osw日志，；日志停止打印，查看最后一次内存信息，内存使用率接近100%。
- **运维建议：** 内存溢出故障需优先排查 “内存占用源头”，而非仅关注进程重启；故障核心是内存拉升脚本持续占用内存，导致内存使用率接近 100%，触发进程重启、主节点漂移，而非单纯的进程异常。后续遇到集群进程重启、主备切换，需先查看内存使用率、进程内存占用，优先定位内存异常，而非盲目重启进程。；临时止损不能替代根源治理
## 第 41 期｜Panweidb 版本升级失败问题分析
- 专辑文件：`01.html`，第 4 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247568126&idx=1&sn=5c70643df2d7921483070f36dfc24fa2&chksm=f88d5afc1c9d4ff2e8d61031f12da621c29e3d27be34c690bf1fa4fe8a3b8cb6840422f97ffb#rd)
- **现象：** PanWeiDB V2.0-S3.0.0_B01升级到PanWeiDB V2.0-S3.2.0_B01升级失败。
- **处置过程：** PanWeiDB V2.0-S3.0.0_B01需要先升级到PanWeiDB V2.0-S3.0.2_B02；；然后再从PanWeiDB V2.0-S3.0.2_B02升级到PanWeiDB V2.0-S3.2.0_B01。
- **运维建议：** 严格遵守数据库版本升级路径规范，禁止跨级越级升级；国产数据库均存在固定升级链路，不支持任意版本跨级直接升级。本次因未提前核实官方标准升级路径，直接进行跨版本升级，导致升级失败。；后续版本升级前，必须查阅官方升级文档，确认源版本、过渡版本、目标版本的完整升级顺序。
## 第 41 期｜Panweidb user_tables表查询不到业务表的信息问题分析
- 专辑文件：`01.html`，第 5 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247568126&idx=1&sn=5c70643df2d7921483070f36dfc24fa2&chksm=f88d5afc1c9d4ff2e8d61031f12da621c29e3d27be34c690bf1fa4fe8a3b8cb6840422f97ffb#rd)
- **现象：** 数据从Oracle迁移到磐维后, 业务验证时反馈user_tables表查询不到业务表的信息, 但是在测试环境查询是正常的。
- **处置过程：** 单独将表user_tables赋权给业务用户, 业务查询还是没有数据。；检查该视图对应的语句发现条件是；dba_tables.owner::text = quote_ident_redwood("session_user"()::text)
- **运维建议：** 迁移前置检查；新增「对象属主一致性检查」项，确保所有业务表 OWNER = 业务用户；；视图适配规范
## 第 41 期｜Goldendb 执行DDL操作导致表被禁用问题分析
- 专辑文件：`01.html`，第 6 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247568126&idx=1&sn=5c70643df2d7921483070f36dfc24fa2&chksm=f88d5afc1c9d4ff2e8d61031f12da621c29e3d27be34c690bf1fa4fe8a3b8cb6840422f97ffb#rd)
- **现象：** GoldenDB执行DDL操作导致表被禁用，有DDL操作；，对表添加字段，执行过程中报对象资源争用。登录insight平台确认，被禁用的表是上线操作的表。
- **处置过程：** 登录insight平台解锁被禁用的表，查询DN和CN上面的建表语句是否一致，上线操作中的DDL语句是否被成功执行；如果不一致，CN和DN执行删除多的字段。
- **运维建议：** 对表在执行DDL操作前对表进行锁表（不同版本不一定支持，使用争抢的语句处理）；锁表：gdblock table 表名;；执行DDL语句;
## 第 41 期｜Goldendb 新创建库建表报错问题分析
- 专辑文件：`01.html`，第 7 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247568126&idx=1&sn=5c70643df2d7921483070f36dfc24fa2&chksm=f88d5afc1c9d4ff2e8d61031f12da621c29e3d27be34c690bf1fa4fe8a3b8cb6840422f97ffb#rd)
- **现象：** mysql（utf8）迁移到goldendb mysql（ utf8mb4）模式新创建库建表报错；ERROR 1071 (HY000): Specified key was too long: max key length is 3072 bytes。
- **处置过程：** 创建的索引（Index）、主键（Primary Key）或唯一约束（Unique Key）的总长度超过了 InnoDB 引擎允许的最大限制（3072 字节）。；MySQL 5.6+ / 5.7 / 8.0 (默认 ROW_FORMAT=DYNAMIC 或 COMPRESSED)：最大键长为 3072 字节。；索引总长度=∑(列定义长度×字符集单字符最大字节数)，字符集是 utf8mb4（ 4 字节），utf8 (3字节)。
- **运维建议：** utf8→utf8mb4 字符集切换，是索引超长报错的直接诱因，4 字节计算是核心；innodb_page_size 必须在库初始化前配置，创建后无法修改，是最关键的前置规划项；迁移前索引长度自动化校验+初始化参数标准化，可 100% 避免此类 DDL 报错
## 第 40 期｜antdb 流复制异常问题分析
- 专辑文件：`02.html`，第 2 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247567656&idx=1&sn=48de376653bfb9065a300abe1d26e315&chksm=f85147bae7ff69ea5e36646df0abaa51bb9cac0106ec5f7eac5bba01ec65597665b3f4655238#rd)
- **现象：** antdb 5.O的slave节点dn10_1、dn1_3、dn1_4流复制异常。；通过分析发现是由于wal日志损坏导致，原理是当从库在恢复过程中遇到一个损坏的WAL记录时，它会正确地跳过该记录，并在日志中报告一次 incorrect checksum错误。；但是恢复进程会在内部状态中“卡住”，反复报告同一个损坏记录的校验和错误，即使该记录早已被跳过。由于恢复进程异常，无法继续推进恢复位置（LSN），最终会导致从库的恢复进度停滞。
- **处置过程：** 重建备节点(最安全的方式)；注：由于是异步备节点，重建期间暂未发现会影响业务。；重建复制槽
- **运维建议：** 新增备节点流复制状态、WAL 日志校验监控，设置 LSN 停滞、反复报校验和错误告警；制定备节点重建标准化流程，确保故障发生时可快速落地。；建立 AntDB 版本管控机制，选型、升级时优先排查核心功能相关 BUG；定期巡检备节点，完善 WAL 日志存储与备份策略，避免日志损坏。；确保备节点数量充足，明确应急联络人，定期演练备节点重建流程，防止多台备节点同时失效，保障数据一致性。
## 第 40 期｜PanweiDB 升级异常问题分析
- 专辑文件：`02.html`，第 3 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247567656&idx=1&sn=48de376653bfb9065a300abe1d26e315&chksm=f85147bae7ff69ea5e36646df0abaa51bb9cac0106ec5f7eac5bba01ec65597665b3f4655238#rd)
- **现象：** 集集中式数据库升级异常。；新版本PanWeiDB_V2.0-S3.2.0_B01，所以需要将原来的PanWeiDB_V2.0-S2.0.2_B01升级至最新版本，升级过程中遇到报错，通过分析发现是大小写参数敏感设置导致，修改参数值之后，重新升级正常。
- **处置过程：** 预检查已正常完成，开始跑升级脚本。；升级报错如下；./pwpatch upgrade
- **运维建议：** 数据库升级前需要对兼容性进行详细检查，确认升级条件满足后再执行升级任务；版本升级前最好回退预案，保证数据库服务的可用性
## 第 40 期｜PanweiDB dtp数据迁移问题分析
- 专辑文件：`02.html`，第 4 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247567656&idx=1&sn=48de376653bfb9065a300abe1d26e315&chksm=f85147bae7ff69ea5e36646df0abaa51bb9cac0106ec5f7eac5bba01ec65597665b3f4655238#rd)
- **现象：** 使用dtp进行数据迁移时，function函数创建失败，部分package不存在，导致函数无法创建等问题，经核查是由于dtp无法同步package问题导致。
- **处置过程：** 手动创建package，并对依赖package的函数，存储过程等进行重编译。
- **运维建议：** 测试 DTP 工具对 package、函数等复杂对象的迁移支持度，梳理工具无法迁移的对象清单，制定手动创建方案。；实时监控迁移日志，重点关注对象创建情况，及时处置 package、函数创建失败问题，避免问题积累。；开展全量比对校验，核对对象完整性（含 package）、数据一致性，对依赖 package 的对象进行重编译，确保所有对象可用。
## 第 40 期｜GreatDB 内存无法释放问题分析
- 专辑文件：`02.html`，第 5 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247567656&idx=1&sn=48de376653bfb9065a300abe1d26e315&chksm=f85147bae7ff69ea5e36646df0abaa51bb9cac0106ec5f7eac5bba01ec65597665b3f4655238#rd)
- **现象：** greatdbcluster5.0.8数据库在使用过程中，主机内存空闲率会不断的降低，且自身无法主动释放内存。
- **处置过程：** 基于两个维度清理cache；每5分钟清理一次。；主机空闲内存少于阈值触发清理。
- **运维建议：** 数据库内核存在内存泄漏特性；GreatDB Cluster 5.0.8 版本自身内存回收机制不完善，运行过程中占用内存持续累积，无自动释放机制，属于版本固有问题，日常运行需重点监控主机内存使用率。；建立内存预警与自动化清理机制
## 第 39 期｜GoldenDB CN内存溢出问题分析
- 专辑文件：`03.html`，第 2 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247567258&idx=1&sn=cb8acfe46934b2308d8a1d2fdffbd82d&chksm=f86bd7bd1375aa91592abd5c32a6a03bcf4bf5511b5019700146f1431f58d23e38d09f81e217#rd)
- **现象：** CN内存溢出问题分析。
- **处置过程：** 观测到租户周期性内存溢出，需要重启DN层才能释放内存；tcmalloc 分析正常；GCORE文件内容分析定位内存使用率最高的SQL
- **运维建议：** 定位并优化高耗内存 SQL，避免大查询、长事务、大量 prepare；根据业务场景合理关闭或限制 prepare 机制，防止内存累积；建立 CN/DN 内存周期性观测机制，及时发现上涨趋势
## 第 39 期｜GoldenDB-MDS-JOB执行超时导致备份失败问题分析
- 专辑文件：`03.html`，第 3 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247567258&idx=1&sn=cb8acfe46934b2308d8a1d2fdffbd82d&chksm=f86bd7bd1375aa91592abd5c32a6a03bcf4bf5511b5019700146f1431f58d23e38d09f81e217#rd)
- **现象：** GoldenDB-MDS-JOB执行超时导致备份失败问题。
- **处置过程：** 通过MDS确定到jobs执行超时错误；通过MDS定位到CN执行压力大；通过CN压力大定位到DN执行压力大
- **运维建议：** 建立备份前巡检机制；备份前检查 CN、DN 节点负载、Redo 刷新速度，负载超标时延迟备份，避免 MDS-JOB 超时。；完善全链路监控
## 第 39 期｜goldendb DN的慢SQL问题分析
- 专辑文件：`03.html`，第 8 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247567258&idx=1&sn=cb8acfe46934b2308d8a1d2fdffbd82d&chksm=f86bd7bd1375aa91592abd5c32a6a03bcf4bf5511b5019700146f1431f58d23e38d09f81e217#rd)
- **现象：** DN的慢SQL中出现commit\g；；根据日志查看commit\g 这个慢SQL集中出现于每天8点-9点半，慢SQL耗时主要在ack_wait_time上，ack_wait_time耗时主要是在等待备机回响应。；通过查看历史主备延迟趋势发现，每天8点-9点半会出现超过7000s。
- **处置过程：** 解析峰值时段得binlog发现；存在日调度 `db`.`table_20260207` （大宽表 167字段，53索引） 得插入操作，原始语句是insert多条记录插入，频次大概为 1分钟 几百万条，大概2千次做一次提交。每次事务延迟4~5秒（ 7点52分 追到8点41分）.；对表分析发现，存在大量未使用过索引。
- **运维建议：** 禁止超大事务，批量插入必须拆分为小事务，提高提交频率；清理无用索引、低选择性索引，写入类表索引数量必须合理管控；定时调度任务（日切、日终、批量插入）必须错峰、限流、分批执行
## 第 39 期｜Gbase8c DN的慢SQL问题分析
- 专辑文件：`03.html`，第 9 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247567258&idx=1&sn=cb8acfe46934b2308d8a1d2fdffbd82d&chksm=f86bd7bd1375aa91592abd5c32a6a03bcf4bf5511b5019700146f1431f58d23e38d09f81e217#rd)
- **现象：** 数据库存储目录在一个月内异常膨胀超过50%，导致磁盘空间告急。业务侧反映查询和写入性能显著下降，响应缓慢。
- **处置过程：** 经分析，核心原因为业务侧大量存储过程（SP）中包含了高频的DELETE和UPDATE操作，产生了巨量的过期行（死元组）。大量空间无法被有效回收复用。；首先，紧急修改实例级autovacuum相关参数，显著降低触发阈值、提高并行度与成本限制，以加速清理进程。；autovacuum_vacuum_scale_factor
- **运维建议：** 对于存在高频UPDATE/DELETE的业务系统，必须在数据库上线前评估并制定非默认的autovacuum参数策略与表级存储参数（如FILLFACTOR）；必须建立对表膨胀率、死元组数量、autovacuum效率的常态化监控，而非仅监控磁盘空间使用率
## 第 38 期｜PanweiDB 宕机问题分析
- 专辑文件：`04.html`，第 10 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247566942&idx=1&sn=beb8d9dedea5fbd7b5f81620ec6c1ee9&chksm=f88cfa4e3c4c1978f4683d85661e69ba8b3c849532f6c72297a026479f161a1222e1a769f6c5#rd)
- **现象：** 主库发生宕机(core)导致主备角色切换，经业务反馈在这个时间段内执行了创建分区表的操作
- **处置过程：** 通过数据库日志和配置文件参数检查发现，localsyscachethreshold=32MB 参数值较小，去掉该参数恢复数据库默认值 256M,重新跑建分区的脚本，数据库正常。
- **运维建议：** 为 pg 分区表读取 syscache 时，因分区信息占用的表元数据缓存信息较多，所以会触发元数据缓存淘汰，淘汰后，记录分区表分区条件的指针指向错误地址，导致宕机。；通过将参数 local_syscache_threshold调成 256MB后，同样语句未出现宕机，但从代码逻辑上，如果分区个数持续增多，还有可能出现此问题。；将系统内的分区表重建为 oracle 的分区表语法格式规避。
## 第 37 期｜PanWeiDB 业务端无法连接数据库问题分析
- 专辑文件：`05.html`，第 2 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247566533&idx=1&sn=11ecbd808f10f786c867e1e3ae953a0c&chksm=f8f446b9c87027cc675c1fe462ddc7e885a328c528ec75f48ef8589aead153daf70da9d74252#rd)
- **现象：** 多套磐维数据库在XXXX年X月XX日上午发生异常，业务端无法连接数据库，现场测试gsql登录数据库卡顿。根据现场收集的信息来看，业务中有使用子事务的情况。但是在子事务过多的情况下，会因为对数组遍历的速度比较慢，导致长时间持有锁，从而导致其他线程取不到锁，最终表象显示为业务无法访问数据库、gsql连接超时。
- **处置过程：** 首先检查数据库主机资源使用情况，主机cpu、内存使用正常，io没有等待。继续检查数据库进程的资源使用情况，top命令可以发现panweidb进程的CPU使用率到达812%，说明panweidb正在执行大量逻辑操作。该数据库当前为准生产环境，并没有大量业务访问，可以排除业务层面原因。继续分析数据库内部线程的资源使用情况，可以发现多个AVCworker正常占用大量CPU，该线程负责自动触发vacuum和analyze。检查其他异常数据库线程，情况相同。；至此现场怀疑是AVCworker线程占用大量CPU资源导致的数据库异常。；对磐维进程做pstack，从堆栈信息可以看出，部分线程陷入锁逻辑，在等待ProcArrayLock，包括上述提及的AVCworker线程。分析对应函数TransactionIdInProgress…
- **运维建议：** 根据现场日志和代码分析确认，本次故障主要原因为；大量未提交子事务导致的TransactionIdInProgress 函数遍历速度下降，引起ProcArrayLock争用。；减少子事务功能的使用或者及时提交事务来防止积累过多的子事务；
## 第 37 期｜PanweiDB 备库以及备中心查询报错问题分析
- 专辑文件：`05.html`，第 3 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247566533&idx=1&sn=11ecbd808f10f786c867e1e3ae953a0c&chksm=f8f446b9c87027cc675c1fe462ddc7e885a328c528ec75f48ef8589aead153daf70da9d74252#rd)
- **现象：** 备库以及备中心查询报错，；User query might have needed to see row versions that must be removed，；如果主中心的表在vacuum或者执行DDL、DML操作，WAL在备节点回放时，备节点上的查询还在继续，此时就会发生冲突，强制退出备节点查询的语句，影响读写分离业务查询（含大数据）。
- **处置过程：** 查看备库主机资源情况均正常。进一步分析PG_LOG也未发现异常。通过报错关键字搜索发现网络上存在相同案例。；并行日志回放的最大线程数，在传统的单线程回放模式下，备机需要顺序处理接收到的日志（WAL），当主库负载很高时，备机可能会因为回放速度跟不上而产生延迟。通过设置recovery_max_workers大于1，可以开启并行回放功能，允许多个线程同时处理不同表的日志，从而显著缩短备机的数据同步时间，降低RTO。；max_standby_streaming_delay
- **运维建议：** 将版本升级至在3.2.0 包基础上；新版本优化了串行回放的逻辑，使备机可以在任意时刻拿快照。；备库修改参数
## 第 37 期｜PanWeiDB 磐维数据库个人账号赋权后建表报错反馈无权限问题分析
- 专辑文件：`05.html`，第 4 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247566533&idx=1&sn=11ecbd808f10f786c867e1e3ae953a0c&chksm=f8f446b9c87027cc675c1fe462ddc7e885a328c528ec75f48ef8589aead153daf70da9d74252#rd)
- **现象：** 业务要求个人账号（具有登陆权限的role）需要对应业务schema的建表权限，但经测试磐维数据库个人账号赋权后建表报错反馈无权限，除非grant role to 个人账号（role为schema的属主user），该权限过大（具有删除schema的权限），赋予个人账号存在安全风险。
- **处置过程：** 将schema的owner改为数据库安装用户即可解决。；alter schema；schema_name owner
- **运维建议：** 用户权限管控；这是一个在运维过程中特别重要的环节，涉及到安全运维以及后期安全审计。；但各国产数据库厂商或者应用都是为了图方便，采用大权限，如果在数据库使用过程中采用最小权限原则进行权限设计是一个重点研究的课题。
## 第 36 期｜Goldendb数据库cdc复制关系异常
- 专辑文件：`06.html`，第 2 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247566146&idx=1&sn=d15673a55794256f56a08199fdaa4f5e&chksm=f8da78c3bc74479f90c68a5f1478e3868ea12da851580e2c822515544f5e68742f252cdd02f0#rd)
- **现象：** cdc复制关系异常。
- **处置过程：** 登录cdc节点，查询cdc的~/log/mysqld.log日志trx gtid的error信息。；修改报错日志中的ctid号的强制合并参数force_merge=0；mysql.cdc_discard_trx_ctid_info
- **运维建议：** CDC ( Change Data Capture )节点指变动数据捕获节点，用于对 GoldenDB 数据库分布式模式下各个分片的 DN 节点进行数据捕获；已提交事务回滚失败，导致gitd不一致报错
## 第 36 期｜Goldendb数据库RDB主备数据不一致
- 专辑文件：`06.html`，第 3 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247566146&idx=1&sn=d15673a55794256f56a08199fdaa4f5e&chksm=f8da78c3bc74479f90c68a5f1478e3868ea12da851580e2c822515544f5e68742f252cdd02f0#rd)
- **现象：** insight告警平台发现报“RDB主备数据不一致”告警。
- **处置过程：** 主管理节点的rdbagent日志中查询关键词inconsistent，发现表mds.gtm_info存在数据不一致问题。；xxx.xxx.xxx.17RDB备节点表mds.gtm_info 中有3条数据的字段 gtm_status 字段与主RDB不一致。；登录xxx.xxx.xxx.17 节点，切换用户到insight，停止备机复制。
- **运维建议：** 增加日志类监控，及时发现此类问题。
## 第 36 期｜Gbase8c异常问题分析
- 专辑文件：`06.html`，第 5 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247566146&idx=1&sn=d15673a55794256f56a08199fdaa4f5e&chksm=f8da78c3bc74479f90c68a5f1478e3868ea12da851580e2c822515544f5e68742f252cdd02f0#rd)
- **现象：** 主库在 发生异常，系统检测到所有 HA peer 心跳失败，触发强制停止实例操作，随后由管理进程重新启动主库为 primary 模式。期间连接报错；“transaction aborted as connection handles were destroyed due to clean up stream failed”。
- **处置过程：** 故障发生时 CN 报错；$GAUSSLOG/pg_log/cn2/***.log：failed to fetch tuples from datanodes, remote close socket unexpectedly。；GTM 日志显示多会话超时被关闭
- **运维建议：** 优化节点心跳超时时间或检测机制；确认集群各节点间网络稳定性；定期验证 GTM、CN、DN 间连接可达性与超时配置
## 第 36 期｜Gbase8c异机备份报错问题分析
- 专辑文件：`06.html`，第 6 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247566146&idx=1&sn=d15673a55794256f56a08199fdaa4f5e&chksm=f8da78c3bc74479f90c68a5f1478e3868ea12da851580e2c822515544f5e68742f252cdd02f0#rd)
- **现象：** gbase8c异机备份报错；Connection timed out,client_loop:send disconnect:Broken pipe；后续发现主机负载高峰时间段备份仍会出现偶发性wal日志传输失败，手动调整错峰备份后显著降低。
- **处置过程：** 怀疑传输日志超时导致，调整了；"wal_receiver_timeout = 1800s","wal_sender_timeout = 1800s";；调整后依旧报错，继续调整sshd参数，
- **运维建议：** 做数据备份时要考虑网络传输带宽以及ssh传输超时问题，可适当调整备份线程数和调度任务以错峰执行。
## 第 35 期｜PanweiDB 单个节点CPU使用率100%
- 专辑文件：`07.html`，第 3 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247565525&idx=1&sn=032fc04a0b8c59485c6a90c5bd16cbf4&chksm=f878079741ce6530b83f3b900fafebf674a8713591c424ca0988d4fabd291083581bbb8eada5#rd)
- **现象：** 业务侧并发抽数时报错；An I/O error occurred while sending to the backend。
- **处置过程：** 默认情况下，驱动会一次性从数据库端获取所有数据，对于数据量很大JDBC提供了基于游标的Resultset，批量获取数据集，使用方法如下；少查询，这会占用客户端大量内存，甚至造成00M，为避免此类情况；设置autoCommit为false；
- **运维建议：** 客户端的游标配置与服务端资源管理必须协同设计，尤其需关注 autoCommit 对游标生命周期的决定性影响；将 autoCommit=false + fetchSize>0 纳入数据库访问层强制标准；；建立大查询熔断机制，防止单节点过载；
## 第 35 期｜PanweiDB 数据库dtp反向迁移问题
- 专辑文件：`07.html`，第 4 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247565525&idx=1&sn=032fc04a0b8c59485c6a90c5bd16cbf4&chksm=f878079741ce6530b83f3b900fafebf674a8713591c424ca0988d4fabd291083581bbb8eada5#rd)
- **现象：** DTP反向迁移至Oracle，同步链路异常中断后重启，导致数据库中产生大量的锁。
- **处置过程：** 接收告警查看数据库会话信息，发现有大量的锁等待，源头阻塞SQL类型为；ALTER TABLE table_name REPLICA IDENTITY FULL。；DTP同步链路中断后重启，每次都会将该链路中的所有表执行该动作。
- **运维建议：** 在 DTP 中禁用 auto_update_replica_identity 功能；；建立 表级锁实时熔断机制，早于业务告警干预；；迁移任务必须配置 Oracle 异步写入 降低同步压力。
## 第 35 期｜PanweiDB 数据库调整参数导致数据库hang死
- 专辑文件：`07.html`，第 5 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247565525&idx=1&sn=032fc04a0b8c59485c6a90c5bd16cbf4&chksm=f878079741ce6530b83f3b900fafebf674a8713591c424ca0988d4fabd291083581bbb8eada5#rd)
- **现象：** PanweiDB数据库调整synchronous_standby_Names参数导致数据库hang死。
- **处置过程：** 根据数据库日志分析可能是BUG导致和集团分析确认后是代码设计存在缺陷。；postmaster主线程拿lwlock必须要以非等待的模式来拿。；因为一旦拿不到锁，需要将自身加入等待队列，调用函数LWLockQueueSelf，在该函数中会判断t_thrd.proc非空（主线程此变量为空），从而触发panic宕机。
- **运维建议：** 生产环境，非必要不要轻易的去调整配置参数，生产环境保持稳定运行最重要。国产库在运维过程中可能会出现意想不到的情况。
## 第 35 期｜PanweiDB 数据库异构数据迁移数据变化不一致
- 专辑文件：`07.html`，第 6 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247565525&idx=1&sn=032fc04a0b8c59485c6a90c5bd16cbf4&chksm=f878079741ce6530b83f3b900fafebf674a8713591c424ca0988d4fabd291083581bbb8eada5#rd)
- **现象：** MySQL到磐维异构数据迁移使用dtp3.0.0_B01导致数据变化不一致。
- **处置过程：** MySQL源端列如果是auto_increment的，且从0开始，迁移到磐维数据库后0这一条数据会自动变成1，然后表里就可能会有2条数据为1的数据，如果该列为主键列或者唯一约束，约束会添加失败。
- **运维建议：** 该问题属于产品bug；需注意数据内容的对比，该问题无法在只校验源端与目标端行数的情况下发现，需要手动修复错误数据；将dtp升级至最新版本可避免
## 第 35 期｜PanweiDB MySQL到磐维异构数据迁移bit数据类型不兼容
- 专辑文件：`07.html`，第 7 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247565525&idx=1&sn=032fc04a0b8c59485c6a90c5bd16cbf4&chksm=f878079741ce6530b83f3b900fafebf674a8713591c424ca0988d4fabd291083581bbb8eada5#rd)
- **现象：** MySQL到磐维异构数据迁移bit数据类型不兼容，应用插入数据报错；You will need to rewrite or cast the expression.
- **处置过程：** 在MySQL端使用了bit(1)类型存储true/false或1/0数据，迁移至panwei后，不支持应用直接插入boolean值或smallint值。；该问题可通过修改表结构(可能影响其他业务)和添加临时转换解决。；鉴于业务多处使用，临时添加转换使用
- **运维建议：** 在迁移前建立 类型兼容性矩阵，标注所有敏感类型；；为关键类型（如 bit）配置 自动化重映射 规则；；在应用层 弃用数据库特异性类型，改用 ANSI SQL 标准类型。
## 第 35 期｜PanweiDB MySQL到磐维异构数据迁移反向增量同步问题
- 专辑文件：`07.html`，第 8 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247565525&idx=1&sn=032fc04a0b8c59485c6a90c5bd16cbf4&chksm=f878079741ce6530b83f3b900fafebf674a8713591c424ca0988d4fabd291083581bbb8eada5#rd)
- **现象：** MySQL到磐维异构数据迁移反向增量同步报插入 text类型字段超长；data too long for column xxx type text；，查看报错日志，单独提取报错语句在MySQL侧和磐维侧执行均无报错。
- **处置过程：** 磐维text数据类型最大存储1GB-1，MySQL text数据类型最大存储65536+2 byte。；主要问题在于；dtp报错语句并不一定是真正出问题的语句，也有可能是报错语句上一条执行的语句，找出真正报错的语句需要去查找增量日志，由于日志量极大且难以查阅需要使用kafka挖数工具对日志进行挖掘取到对应位点的语句，发现是一条列值超过7w字符的数据插入引起报错，与报错语句相差极大 。
- **运维建议：** 为同步任务启用 语句级序列号追踪，绑定错误与真实 SQL；；建立源端字段长度分布画像，迁移前识别超长风险；；在同步层部署智能截断和跳过机制，保障任务连续性。
## 第 33 期｜磐维数据迁移问题
- 专辑文件：`09.html`，第 1 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247564523&idx=1&sn=c8803dd8c63037aa584df7b8066885b5&chksm=f8a6eb1d08fa541fe00a67de53f6231f35a27610eadaf907f9f6b337f9eb86d055b16ce1515b#rd)
- **现象：** GoldenDB -> 磐维a模式。；char长度被扩大3倍（ char(n)变为char(3n) ），业务获取到的数据末尾有空格，导致报错。
- **处置过程：** GoldenDB，char(n)中的n代表字符；；磐维a模式，char(n)中的n代表字节；；在 UTF-8 编码中，一个英文字母占一个字节，一个中文占三个字节。
- **运维建议：** 自定义dtp迁移规则，将char变成varchar。
## 第 33 期｜磐维数据库用户存在drop schema的权限问题
- 专辑文件：`09.html`，第 2 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247564523&idx=1&sn=c8803dd8c63037aa584df7b8066885b5&chksm=f8a6eb1d08fa541fe00a67de53f6231f35a27610eadaf907f9f6b337f9eb86d055b16ce1515b#rd)
- **现象：** 磐维数据库用户对应会默认创建一个schema，且schema的默认owner为对应的用户，该用户存在drop schema的权限（且dbever在功能菜单上有drop的菜单），存在较大操作风险。
- **处置过程：** 将schema的ownre授予给管理员用户；此为治标方案，目前湖南区域正按照此方案实施。；回收schema的默认owner的方案
- **运维建议：** 将drop schema的权限从owner中剥离出来；drop schema的权限只有管理员（DBA）拥有，通过DBA可以单独去进行drop schema赋权。以降低生产误操作风险。；按照这样赋权后发现新的问题：业务用户 UOP_XX对增量的对象缺少访问权限。
## 第 33 期｜antdb的ddl语句问题
- 专辑文件：`09.html`，第 5 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247564523&idx=1&sn=c8803dd8c63037aa584df7b8066885b5&chksm=f8a6eb1d08fa541fe00a67de53f6231f35a27610eadaf907f9f6b337f9eb86d055b16ce1515b#rd)
- **现象：** 开发执行ddl语句，ddl语句长时间执行不完毕，一直等待，直到ctrl+c中断操作。
- **处置过程：** 2个gc（gtmcoord） ，一主一备，2个之间是实时同步复制，gc2挂掉了，gc1一直等到gc2的反馈，没有反馈就一直等待。；先停止gc的slave节点；stop gtmcoord slave
- **运维建议：** 同步复制在数据库环境中；特别是分布式环境中，是需要关注一点，比较的隐蔽，不像dn和cn出现问题那么的明显，gc节点没有那么的明显，从集群环境中观察都是没有问题，但是就是执行ddl语句不成功。；存在迷惑性
## 第 32 期｜goldendb主键唯一索引问题
- 专辑文件：`10.html`，第 6 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247564072&idx=1&sn=66e01de4913e95d6105acb286307659d&chksm=f8ce7c490ad51e946526d5c086d1a1b68b101c386c98e5cead5e0d73f2e96e4e42b000588425#rd)
- **现象：** 主键唯一索引问题。
- **处置过程：** 业务表查出来了2个相同的主键值，where 条件不同 业务返回不同的行数。；分析发现表是分区表，分区健不在主健内，DN remove_partition_key_limitation等于ON时，分区健不在主健内，只能保证分区内唯一。
- **运维建议：** 建表前分区表需要业务评估，是否需要保持主键全局唯一，DN参数 remove_partition_key_limitation是否改成off，分区健在主健内，避免主键值不唯一。
## 第 32 期｜goldendb无法连接cn
- 专辑文件：`10.html`，第 7 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247564072&idx=1&sn=66e01de4913e95d6105acb286307659d&chksm=f8ce7c490ad51e946526d5c086d1a1b68b101c386c98e5cead5e0d73f2e96e4e42b000588425#rd)
- **现象：** Goldendb DBPROXY版本：6.1.03.02.T7；收到告警，无法连接cn。
- **排查与原因：** distinct ... 语句，GDB内部会优化加order by，然后CN层走sort merge去重，这个流程再计算distinct之前如果需要CN层计算where过滤，导致触发了bug。
- **处置过程：** 登录主机参看cn节点状态，dbproxy进程已经被agent进程拉起，异常节点为业务节点。；通过查看dbproxy.log发现cn hang住被关闭，/data/core下发现重启后都有异常的core文件。；通过手动coredump文件发现是由于一条运维语句导致。
- **运维建议：** 运维人员只能访问运维CN，避免影响业务CN；问题代码需要整改；规范开发，禁止distinct ... 语句没有加order by的语句，并排查已有业务代码避免distinct ... 语句没有加order by，问题代码需要整改。
## 第 32 期｜GOLDENDB数据库集群安装过程问题
- 专辑文件：`10.html`，第 8 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247564072&idx=1&sn=66e01de4913e95d6105acb286307659d&chksm=f8ce7c490ad51e946526d5c086d1a1b68b101c386c98e5cead5e0d73f2e96e4e42b000588425#rd)
- **现象：** 集群安装过程中存在；用户鉴权失败、；RDB安装失败、
- **处置过程：** 问题1：用户鉴权失败；2025-03-05 11:02:57,955 [ERROR] - createGoldendbGroup.py(239) - *.*.10.62 root 用户鉴权失败，检查密码是否正确；vim /etc/ssh/sshd_config
- **运维建议：** 安装前准备工作做好，遇到异常根据报错提示逐步分析，一般情况，不用清理，调整后继续安装。
## 第 32 期｜teledb(mysql)主库线程数高
- 专辑文件：`10.html`，第 10 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247564072&idx=1&sn=66e01de4913e95d6105acb286307659d&chksm=f8ce7c490ad51e946526d5c086d1a1b68b101c386c98e5cead5e0d73f2e96e4e42b000588425#rd)
- **现象：** 主库线程数很高，连接数未到3000,但底层通过socket报too many connection，主从存在延迟无法完成切换。kill主库mysql进程拉起后一直在recovery状态无法恢复完成。
- **处置过程：** 查看两台从库的同步状态以及gtid值，确认从库同步到最新数据后再进行主从切换即可优先恢复故障。；查看gtid的语句：show global variables like '%gtid%'；；通过自动化运维平台teledb主从切换脚本进行主从切换；
- **运维建议：** 在业务高峰期，禁止进行大量批量操作，避免占用大量的主机和数据库资源。
## 第 31 期｜磐维数据库wal apply的操作与query冲突
- 专辑文件：`11.html`，第 1 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247563572&idx=1&sn=a1a1d2d99648a7eb07a728a262bf1174&chksm=f8e81ffa8afda84dad2f023ac6523d6c54e59de7815ea6d2468289bceebfd6d4c4238c2ad2d4#rd)
- **现象：** 磐维数据库集群节点2宕掉，原因是wal apply的操作与query冲突，疑似触发BUG。并且也因为此冲突导致无法节点启动。
- **处置过程：** 通过删除添加节点方式成功将节点加入集群。；出现冲突报错的原因可能是由以下几种情况产生；max_standby_streaming_delay参数值设置过低PostgreSQL的默认值是30s，openGauss 的默认值是3s，这个值需根据不同的业务应用去设置。
- **运维建议：** 适当增加max_standby_streaming_delay参数值，目前为默认值3S。具体数值调整为多少需要与磐维官方确认。
## 第 31 期｜磐维数据库CMServer状态异常
- 专辑文件：`11.html`，第 2 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247563572&idx=1&sn=a1a1d2d99648a7eb07a728a262bf1174&chksm=f8e81ffa8afda84dad2f023ac6523d6c54e59de7815ea6d2468289bceebfd6d4c4238c2ad2d4#rd)
- **现象：** 磐维数据库某个节点CMServer状态异常。
- **处置过程：** 收到告警提示，磐维数据库Datanode状态异常，核查相关日志发现是由于网络闪断导致CM监控不到其他节点的CM和DN状态导致 gs_om -t status --detail 命令运行的结果显示节点3状态异常，时长为一分钟左右，网络闪断时间点，主节点未受影响，正常对外提供服务。；联系主机网络厂商核查网络闪断的原因。
- **运维建议：** 加强对节点间网络通信状况的监控。
## 第 31 期｜磐维数据库句柄不释放
- 专辑文件：`11.html`，第 3 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247563572&idx=1&sn=a1a1d2d99648a7eb07a728a262bf1174&chksm=f8e81ffa8afda84dad2f023ac6523d6c54e59de7815ea6d2468289bceebfd6d4c4238c2ad2d4#rd)
- **现象：** truncate及drop表文件句柄不释放，进而导致空间无法释放。
- **处置过程：** 该问题为磐维数据库自身缺陷，临时是重启数据库释放句柄。
- **运维建议：** 根据前期与IT公司沟通协调，IT公司反馈在4月份版本中可以解决该问题，根据IT公司提供的新版本， 已完成对相关磐维数据库升的级工作；（cm和om均需要升级）；，目前已升级到V2.0-S3.1.1版本
## 第 30 期｜磐维数据库dtp迁移问题分析
- 专辑文件：`12.html`，第 5 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247563201&idx=1&sn=721943503d74d423fd5b1494b25135a6&chksm=f8df435ecb05f7700e1cc92b73ebbd62d8edda63efe48a6b1604a22a11f07fd5c541c73b3e30#rd)
- **现象：** 某割接窗口期，某业务系统启动12个业务用户至磐维数据库的全量数据迁移。前11个用户数据量均小于T级，迁移顺利，于次日凌晨12:30左右完成，历时约3.5小时。最后一个用户A数据量较大；（1.34TB）；，于凌晨1:00启动迁移，但次日下午14:00发现DTP无法访问，页面空白，无反馈。
- **处置过程：** 进程状态无异常，panwei_dtp有相关的进程。；端口状态无异常，31030是dtp的默认开放端口。；curl排查
- **运维建议：** 根据官方文档的，最大堆内存；（Xmx）；和初始堆内存
## 第 30 期｜磐维数据库迁移乱码问题分析
- 专辑文件：`12.html`，第 6 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247563201&idx=1&sn=721943503d74d423fd5b1494b25135a6&chksm=f8df435ecb05f7700e1cc92b73ebbd62d8edda63efe48a6b1604a22a11f07fd5c541c73b3e30#rd)
- **现象：** 某割接窗口期，某业务系统启动12个业务用户至磐维数据库的全量数据迁移，迁移后发现目标库的中文注释全部乱码，英文、数字等显示正常。；检查发现，服务端的是和客户端是一样的，中文注释也存在乱码的情况，英文、数字，显示正常。；检查磐维DTP的迁移任务
- **处置过程：** 检查客户端与服务端的字符集是否匹配；检查客户端字符集：业务侧使用的第三方连接工具DBserver，检查DBserver的字符集为UTF-8;检查服务端字符集：服务端的磐维数据库使用的字符集为UTF-8，与客户端保持一致。；检查服务端是否有乱码情况
- **运维建议：** 在磐维DTP；（数据迁移平台）；的配置过程中，存在对“应用环境字符集”参数的误解。
## 第 30 期｜磐维数据库互信失效问题分析
- 专辑文件：`12.html`，第 7 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247563201&idx=1&sn=721943503d74d423fd5b1494b25135a6&chksm=f8df435ecb05f7700e1cc92b73ebbd62d8edda63efe48a6b1604a22a11f07fd5c541c73b3e30#rd)
- **现象：** omm互信失效启动数据库集群失败处理。
- **处置过程：** 磐维数据库空间使用率超过85%后数据库只读的隐患；(datastorage_threshold_value_chec)；后启动汲取失败。
- **运维建议：** 涉及变更及操作时可以先通过磐维工具gs_ssh检查omm互信；omm互信是否正常。防止此类问题。
## 第 27 期｜磐维数据库长会话僵死
- 专辑文件：`15.html`，第 1 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247562000&idx=1&sn=8c906945a61862b190e5d4e425f949b4&chksm=f88e88553a72b2d8ffa17f7835b3d93ee7ad2f5a5f5719a161a343b041194351ba125fd68b1e#rd)
- **现象：** 集群上有条长会话僵死在主节点上无法进行kill正常清理会话。
- **处置过程：** 查看长会话sql；使用函数pg_terminate_backend(pid);进行会话清理,无法清理；使用cm_ctl stop 停止cm_ctl start重启数据库
- **运维建议：** 集群有长会话无法正常清理时，应首先尝试使用数据库内部提供的工具或函数进行清理
## 第 27 期｜磐维分布式数据库不支持自定义dcs组件数据目录
- 专辑文件：`15.html`，第 2 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247562000&idx=1&sn=8c906945a61862b190e5d4e425f949b4&chksm=f88e88553a72b2d8ffa17f7835b3d93ee7ad2f5a5f5719a161a343b041194351ba125fd68b1e#rd)
- **现象：** 磐维分布式数据库不支持自定义dcs组件数据目录。
- **处置过程：** 磐维数据库安装后检查各组件服务，发现dcs组件默认的数据目录在/var/lib/etcd，占用根分区空间，由于根分区容量太小，需要将dcs数据库目录指定到其它容量大的磁盘。；使用以下两种方式自定义修改etcd数据目录；方式一：拷贝etcd旧数据到新数据目录；
- **运维建议：** 提高评估分区容量预见性；本次事件暴露出我们在资源规划方面的不足，在接收和使用一级云提供的资源时，我们未能充分考虑到用户数据增长的情况，导致根分区容量在初期就显得捉襟见肘。；这提醒我们在未来的资源规划中，需要更加谨慎地评估分区容量，并预留足够的空间以应对未来的数据增长。
## 第 27 期｜goldendb数据库业务响应慢
- 专辑文件：`15.html`，第 9 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247562000&idx=1&sn=8c906945a61862b190e5d4e425f949b4&chksm=f88e88553a72b2d8ffa17f7835b3d93ee7ad2f5a5f5719a161a343b041194351ba125fd68b1e#rd)
- **现象：** GDB库业务响应慢。
- **处置过程：** 9.2.1 问题分析；19:30左右反馈工单处理慢；20：10经过排查，发现update语句耗时6.62s，其中lock_sql_wait耗时5.57s，询问厂家，反馈这条SQL是新的业务变更
- **运维建议：** 学习提升深入了解国产化数据库的特性；数据库国产化后，我们面临了一些与以往不同的系统功能逻辑。在这次问题中，由于对国产化数据库的一些特性了解不够深入，我们没有及时准确地分析出问题所在。；此外，我们还低估了锁等待日志对系统性能的影响
## 第 27 期｜gbase8c数据库执行计划不能下推dn
- 专辑文件：`15.html`，第 10 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247562000&idx=1&sn=8c906945a61862b190e5d4e425f949b4&chksm=f88e88553a72b2d8ffa17f7835b3d93ee7ad2f5a5f5719a161a343b041194351ba125fd68b1e#rd)
- **现象：** 业务sql使用connect by 生成序列导致执行计划不能下推dn，gbase8c端执行13分钟。优化后执行8秒。
- **处置过程：** 查看执行计划，执行计划不能下推到dn，基表数据从dn顺序扫描到cn进行计算。执行效率相比较fqs和stream低。修改connect by 语句；SELECT ROWNUM rn FROM dual CONNECT BY ROWNUM <= 24；select rn from generate_series(1,24) rn
- **运维建议：** 异构迁移SQL性能劣化是一个常见问题；在将Oracle等关系型数据库迁移到GBase 8C等分布式数据库系统时，由于底层架构和执行引擎的差异，原有的SQL语句可能无法直接获得最优的执行计划。因此，在迁移过程中，我们需要对SQL语句进行充分的测试和优化，以确保其在新系统中的性能表现。；对于使用CONNECT BY等特定语法生成序列的SQL语句，我们需要
## 第 26 期｜磐维数据库SQL执行不一致问题分析
- 专辑文件：`16.html`，第 1 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247561730&idx=1&sn=03127efd7dfb31578888f6c12a416961&chksm=f8a9b6214a200ad061848edb6ad1a642ecc32c2ddffbde5e0c712542d9d3558824806032f0d5#rd)
- **现象：** 磐维数据库调试过程中，业务反馈在测试库中可以执行的SQL在生产库中执行报错。
- **处置过程：** SQL在原GoldenDB中书写是不符合标准语法规范，非聚合列没有在group by中。；在测试库能正常执行，在生产环境却报错，通过对比测试库和生产库的表结构，发现生产库中表中缺少主键约束，手动对该表添加主键约束后该语句在生产环境能正常执行。
- **运维建议：** 严格遵循标准SQL语法规范；SQL编写需符合标准语法，特别是在涉及 GROUP BY 的场景中，确保非聚合列在 GROUP BY 子句中明确列出，避免在不同数据库实现中因语法差异产生问题。；保持测试与生产环境的一致性
## 第 26 期｜磐维数据库同步归档删除异常问题分析
- 专辑文件：`16.html`，第 2 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247561730&idx=1&sn=03127efd7dfb31578888f6c12a416961&chksm=f8a9b6214a200ad061848edb6ad1a642ecc32c2ddffbde5e0c712542d9d3558824806032f0d5#rd)
- **现象：** Oracle使用dtp同步到磐维，归档无法正常使用rman删除。
- **处置过程：** DTP服务异常；（服务异常的原因包括服务异常终止，网络异常，主机宕机等各种原因）；，导致的源库ORACLE的归档无法删除。查到dtp使用归档情况，手工删除应用的归档文件。
- **运维建议：** 完善同步服务监控机制；部署DTP同步延迟监控，实时跟踪DTP服务的状态及同步延迟情况，确保服务异常时能够及时发现并采取补救措施。；加强归档管理与自动化
## 第 26 期｜磐维数据库python3版本导致数据库预安装失败分析
- 专辑文件：`16.html`，第 3 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247561730&idx=1&sn=03127efd7dfb31578888f6c12a416961&chksm=f8a9b6214a200ad061848edb6ad1a642ecc32c2ddffbde5e0c712542d9d3558824806032f0d5#rd)
- **现象：** 使用gs_preinstall工具进行磐维数据库预安装，过程中lib3.7目录下的包不存在。
- **处置过程：** 查看python3 -V版本，报错为python3。；版本过新,需要3.6版本的python3,使用yum 安装python3.6版本的包。；再次预安装，没有再出现报错。
- **运维建议：** 磐维数据库的安装需要明确Python3版本包的版本；在安装磐维数据库之前，我们需要仔细阅读数据库的官方文档或安装指南，了解其对Python版本的具体要求。不同版本的数据库可能对Python版本有不同的兼容性要求，因此我们需要根据数据库的版本和操作系统的类型，匹配对应的Python3版本包。；注意安装方式
## 第 24 期｜磐维数据库连接数限制问题分析
- 专辑文件：`18.html`，第 4 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247560737&idx=1&sn=cb01276366d6818c6aec834908e03dd0&chksm=f89e5f449198f4a5d9fb69918f34a676ff26b704f61db98491107c4f2ddb8f019fb7c7e3af22#rd)
- **现象：** 磐维3.0以下的版本账号未作连接数限制。；磐维3.0的版本账号连接数限制默认为100个【若为低版本升级至3.0，升级前创建的账号也无账号连接数限制】。
- **处置过程：** 执行"alter user xxx connection limit -1;"命令，取消账号连接数上限。
- **运维建议：** 1）了解数据库版本特性；国产数据库在不同版本中可能会增加安全限制或优化功能，升级或上线前必须深入了解相关版本特性。；2）全面核查配置变更
## 第 24 期｜磐维数据库字符集不兼容问题分析
- 专辑文件：`18.html`，第 5 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247560737&idx=1&sn=cb01276366d6818c6aec834908e03dd0&chksm=f89e5f449198f4a5d9fb69918f34a676ff26b704f61db98491107c4f2ddb8f019fb7c7e3af22#rd)
- **现象：** 磐维数据库字符集是gbk，创建utf8的database报错。
- **处置过程：** 数据库初始化时，没有指定参数lc-collate=C、lc-ctype=C，那么数据库这两个参数就会使用主机环境的参数，而不是使用默认的C；（opengauss默认的是C）；。这样会导致创建的database，不能使用不同的字符集。
- **运维建议：** 1）数据库初始化配置至关重要；在数据库初始化时，必须明确设置关键参数（如 lc-collate 和 lc-ctype），避免使用主机环境默认值。这种疏忽可能导致字符集和排序规则不兼容的问题。；2）深入了解产品定制化特性
## 第 23 期｜某系统的teledb数据库内存使用过高，占满主机内存
- 专辑文件：`19.html`，第 1 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247560374&idx=1&sn=973ef698612ac5e7f6c7f6e1d7b91771&chksm=f809b38113526af6d617cae3717ed9e2ca4f006a87930338cd2b7b7d8913cb8b345725feade8#rd)
- **现象：** 某系统的teledb数据库内存使用过高，占满主机内存。
- **处置过程：** 查看主机内存；内存占用过高，且基本都是teledb数据库占用，初步判断为未加载Jemalloc库；(它的优势在于减少内存碎片和提升高并发场景下内存的分配效率)
- **运维建议：** 及时跟进数据库更新和修复通告；数据库系统是业务的核心组件，任何潜在的性能问题或内存泄漏都可能导致严重的服务中断。通过及时关注并应用数据库的更新和修复补丁，可以有效预防此类问题的发生。；尤其是在高并发场景下，像
## 第 23 期｜行云数据库重启管理节点的XEA服务后，进程启动失败
- 专辑文件：`19.html`，第 6 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247560374&idx=1&sn=973ef698612ac5e7f6c7f6e1d7b91771&chksm=f809b38113526af6d617cae3717ed9e2ca4f006a87930338cd2b7b7d8913cb8b345725feade8#rd)
- **现象：** 重启管理节点的XEA服务后，进程启动失败。
- **处置过程：** 在对行云数据库的操作系统做国产化升级过程中，重启管理节点的XEA服务后，进程启动失败，XEA是用于批量启停行云计算引擎节点的。；查看XEA的日志，发现它启动时会通过ssh访问备的管理节点，主机用户hadoop的密码不对导致启动失败，这个用户密码信息明文保存在管理节点的repository.xml文件中。；hadoop用户在之前因安全方面的原因修改了密码，所以此次重启XEA服务后因repository.xml文件中记录的密码没有同时更改导致无法启动服务。
- **运维建议：** 架构设计的安全性与便利性权衡；本次故障揭示了行云架构设计中的一个安全隐患；密码信息以明文形式存储在配置文件中，并且服务启动依赖于SSH访问其他管理节点。这种设计在管理密码更新时增加了复杂性，容易引发问题。一旦主机密码变更，必须同步更新相关配置文件，否则可能导致服务无法启动。
## 第 22 期｜磐维数据库安装时密码输入不一致
- 专辑文件：`20.html`，第 3 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247560119&idx=1&sn=ac3ac27b52a1dc3dc065c76f65d347ee&chksm=f88a0a6e919773fa9c8827629aa096351f5593291a841dc5d109e455eccd9957689dc8ea0c9f#rd)
- **现象：** 探活告警提示数据库无法连接。
- **处置过程：** 经排查是由于主机上做了安全限制，相互窗口中出现password关键字，按照以下方法可以规避；编辑/cmdblog/tool/script/gspylib/common/ParallelBaseOM.py文件；注释以下几行代码
- **运维建议：** 考虑安全限制对安装过程的影响；在本次安装过程中，因主机上设置了安全限制，导致在输入密码时出现了“不一致”的错误提示，进而导致安装脚本退出。；这表明，在安装和配置过程中，
## 第 22 期｜磐维目录使用率暴增，导致主节点hang住
- 专辑文件：`20.html`，第 4 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247560119&idx=1&sn=ac3ac27b52a1dc3dc065c76f65d347ee&chksm=f88a0a6e919773fa9c8827629aa096351f5593291a841dc5d109e455eccd9957689dc8ea0c9f#rd)
- **现象：** 目录使用率暴增，导致主节点hang住，然后发生主备切换。
- **处置过程：** 分析发现，目录暴增主要是有业务sql频繁在访问不存在的表，导致日志暴增。删除日志，并通知开发商暂停相关业务，故障恢复。
- **运维建议：** 增强监控告警，及时发现异常SQL访问；本次故障的根因是业务SQL频繁访问不存在的表，导致日志文件暴增，进而导致目录使用率飙升，最终引发主节点的故障并触发主备切换。；这暴露出当前监控体系的不足，未能及时捕获和告警这些异常的SQL访问。
## 第 22 期｜行云namenode节点服务重启后很快宕掉
- 专辑文件：`20.html`，第 8 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247560119&idx=1&sn=ac3ac27b52a1dc3dc065c76f65d347ee&chksm=f88a0a6e919773fa9c8827629aa096351f5593291a841dc5d109e455eccd9957689dc8ea0c9f#rd)
- **现象：** 在对行云数据库的操作系统做国产化升级过程中，重启namenode服务后，进程很快宕掉。
- **处置过程：** 查看namenode日志；发现是由于随着集群数据量的增长，元数据也相应增长，对堆内存的需求更大。重启服务后，由于namenode没有设置JVM参数，进程启动后因JVM内存不足导致产生full GC，所以服务宕掉。；在hadoop-env.sh中设置namenode的JVM内存
- **运维建议：** 集群监控和容量规划的重要性；在系统运维过程中，随着集群的数据量和复杂度不断增加，元数据的增长也是不可避免的。；尤其是在大数据环境中，元数据的体量会对系统的堆内存产生越来越大的需求。如果没有提前监控和规划好内存需求，可能会在重启或升级操作中引发内存不足的问题，导致服务不可用。
## 第 22 期｜行云数据库集群同步数据有时会报错
- 专辑文件：`20.html`，第 9 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247560119&idx=1&sn=ac3ac27b52a1dc3dc065c76f65d347ee&chksm=f88a0a6e919773fa9c8827629aa096351f5593291a841dc5d109e455eccd9957689dc8ea0c9f#rd)
- **现象：** 业务侧反馈行云数据库集群同步数据有时会报错，时好时坏。；经过沟通了解，定为到是行云集群的某一个计算节点主机引起，行云的xcloud服务与华为自维的一套hadoop集群之间进行数据同步。；华为的hadoop集群部署有kerberos服务，行云的主机作为客户端去访问华为hadoop集群的kerberos服务端需要验证票据,而行云的日志报错提示票据验证失败。
- **处置过程：** 查看行云的日志；发现数据同步报错的时间段，行云的日志提示；org .apache .hadoop .security .KerberosAuthException
- **运维建议：** 集群节点系统时间一致性的关键性；集群环境中，系统时间的一致性至关重要；，尤其是在涉及安全认证
## 第 21 期｜磐维数据目录使用率97%问题分析
- 专辑文件：`21.html`，第 6 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247559855&idx=1&sn=6d6126bdf60a61d0700bfbc30a6164cd&chksm=f8ecb6b58fc8f4602cc5f55f65682bff8f616bf575b7f97eb33a866aea324e42d26a2435be1b#rd)
- **现象：** 某现场/data目录使用率达到97%。
- **处置过程：** 通过进程查找panwei安装路径，统计归档日志和数据目录大小。；查找数据占比最大的数据库，统计其下面所有schema大小，由于开启全量备份和增量备份，数据突增时归档日志也随之增多，清理部分归档日志释放空间，反馈业务侧数据突增的schema。；在中，我们发现开启全量备份和增量备份会导致数据突增时归档日志也随之增多。这提示我们需要优化数据库的备份策略，以平衡数据恢复的需求和磁盘空间的占用。
- **运维建议：** 深入理解数据库空间使用与增长机制；在处理/data目录使用率高达97%的问题时，我们深刻认识到，仅仅关注磁盘空间的使用情况是不够的，还需要深入理解数据库内部的空间使用与增长机制。特别是，当数据库处理大量数据写入时，除了数据表本身的空间占用外，还需要考虑索引、系统表、以及最重要的归档日志等额外空间的需求。；归档日志的重要性
## 第 21 期｜磐维数据库探活告警提示数据库无法链接
- 专辑文件：`21.html`，第 7 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247559855&idx=1&sn=6d6126bdf60a61d0700bfbc30a6164cd&chksm=f8ecb6b58fc8f4602cc5f55f65682bff8f616bf575b7f97eb33a866aea324e42d26a2435be1b#rd)
- **现象：** 磐维数据库探活告警提示数据库无法链接。
- **处置过程：** 登录对应数据库主机查看数据库状态是否正常，查看结果正常。；查看数据库日志发现报错日志；FATAL:The password has been expired,please
- **运维建议：** 定制化密码策略以适应实际环境；原厂的最佳实践密码策略可能不完全适合生产环境。对于生产系统，特别是那些需要高可用性和稳定性的系统，应该根据实际业务需求定制密码过期策略。；例如，可以根据业务要求设置更长的密码过期时间或实施密码管理工具，以平衡安全性和系统稳定性。
## 第 19 期｜goldendb 部分计算节点偶发性连接失败
- 专辑文件：`23.html`，第 9 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247558577&idx=1&sn=d36bb094e2c549a9c1163a84ccbfbbe7&chksm=f85079dff3faf4683b02ae1ae50fcbe84cfebfe5c270c27e3188ceff84e68e78ae828517e686#rd)
- **现象：** 监控发现部分计算节点偶发性连接失败，手动测试连接时时不时地连不上。
- **处置过程：** 查看dbproxy.log未见异常报错，只有少量的warn告警，但是指向也不明确；dbtool -p -x -c 查看计算节点的连接数，发现对应cn节点的连接均未达到最大连接数，；数据节点、gtm节点均运行正常，只有cn节点时不时的报连接失败；主机资源使用也未见异常；
- **运维建议：** 重视慢SQL的监控与优化；慢SQL是导致执行线程积压和连接认证失败的主要原因。未能及时发现和优化慢SQL，会严重影响系统的整体性能和稳定性。；建立定期审查慢查询日志的机制，使用SQL优化工具（如EXPLAIN）分析慢SQL的执行计划，并针对性地进行索引优化、查询重写等改进措施。
## 第 19 期｜goldendb备库主备DN切换后备dn宕机
- 专辑文件：`23.html`，第 10 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247558577&idx=1&sn=d36bb094e2c549a9c1163a84ccbfbbe7&chksm=f85079dff3faf4683b02ae1ae50fcbe84cfebfe5c270c27e3188ceff84e68e78ae828517e686#rd)
- **现象：** 主备DN切换背景；insight平台告警：DN同步不一致。
- **处置过程：** 联系原厂后告知的是对主备DN进行一次切换，可以解决。；10.2.1；容灾集群切换DN主备节点后，原主节点，现备节点宕机
- **运维建议：** 充分测试与验证；分片测试与观察；在进行主备DN切换等重大操作时，不应仅局限于单一分片，而应至少对多个分片进行测试，并延长观察时间以确保系统稳定。同时，应记录每个分片的操作过程与结果，以便后续分析。
## 第 18 期｜ANTDB误删etcd的数据目录问题处理
- 专辑文件：`24.html`，第 6 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247557767&idx=1&sn=69ce887ff2044e523ab1ab089655c2b1&chksm=f89e7d05abda444a45ee125a3b68780fa677b20ebb033ecd5db39244b9b06ad31dee41c79c76#rd)
- **现象：** 在测试环境上面由于手误的原因删除了etcd的数据目录，该目录保存了etcd和patroni相关信息，比如说集群标识号，导致出现当前节点的期望id与其他节点的不匹配。；id mismatch，node xxx belongs；different cluster xxx！= xxx
- **处置过程：** 查看etcd高可用组件的日志信息，在/var/log/messages文件里；cat /var/ log / messages；i Etcd
- **运维建议：** 深入理解每个文件和组件的重要性；在运维或开发过程中，每一个文件、目录乃至配置项都承担着特定的角色和职责。对于像etcd这样的分布式键值存储系统，其数据目录不仅是存储数据的地方，更是集群状态、成员信息和集群配置的基石。
## 第 18 期｜ANTDB数据库主机cpu突增问题分析
- 专辑文件：`24.html`，第 7 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247557767&idx=1&sn=69ce887ff2044e523ab1ab089655c2b1&chksm=f89e7d05abda444a45ee125a3b68780fa677b20ebb033ecd5db39244b9b06ad31dee41c79c76#rd)
- **现象：** 数据库主机cpu突增，检查发现是由于高耗sql导致。
- **处置过程：** 经排查，高耗sql上有相关索引，开发商反馈索引失效，通过重建表和索引解决。
- **运维建议：** 建立和完善SQL性能监控体系；本次故障暴露出高耗SQL未能及时被检测和处理的问题。为了防止类似情况再次发生，梳理现有的监控告警规则，并针对高耗资源的SQL语句；（如长时间运行的查询、频繁触发全表扫描等）
## 第 17 期｜goldendb 长时间执行sql导致cn断连
- 专辑文件：`25.html`，第 4 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247557370&idx=1&sn=b513142a14c9bf833157a0b0d1736a5d&chksm=f85e55f18afb5b89609ef1e5a99b63d49dcb74ac4c8e311dd943e3d06250ad0c6008bade7a30#rd)
- **现象：** cn节点重启，dbproxy.log发现Out of memory。
- **处置过程：** 登录主机查看cn节点状态，已被agent拉起。；查看dbproxy.log发现ErrMsg:Out of memory；(need xxx bytes)
- **运维建议：** 优化SQL查询；针对导致OOM的长时间运行的SQL，进行详细的性能分析和优化。使用EXPLAIN PLAN或类似工具分析查询执行计划，识别并优化耗时的操作，比如添加合适的索引，调整查询逻辑等。；限制查询结果集大小
## 第 17 期｜goldendb 存储过程调用失败
- 专辑文件：`25.html`，第 5 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247557370&idx=1&sn=b513142a14c9bf833157a0b0d1736a5d&chksm=f85e55f18afb5b89609ef1e5a99b63d49dcb74ac4c8e311dd943e3d06250ad0c6008bade7a30#rd)
- **现象：** 业务侧反馈存储过程调用失败。
- **处置过程：** 和业务确认该存储过程在哪个节点执行，登录该节点查看gener日志，发现报错；ORA-06575；Package or function xxxx is in an invalid state。
- **运维建议：** 确保所有数据库对象；（如表、存储过程等）；的定义都存档在版本控制系统中
## 第 17 期｜teledb 某系统数据库连接数过高引起的问题
- 专辑文件：`25.html`，第 10 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247557370&idx=1&sn=b513142a14c9bf833157a0b0d1736a5d&chksm=f85e55f18afb5b89609ef1e5a99b63d49dcb74ac4c8e311dd943e3d06250ad0c6008bade7a30#rd)
- **现象：** 某日收到数据库连接数过高的告警，业务也反应查询变慢。
- **处置过程：** 检查teledb相关的组件的可用性，发现多个底层库连接数过高，数据库压力大；；停止业务和dbproxy后，底层库的连接数任然没有释放；；查询到底层库存在大量otter用户的连接，怀疑跟同步有关系；
- **运维建议：** 在业务高峰期避免进行全量同步的工作；建立有效的监控系统；监控Teledb数据库连接数、负载、性能等指标，并设置相应的预警阈值。当数据库连接数异常升高时，及时发出警报，以便进行调查和处理。
## 第 14 期｜磐维集群节点状态unkown报错处理
- 专辑文件：`28.html`，第 5 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247554331&idx=1&sn=697888cd27e2fb9c0fee80820873bb4f&chksm=f852eb76eaf416609ad4b681576941463c7aefc068703fc8909d45068f5696f7e6edca6b22fc#rd)
- **现象：** 查询集群节点状态为unkown。
- **处置过程：** 检查磐维数据库；发现集群节点为unkown状态。；进一步检查数据库参数配置
- **运维建议：** 在开启数据库的某些功能之前，需要仔细评估其对系统整体性能和运行状态的影响；对于诸如事务ID审计这样的功能，需要考虑其对集群状态检测等功能的影响。；确保在对数据库进行配置更改时，有清晰的文档记录和变更管理流程
## 第 14 期｜磐维2.0数据库安装问题
- 专辑文件：`28.html`，第 6 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247554331&idx=1&sn=697888cd27e2fb9c0fee80820873bb4f&chksm=f852eb76eaf416609ad4b681576941463c7aefc068703fc8909d45068f5696f7e6edca6b22fc#rd)
- **现象：** 磐维2.0数据库安装报错；'utf-8' codec can't decode byte 0xbb in position 913: invalid；start byte
- **处置过程：** 通过检查日志发现是安装时内部执行py脚本报错字符乱码；修改当前安装用户系统环境变量，在/home/omn/.bashrc中添加"export LANG=zh_CN.gbk"，即调整系统字符集为gbk格式后再安装；修改gs_sdr工具py脚本
- **运维建议：** 在安装之前，确认系统的字符集编码，并确保所有相关环境都采用相同的字符集编码；这可以减少由于字符集不一致导致的问题。；在安装过程中，可提前设置好必要的环境变量，以确保安装程序能够正确识别和处理字符集
## 第 13 期｜antdb安装部署后检查报错
- 专辑文件：`29.html`，第 1 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247553647&idx=1&sn=a4e3034acc8ffb27e39eeeba5ab3d053&chksm=f8ee8d04a3f80fd5f349f67890eef740ef2bd2e9c34b4805420d6d8fee25f6181b4f53cba4a5#rd)
- **现象：** 在部署antdb的高可用组件etcd和patroni，安装完成etcd和patroni之后，会使用pip/pip3 list来检查所安装python安装包，在执行pip3 list的时候出现no moudle pip._internal问题。
- **处置过程：** 由于在服务器需要纳入4A系统，进行安全基线扫描，会暴露出很多的安全隐患，其中有一条安全隐患就是umask的设置umask=027。；在没有修改umask的值创建一个文件是会有一个默认权限的，那么这个权限是怎么来的呢？；这就是umask干的事情。
- **运维建议：** 临时调整 umask；在安装或配置软件过程中临时调整 umask 设置，安装完成后再恢复原来的严格设置。；针对特定应用调整权限
## 第 13 期｜goldendb 镜像分片数据与源端不一致
- 专辑文件：`29.html`，第 8 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247553647&idx=1&sn=a4e3034acc8ffb27e39eeeba5ab3d053&chksm=f8ee8d04a3f80fd5f349f67890eef740ef2bd2e9c34b4805420d6d8fee25f6181b4f53cba4a5#rd)
- **现象：** goldendb上线前，需要验证快速拉起一套对应的镜像数据库，用于业务日常测试。在测试拉起过程中发现分片数据与源端不一致。；初步确定数据在g1上，但DB并没有到g1上去找数据， 通过执行计划方式能够比较直观的看到这一(执行计划extra提示：no matching row in const table, g5)。；经备份厂家核实后反馈，该问题为程序bug(挂载的时候gid顺序出现bug，导致随机挂载)，经过修复bug后复测，数据正常。
- **处置过程：** 在CN端无法查询到，例如:"select * from tab where id = 1"；如果指定分片可以查询到，例如:"select * from tab where id = 1 storagedb g1"；
- **运维建议：** 在部署和测试过程中，确保系统和应用的日志记录详尽并开启，这将有助于在问题发生时快速定位问题源；实施自动化的数据一致性检查工具，定期或在关键操作后执行，以确保数据在各个分片之间保持一致；开发更健壮的错误处理逻辑，一旦检测到数据一致性问题或其他关键错误，立即触发警报并启动预定义的回滚流程
## 第 13 期｜goldendb cn断连
- 专辑文件：`29.html`，第 9 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247553647&idx=1&sn=a4e3034acc8ffb27e39eeeba5ab3d053&chksm=f8ee8d04a3f80fd5f349f67890eef740ef2bd2e9c34b4805420d6d8fee25f6181b4f53cba4a5#rd)
- **现象：** cn节点断连且agent进程拉起后，二次断连。
- **处置过程：** 登录主机参看cn节点状态，dbproxy进程已经被agent进程拉起，但不到5分钟后发现cn再次断连，异常节点为运维节点，和业务沟通后手动停止agent防止进程再次拉起，待找到根因并解决后在拉起。；通过查看dbproxy.log未发现异常，无error信息。但/data/core下发现每次重启后都有异常的core文件。；通过手动coredump文件发现是由于一条运维语句导致，在和业务确认后暂停该语句执行，再次拉起cn后未发生重启。
- **运维建议：** 建立快速回滚机制；当检测到系统关键组件失败时，能自动回滚到上一个稳定状态。如在检测到CN节点异常时，自动将流量切换到备用节点。；定期对系统进行安全和稳定性审计
## 第 12 期｜磐维数据库主节点呈现readonly状态处置
- 专辑文件：`30.html`，第 1 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247552823&idx=1&sn=9693ecf3a5d69404fc032c4793a7f490&chksm=f85b749fb8c5158e15da1fdec6ed0ca79c79038f8b7842455dec3e42fe349048f133597fcc9c#rd)
- **现象：** panweidb主节点处于readonly状态。
- **处置过程：** 查看数据库状态发现只读模式被打开；排查数据库主节点资源状态；发现所在磁盘使用率未超阈值，默认60%。
- **运维建议：** panweidb默认磁盘告警阈值过低，生产环境调高监控告警阈值，"数据库盘空闲率"须大于"数据库只读模式的磁盘占用阈值"。
## 第 12 期｜磐维2.0版本数据库添加数据库白名单出现白名单覆盖的情况
- 专辑文件：`30.html`，第 2 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247552823&idx=1&sn=9693ecf3a5d69404fc032c4793a7f490&chksm=f85b749fb8c5158e15da1fdec6ed0ca79c79038f8b7842455dec3e42fe349048f133597fcc9c#rd)
- **现象：** PanWeiDB2.0数据库添加数据库白名单出现白名单覆盖的情况。
- **处置过程：** 通过尝试，除了集群内部IP，添加业务IP白名单只能添加三个网段，继续添加会覆盖；通过白名单操作函数来替代gs_guc命令；命令格式：select * from modify_hba_config(1, 'host all all xx.xx.xx.xx/0 sha256'::cstring);
- **运维建议：** 磐维2.0的新特性，实践出真知！
## 第 12 期｜ANTDB数据库复制主库性能抖动处理
- 专辑文件：`30.html`，第 3 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247552823&idx=1&sn=9693ecf3a5d69404fc032c4793a7f490&chksm=f85b749fb8c5158e15da1fdec6ed0ca79c79038f8b7842455dec3e42fe349048f133597fcc9c#rd)
- **现象：** 在进行物理备库的复制的时候，主库的性能有明显的波动，cpu使用率瞬时偏高，系统负载瞬时升高，备库复制出现延迟，这个周期性的出现。；主库表膨胀,重复扫描垃圾版本，重复耗费CPU资源进行垃圾回收。如果vacuum_defer_cleanup_age到达阈值同时antdb也产生大量的垃圾，在进行垃圾会少会产生大量的WAL日志，从而造成WAL的写IO波峰波谷的。；与该参数相关的参数还有 hot_standby_feedback，max_standby_archive_delay， max_standby_streaming_delay。
- **处置过程：** 排查发现物理备库上面设置了 vacuum_defer_cleanup_age这个参数；该参数代表了设置主库垃圾回收延迟，如果设置400，表示垃圾版本将延迟400个事务再被回收。；在测试环境中测试发现，有以下问题
- **运维建议：** 在数据库参数在设置之前，需要深知其意、理解参数的具体使用场景，并在测试环境进行测试。
## 第 12 期｜ANTDB数据库监控节点丢失处理
- 专辑文件：`30.html`，第 4 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247552823&idx=1&sn=9693ecf3a5d69404fc032c4793a7f490&chksm=f85b749fb8c5158e15da1fdec6ed0ca79c79038f8b7842455dec3e42fe349048f133597fcc9c#rd)
- **现象：** 在antdb3节点出现了一个antdb监控节点的丢失，在grafana里面找不到该节点，查询Prometheus日志发现，“Get http://10.142.x.x/metricsdial tcp 10.142.x.x：910x：connect no route to host”
- **处置过程：** 设置iptables,没有添加端口910x的防火墙规则；更换损坏磁盘，antdb数据库进行了重启；发现另外2台antdb节点，没有防火墙规则，没有丢失监控节点。
- **运维建议：** 在进行数据库重启或者主机重启之后重新加载防火墙规则。
## 第 12 期｜GreatDB数据库主机开启防火墙导致节点通信故障
- 专辑文件：`30.html`，第 10 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247552823&idx=1&sn=9693ecf3a5d69404fc032c4793a7f490&chksm=f85b749fb8c5158e15da1fdec6ed0ca79c79038f8b7842455dec3e42fe349048f133597fcc9c#rd)
- **现象：** GreatDB数据库主机开启了防火墙导致节点通信故障。放开防火墙后，事务出现异常sqlnode节点无法加入集群。
- **处置过程：** 踢掉报错的sqlnode error节点，重新初始化sqlnode节点。
- **运维建议：** 目前国产数据库整体文档、生态均属于建设过程中，摸石头过河，此案例其实就是一个摸石头过河的案例。
## 第 11 期｜磐维数据库使用一段时间后，无法正常启动
- 专辑文件：`31.html`，第 2 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247552221&idx=1&sn=a351b2e25f679c85214503d39ac9a2d1&chksm=f86c24ebbfa8ea998a17a9b0c070ec51f076dd2b0228a8bd622174bf69cc5755d5c2287922ed#rd)
- **现象：** panweidb数据库使用一段时间后，无法正常启动，查看pg_log相关日志，具体报错如下；FATAL: could not；create shared memory segment
- **处置过程：** 物理内存不足；内核参数或数据库参数优化问题，修改内核参数或数据库参数即可；调整内核参数（
- **运维建议：** 一般shmmax设置为主机物理内存的60%，shmall >= shmmax/4096。例如主机100G内存，shmmax=100G*60%*1024*1024*1024= 64424509440，shmall= 64424509440/4096= 15728640。；调整数据库参数（；max_process_memory以及shared_buffers设置小一点就可以了。
## 第 11 期｜磐维数据库高可用组件cm选主异常处理
- 专辑文件：`31.html`，第 3 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247552221&idx=1&sn=a351b2e25f679c85214503d39ac9a2d1&chksm=f86c24ebbfa8ea998a17a9b0c070ec51f076dd2b0228a8bd622174bf69cc5755d5c2287922ed#rd)
- **现象：** 高可用组件cm选主异常。
- **处置过程：** cm_ctl stop && cm_ctl start；清理dcf数据；停止所有cm进程，再删除如下目录
- **运维建议：** 此问题属于软件bug，及时升级数据库版本。
## 第 11 期｜磐维数据库安装完成后无法启动
- 专辑文件：`31.html`，第 4 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247552221&idx=1&sn=a351b2e25f679c85214503d39ac9a2d1&chksm=f86c24ebbfa8ea998a17a9b0c070ec51f076dd2b0228a8bd622174bf69cc5755d5c2287922ed#rd)
- **现象：** 磐维数据库安装完成后无法启动，查看pg_log相关日志，具体报错如下；bbox dumppath is set to / xxx / corefile / 09 44；26.9661[984148]
- **处置过程：** 联系主机同事，添加相关指令集。；1）检查omm密码是否过期，导致定时任务无法使用；；2）检查内核参数；
- **运维建议：** 数据库环境搭建前严格检查环境配置是否完整。
## 第 10 期｜Gbase DDL recover影响到其他的用户insert
- 专辑文件：`32.html`，第 1 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247551782&idx=1&sn=3f4082f334675de4fbfeed4c1b694d0d&chksm=f8672a0da5e362ca96f9b36b5dc6a8bc14c98dd5cb0d14a149dc1b2ff52b5a6d8b42d5083ced#rd)
- **现象：** 业务人员反馈业务程序有实时insert中断报错，分析数据库日志发现node5和node10节点出现数据节点的主备数据一致性状态异常情况，回溯历史告警当时只有一条记录，通过短信告警频率判断，15分钟之内数据库自动修复，之后分析日志也显示数据库在较短时间内自动修复。结合业务和数据库日志从时间线分析实时insert中断与数据一致性状态异常有关联。；通过Gbase 8a的产品手册了解到，8a自动切换机制，节点故障对应用透明，不会中断正在执行的业务，但是分析这次的日志，数据库日志开始检测需要做recover，并在之后开始start DDL recover。业务日志输出显示实时insert中断。从时间线上分析是有关联，为什么会出现event事件做start DDL recover影响到其他的用户insert，在日志里面没有明…
- **运维建议：** 由于业务侧未配置异常重连机制，导致业务中断后未继续进行，但当时当时数据库已恢复，直至工作日发现。了业务侧优化异常中断之后的重连机制，减少影响时间。；对于出现疑似数据不一致的告警，即使告警恢复，在未有结论的情况下，需要和业务进一步关注。
## 第 10 期｜goldendb nsight界面无法查看主备延迟
- 专辑文件：`32.html`，第 8 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247551782&idx=1&sn=3f4082f334675de4fbfeed4c1b694d0d&chksm=f8672a0da5e362ca96f9b36b5dc6a8bc14c98dd5cb0d14a149dc1b2ff52b5a6d8b42d5083ced#rd)
- **现象：** nsight界面无法查看主备延迟,后台日志报错信息如下；2023 10 07 08；ERROR [pool
- **处置过程：** 通过对比正常主机该端口对应进程，发现有部分进程不在，后得知该主机发生过重启，手动拉起守护进程后可正常查看主备延迟。
- **运维建议：** 该程序已添加至开机自启动脚本中，但主机重启未正常拉起，今后主机重启后要查看该进程是否存在。
## 第 10 期｜goldendb DB备机回放期间，备机服务器断电重启，start slave出现异常
- 专辑文件：`32.html`，第 9 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247551782&idx=1&sn=3f4082f334675de4fbfeed4c1b694d0d&chksm=f8672a0da5e362ca96f9b36b5dc6a8bc14c98dd5cb0d14a149dc1b2ff52b5a6d8b42d5083ced#rd)
- **现象：** DB备机回放期间，备机服务器断电重启，之后备机start slave期间可能出现；ERROR 1201；(HY000): Could not initialize master
- **处置过程：** 版本上需要dbagent在识别到该问题出现后，通过reset slave all、change master + start slave来重置复制关系、即可恢复正常。
- **运维建议：** 此次故障暴漏了mysql主从延迟的弊端，在重要的业务系统上，将；都设置为1，以日志保证实时落盘。
## 第 10 期｜panweidb不支持序列+大序列问题
- 专辑文件：`32.html`，第 11 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247551782&idx=1&sn=3f4082f334675de4fbfeed4c1b694d0d&chksm=f8672a0da5e362ca96f9b36b5dc6a8bc14c98dd5cb0d14a149dc1b2ff52b5a6d8b42d5083ced#rd)
- **现象：** panweidb迁移oracle，业务测试报错 all_sequences 序列视图表not exists。；panweidb迁移oracle数据库序列后新建序列失败。
- **处置过程：** panweidb迁移Oracle，业务测试报错 all_sequences 序列视图表not exists。；排查原因是panweidb默认不支持序列视图，需要安装第三方开源compat-tools开源插件。；在compat-tools工具包下面有一些支持oracle/mysql数据库的兼容性对象，使用gsql -d xxx -p xxx 指定总脚本runMe.sql安装兼容性视图，安装后select查看all_sequences视图数据征程。
- **运维建议：** 迁移国产数据库时，留意报错信息，根据报错定位原因解决问题。
## 第 9 期｜Gbase版本V9.5.2存在产品缺陷
- 专辑文件：`33.html`，第 9 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247550974&idx=1&sn=01795083e9452df817ff2b8ea37c2c06&chksm=f873f7423ffa7fbf6360f433598b5441d204ef2d0ac6b1344396b5694489fc4646ba0ee3b55c#rd)
- **现象：** 通过gcadmin和服务状态监控数据库出现一致性状态异常的告警，并且在运行过程中出现了连续的多个数据节点Gbased服务宕机重启事件，导致部分数据节点间数据不同步，进而出现数据库不能自动修复的event事件，正常情况下event事件数据库会自动修复。；与业务沟通了解在超过10亿行数据表频繁进行写入的情况下易出现gbased服务宕掉的情况，且部分情况下业务的写入中断。
- **处置过程：** 出现event事件不能自动修复，出于安全性考虑未直接对各节点表进行修复，而是采用手动对触发表进行重建并将原表数据进行转移，之后删除原表的方式处理，event事件消失。；对于Gbased服务宕机重启，升级数据库版本，观察至今未出现相同类似的情况。
- **运维建议：** 升级Gbase版本，从V9.5.2升级至V9.5.3。
## 第 9 期｜gaussdb200数据库无法使用
- 专辑文件：`33.html`，第 10 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247550974&idx=1&sn=01795083e9452df817ff2b8ea37c2c06&chksm=f873f7423ffa7fbf6360f433598b5441d204ef2d0ac6b1344396b5694489fc4646ba0ee3b55c#rd)
- **现象：** gaussdb200数据库整个集群不可用，告警出现standby promoting，disk damaged，standby need repair。；分析发现是由于一个节点磁盘损坏，在硬盘更换过程数据重平衡重启后整个集群不可用。
- **处置过程：** 通过查看集群节点状态发现集群状态不可用，DataNode27节点上所有实例异常，DataNode26节点上的6379实例处于standby promoting状态。；查看DataNode27节点上实例的日志发现报could not read directory No data available,进一步分析发现DataNode27节点上2个数据目录不能读写，主机命令ls查看这2个数据目录都报错IO错误。；为了提高在单节点停掉下的集群性能，将synchronous_commit参数的值修改成off。
- **运维建议：** 增加数据库巡检和告警内容，针对硬盘状态和目录读写状态进行监控，及时发现异常可以减少故障时间和业务受影响时间。
## 第 8 期｜磐维数据库修改参数后无法拉起
- 专辑文件：`34.html`，第 2 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247550409&idx=1&sn=be35df1e75f261fcf47240c515120415&chksm=f8f2fd7089ce4eb53f071ef3f7b8cc3609442d032d6d9f00a3f27702d15e7cfe739d80c05899#rd)
- **现象：** 应业务方需求在凌晨更改系统及数据库参数，在更改完参数重启集群时无法启动，后集群主备自动发生切换后，老主库依旧无法启动。；2.2 处置方案；首先检查数据库服务是否运行正常，磁盘是否正常，主机间互信是否正常，业务日志有无明显报错。
- **运维建议：** 建立错误排查记录文档，在出现故障后可以先寻找以往案例快速定位。；在暂时无法找到具体问题情况下优先恢复业务，老主库随后再排查。；在对数据库做改动前做好相关备份，保证回退方案。
## 第 8 期｜GOLDENDB通过CN节点无法查询到新增的分区
- 专辑文件：`34.html`，第 10 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247550409&idx=1&sn=be35df1e75f261fcf47240c515120415&chksm=f8f2fd7089ce4eb53f071ef3f7b8cc3609442d032d6d9f00a3f27702d15e7cfe739d80c05899#rd)
- **现象：** GOLDENDB因为运维人员误连接到DN的一个分片，对一个分区表新增分区，导致业务人员通过CN节点无法查询到新增的分区。
- **处置过程：** 在原分片中，删除新增的分区，然后通过CN连接数据库，新增分区。
- **运维建议：** 分布式数据库运维过程中，切勿连接其中一个分片进行相关操作。；平时运维过程中，养成使用CN连接数据库的习惯，尽量避免通过DN连接数据库；国产数据库本身的容错机制需要进一步加强，对于直接操作DN的变更，需要进行提示。
## 第 7 期｜goldendb日志集解析时间边长处置
- 专辑文件：`35.html`，第 9 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247548418&idx=1&sn=26252ff7559fe5a415057991c65fb400&chksm=f8e206d71ca6c58cda2f9738f9c6135e14f34d93d75c26026f6f95b4243c7ee87399027622a0#rd)
- **现象：** 某19.13数据库的SCN多次发生跳变，导致goldendb做日志集解析时间比往常增加了很多，对迁移割接产生影响。
- **处置过程：** 查看数据库的alert日志中 SCN变化的原因是通过dblink分布式的事务导致的，并不是本地的事务，SCN的变化的源头是另一个12.1.0.2版本数据库。；评估当前数据库scn风险：scn上限是2的48次方减1（即281474976710655），从Oracle12.2开始，scn允许的最大值是2的63次方减1，当前19.13数据库的scn是：17839739901756，还有很大的空余，暂无风险；；与业务沟通后，业务修改dblink密码，使得dblink不可用；业务调整逻辑，改为jdbc直连，不采用dblink方式。
- **运维建议：** 将数据库scn值的检查加入监控和日常巡检中。；尽量减少dblink的使用。；给原厂提，goldendb对日志解析机制需要优化。
## 第 7 期｜goldendb迁移过程问题分析
- 专辑文件：`35.html`，第 10 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247548418&idx=1&sn=26252ff7559fe5a415057991c65fb400&chksm=f8e206d71ca6c58cda2f9738f9c6135e14f34d93d75c26026f6f95b4243c7ee87399027622a0#rd)
- **现象：** mysql往goldendb数据库数据迁移过程遇到的2个问题；source表结构时，全库导入，导致goldendb数据库中存在多种存储引擎；；导入结构时按照源库默认排序导入，但是goldendb数据库不支持，导致数据无法传入。
- **处置过程：** MySQL5.7的版本中系统表里含除innodb以外的存储引擎，导致做部分DDL语句的时候，会报错事务中存在多种存储引擎，这种情况只能重装数据库，再此导入时，不导入MySQL系统库。；创建表结构时用了源数据库默认的数据库排序方式：utf8_general_ci，这个排序goldendb数据库(mysql8.0)不支持，数据无法正常导致导入，就需要修改数据库的排序方式;修改时需注意，要修改数据级别的排序方式，表的排序方式，还会涉及字段上的排序方式，都需要做调整;调整的语句可以通过查询系统表来统一生成。
- **运维建议：** 谨慎创建数据库结构，尽可能多的了解mysqldump出的表结构（sql语句 ）的含义，例如，字符集、存储引擎，排序规则，甚至是注释中的内容。；增加上线评审环节。
## 第 6 期｜磐维数据库预安装报错
- 专辑文件：`36.html`，第 1 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247547362&idx=1&sn=e81f89caa975c5168690b4aaa64a34e3&chksm=f8214034dc2cdac26f9fcee01a8c4389ddf22c0fdb982fb6b71d6397e4bb9a3a3d2fba160f78#rd)
- **现象：** 预安装检查无法通过，由于su安装用户omm时有错误提示，切用户时，不能有信息输出。
- **处置过程：** 执行过程中需要手动写入的：是否需要root互信、是否需要数据库安装用户互信、输入数据库用户的密码。输入yes来使gs_preinstall程序自动配置root用户互信和omn用户互信。；如果gs_preinstall执行时报互信问题，说明互信配置有问题，须手动配置互信。CMDB故障解决指南）中互信相关错误处置。；预检查执行时报[GAUSS-50612]
- **运维建议：** 数据库国产化，一路各种小怪兽，关关难过关关过。加强生态建设与技术储备。
## 第 6 期｜Goldendb在线创建索引导致业务堵塞
- 专辑文件：`36.html`，第 9 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247547362&idx=1&sn=e81f89caa975c5168690b4aaa64a34e3&chksm=f8214034dc2cdac26f9fcee01a8c4389ddf22c0fdb982fb6b71d6397e4bb9a3a3d2fba160f78#rd)
- **现象：** goldendb在线创建索引导致业务堵塞。
- **处置过程：** GolenDB paper集群业务反应存在一条慢sql，经分析需要创建索引优化，在和业务人员沟通后决定晚上9点进行索引创建。；创建过程中业务工程师反馈影响业务正常办理。；经查看后发现是创建索引导致锁表，随即马上取消创建索引。
- **运维建议：** DDL语句执行需要加强评审。；DDL语句执行需要选择窗口在业务停止后执行，避免锁表。
## 第 5 期｜行云数据库目录使用节点不平衡处置
- 专辑文件：`37.html`，第 5 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247546419&idx=1&sn=166891468c4eeb9c37a0b109baf3be3e&chksm=f872028936151d568f95bde0da5bc82853ed177f355e7060d2cfa6d370493bd8004d94f21fd5#rd)
- **现象：** 行云数据库集群各节点数据存在不均衡情况（整体使用率未超过90%，但部分节点达到了98%）。；发现有不平衡，及时使用相关步骤进行数据重平衡。；执行数据重平衡时会对IO有影响，需要关注并发度以及业务性能。
- **处置过程：** 用Hadoop用户在非namenode 的某个节点上执行；hdfs dfsadmin -setBalancerBandwidth 104857600；这个命令是设置带宽的大小，单位是字节，如果带宽太大会使集群之间的IO通信负担过大，可能会使集群的部分进程挂掉，太小会让数据均衡执行太慢，所以要根据集群的性能来设置，默认是10M，推荐用100M。
- **运维建议：** 配置行云数据库目录使用告警。；在日常巡检指标中增加数据不平衡巡检指标项。
## 第 5 期｜Greatdb
- 专辑文件：`37.html`，第 7 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247546419&idx=1&sn=166891468c4eeb9c37a0b109baf3be3e&chksm=f872028936151d568f95bde0da5bc82853ed177f355e7060d2cfa6d370493bd8004d94f21fd5#rd)
- **现象：** 万里开源greatdb 集群主机内存剩余过小，多次flush cache也释放不出多少。
- **处置过程：** 数据节点和计算节点的共享内存参数设置总和超过70%，给线程预留的私有内存过少，导致随着连接数的增加，主机内存剩余出现过低的情况。结合当晚窗口对节点进行切换释放内存，理论上对业务无感知，但切换后，所有节点hang，业务全阻。；最终通过对计算节点，存储节点全停全起解决。节点全停全起后，有一个datanode一直处于revover状态，后经分析为触发万里数据库内部机制导致该节点数据文件重新同步。；基于本次操作，有两个疑惑怀疑与万里数据库本身机制有关：一个是做datanode切换释放内存，所有节点都hang死。第二是全停全起恢复后，有一个datanode的数据文件被集群重新同步了（这种情况一般是事物相差太大，但我们对比了事务远小于参数配置，第二种可能是binlog丢失，可能因为切换后节点hang死后数据落盘异常，但这些都只…
- **运维建议：** 数据节点和计算节点的共享内存参数设置总和不超过60%。；做相关变更之前，将用户锁定，避免业务事务增长。；部署剩余内存监控，并将剩余内存监控阀值调低，在剩余内存小于主机总内存大小的20%时，申请主动维护窗口进行重启，避免内存耗尽后引发故障。
## 第 5 期｜万里开源数据库添加字段报错异常处置
- 专辑文件：`37.html`，第 8 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247546419&idx=1&sn=166891468c4eeb9c37a0b109baf3be3e&chksm=f872028936151d568f95bde0da5bc82853ed177f355e7060d2cfa6d370493bd8004d94f21fd5#rd)
- **现象：** 应用侧在GreatDB中添加字段时，发现特别慢，于是强制取消了添加字段的操作。再次添加该字段时，发现报错。；Error code 8537，；execute cmd error
- **运维建议：** 因过程数据库本身需要进一步完善，；通过workround规避；执行ddl操作前，需停止相关业务。如无法停止业务，最好低谷期不要有其他语句在操作相关表，否则锁等待时间会很长。
## 第 3 期｜磐维数据库主机重启后cmserver无法启动
- 专辑文件：`39.html`，第 8 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247545071&idx=1&sn=aac931fa16e31d4a7cab4b63ed930cf2&chksm=f8b74916863b9b6abd37c1a3aa35465d11acaacf942e0030e03a53422fdb3ad465b87d821d9e#rd)
- **现象：** 主机重启后cmserver无法启动。；2. 处置方案；两套3节点的国产磐维库，在配合修改主机参数disk cache policy时，有一台机器重启后，集群无法拉起。
- **运维建议：** 对于不熟悉的配置，不轻易做调整；。过于相信经验判读，没想到crontab也会影响到数据库启动。
## 第 1 期｜kingbase数据库无法连接问题处置
- 专辑文件：`41.html`，第 9 个案例
- [查看原文](https://mp.weixin.qq.com/s?__biz=MzUxNTYzMjA5Mg==&mid=2247541586&idx=1&sn=6679d801fbeb3b8917f7298aeb573457&chksm=f8a211250a8a15312f5b12a9a56492512a3162a433ea92855b359aae4f82acfe75f1121e4b3b#rd)
- **现象：** 4个节点主备架构的国产库，主节点告警连接不上，备节点接管转为主库提供服务。
- **处置过程：** 主备架构下，备节点自动接管业务。；主节点手工加入集群中。；因数据库表字段名称为中文字段，触发数据库BUG，导致数据库重启，主从架构下可以自动处理故障节点，备节点自动接管业务，业务影响较短。
- **运维建议：** 根据实际情况持续增加监控维度及标准；；建立数据库模型管控标准，任何上线都需要通过评审，从而规避中文字符别名；；根据原厂版本发布情况后期进行版本升级。