折腾电科金仓 Docker 部署的一晚上：角色登录失败、远程连接失败，这几个坑终于踩完了

最近测试国产数据库环境，需要在一台 CentOS 云服务器上部署电科金仓 KingbaseES。

原本计划很简单：

Docker 拉镜像 → 启动数据库 → 创建用户 → DBeaver连接。

按照以前部署 PostgreSQL 的经验，这种事情基本半小时搞定。

但真正开始操作后，才发现国产数据库和自己之前熟悉的 PostgreSQL 还是有一些区别。

第一个问题就卡了很久。

进入容器以后，连续几个登录命令全部失败：

role "xxx" does not exist

后面又遇到了新建用户权限异常、本地不用密码直接登录、外网端口无法访问等问题。

中间反复查配置、改参数、重启容器，最后才把整个链路跑通。

这里记录一下整个过程，主要是一些新手部署电科金仓时比较容易忽略的细节。

1. 第一个坑：kingbase 用户为什么登录不了？

刚开始进入容器的时候，我看到系统用户名是 kingbase。

按照惯性思维，直接尝试：

ksql-Ukingbase-dtest

结果：

role "kingbase" does not exist

随后又试了几个网上经常出现的用户名：

ksql-UKingbase-dtestksql-Uroot-dtest

结果还是一样。

当时第一反应是：

是不是数据库初始化失败？

是不是 Docker 镜像有问题？

甚至重新启动了一遍容器。

但是问题依旧。

后来重新梳理了一遍才发现，自己一开始就搞错了方向。

这里其实有两个完全不同的概念：

• Linux 用户
• 数据库角色

虽然名字看起来一样，但它们没有任何自动关联关系。

容器里面的：

kingbase

只是操作系统账号。

它主要负责：

• 数据目录权限
• 数据库进程运行
• 文件访问

但是数据库里面能不能登录，需要看 Kingbase 自己维护的角色。

也就是说：

Linux存在：

kingbase用户

不代表数据库里面一定存在：

kingbase角色

这也是为什么前面几个命令都会提示：

role does not exist

默认管理员不是 kingbase，而是 SYSTEM

继续排查后发现，电科金仓初始化后的默认管理员是：

SYSTEM

而不是很多资料里面写的：

kingbase

使用：

ksql-USYSTEM-dtemplate1

终于进入数据库。

进入以后先查看当前角色：

SELECTrolnameFROMpg_roles;

可以看到数据库里面真实存在的用户。

这时候才发现，之前一直尝试登录的几个用户名，数据库里根本没有。

这个地方其实挺容易误导。

很多 PostgreSQL 教程里面默认：

postgres

用户。

但是到了 KingbaseES：

默认管理员和配置方式都有自己的调整。

如果完全照搬 PostgreSQL 文档，很容易第一步就卡住。

创建业务用户时，又遇到一个奇怪问题

进入数据库以后，我准备创建自己的业务账号。

例如：

CREATEUSERzhuyhWITHPASSWORD'xxxxxx';

执行成功：

CREATE ROLE

看起来没问题。

然后准备给它超级权限：

ALTERROLE zhuyhWITHSUPERUSER;

结果：

ERROR: role "zhuyh" does not exist

这就比较奇怪了。

因为刚刚明明创建成功。

于是继续检查：

SELECTrolnameFROMpg_rolesWHERErolname='zhuyh';

结果能查到：

zhuyh

但是 ALTER 又失败。

当时有点懵。

一个用户：

查得到。

但是：

改不了。

后面定位到两个原因

第一个是事务问题。

在交互式 ksql 环境里面，如果之前执行过一些操作，没有及时提交事务，新创建的角色状态可能没有完全落盘。

所以创建以后建议：

COMMIT;

再继续执行后续权限修改。

第二个原因和版本有关。

部分 KingbaseES 版本在角色目录同步方面存在异常情况：

pg_roles

能看到角色记录。

但是权限认证相关目录没有同步完成。

于是出现：

用户存在，但是 ALTER 失败

这种比较迷惑的问题。

后来换了一种更稳的创建方式

与其：

先创建用户

再修改权限

不如一次性创建完成。

直接：

DROPROLEIFEXISTSzhuyh;CREATEROLE zhuyhWITHLOGIN PASSWORD'xxxxxx'SUPERUSER CREATEDB CREATEROLE;

创建完成以后检查：

SELECTrolname,rolsuperFROMpg_rolesWHERErolname='zhuyh';

看到：

zhuyh | true

才算真正完成。

这个过程中最大的感受就是：

数据库用户权限这块，不要完全按照 MySQL 或 PostgreSQL 的习惯操作。

尤其国产数据库，虽然兼容 PostgreSQL，但是一些初始化细节还是有差异。