做 Qlik Sense 运维的人八成绕不开 Sebastian_Linser 维护的这套 Qlik Sense PostgreSQL installer。我第一次看到 “SupportRelease Notes Qlik Sense PostgreSQL installer version” 这个标题时以为是再普通不过的发布说明直到一次客户环境里 Qlik Sense Repository 服务连不上数据库、查了一整天才定位到问题出在安装器版本和 PostgreSQL 版本错位才意识到这份 Release Notes 完全不是摆设。它不是给 PostgreSQL 爱好者看的技术文档而是给所有需要在 Windows 或 Linux 上独立部署 Qlik Sense 后台数据库的管理员准备的一份“版本对照表和排错路线图”。这篇内容就围绕这套安装器展开它到底解决什么问题、版本号该怎么读、怎么部署、踩坑怎么排、升级怎么规划。系统集成商、BI 平台运维、负责 Qlik 环境交付的同事都能直接参考。1. 一套不起眼的安装器背后是整个 Qlik 数据底座1.1 Qlik Sense 为什么离不开 PostgreSQL先理清关系Qlik Sense 的分析引擎、Hub、管理中心是一回事它背后的存储库数据库Repository Database是另一回事。应用元数据、用户权限、调度任务、操作日志、业务连接信息全部存在这个数据库里。Qlik Sense 默认使用 PostgreSQL 来承担这个角色官方安装向导也会在你安装 Qlik Sense 时自动把配套的 PostgreSQL 装进系统。听起来没什么存在感但实际环境里情况完全不同。我在交付项目时经常遇到三类场景一是企业 IT 不允许安装向导动服务器要求数据库单独装、单独管二是升级 Qlik Sense 大版本时希望继续复用现有数据库实例不想把应用数据再导一遍三是离线内网环境根本没有官方向导依赖的组件源。这几种情况都指向同一个需求需要有一个独立的、能一次装好、并且从一开始就按 Qlik 存储库要求完成初始化的 PostgreSQL 安装器。Sebastian_Linser 这套安装器做的正是这件事——把 PostgreSQL 的二进制、配置脚本、服务注册、初始账号体系打包成一个可重复执行的安装流程避免管理员手工初始化时漏掉关键参数。还有一点容易被忽略Qlik Sense 的 Repository 服务对数据库的稳定性极其敏感。数据库连不上你在 Qlik 控制台里看到的可能只是“服务启动失败”但排查链路会一路从服务日志追到 ODBC 驱动再追到 PostgreSQL 的监听地址和端口。这个链条里任何一个环节和安装器版本对不上都会变成疑难杂症。1.2 Release Notes 才是真正有用的入口很多人下载完安装器解压、下一步、完成从没认真读过 Release Notes。但我个人的习惯恰恰相反拿到新版本安装器第一件事就是看 Release Notes尤其是看里面三个映射关系——安装器自身版本、内嵌的 PostgreSQL 版本、适配的 Qlik Sense 版本。这三者只要错一个后面连接、备份、升级都会出问题。这套安装器的 Release Notes 通常按几个固定板块组织。New Features 会告诉你新增了哪些安装参数、支持了哪些操作系统版本Fixed Issues 会列出这个版本修掉了哪些安装失败场景Known Issues 会告诉你哪些边界场景还没支持。我一直把 Fixed Issues 当作排错字典用遇到安装报错先去对应版本的 Fixed Issues 里搜一遍很多时候报错早就被修过只是你手里的安装器版本太老。1.3 版本号的正确打开方式标题里的 version 很容易让人误解。安装器版本号例如 v7.0.0 这类格式并不直接等于 PostgreSQL 版本它代表的是“安装器封装层自身的迭代版本 内嵌的 PostgreSQL 小版本”。Release Notes 的正文里通常会明确写一行 bundled PostgreSQL version那才是你真正需要记住的数字。这里我踩过一次坑看到一个安装器版本号很高下意识以为数据库也很新结果部署完才发现内嵌的 PostgreSQL 版本和当时适配的 Qlik Sense 版本差了整整一个大版本导出导入折腾了一个通宵。所以读版本信息时要养成一个习惯不是看安装器版本号而是看两行信息——一行是 bundled PostgreSQL version一行是 supported Qlik Sense versions。有些 Release Notes 还会带 build date这个日期也能用来判断安装包内嵌的 PostgreSQL 补丁级别比如是否包含某个安全修复。生产环境选安装器不选最新版要选和 Qlik Sense 主版本配套的那一版。2. 版本兼容性别让数据库跑得比 Qlik 还快2.1 Qlik 的认证版本向来不是最新版每次有同行来问“PostgreSQL 下载哪个版本”我都会反问一句你是给哪个应用用的如果答案是 Qlik Sense那正确答案不是去 PostgreSQL 官网挑最新版而是看 Qlik 认证过的版本列表。Qlik 对 PostgreSQL 的版本认证向来是“滞后哲学”社区里 PostgreSQL 已经出到 17 的时候Qlik 认证列表里往往还停留在 14 或 15 附近。这不是 Qlik 技术落后而是因为商业智能平台的数据库底座讲究的是稳定压倒一切。Qlik 的驱动、内部查询逻辑、存储过程都需要在特定 PostgreSQL 版本上做完整验证验证需要时间。对应到这套安装器场景里结论很简单使用安装器时以 Release Notes 里声明的 bundled PostgreSQL version 为准不要自己手动换成更新版本的 PostgreSQL 二进制。我见过同事觉得内嵌版本太老自己下载了新版 PostgreSQL 替换结果 Qlik Sense 的服务日志里全是语法错误和驱动版本不兼容最后只能重装。这里可以给一个粗略的决策参考表具体数字以官方认证矩阵为准你的部署场景首选数据库来源建议做法官方安装向导正常使用向导内置 PostgreSQL不要手动替换数据库版本分步部署、离线环境、独立安装器安装器 Release Notes 声明的 bundled version锁定版本号不追新已有独立 PostgreSQL 集群Qlik 官方认证的版本列表保持大版本一致小版本不低于要求测试、概念验证便携版 PostgreSQL可以随意生产环境不要用便携版2.2 三类发布条目扫一眼就知道能不能装Release Notes 读得多了你会发现真正需要关注的条目就三类。第一类是新增支持例如“support for PostgreSQL 15 on Windows Server 2022”这行文字等于告诉你如果你要在 Windows Server 2022 上部署 Qlik 配套数据库这个安装器版本是验证过的。第二类是修复项例如“fixed: installer fails when path contains non-ASCII characters”如果你的服务器用户名、路径带中文或特殊字符这条修复就跟你直接相关。第三类是已知问题例如“known issue: silent install does not work on Ubuntu 24.04 with SELinux enforcing”遇到这种条目就别硬上要么换系统要么关掉强制模式再试。我也习惯把 Release Notes 当作兼容性排查列表来用。出问题时先对照当前环境版本再对照 Release Notes 里声明的支持范围往往能在五分钟内定位到是“环境不支持”还是“安装器 bug”。这个动作比直接在搜索引擎里复制报错信息更高效因为搜索引擎的结果大多是其他软件的报错和你的场景并不一致。2.3 便携版、独立版、源码编译怎么选热词里很多人搜 PostgreSQL 16 便携版、PostgreSQL 17说明不少人在纠结数据库版本和安装方式。在 Qlik Sense 场景里我的建议非常明确生产环境用安装器内嵌版本便携版只适合在测试机或自己的笔记本上做概念验证。便携版虽然方便解压就能跑但它在服务注册、开机自启、权限模型上和正式安装版有差异容易在部署后出现“数据库进程还在但服务管理里找不到”的尴尬情况。源码编译则是备选中的备选。为什么有人要源码编译 PostgreSQL通常是系统自带的二进制版本不满足要求或者系统的 glibc 库太老官方二进制跑不起来。源码编译的好处是可定制、能匹配老系统坏处是后续补丁升级要自己重新编译运维成本明显变高。在 Qlik 场景里源码编译的 PostgreSQL 还可能出现和 Qlik 驱动兼容性未知的问题所以我不建议为了省事选这条路除非你已经在 Release Notes 里确认过没有现成二进制可用。3. 部署实操从下载安装器到 Qlik 连上数据库3.1 安装前把这些事情定下来装这套安装器之前先把下面几件事定死能省掉后面 80% 的返工。第一操作系统版本。Windows 环境确认是 Server 2019 还是 Server 2022Linux 环境确认是 CentOS 7.x、Ubuntu 还是其他发行版不同平台对应的安装器包不同Release Notes 里也明确写了支持范围。第二服务账号。Windows 下我习惯给数据库单独建一个本地账号不给管理员权限Linux 下一定不要用 root后面踩坑章节会专门说。第三端口。默认 5432 够用但如果这台服务器上已经装了别的 PostgreSQL或者公司安全策略要求使用高位端口提前定好端口号后面所有连接串都要跟着改。第四数据目录。不要把数据放在系统盘尤其不要放 C 盘系统目录里数据库文件增长快系统盘爆了连 Windows 登录都会卡。第五防火墙和 hosts 解析。Qlik Sense 服务器和数据库服务器如果不是同一台机器要确保两者之间端口互通并且主机名能解析。我遇到过不少“数据库装好了Qlik 连不上”的案例最后查出来是 hosts 文件里没有加映射应用用了主机名解析不到 IP。3.2 静默安装的参数套路这套安装器支持交互式安装和静默安装交付项目时一定要用静默模式因为可以写进部署脚本重复执行不弹窗。以常见的 Linux 命令行安装器为例参数大致是这样./qlik-sense-postgresql-installer.bin \ --mode unattended \ --unattendedmodeui none \ --prefix /opt/qlik/pgsql \ --datadir /data/qlik/pgdata \ --superuser postgres \ --superuserpasswd 强密码 \ --port 5432 \ --serviceuser qlikrepo \ --serviceuserpasswd 强密码需要说明的是具体参数名请以你拿到的安装器 --help 输出为准不同封装方式InstallBuilder、Inno Setup、Advanced Installer的命令行参数略有差异。Windows 下通常是对应 exe 加静默参数或者同样支持 --mode unattended。第一次使用时先跑一下installer --help看参数列表比直接猜参数靠谱得多。有几个细节值得注意。一是密码不要在命令行里明文保留太久部署完要及时清理 shell 历史或者用参数文件方式传递敏感信息。二是 superuser 名建议保持 postgres不要改成自定义用户名后续 Qlik 的初始化脚本默认会连接 postgres 超级用户。三是 datadir 一定要单独指定到数据盘安装器默认路径不一定适合你的环境。四是安装日志要留一份通常安装器会输出安装日志路径出问题时第一件事就是翻日志。静默安装完成后第一轮验证是检查服务和进程。Windows 下看服务管理器里有没有 PostgreSQL 相关服务Linux 下看 systemctl 状态是否 active。第二轮验证是连接测试psql -h 127.0.0.1 -p 5432 -U postgres -c select version();能正常返回版本号说明数据库层面已经通了。3.3 初始化、服务注册、让 Qlik Sense 找到数据库安装器装好的只是一个能跑的 PostgreSQL 实例要让 Qlik Sense 真正用上它还要完成存储库数据库的初始化。部分安装器本身就带了初始化脚本会自动创建 Qlik 需要的数据表结构如果没有就要在 Qlik Sense 的配置向导里把数据库指向这个实例让向导完成初始化。连接配置这一步最容易出错。Qlik Sense Repository Service 的连接串通常需要包含主机名、端口、数据库名和账号信息类似这样Hostqlik-db-host;Port5432;DatabaseQSR;Userqlikrepo;Password...这里的 Host 建议写 Qlik Sense 服务器能解析到的完整主机名不要写 localhost因为服务跨机器时 localhost 指向的是本机而不是数据库服务器。端口必须和安装器指定的一致自定义过端口的人最容易在这里栽跟头。Database 名称以你的初始化脚本实际创建的库名为准别默认它叫 postgres。配置完连接串启动 Qlik Sense Repository Service观察日志有没有报数据库连接错误。打开 Qlik Sense 管理控制台能正常加载应用列表和用户权限说明数据库已经接上了。整个过程中Qlik 控制台只是表象后台 Repository 数据库的日志才是真相来源。4. 安装现场的高频报错排查链路完整还原4.1 Linux 下 cannot install as root不是 bug 是安全线在 Linux 上部署时很多人习惯 sudo 执行一切安装程序结果这套安装器直接甩出一行报错error: exiting installer: cannot install as root user !第一次遇到时我的第一反应是安装器坏了后来才明白这是有意为之。PostgreSQL 的 postgres 服务进程出于安全设计拒绝以 root 身份运行因为一旦数据库进程被攻破以 root 权限运行的后果是整个服务器沦陷。安装器既然知道数据库服务最终不能以 root 跑干脆在安装阶段就拒绝 root逼你在安装时就把账号模型建对。正确的做法是创建一个专用账号并把安装目录和数据目录的属主都交给这个账号useradd -r -m -d /home/qlikrepo qlikrepo mkdir -p /opt/qlik/pgsql /data/qlik/pgdata chown -R qlikrepo:qlikrepo /opt/qlik/pgsql /data/qlik/pgdata su - qlikrepo -c /path/to/installer.bin --mode unattended ...这里有个细节不要给数据目录 chmod 777这会绕开权限模型短期看能装成功长期看会造成数据库数据文件权限混乱服务重启后可能起不来。正确的姿势永远是“账号 属主”而不是“权限放开”。排查这条链路时先确认当前执行安装的用户是谁再确认目标目录属主最后检查服务账号是否能读安装目录。4.2 Windows Installer 服务不可用、错误 1053系统层问题Windows 环境下的安装器报错往往不是安装器自身的问题而是系统组件坏了。热词里有条非常典型的信息visual studio installer windows installer 服务不可用请重启系统以及 Windows 无法启动 Windows Installer 服务错误 1053。这类报错常见于服务器上装过大量软件、卸载不干净或者被安全软件禁用了系统服务的场景。Windows Installer 服务是 MSI 格式安装包的基础很多安装器会先调用它去装前置依赖比如 VC 运行库前置依赖装不上主安装器自然失败。完整的排查链路如下打开 services.msc找到 Windows Installer。正常状态应该是手动触发手动启动时应能正常变为正在运行如果启动时直接报 1053说明服务本身状态损坏。以管理员身份打开命令行重新注册服务msiexec /unregister msiexec /register如果重新注册后仍启动失败检查 C:\Windows\System32\msiexec.exe 和 msi.dll 是否存在、是否被安全软件隔离。系统文件缺失时执行完整性修复sfc /scannow仍不行就用 Windows Installer Clean Up 工具清理掉以往安装失败的残留记录再重试。这里可以把常见错误码和响应对应对照起来错误现象可能原因处理动作Windows Installer 服务不能启动MSI 服务注册表损坏msiexec /unregister 后 /register错误 1053 服务没有及时响应系统文件缺失或 DLL 注册异常sfc /scannow检查 msi.dll安装中途提示某组件已存在上一次安装残留用 Windows Installer Clean Up 清理Visual Studio Installer 触发 Windows Installer缺少运行库前置项先单独装对应 VC 运行库这套链路不一定只对该安装器有效任何 Windows 下 MSI 类的安装器基本都适用。4.3 Linux 二进制依赖缺失GLIBCXX_3.4.21 not foundLinux 下还有一类高频报错运行安装器时提示/lib/libstdc.so.6: version GLIBCXX_3.4.21 not found。这种现象在 CentOS 7.9 上尤其常见因为系统自带的 libstdc.so.6 版本偏老而安装器或 PostgreSQL 二进制是由新版 GCC 编译的运行库版本对不上。排查链路不复杂。先确认运行库支持到哪个版本strings /usr/lib64/libstdc.so.6 | grep GLIBCXX如果输出里找不到 GLIBCXX_3.4.21就说明运行库确实不够新。解决方案按优先级排列第一找对应系统版本编译的二进制包这是最省事的第二安装较新的开发工具集运行库把 libstdc 升级到满足要求的版本第三源码编译 PostgreSQL把运行库依赖降到系统可用范围内但代价是后续升级麻烦。在 Qlik 场景里我优先推荐第一种因为源码编译的版本没有经过安装器 Release Notes 的验证埋下的隐患可能要很久以后才暴露。4.4 容器化替代路径的坑有些团队倾向用 Docker 跑 PostgreSQL 给 Qlik 用这个思路可行但容器环境本身有独立于安装器的坑。热词里有一条典型报错docker search redis request returned 500 internal server error后面还带一句 check if the server supports the requested api version。这类报错和 PostgreSQL 毫无关系是 Docker 客户端和引擎的 API 版本不一致或者 Docker Desktop 引擎没有正常启动。排查时先看两端版本docker version如果 Client 和 Server 的 API 版本明显不一致或者 Server 端显示为空重启 Docker 引擎或 Docker Desktop 基本能解决。容器方式跑 PostgreSQL 还有三个注意点数据卷必须挂载到宿主机否则容器一删数据全没端口映射后Qlik 连接串里写的是宿主机地址加映射端口容器镜像的 PostgreSQL 版本要和 Qlik 认证版本对齐不要随手拉 latest 标签。容器化适合临时环境、测试环境和贴合公司容器化规范的生产环境但如果公司有一个专职 DBA 团队管理数据库传统安装器部署往往更容易被运维体系接受。5. 升级维护把 Release Notes 当路线图用5.1 升级前必须对照的三张表每次升级 Qlik Sense 或 PostgreSQL我都习惯先整理三张表。第一张是 Qlik Sense 版本和认证 PostgreSQL 版本的对应表确认目标数据库大版本被 Qlik 支持第二张是安装器 Release Notes 里该版本声明的新增、修复、已知问题确认升级路径有没有 breaking change第三张是当前环境的备份和恢复演练记录确认万一升级失败能在一个小时内回到原状态。常有人只盯着第一张表跳过了第二张。实际上 Release Notes 里写得很清楚的事比如某个版本的安装器不再支持 Windows Server 2016、某个版本改了默认数据目录名称不看就会踩中兼容性雷区。升级不是下载新版本往上盖必须先读发布说明。5.2 一个稳妥的小版本升级动作清单如果只是 PostgreSQL 小版本升级我的标准操作顺序是维护窗口前做一次 pg_dump 全量备份再对数据目录做一次冷备份双保险。停掉 Qlik Sense 相关服务至少停 Repository Service避免升级过程中应用还在写数据库。停掉 PostgreSQL 服务。用新安装器执行升级动作或者使用 pg_upgrade 工具。跨大版本升级时务必先跑 pg_upgrade --check 做预检预检不过就停下来查原因不要强跑。启动 PostgreSQL 服务用 psql 做一次连接和权限验证。启动 Qlik Sense 服务验证登录、刷新任务、打开几个应用确认正常读取元数据。观察一个发布周期后再清理旧备份。升级中最怕的是跳过预检直接上生产。pg_upgrade 虽然成熟但遇到自定义扩展、旧版本残留配置时也会翻车。我的经验是升级动作本身不复杂复杂的是升级前的检查清单是否完整。5.3 一个老运维的碎碎念最后说几句个人体会。这套安装器和它的 Release Notes看起来是给机器用的技术文档实际上更像是给管理员的一份“版本安全地图”。我见过太多安装失败的现场最后定位到的原因不是安装器不行而是版本组合不对——Qlik 主版本、安装器版本、PostgreSQL 版本、操作系统版本四个变量里只要有一个偏离认证范围问题就会以各种形式出现。所以不要小看 Release Notes 里那一行小版本数字。PostgreSQL 的补丁版本往往包含安全修复第三方安装器更新通常就是为了跟进这些补丁遇到无法解释的安装失败先去对应版本的 Fixed Issues 里搜一遍生产环境不要用便携版测试环境要尽量模拟生产的小版本号。这些细节单看都不起眼但组合起来就是一套能稳稳跑上几年的 Qlik 数据底座。