折腾电科金仓 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 文档很容易第一步就卡住。创建业务用户时又遇到一个奇怪问题进入数据库以后我准备创建自己的业务账号。例如CREATEUSERzhuyhWITHPASSWORDxxxxxx;执行成功CREATE ROLE看起来没问题。然后准备给它超级权限ALTERROLE zhuyhWITHSUPERUSER;结果ERROR: role zhuyh does not exist这就比较奇怪了。因为刚刚明明创建成功。于是继续检查SELECTrolnameFROMpg_rolesWHERErolnamezhuyh;结果能查到zhuyh但是 ALTER 又失败。当时有点懵。一个用户查得到。但是改不了。后面定位到两个原因第一个是事务问题。在交互式 ksql 环境里面如果之前执行过一些操作没有及时提交事务新创建的角色状态可能没有完全落盘。所以创建以后建议COMMIT;再继续执行后续权限修改。第二个原因和版本有关。部分 KingbaseES 版本在角色目录同步方面存在异常情况pg_roles能看到角色记录。但是权限认证相关目录没有同步完成。于是出现用户存在但是 ALTER 失败这种比较迷惑的问题。后来换了一种更稳的创建方式与其先创建用户再修改权限不如一次性创建完成。直接DROPROLEIFEXISTSzhuyh;CREATEROLE zhuyhWITHLOGIN PASSWORDxxxxxxSUPERUSER CREATEDB CREATEROLE;创建完成以后检查SELECTrolname,rolsuperFROMpg_rolesWHERErolnamezhuyh;看到zhuyh | true才算真正完成。这个过程中最大的感受就是数据库用户权限这块不要完全按照 MySQL 或 PostgreSQL 的习惯操作。尤其国产数据库虽然兼容 PostgreSQL但是一些初始化细节还是有差异。