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

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

原本计划很简单：

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

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

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

第一个问题就卡了很久。

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

arduino 复制代码

role "xxx" does not exist

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

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

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

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

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

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

bash 复制代码

ksql -Ukingbase -d test

结果：

arduino 复制代码

role "kingbase" does not exist

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

bash 复制代码

ksql -UKingbase -d test

ksql -Uroot -d test

结果还是一样。

当时第一反应是：

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

是不是 Docker 镜像有问题？

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

但是问题依旧。

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

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

Linux 用户
数据库角色

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

容器里面的：

复制代码

kingbase

只是操作系统账号。

它主要负责：

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

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

也就是说：

Linux存在：

复制代码

kingbase用户

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

复制代码

kingbase角色

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

复制代码

role does not exist

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

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

sql 复制代码

SYSTEM

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

复制代码

kingbase

使用：

bash 复制代码

ksql -USYSTEM -d template1

终于进入数据库。

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

sql 复制代码

SELECT rolname FROM pg_roles;

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

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

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

很多 PostgreSQL 教程里面默认：

复制代码

postgres

用户。

但是到了 KingbaseES：

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

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

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

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

例如：

sql 复制代码

CREATE USER zhuyh WITH PASSWORD 'xxxxxx';

执行成功：

sql 复制代码

CREATE ROLE

看起来没问题。

然后准备给它超级权限：

sql 复制代码

ALTER ROLE zhuyh WITH SUPERUSER;

结果：

vbnet 复制代码

ERROR: role "zhuyh" does not exist

这就比较奇怪了。

因为刚刚明明创建成功。

于是继续检查：

sql 复制代码

SELECT rolname 
FROM pg_roles 
WHERE rolname='zhuyh';

结果能查到：

复制代码

zhuyh

但是 ALTER 又失败。

当时有点懵。

一个用户：

查得到。

但是：

改不了。

后面定位到两个原因

第一个是事务问题。

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

所以创建以后建议：

sql 复制代码

COMMIT;

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

第二个原因和版本有关。

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

复制代码

pg_roles

能看到角色记录。

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

于是出现：

用户存在，但是 ALTER 失败

这种比较迷惑的问题。

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

与其：

先创建用户

再修改权限

不如一次性创建完成。

直接：

sql 复制代码

DROP ROLE IF EXISTS zhuyh;


CREATE ROLE zhuyh
WITH
LOGIN
PASSWORD 'xxxxxx'
SUPERUSER
CREATEDB
CREATEROLE;

创建完成以后检查：

sql 复制代码

SELECT 
rolname,
rolsuper
FROM pg_roles
WHERE rolname='zhuyh';

看到：

arduino 复制代码

zhuyh | true

才算真正完成。

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

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

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