postgresql - 在非常大的表上运行 AUTO_VACUUM（以防止回绕）的问题

Question

我遇到了问题，需要一些建议。我通常是一名开发人员，但是由于最近我公司的人员变动，我现在是唯一的 IT 人员，所以我不得不涉足许多未知领域并且确实需要一些帮助。

我们正在运行 postgres 8.3。数据库正在尝试在大型对象表 (pg_catalog.pg_large_object) 上运行 AUTO_VACUUM 以防止事务 ID 回绕。我想我理解这意味着什么的基础知识。问题是，这张表是 750G，有 4.52 亿行。AUTO_VACUUM 大量写入磁盘，占用了磁盘空间（昨天它消耗了我们最后 250GB 的 1TB）。紧急中断后，我们以 1100GB 的空间和 100GB 的可用空间恢复运行。然而，一旦 postgres 重新启动并运行，它就会再次启动 AUTO_VACUUM 进程。如果我终止交易（我确定不推荐这样做），它就会重新启动。

所以这是我的问题：

1) 对于该表，完成 AUTO_VACUUM 进程需要多少空间？我如何确定这一点？

2) 有没有更好的方法来配置服务器来处理这种情况，以便在需要时不需要大量的磁盘空间？

3）如果不是 2，你建议如何解决这个问题？

我不是 DBA，也没有 linux 服务器管理经验，只是一个被要求身兼数职的开发人员。我正试图让 DBA 顾问帮助解决问题，但该公司正在回击。尽管我尽了最大努力，但他们似乎并不了解问题的严重性。

建议？注释？您可以提供的任何建议或指导将不胜感激。如果您需要更多信息，请告诉我。

Answer 1

如果您不尽快解决此问题，您的数据库将进入紧急关闭状态以防止数据损坏并拒绝启​​动备份，直到 txid 环绕 vaccuum 完成。检查日志以查看您离这一点有多近，您将看到如下消息：

WARNING:  database "mydb" must be vacuumed within 177009986 transactions 
HINT:  To avoid a database shutdown, execute a database-wide VACUUM in "mydb". 

不要只是杀死真空并将问题搁置。你真的，真的需要解决这个问题，除非你能承受一些计划外的停机时间。

它消耗大量磁盘空间的原因可能是您使用的旧版本没有自动管理的 freespacemap 设置，并且您可能已经超过max_fsm_pages和/或max_fsm_relations. 检查日志，您可能会看到有关这些的消息。

不幸的是，您不能在事后仅仅提高这些参数。这个旧的 PostgreSQL 安装已经失去了关于表中哪些空间是空闲的知识。正确的清理和恢复将需要一个CLUSTER表，它至少需要与表+索引大小一样多的可用空间，并且需要在运行期间对表进行排他锁。

既然您正在接近强制 txid 环绕预防，那么大多数侵入性较小的缓解选项（例如pg_reorg）不再对您开放。您最好的选择很可能是为 autovacuum 提供完成工作所需的空间 - 或者处理停机时间，CLUSTER然后VACUUM FREEZE处理表格以更快地完成该过程。

一旦你恢复了，我会建议大大增加max_fsm_pages并确保max_fsm_relations足够大。搜索这些旧版本的许多调整建议。

计划升级到 9.2，它会自动管理自由空间地图（就像任何 8.4+ 版本一样）并具有各种 autovac 增强功能，以帮助您首先阻止您进入这些泡菜。

如果这种情况非常危急，请考虑与专业的 PostgreSQL 支持提供商联系。（正确披露：我为 2ndQuadrant 工作，这是列出的提供商之一）。

Answer 2

FreeNode 的#postgresql (IRC) 的实时支持令人惊叹。经常有知识渊博的人醒着，可以谈论 DBA/开发细节。我不能推荐它。