★ FEATURED ARTICLE 简介这是一份面向数据库开发、运维及迁移实施人员的 Navicat 连接人大金仓操作指引重点解决跨库连接配置、日常管理与数据迁移中的常见问题。压缩包内共 1 个 docx 文件大小约 1.62MB篇幅集中、便于查阅。文档从 Navicat 的功能与下载安装讲起依次覆盖新建连接、账号密码配置、连接成功后的对象管理、创建数据库、转储 SQL 文件、复制为插入语句以及执行 SQL 语句并在注意事项中提示排序规则与字符集保持一致、谨慎选择图形工具及账号权限保护等要点。已有 1300 人学习适合需要快速上手人大金仓连接与基础库表操作、或对照排查乱码与迁移细节的读者参考。1. Navicat 连人大金仓那个“连接成功却查不出表”的坑用 Navicat 连人大金仓KingbaseES时最让人抓狂的不是连不上而是明明显示连接成功左侧却是一片空白建好的库、表全都不见了。我第一次遇到时以为权限出了问题反复换账号、重装客户端折腾了大半天才反应过来——客户端默认按 PostgreSQL 的协议去读系统表命名空间和服务端返回的目录结构对不上于是“连上了但看不见”。这类问题在国产数据库替代的迁移项目里特别常见开发日常用的是 Navicat服务端换成人大人金仓之后连接配置、字符集、排序规则、SQL 方言四道坎全堆在一起。下面按“连不上、连上乱码、能看见但导不出、能导出但跑不通”这几种典型故障把我踩过的坑和对应的排查顺序讲清楚新手照着命令能解决熟手能看到根因在哪。2. 连接报错排查从“连接失败”到账号验证的完整链路2.1 先分清到底是网络不通还是认证不过Navicat 点“测试连接”后弹出来的错误字面上大同小异但指向完全不同的层。我一般按下面的顺序切分报错关键词大概率卡在哪一层首查项Connection refused / 连接被拒绝TCP 层服务是否启动、端口是否监听timeout / 连接超时网络层防火墙、监听地址password authentication failed认证层用户名、密码、加密方式database xxx does not exist库名层库名大小写、默认库配置FATAL: no pg_hba.conf entry授权层服务端访问白名单先做最基础的一步确认服务端真的在监听。人大金仓默认端口是 54321这一点和 PostgreSQL 的 5432 相差一个数字很多人就是照着 PG 的习惯填了 5432结果一直提示连接被拒绝。# 在数据库服务器上执行确认 54321 端口处于监听状态 # Linux 环境用 ss 或 netstat两者有一个能用就行 ss -lntp | grep 54321 # 如果上面的命令没有任何输出说明服务没起或没监听该端口 # 查服务进程进程名通常是 kingbase ps -ef | grep kingbase | grep -v grep # 再看监听地址配置确认没有只绑定在 127.0.0.1 上 # 配置文件一般在数据目录下的 kingbase.conf grep -E ^listen_addresses|^port $KINGBASE_DATA/kingbase.confss -lntp里的-l只显示监听态、-n不做域名反解快、-t限定 TCP、-p显示进程。如果输出是127.0.0.1:54321而不是0.0.0.0:54321或*:54321那远端 Navicat 无论如何都连不上必须改listen_addresses。改完要重启服务配置不是热生效的。端口通了还报password authentication failed就别再怀疑密码打错了。人大金仓的密码加密方式和客户端握手协议有关服务端kingbase.conf里的password_encryption如果设成了 scram 类而客户端版本老握手阶段就会失败。常见做法是先用服务端自带的命令行工具验证一遍账号把客户端变量排除掉# 用服务端自带客户端验证账号是否可用 # -h 指定地址-p 指定端口-U 指定用户-d 指定库 ksql -h 127.0.0.1 -p 54321 -U system -d test # 若能登录说明账号密码没问题问题在 Navicat 侧或网络侧 # 若报认证失败先在服务端重置密码再试ksql是人大金仓自带的交互式客户端参数和 psql 基本一致。这一步的价值在于切断变量ksql在服务器本机能登、Navicat 在开发机不能登那问题百分之百在网络链路或客户端配置两边都登不上问题在服务端账号或sys_hba.conf白名单。白名单文件里没有开发机所在网段时报错就是no pg_hba.conf entry那一类需要加一行host all all 10.x.x.0/24 scram-sha-256之类的记录再重载配置。2.2 连接类型和端口填错是最容易被忽略的一类Navicat 新建连接时类型下拉里没有直接写“人大金仓”的选项需要用 PostgreSQL 类型来连。这一步选错比如选了 MySQLNavicat 会按 MySQL 的握手包发过去服务端直接断开报错往往是一句含糊的“Lost connection”或者“2003 - Cant connect”看日志完全对不上症结。我把这类配置的对照关系整理成表建连接时照着填Navicat 配置项正确填法常见错误填法连接类型PostgreSQLMySQL / Oracle主机数据库服务器 IPlocalhost跨机时无效端口543215432 / 3306初始数据库已存在的库名留空或填不存在的库认证方式按服务端实际配置随意勾选“初始数据库”这一项留空时部分 Navicat 版本会去连一个默认库如果服务端没有对应库报错是database xxx does not exist看起来像库被删了其实只是客户端默认值和服务端不一致。填一个确定存在的库比如安装时初始化的那个就能绕开这个假故障。2.3 认证失败反复出现时的排查顺序真遇到密码怎么输都不对我按这个顺序走基本两三轮就能定位服务端用ksql本地登录验证账号本身可用查sys_hba.conf部分版本是kingbase.conf同目录下的pb_hba.conf确认开发机网段在列、认证方法一致确认密码加密方式必要时临时改成 md5 验证是否握手问题换一个已知可用的客户端比如服务端自带图形工具交叉验证全部通过后仍失败抓一次客户端连接日志看握手阶段服务端返回的具体错误码。第 3 步属于典型的“临时绕过”手段验证完记得改回去。加密方式降级只是排错手段不是长期方案生产环境改配置要评估影响面。3. 连上之后乱码字符集与排序规则不一致引发的连锁反应3.1 乱码不是客户端的问题是建库时就埋下的连接成功、表也能看见一查数据中文全是问号或者方块这种故障根子在建库那一刻就种下了。Navicat 建库向导里有一项“排序规则”如果随手选了默认值建出来的库编码可能和用人大金仓自带图形工具建出来的库不一致——后者常见的是zh_CN.UTF-8一类的本地化设置混着用时就会出现“同一个中文在这边显示正常导到那边成乱码”。我一般建库前先查清服务端现状避免盲选-- 查看当前实例支持哪些字符集与排序规则组合 -- 这条能看出哪些 locale 是真正可用的 SELECT * FROM sys_collation ORDER BY collname; -- 查看已有库的编码和排序规则新库按它对齐 SELECT datname, pg_encoding_to_char(encoding) AS encoding, datcollate, datctype FROM sys_database;第一条查的是排序规则目录sys_前缀是人大金仓对系统表的命名习惯写法上兼容 PostgreSQL 的元数据查询思路。第二条最关键datcollate和datctype两列决定了这个库怎么比较字符串、怎么分类字符。新建库时把这两项抄成和源库完全一致是避免乱码最省事的做法。建库语句可以显式指定比在 GUI 里点选更可控-- 显式指定编码与排序规则与源库保持一致 -- TEMPLATE template0 避免继承模板库的本地化设置 CREATE DATABASE appdb WITH ENCODING UTF8 LC_COLLATE C LC_CTYPE C TEMPLATE template0;LC_COLLATE C表示按字节序排序LC_CTYPE C表示按 ASCII 分类字符。这两项用C的好处是行为最稳定、跨平台迁移不漂移代价是中文排序不按拼音走。项目正文里明确建议用C原因就在这排序规则一旦不一致不只是乱码索引的比较行为、唯一约束的判定都会跟着变迁移过去后可能出现“明明没重复却报唯一键冲突”这种玄学问题。TEMPLATE template0这行不能省用 template1 会把模板库的 locale 一起继承过来等于白设。3.2 已经乱码的库怎么补救库已经建歪了重来成本高的话分两条路走能接受停机的用导出重建的方式换编码不能停机的先确认乱码是存储层坏了还是显示层的问题。判断方法很简单——用ksql直接查同一行数据如果命令行里显示正常、只有 Navicat 里乱码那是客户端编码设置问题在 Navicat 连接属性里把编码调成 UTF-8 即可数据本身没坏。-- 在乱码库中执行确认实际存储的字节序列 -- convert_from 把字节按指定编码解释能看出存进去时用的什么编码 SELECT convert_from(convert_to(name, UTF8), UTF8) FROM t_user LIMIT 5;如果命令行查出来也是乱码数据在入库时就已经按错误编码存进去了只能导出后重新导入导入时显式指定编码。导出的 SQL 文件头部通常带SET client_encoding语句导入前检查这一行把它改成和服务端一致的 UTF8能救回相当一部分数据。提示用 Navicat 图形化建库时排序规则下拉框的默认值不一定是服务端推荐值。养成建库前先跑一遍sys_database查询、照着已有库抄参数的习惯比事后救火便宜得多。4. 导出导入报错转储 SQL、复制插入语句的典型翻车场景4.1 转储 SQL 文件失败先看权限和路径“转储 SQL 文件”是迁移时用得最多的功能报错却经常只有一句“保存失败”或者进度条卡住。根因无非三类导出路径无写权限、库太大导致单文件超限、服务端权限不足读不到某些对象。# 确认导出目录有写权限Navicat 在客户端本机写文件 # 用当前登录用户身份测试 touch /data/export/test.sql echo write ok # 若是从服务端直接导确认账号对目标表有 SELECT 权限第一种情况最常见Windows 上选了C:\Program Files下的目录或者 Linux 上选了个只有 root 能写的路径Navicat 进程没有权限创建文件报错信息却只提示失败不提示原因。换成用户目录下的路径重试往往立刻就好。第二种情况在大表上很典型。单表几十 GB 时转储会生成巨大的 SQL 文件客户端内存或磁盘先扛不住。我一般改成按表分批导或者直接用服务端命令导出稳定得多# 用服务端自带工具导出按表逐个导避免单文件过大 # -f 指定输出文件-t 指定表名-d 指定库名 sys_dump -h 127.0.0.1 -p 54321 -U system -d appdb \ -t public.t_order -f /data/export/t_order.sqlsys_dump是人大金仓的导出工具参数体系和 pg_dump 一致。-t指定单表时只导结构和数据配合--inserts可以生成纯 INSERT 语句方便在其他环境重放不加--inserts则生成 COPY 格式导入更快但可读性差。迁移场景我倾向加--inserts出问题时能直接看出是哪条记录炸的。4.2 复制为插入语句时间戳和转义容易炸“复制为插入语句”适合小批量搬数据但直接粘贴执行经常报错。三类高频翻车点第一类是文本里的单引号没转义。数据里带OBrien这种内容时生成的语句会把 SQL 截断执行报语法错误。Navicat 生成语句时通常会自动转义但跨版本、跨数据库类型粘贴时不一定保留。第二类是时间戳格式。人大金仓对timestamp的默认输入格式和某些客户端生成的不一致粘贴后报invalid input syntax for type timestamp。解决办法是粘贴后统一改成标准格式或者在 INSERT 时用to_timestamp()显式转换-- 显式转换时间避免格式假设 -- YYYY-MM-DD HH24:MI:SS 是人大金仓通用可解析的格式 INSERT INTO t_order (id, order_no, created_at) VALUES (1, NO20240101, to_timestamp(2024-01-01 10:00:00, YYYY-MM-DD HH24:MI:SS));to_timestamp的第二个参数是格式模板HH24是 24 小时制写成HH在某些版本下会被当 12 小时制解析下午的时间就错了。第三类是序列没跟上。手工插入指定了主键值但序列的当前值没推进后续正常插入立刻报主键冲突。这是血泪经验里最隐蔽的一种——搬完数据一切正常第二天业务写入全挂。搬完手工插入的数据后记得把序列校准-- 把序列推进到当前最大 id避免后续插入主键冲突 SELECT setval(t_order_id_seq, (SELECT MAX(id) FROM t_order));setval的第二个参数是下一个可用值的前一个值默认不传第三个参数时下一次nextval返回的就是MAX(id)1。多表迁移时每张表都要过一遍漏一张就留一颗雷。5. 避坑清单连接与迁移中最容易翻车的五件事坑一端口照着 PostgreSQL 填 5432。现象是连接被拒绝或超时排查半天网络。原因是人大金仓默认端口是 54321差一个数字。解决是把连接配置和防火墙规则统一改成 54321并在文档里写死别让下一个人再猜。坑二建库时排序规则随手选默认。现象是数据导过去中文变乱码或者唯一索引莫名冲突。原因是源库和目标的datcollate、datctype不一致比较行为漂移。解决是建库前先查sys_database把参数抄一致优先用C。坑三用 Navicat 连接却不改连接类型。现象是报“Lost connection”日志看着像网络故障。原因是客户端按 MySQL 协议握手服务端直接断开。解决是连接类型选 PostgreSQL初始数据库填一个确实存在的库。坑四大批量数据用 GUI 一次性转储。现象是进度条卡死、内存暴涨、文件写到一半失败。原因是客户端把所有数据拉进内存再落盘。解决是改用sys_dump按表分批导或者拆成多个批次。坑五手工插完数据不校准序列。现象是迁移当天一切正常次日业务写入报主键冲突。原因是序列当前值落后于实际最大 id。解决是每张表执行一次setval把序列顶到MAX(id)。这五条里有三条的报错信息都具有误导性——看着像网络问题、权限问题实际是配置问题。排查时先怀疑配置比先怀疑环境效率高得多。6. 快速定位一套五分钟内跑完的排查动作接手一台连不上人大金仓的开发机我一般五分钟内走完下面这套动作绝大多数问题在第三步之前就暴露了。# 1. 网络层端口通不通在开发机执行 nc -zv 10.0.0.10 54321 # 2. 认证层账号能不能过在服务器本机执行 ksql -h 127.0.0.1 -p 54321 -U system -d appdb -c select 1; # 3. 授权层客户端网段在不在白名单 grep -v ^# $KINGBASE_DATA/sys_hba.conf | grep -v ^$nc -zv的-z是只扫不传数据、-v输出详情几秒出结果。第 1 步不通就是网络或服务没起第 1 步通第 2 步不通是账号或加密方式第 1、2 步都通但 Navicat 连不上那问题就在客户端配置或白名单直接看第 3 步的输出对照开发机 IP 网段。排查时对照下表快速归位现象优先怀疑一条命令验证连接被拒绝端口填错 / 服务没起ss -lntp | grep 54321连接超时防火墙 / 监听地址nc -zv IP 54321认证失败密码 / 加密方式ksql -U user -d db库不存在初始库名填错\l列出所有库中文乱码编码 / 排序规则查sys_database导入报语法错转义 / 时间格式单条语句重放几个容易被误判的点值得单独拎出来。报“连接超时”时很多人第一反应是网络不通实际上监听地址绑成 127.0.0.1 也会表现为超时所以nc通不代表配置对还得回服务端看listen_addresses。报“库不存在”时先别急着找备份多数是 Navicat 初始数据库那栏填了个已经不存在的库名。报语法错误的 INSERT先单独拎出来执行看是转义问题还是方言差异——人大金仓兼容 PG 语法但并非完全等同个别函数名和类型转换写法有差别。最后说一个我吃过的亏一次迁移项目里所有表都导完了业务方开始验收才发现某张表的序列没校准第二天早上批量写入全报主键冲突回滚重来花了整整一个下午。从那以后我每次做完数据迁移都会强制走一遍“逐表 setval 抽三条数据做写入测试”的收尾动作不管数据量多小。排查这件事事后补救的成本永远高于事前多敲两行命令。希望这些步骤能帮你少走几个弯路。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
