一个权限配置错误引发的“血案”：数据库访问控制手记
一个权限配置错误引发的“血案”：金仓数据库访问控制手记
深夜的那通电话
凌晨两点，手机响了。
值班同事声音发紧：“大哥，金仓核心交易库连不上了，应用那边在报‘no sys_hba.conf entry’，这是什么意思？”
我一边穿衣服一边让他把详细报错发过来。截图上的信息很明确：
FATAL: no sys_hba.conf entry for host "10.207.88.101"这是个典型的访问控制配置遗漏问题。新上线的应用服务器IP没加到白名单里，金仓数据库直接把连接请求拒了。
加一行配置、重载、业务恢复，前后不到五分钟。但这件事让我意识到，很多DBA对金仓这套访问控制机制的理解，还停留在“照着文档配一下”的阶段。
一、用户和角色：别把这两个概念搞混了
先从一个常见的认知误区说起。
刚接触金仓数据库的时候，我一直没搞明白USER和ROLE到底有什么区别。后来才弄懂：在金仓里，用户就是能登录的角色。
-- 这两条语句干的是同一件事CREATEUSERfin_appWITHPASSWORD'app123';CREATEROLE fin_appWITHLOGIN PASSWORD'app123';区别只有一个：USER默认带LOGIN权限，ROLE默认不带。
这个设计其实挺巧妙的。你可以用ROLE定义一组权限（比如“只读组”、“读写组”），然后用USER创建具体的人，再把权限组赋给用户。这样改权限的时候，只需要改ROLE，所有继承这个角色的用户自动跟着变。
一个真实的权限设计案例
去年做的一个金融系统，权限结构是这么搭的：
-- 先建三个基础角色CREATEROLE read_only;-- 只能查CREATEROLE read_write;-- 能查能改CREATEROLE app_admin;-- 管理员-- 给角色授权GRANTSELECTONALLTABLESINSCHEMApublicTOread_only;GRANTINSERT,UPDATE,DELETEONALLTABLESINSCHEMApublicTOread_write;GRANTCREATE,DROPONALLTABLESINSCHEMApublicTOapp_admin;-- 创建用户并分配角色CREATEUSERfin_appWITHPASSWORD'app123';GRANTread_writeTOfin_app;CREATEUSERreport_userWITHPASSWORD'report456';GRANTread_onlyTOreport_user;CREATEUSERdba_zhangWITHPASSWORD'dba789'CREATEDB;GRANTapp_adminTOdba_zhang;这样做的好处很明显：后来报表系统需要增加一个临时账号，直接CREATE USER然后GRANT read_only就行，不用再重新授权。权限收回来也方便，一条REVOKE就完事。
金仓特有的权限查看命令
-- 看用户属于哪些角色组SELECTr.rolname,m.rolnameasmember_ofFROMsys_roles rJOINsys_auth_members amONr.oid=am.memberJOINsys_roles mONam.roleid=m.oid;-- 看某个表上谁有什么权限SELECTgrantee,privilege_typeFROMinformation_schema.role_table_grantsWHEREtable_name='accounts';-- 列级权限：只给特定字段（金仓支持到列级别的精细控制）GRANTSELECT(id,name)ONhr.employeesTOreport_user;-- salary字段没给，报表用户查不到工资信息关于金仓超级用户的提醒
金仓数据库的默认超级用户是system，这个账号能绕过所有权限检查。有几个原则建议遵守：
- 应用程序连接绝对不能用超级用户
- 日常运维也尽量使用普通管理员账户
- 超级用户的密码要定期更换、严格保管
二、连接控制：谁才能进门
说完“进来后能干什么”，再说“谁才能进来”。金仓通过s alt="sys_hba.conf文件来控制客户端访问权限。
2.1 文件格式长什么样
# TYPE DATABASE USER ADDRESS METHOD host all all 192.168.1.0/24 scram-sha-256每行五个字段：连接类型、数据库名、用户名、来源地址、认证方式。
金仓支持的认证方式
| 方式 | 说明 | 什么时候用 |
|---|---|---|
| trust | 不需要密码 | 本地维护用，生产环境千万别开 |
| scram-sha-256 | SCRAM加密认证 | 生产环境首选，金仓默认推荐 |
| md5 | MD5加密 | 老系统兼容 |
| sm3 | 国密SM3认证 | 国密合规场景 |
| reject | 直接拒绝 | 封IP用的 |
2.2 那次差点出事的配置遗漏
回到开头的那个案例。新上线的报销系统连不上金仓数据库，报错说找不到对应的sys_hba.conf记录。
登录服务器一看，配置文件里只有老系统的IP：
host all all 10.207.88.50/32 scram-sha-256 host all all 10.207.88.51/32 scram-sha-256新服务器10.207.88.101不在列表里。
加上就好了：
host all all 10.207.88.101/32 scram-sha-256然后执行重载让金仓重新读取配置：
SELECTsys_reload_conf();业务恢复。事后我补了个检查清单：每次新服务器上线，必须确认DBA知道、网络通了、白名单加了。
改了配置为什么不生效？
金仓的sys_hba.conf改了之后必须重载。两种方式：
-- SQL里执行SELECTsys_reload_conf();# 命令行执行sys_ctl reload-D$KINGBASE_DATA重载不会中断现有连接，只对新连接生效。
三、会话监控：看看连接都在干什么
连接进来了，怎么知道它们在干什么？金仓的sys_stat_activity视图就是干这个的。
3.1 常用监控查询
-- 看当前所有活跃的查询SELECTpid,usename,client_addr,state,queryFROMsys_stat_activityWHEREstate='active';state字段很关键：
active：正在执行SQLidle：闲着，等新命令idle in transaction：事务开了没提交——这个状态要警惕
3.2 那次连接池被占满的事故
有天下午业务高峰，金仓数据库监控突然告警：大量支付请求失败。
DBA试着登录，竟然连上了——因为金仓为超级用户保留了专用通道。这是superuser_reserved_connections参数的作用，默认留了几个槽位给超级用户，就是为了这种紧急情况。
先看连接数：
SELECTcount(*)FROMsys_stat_activity;-- 300，达到了金仓max_connections的上限再看会话状态分布：
SELECTstate,count(*)FROMsys_stat_activityGROUPBYstate;结果：
| state | 数量 |
|---|---|
| idle in transaction | 285 |
| active | 12 |
| idle | 3 |
285个连接挂着事务不提交也不回滚。这比单纯连接满更麻烦——它们可能还拿着锁，会堵住别人的操作。
查一下这些连接是谁的、挂了多久：
SELECTpid,usename,application_name,now()-xact_startasduration,queryFROMsys_stat_activityWHEREstate='idle in transaction'ORDERBYdurationDESC;发现都来自一个第三方支付模块，大部分事务已经挂起超过30分钟。联系开发排查，发现那个模块在某个异常分支里忘了关闭事务。
怎么处理
先杀僵尸会话恢复业务：
SELECTsys_terminate_backend(pid)FROMsys_stat_activityWHEREstate='idle in transaction'ANDnow()-state_change>interval'3 minutes';然后设置金仓的自动清理参数，防止以后再发生：
ALTERSYSTEMSETidle_in_transaction_session_timeout='10min';SELECTsys_reload_conf();这个参数的意思是：事务空闲超过10分钟，金仓自动把它终止掉。
3.3 金仓杀会话的两种方式
-- 温和版：取消当前查询，但不断开连接SELECTsys_cancel_backend(pid);-- 暴力版：直接断开连接SELECTsys_terminate_backend(pid);一般先试温和版，不行再用暴力版。
四、max_connections：这个参数在金仓里怎么调
4.1 先看当前值
-- 最常用SHOWmax_connections;-- 想看详细信息SELECTname,setting,context,pending_restartFROMsys_settingsWHEREname='max_connections';context字段告诉你改完要不要重启：
postmaster：必须重启sighup：重载就行user：会话里直接set
金仓的max_connections是postmaster级别，改完必须重启数据库。
4.2 改之前先算算内存
根据金仓官方文档，每个连接大概消耗的内存：
- 连接本身：约400字节
- 锁空间：每个连接默认64个锁，每个锁约270字节
加起来每个连接约17.3KB。
500个连接就是8.6MB，2000个连接约34.6MB。这个数字其实不大，真正的内存大户是金仓的shared_buffers和work_mem。
4.3 改的正确姿势
-- 方法一：ALTER SYSTEM（金仓推荐）ALTERSYSTEMSETmax_connections=500;-- 方法二：改配置文件-- vi $KINGBASE_DATA/kingbase.conf-- max_connections = 500-- 改完必须重启金仓数据库sys_ctl restart-D $KINGBASE_DATA-- 验证SHOWmax_connections;一个金仓特有的坑：ALTER SYSTEM会把配置写进kingbase.auto.conf，这个文件的优先级比kingbase.conf高。如果你改了kingbase.conf发现不生效，检查一下auto.conf是不是有相同的参数。
4.4 什么时候该改，什么时候不该改
该改的情况：
- 业务增长，连接数确实不够了
- 压测验证过，服务器资源扛得住
不该改的情况：
- 连接被僵尸会话占满了——先清理会话，别急着扩
- 偶尔的并发峰值——应该用连接池缓冲，不是无限扩容
- 内存本来就不够——加了参数可能导致金仓起不来
那次连接池占满的事故，事后我们评估了一下：300的连接数其实够用，问题是285个被无效占用了。加了金仓的idle_in_transaction_session_timeout自动清理之后，再也没出过问题。
五、金仓运维中积累的几个小工具
5.1 快速查看权限配置
-- 所有可登录用户及其权限SELECTrolname,rolcanlogin,rolsuper,rolcreatedbFROMsys_authidWHERErolcanlogin=trueORDERBYrolname;5.2 查看当前HBA规则
SELECTtype,user_name,address,auth_methodFROMsys_hba_file_rulesORDERBYuser_name;5.3 监控连接数变化
-- 每分钟记录一次连接数SELECTnow(),count(*)FROMsys_stat_activity;六、金仓数据库访问控制踩坑总结
这些年用金仓数据库，在这些方面踩过的坑，总结几条：
1. 权限设计要从一开始就做
等项目上线了再补权限，开发已经把所有代码写成用超级用户连接，改起来代价极大。接手新项目第一件事，先把金仓的权限结构搭好。
2. sys_hba.conf改了要重载
这条看着简单，但每次故障复盘都会发现有人忘了这步。金仓的SELECT sys_reload_conf()是常用命令，建议写在配置文件的注释里。
3. 监控idle in transaction
这个状态是金仓连接池的隐形杀手。设置idle_in_transaction_session_timeout是性价比最高的防御手段。
4. 超级用户的保留通道不能丢
金仓的superuser_reserved_connections默认值通常是3，别把它改成0。关键时刻能不能登录进去，就靠这个参数了。
5. 参数改之前先看context
金仓的max_connections是postmaster级别的参数，改了要重启。生产环境调整这类参数，需要提前申请变更窗口。
6. 优先级问题
金仓的ALTER SYSTEM写的kingbase.auto.conf优先级高于kingbase.conf。改完不生效，先检查这里。
金仓数据库的访问控制体系说复杂也复杂，说简单也简单。无非就是三件事：谁可以进来、进来后能干什么、出了问题怎么处理。把这三点理清楚，大部分问题都能迎刃而解。