我正在努力解决Postgres的民间记忆问题。
听说很久以前在一个遥远的星系(Ubuntu 12.04下的PostgreSQL 8.4),PostgreSQL经常遇到一个问题,如果承载服务器的机器出现故障(例如内核崩溃),当机器重新启动时,Postgres将启动,但数据库上的索引可能已损坏。例如
SELECT foo FROM bar WHERE baz = 123
Run Code Online (Sandbox Code Playgroud)
会失败,因为上的索引bar.baz
会损坏。重新索引表修复了问题,但由于无法检测到此问题,而且这是在设备环境中(手头没有 DBA),本质上为了防止这种情况,有必要在重新启动时重新索引所有表,这会非常昂贵。因此(推理是这样的)如果手头没有 DBA,使用 Postgres 是不明智的,特别是在表很大且计算索引昂贵的环境中。
由于这种民间传说,在这种情况下首选 MySQL。
我依稀记得在 8.4 下看到过这个问题,所以我认为其中有一些道理。
我确信这也发生在 Ubuntu 14.0.4 下的 Postgres 9.3 上。我不知道它是否“经常”发生。它发生的系统正在运行(公认的旧)企业级 SAS 驱动器,该驱动器声称写入缓存已关闭,因此我认为这不是写入缓存问题。
如果情况仍然如此,我想我可以在网上找到比我能找到的更多的证据。
因此,我怀疑它可能已修复,或者可能是由于某些问题造成的postgresql.conf
(尽管检查表明只有 autovacuum 设置从默认值更改)。
在我最近知道的系统中(使用 9.3)没有使用 LVM。存储系统是 ext4,安装在具有默认属性的物理驱动器上。这个驱动器是一个(公认的老)企业 SAS 驱动器加上 SAS1068 PCI-X Fusion-MPT SAS 控制器,它sdparm
声称它没有打开写缓存,但这已经(据称)在不同供应商的多个驱动器上看到过等等。 ,虽然总是在 Ubuntu 上的 ext4 上。
fsync
处于默认状态(on
我相信)。
没有主/从配置——只有一个主——(所以这不是multixact
错误)。
表是使用默认索引创建的(没有花哨的哈希索引)。
Postgres 会定期更新到任何相关的 Ubuntu LTS 版本。最新的问题是在 14.04。
系统崩溃后手动重建索引是一项预期任务吗?
如果没有,是否曾经有过,什么时候改变过?
是否可以避免手动重新索引的需要?