升级 RDS 这种事干多了以为万事俱备但真正自己动手做一次 Qlik Sense 的 Repository Database 解绑才知道里面有不少讲究。标题里那个 unbundling 翻译成大白话就是把 Qlik Sense 默认装在机器里的那个 PostgreSQL 数据库“请出去”换成你自己管理的独立数据库实例同时顺手把 PostgreSQL 从老版本升到新版。这事通常不是你心血来潮而是量上来了、团队分工变了、或者安全合规要求你不能再把元数据库扔在安装目录下面这时候就必须用 Qlik 官方的 Qlik PostgreSQL Installer 把这个过程标准化。本文我会按自己的实测经验把从准备、安装、迁移到切换验证的完整过程连同踩过的坑一起讲清楚。1. 为什么要把 Repository Database 从 Qlik Sense 里“拆”出来1.1 Repository Database 到底存了什么很多刚接触 Qlik Sense 的人容易把注意力都放在 QVD、sense 应用和数据连接上几乎忽略了 Repository 数据库的存在。但实际上你的 Qlik Sense 服务能不能正常工作全靠这个仓库数据库撑着。它保存的不只是应用元数据还包括站点 ID、用户目录配置、安全规则、任务调度、日志条目、Stream 权限、自定义属性甚至你发布到共享空间里的所有应用内容都映射在 Repository 的表里。打个比方Qlik Sense 的引擎像是厨房里的灶台和锅而 Repository Database 就是那本记录了所有菜谱、库存和出餐记录的总账本。灶台临时坏了还能修可账本乱了整家店就分不清谁点了什么菜。所以在做任何升级、迁移之前必须把这个库的完整性和连续性放在第一位。我遇到过因为 Repository 表索引损坏导致 Qlik Management Console 登录界面直接 500 的情况那查错查得人想换行最后发现数据库已经撑不住频繁读写索引更新失败这才催生了解绑升级的念头让数据库归数据库让 Qlik 归 Qlik。1.2 什么时候你需要做升级和拆库通常出现以下几类信号你就该认真考虑这个操作了第一类是数据库版本太老。Qlik Sense 内置的 PostgreSQL 版本随发行版锁定并不会像独立数据库那样及时获得迭代。老版本除了功能缺失外也存在安全风险不少企业的安全审计会明确要求数据库版本进入维护期后必须升级。此时如果不把数据库解绑出来单纯在 Qlik 安装目录里动数据库文件风险极高官方也不推荐。第二类是并发压力上来了。默认内置 PostgreSQL 在测试环境或小规模生产环境里扛得住但当同时在线用户超过一定规模、调度任务频繁再加上 Dashboard 访问量飙升内置实例往往因为内存、CPU 限额或磁盘 IO 配置不合理而成为瓶颈。独立部署之后你可以按照服务器的实际硬件规格单独调参数把 shared_buffers、work_mem、checkpoint 间隔都配置到合适的值性能潜力完全不一样。第三类是数据库运维职责要外包或独立。很多企业希望把 BI 应用的运维和应用数据库运维分开由专职 DBA 团队管理 Qlik Sense 元数据库。这种情况下数据库必须脱离 Qlik 安装目录独立在专门的数据库服务器上按企业标准进行备份、监控和切换。也只有这样DBA 才能用他们熟悉的工具链操作而不是每次都要进入 Qlik 安装目录用特殊脚本启动服务。1.3 Qlik PostgreSQL Installer 解决了什么问题Qlik 官方提供了一个名为 Qlik PostgreSQL Installer 的工具本质上是封装了 PostgreSQL 安装流程的一组程序能够识别 Qlik Sense 使用的标准角色、库名和权限结构。如果你手动装一个原版 PostgreSQL 然后自己建库建用户也并非不可以但很容易漏掉一些 Qlik 服务运行所需的扩展和系统配置例如qlikservice登录权限、repository_admin与repository_user账号关系以及数据库初始化时需要的qlik插件扩展。用官方这把“钥匙”去开锁至少能保证初始化的库、角色、权限和 Qlik Sense 预期的完全一致。我见过不少人手动建库后Repository Service 启动时报permission denied for database qliksense_repository而用安装器初始化出来的实例默认就已经把该配的都配好了。这个工具就是专门为 Qlik 场景定制的 Postgres 分发版本你把它当成一个 Qlik 专属的 PostgreSQL 套件即可。从这个角度讲upgrading 和 unbundling 实际上是同一套动作的两个维度用 Qlik PostgreSQL Installer 装新版独立实例把旧 Repository 数据整体搬过去再让 Qlik 服务改连新库。数据库从“内嵌模块”变成了“外部服务”版本也顺势完成升级。2. 动手前的准备版本、备份、环境检查2.1 版本匹配Qlik Sense 与 PostgreSQL 的生命线在真正执行升级前你首先要明确现有 Qlik Sense 版本支持哪个 PostgreSQL 版本。Qlik 对每个 Qlik Sense 发行版都会在文档中列出对应的 PostgreSQL 版本比如较老的 Qlik Sense 发布于 PostgreSQL 9.6 时代新版本则跟随 12、13 或更高版本。你从官网下载到的 Qlik PostgreSQL Installer 也往往与 Qlik Sense 版本对应如果用新版安装器去装数据库再让一个老版本的 Qlik Sense 服务去连可能出现驱动或协议兼容性问题。我个人的做法是先确认三件事当前 Qlik Sense 的版本号、该版本官方支持的 PostgreSQL 版本范围以及未来升级 Qlik Sense 的计划。如果你短期内有升级 Qlik Sense 的计划那这一次解绑升级就要先对准未来的目标版本宁可一次做到位也不要半年后再重复迁移一次。毕竟每次迁移都存在窗口期风险不是零。2.2 完整备份没有一次万无一失的回滚就不要开始任何上门老师傅都会劝你先备份再折腾。Repository Database 不像业务库那样每天有大量事务更新但它的数据结构和权限关系非常复杂一旦丢失重建站点配置的成本远远高于你想象的。官方建议使用 PostgreSQL 原生的 pg_dump 或 Qlik 控制台里的备份功能但我更推荐两者双轨并行。首先是启用 Qlik Sense Repository Service 的数据库级备份如果你使用的是集中式部署可以按官方最佳实践在 Qlik Management Console 里配置存储备份路径。但数据库完整备份建议用 pg_dump。你需要找到内置 PostgreSQL 的数据目录通常位于 Qlik 安装目录的pgsql\data下然后找到pgsql\bin\pg_dump.exe。备份命令可以参考下面这种形式pg_dump.exe --hostlocalhost --port5432 --usernamepostgres --formatcustom --fileqlik_repo_2024.dump qliksense_repository注意这里有一个关键的隐蔽细节默认端口 5432 可能是内置实例使用的当新实例安装后端口必然冲突。所以在备份阶段就要记录旧实例的端口、数据目录路径、安装版本号以及最核心的“数据库超级用户密码”。如果这个密码丢失后续想改配置会比较麻烦最好提前通过内置的授权机制维护好。2.3 环境检查清单我在执行正式迁移前通常会把如下项目逐项核对每条都要打钩当前 Qlik Sense 服务列表完整且 Repository Service 状态正常。磁盘空间新的 PostgreSQL 数据目录所在盘要有足够空间能容纳至少两倍于当前 Repository 库文件的大小。因为迁移期间可能同时存在导出的 dump 文件和新实例的数据文件。端口规划新实例必须使用尚未被占用的端口常用做法是把新库放到其他机器上用 5432或者在本机错开到 5433。Windows 服务账号新 PostgreSQL 服务默认需要NT AUTHORITY\NetworkService或自定义的服务账号。这个账号还需要对数据目录有完全控制权否则初始化后启动必失败。防火墙规则如果独立数据库在另一台服务器还要确保 Qlik Sense 所在机器到数据库服务器的 TCP 端口通畅并且 PostgreSQL 的pg_hba.conf里允许 Qlik 服务所在 IP 使用密码认证。有一次我就是因为忽略最后一条迁移完数据库后 Repository Service 怎么改连接都连不上抓包才发现流量被防火墙挡了。这类看似低级的问题在迁移演练前很难暴露。3. 使用 Qlik PostgreSQL Installer 安装独立 PostgreSQL 实例3.1 安装流程的完整拆解Qlik PostgreSQL Installer 其实是一个可执行安装程序但它在安装过程不是简单解压文件而是会执行一系列数据库初始化任务。在你启动安装程序后首先要选择安装功能组件。这里要特别注意即使你只是在同一台机器上做“解绑”也不能让安装程序覆盖现有 Qlik Sense 的内置 PostgreSQL 实例。常见的做法是选择安装一个新的 PostgreSQL 实例并且安装时把端口指定为一个独立端口比如 5433数据目录指向新的磁盘位置。过程中会让你指定 Repository 数据库名、Repository 管理员账号、Repository 用户账号和对应密码。这里我建议直接参考旧库的信息保持命名一致避免后续连接配置出现混淆。例如数据库名统一用默认的qliksense_repository管理员账号repository_admin普通用户账号repository_user。密码尽量复杂但必须记录下来因为后面配置 Repository Service 连接时还要用到。安装完成后你会看到一个验证脚本通常它会列出本次安装的实例信息、端口、服务名。此时先不要急着把旧库停掉让新旧实例并存一段时间方便你后续做数据恢复。这也再次印证了端口隔离的重要性同一台机器上跑两个 PostgreSQL 实例并不冲突只要服务名、端口、数据目录不相同即可。3.2 实例初始化有哪些关键参数Qlik PostgreSQL Installer 初始化的库在内部配置上会比原版多出一些 Qlik 扩展。例如qlikschema、用于存储 app 元数据和使用分析所依赖的分区表以及 Qlik Sense 服务通信时需要加载的自定义函数。如果你用原生 PostgreSQL 手动初始化这些扩展和表结构都必须自己从头建出错率很高。所以我在这里也建议读者哪怕你觉得自己的 PostgreSQL 管理能力很强也不要绕过 Qlik PostgreSQL Installer 去手工搭 Repository Database它的价值就是在初始化阶段就把 Qlik 特有的对象结构全部准备好。初始化过程中安装器还会创建两个 PostgreSQL 角色一个是 Repository 服务进程连接数据库时使用的普通角色另一个是具备管理权限的角色。两者的权限差异体现在日常运维上普通角色不应该拥有 DDL 权限只能执行应用运行所需的数据操作管理员角色才用于备份恢复和变更数据库对象。这个设计初衷是防止 Repository 服务进程因权限过高而意外修改表结构。如果你在后期运维中非得给普通角色加权限操作前最好想清楚后果。3.3 别踩的坑默认端口冲突与 Windows 服务账号这一节我要多啰嗦几句因为这两点是我见过翻车概率最高的地方。先讲端口冲突。Qlik Sense 内置 PostgreSQL 默认占用 5432 端口新装的独立实例如果也选了 5432那么安装程序要么报错要么直接覆盖旧实例的配置。你想象一下本来想新老并存结果安装完发现旧库服务起不来了那下一步迁移就变成救火。所以我强烈建议执行安装前先用netstat -ano | findstr :5432确认端口占用情况如果旧库在用新实例一律改成 5433、5434 或其他空闲端口。再讲 Windows 服务账号。很多初次上手的人会直接沿用安装程序默认的服务账号但遇到企业域环境时默认的NT AUTHORITY\NetworkService可能无法访问你指定的独立数据目录尤其是数据目录位于网络存储路径时。要给服务账号配置目录安全权限进入数据目录的“属性 - 安全”里手动加好完全控制权限。这一步如果漏掉PostgreSQL 服务即使能启动也会在初始化时频繁报could not open directory pg_wal之类的权限错误。另外一个隐藏问题与系统区域设置有关。安装器在初始化数据库字符集时会根据操作系统区域设置选择 locale如果你在中文 Windows 上安装可能得到Chinese (Simplified)_China.936这类 locale后续备份还原到新的英文实例时字符集或排序规则不一致会影响某些表格的比较操作。我建议在安装时尽量将实例的 locale 固定为C或en_US.UTF-8确保跨实例一致性。这个参数在初始化过程中虽然不起眼但在数据迁移阶段能省掉大量兼容性麻烦。4. 数据迁移与 Repository 连接切换4.1 数据导出旧库的 dump 怎么做你要做的第一件事不是去新实例上恢复 dump而是先从旧库导出一份“干净”的 dump。这里说的干净指的是导出前先检查有没有长时间运行的事务、锁等待和未完成的清理任务。Repository 库在 Qlik Sense 正常运行期间Repository Service 会持续写入日志表和任务状态表如果在导出过程中库里有比较重的大事务生成的 dump 文件可能不一致。所以我的操作顺序一般是这样在 Qlik Management Console 里暂时禁用所有周期性重载任务或者干脆停止 Repository Service 之后再做 dump。停止服务的方式可以保证数据库不被写入但会导致管理控制台不可用。如果站点是生产环境你需要和业务方协调维护窗口。如果没办法暂停业务至少要在导出后对 dump 文件的完整性做验证比如用pg_restore -l列出 dump 中的对象清单确认表格数量与源库一致。导出时使用--no-owner参数这样权限信息不会被原样写入 dump避免导入到新库时因为用户名不匹配导致权限错乱。Qlik 的 Repository 库用户在新实例上会由 Qlik PostgreSQL Installer 按标准角色创建所以权限只需在导入后重新校准即可。最后把命令写成下面这样pg_dump.exe -h localhost -p 5432 -U postgres --no-owner --formatcustom --filerepo_backup.dump qliksense_repository4.2 数据恢复与新实例调优新实例装好后恢复 dump 之前我建议先做一次“冒烟检查”用安装器创建时的管理员账号尝试连接新库运行SELECT version();确认实例资源正常。此时可以顺便调整 PostgreSQL 的关键参数。Qlik Repository Database 与其说是业务数据库更像一个频繁写入的系统库日志表、审计表都增长得很快。独立实例配置上尤其要侧重这几个方面shared_buffers设置为机器物理内存的 1/4 左右在数据库服务器上不要贪多留出操作系统缓存空间。work_mem不需要调太高因为 Qlik 应用的元数据查询基本是点查和短事务太高反而容易引发内存溢出。checkpoint_completion_target适当拉长 checkpoint 周期减少对磁盘 IO 的突发压力。这些参数可以直接写入新实例的postgresql.conf修改后重启服务生效。不过我更建议你等数据恢复完成后再调整因为调参后新实例会启动得更慢对大 dump 恢复没有额外帮助反而可能因为检查点过于频繁影响恢复速度。恢复 dump 使用pg_restore命令示例pg_restore -h localhost -p 5433 -U repository_admin -d qliksense_repository --no-owner --verbose repo_backup.dump注意新库的原生表已经初始化直接用--clean或者--if-exists时一定要谨慎。因为 pg_restore 会把整个数据文件里的对象重建而新库初始化时已经存在同名的表结构不加--clean会因对象重复报错。推荐在第一次恢复前先连到其他库比如postgres数据库执行验证性恢复把对象结构预览一遍确认 dump 没有异常再往目标库正式恢复。4.3 修改 Repository 服务连接配置数据库数据恢复只是“搬家”完成了一半接下来关键的一步是让 Qlik Sense 的 Repository Service 指向新数据库。Qlik Sense 的连接信息集中存放在一个配置文件中通常位于C:\ProgramData\Qlik\Sense\Repository\PostgreSQLSettings.ini或者通过 Windows 服务面板中的“Repository Database Configuration”图形工具修改。不同版本路径略有差异但基本都是同一类配置。这里你必须修改的内容包括数据库服务器主机名、端口、数据库名、Repository 连接使用的用户名和密码。要注意即使新库和旧库在同一台机器上主机名建议也写实际主机名或固定 IP不要写localhost因为 Repository Service 运行在 Windows 服务背景下localhost解析在某些网络策略下会被 IPv6 优先从而误连到错误实例。这我在一次部署中吃过亏服务日志一直报连接拒绝后来把主机名从localhost改成具体的 IP 就好了。修改完配置后先不要急着重启所有服务。如果 Qlik Sense 站点里有多个节点或者包含调度服务等其他服务它们也会依赖 Repository Service 的连接所以建议按顺序操作先重启 Repository Service等日志显示连接已建立再依次启动其他服务。如果一次把全部服务重启日志信息会非常混乱根本分不清故障点。4.4 服务启动与首次验证启动 Repository Service 后不要只看服务状态变成“正在运行”就宣布成功。真正的验证要打开 Qlik Management Console 看看站点是否正常加载应用列表、数据连接配置、调度任务是否完整可见。我总结了一个简单有效的验证清单查看C:\ProgramData\Qlik\Sense\Log\Repository\Trace\Repository.log确认其中包含类似Successfully connected to database的日志行。打开 Qlik Management Console能正常登录并显示所有站点资源。触发一个测试任务确认调度程序可以把任务状态写回新 Repository 数据库。用数据库查询工具查看新库中的public.qsl_audit或类似审计表确认新的审计记录正在生成。这几项都通过了才可以说数据库连接切换成功。如果其中任何一项失败不要贪快立即回滚到旧配置排查原因后重新切换。注意切换过程不要反复来回每次切换都会造成数据库连接缓存和锁的扰动尽量一次成功。5. 常见问题速查与排障记录5.1 认证失败pg_hba.conf 与密码加密问题在解绑升级过程中最常见的报错就是password authentication failed for user repository_admin。排查这个问题的思路和常规 PostgreSQL 一模一样的先确认密码是否正确、再确认pg_hba.conf中的认证方式是否允许密码登录。新版 PostgreSQL 对密码加密方式有默认要求通常是scram-sha-256而老版本可能使用md5。如果你在 dump 时没有包含当前用户的密码或者新实例创建时用户名冲突就会导致认证失败。我最想强调的是Qlik PostgreSQL Installer 初始化的账号密码可能会存档在安装日志里但那个密码只在初始化时生效。如果你在安装过程中没有记录下来后面基本只能重新创建角色或者修改密码而不是去日志里猜。修改密码的方法是在新库上运行ALTER USER repository_admin WITH PASSWORD YouStrongPass;但别忘记修改完密码后QLik Repository Service 的连接配置也要同步更新。5.2 服务起不来日志看得透很多朋友见服务启动失败第一反应去 Windows 事件查看器翻一遍信息不够又去看 Qlik 的 log最后发现真正的错误在 PostgreSQL 的数据目录里log文件夹下。那里面记录了数据库实例本身的错误例如数据目录权限不足、磁盘空间满、postmaster.pid残留等。如果 PostgreSQL 服务就是起不来请依次检查以下三个位置数据目录postmaster.pid文件是否存在但 PID 已失效这会导致服务以为实例已在运行需要删掉该文件后重试。数据目录下的log目录找当前日期的.log文件查看最后几行。Windows 服务管理器中 PostgreSQL 服务所使用的可执行文件路径是否指向正确的pg_ctl.exe。有一次迁移后新实例无法启动最后发现是 Qlik PostgreSQL Installer 在初始化时将数据目录指向了一个不存在的路径服务注册的却是旧路径。这种环境下直接“修复安装”是最快的方案但修复不会覆盖你现有的数据目录可以放心重跑安装器只要保证路径正确。5.3 数据不一致迁移后的对账技巧迁移完成后你不仅要用 QMC 页面验证还应该做一次数据层的“对账”。怎么对账用新库查询旧库当初的总行数。最实用的做法是迁移前先对若干核心表的行数做一个快照迁移后逐一核对。常见需要核对的核心表包括应用元数据表通常以qrs_开头任务状态表用户信息表与安全规则表如果发现某个表行数对不上优先检查是不是 dump 恢复时遗漏了索引、触发器或外键约束。PostgreSQL 的pg_restore默认会按依赖顺序恢复对象但如果你使用了--data-only那结构对象会缺失如果使用了--schema-only则没有数据。我建议完整恢复时不要加这些分片参数。还有恢复过程中出现ERROR: relation does not exist且后续操作继续执行的错误一定不要忽略通常意味着对象依赖断裂最终状态不可信。5.4 总结一个实用的回滚流程再稳的操作也要留后手。我的习惯是开始迁移前把旧库整个数据目录复制一份到安全位置同时保留旧服务配置文件的备份。如果切换后新库出现短期内无法修复的问题执行回滚流程停止所有 Qlik Sense 服务。把 Repository 配置文件恢复为旧连接。确保旧 PostgreSQL 实例还能正常启动。如果旧实例还保留着原始数据目录端口也是原来的那这一步通常不难。启动 Repository Service确认连接旧库成功。登录 QMC 做最终验证。不要把回滚想成多么复杂的工程它的前提条件就是你准备工作做得足版本信息、备份文件、配置内容和端口资源都可视化记录在案。否则现场找配置比迁移本身还耗时间。从实操经验来看用 Qlik PostgreSQL Installer 做 Repository Database 的升级和解绑最花时间的环节反而不是执行而是前期的环境评估和备份。只要你把新库的初始化标准化了数据迁移只是pg_dump和pg_restore之间的一次搬运真正的风险在于服务切换那一刻的漏配。我个人在操作时还有一个习惯所有命令和密码都保留在一个本地加密的笔记文件中同时把每一步的执行窗口时间、日志路径记录清楚。这样即便中途被临时打断回来也能迅速衔接上下文。最后再分享一个额外的方向如果你们团队已经决定把 Repository Database 独立出来下一步不妨把数据库备份策略也纳入现有备份体系比如通过 PG 的物理备份工具做连续归档而不只是依赖 Qlik 内置的备份机制。数据库级别的高可用做起来之后Qlik Sense 这个“总账本”就会比以往任何时候都稳之后的季度升级也就没有再需要担惊受怕的环节了。