0

我使用 pg_upgrade--link选项从 Postgres 10 升级到 Postgres 14。数据库总大小约为 10TB。pg_upgrade 成功且快速，就像建议的工具一样 -

Optimizer statistics are not transferred by pg_upgrade. Once you start the new server, consider running: /usr/pgsql-14/bin/vacuumdb --all --analyze-in-stages

我运行了上述命令，但进程卡住了。作为这种（或不确定，不确定）的副作用，当我创建出版物时，提示永远不会回来，并且即使经过数小时也不会创建出版物。

postgres=# select * from pg_stat_progress_vacuum;

c1 c2
PID 9520
数据 16402
数据名 xyz
重 22423
阶段 吸尘指数
heap_blks_total 232816470
heap_blks_scanned 36766348
heap_blks_vacuumed 0
index_vacuum_count 0
max_dead_tuples 11184809
num_dead_tuples 11184521

这与昨天的输出相同。我能做些什么来加快这个和“创建出版物”命令？附带说明：运行 Postgres 的 VM 非常强大（64GB RAM，16 核）。谢谢！

编辑 1：相同 pid 的 pg_stat_activity 的输出，

c1 c2
PID 9520
backend_start 2021-12-06 15:13:23.479071-08
xact_start 2021-12-06 15:13:23.512581-08
查询开始 2021-12-06 15:13:23.512581-08
state_change 2021-12-06 15:13:23.512581-08
等待事件类型 超时
等待事件 真空延迟
状态 积极的
backend_xmin 3140627534
询问 autovacuum: VACUUM xyz (防止环绕)
后端类型 自动吸尘器
4

2 回答 2

1

vacuumdb --all --analyze-in-stages不会运行VACUUM，但是ANALYZE，所以你必须看看pg_stat_progress_analyze它是怎么做的。

您看到的VACUUM运行过程与此无关。这是一个反环绕式真空吸尘器，目前正在休眠，但正在处理中。让它结束；此过程对于数据库的健康很重要。如果您希望在该表上进一步运行 autovacuum 以更快地完成，请减少autovacuum_vacuum_cost_delay该表。

于 2021-12-07T17:40:57.187 回答
1

简单地进行升级不应该导致反环绕真空运行，因此它决定在升级后立即运行可能是时间巧合。另一方面，也许你的新数据库版本有不同的配置设置，例如较低的值autovacuum_freeze_max_age，使用这个新设置运行是触发它现在启动的原因。您是否将所有非默认配置设置从 v10 转移到 v14？

我同意 Laurenz 的观点，确实需要让它完成，但这并不意味着你需要让它立即完成。您可以终止清理后端，以便您的 CREATE PUBLICATION 有机会运行。autovac 可能会立即重新启动，因此当您取消清理时，您应该已经尝试运行 CREATE PUBLICATION。这样，它就能够在真空再次启动并再次获取锁之前获取锁。但是请确保您不会养成每次给您带来不便时取消真空吸尘器的习惯。

此外，您应该将maintenance_work_mem 增加很多。看起来它当前设置为 64MB，这对于您描述的服务器来说是相当低的。如果您将其设置为 1GB，那么它应该能够只通过索引一次而不是您目前正在使用的七次来清理整个表。在取消真空之前，我会在 conf 文件中更改此设置并 SIGHUP 服务器，这样启动的新真空应该具有新设置。

最后，我不知道为什么这会清除索引。我认为 v14 对其进行了更改，因此紧急清理程序不会费心去做，而是冻结堆中的元组并将索引留给以后使用。我想我需要更多地研究 v14 来弄清楚它在这里的真正作用。

于 2021-12-08T04:11:04.213 回答