企业官网建设流程全解析

升级 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 --host=localhost --port=5432 --username=postgres --format=custom --file=qlik_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 文件可能不一致。

所以我的操作顺序一般是这样：

1. 在 Qlik Management Console 里暂时禁用所有周期性重载任务，或者干脆停止 Repository Service 之后再做 dump。停止服务的方式可以保证数据库不被写入，但会导致管理控制台不可用。如果站点是生产环境，你需要和业务方协调维护窗口。
2. 如果没办法暂停业务，至少要在导出后对 dump 文件的完整性做验证，比如用pg_restore -l列出 dump 中的对象清单，确认表格数量与源库一致。
3. 导出时使用--no-owner参数，这样权限信息不会被原样写入 dump，避免导入到新库时因为用户名不匹配导致权限错乱。Qlik 的 Repository 库用户在新实例上会由 Qlik PostgreSQL Installer 按标准角色创建，所以权限只需在导入后重新校准即可。

最后把命令写成下面这样：

pg_dump.exe -h localhost -p 5432 -U postgres --no-owner --format=custom --file=repo_backup.dump qliksense_repository

4.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 总结一个实用的回滚流程

再稳的操作也要留后手。我的习惯是开始迁移前把旧库整个数据目录复制一份到安全位置，同时保留旧服务配置文件的备份。如果切换后新库出现短期内无法修复的问题，执行回滚流程：

1. 停止所有 Qlik Sense 服务。
2. 把 Repository 配置文件恢复为旧连接。
3. 确保旧 PostgreSQL 实例还能正常启动。如果旧实例还保留着原始数据目录，端口也是原来的，那这一步通常不难。
4. 启动 Repository Service，确认连接旧库成功。
5. 登录 QMC 做最终验证。

不要把回滚想成多么复杂的工程，它的前提条件就是你准备工作做得足：版本信息、备份文件、配置内容和端口资源都可视化记录在案。否则现场找配置比迁移本身还耗时间。

从实操经验来看，用 Qlik PostgreSQL Installer 做 Repository Database 的升级和解绑，最花时间的环节反而不是执行，而是前期的环境评估和备份。只要你把新库的初始化标准化了，数据迁移只是pg_dump和pg_restore之间的一次搬运，真正的风险在于服务切换那一刻的漏配。我个人在操作时还有一个习惯：所有命令和密码都保留在一个本地加密的笔记文件中，同时把每一步的执行窗口时间、日志路径记录清楚。这样即便中途被临时打断，回来也能迅速衔接上下文。

最后再分享一个额外的方向：如果你们团队已经决定把 Repository Database 独立出来，下一步不妨把数据库备份策略也纳入现有备份体系，比如通过 PG 的物理备份工具做连续归档，而不只是依赖 Qlik 内置的备份机制。数据库级别的高可用做起来之后，Qlik Sense 这个“总账本”就会比以往任何时候都稳，之后的季度升级也就没有再需要担惊受怕的环节了。