我们的应用程序在Postgres 7.4.X上运行。我同意这是Postgres的一个非常古老的版本，我们应该升级。我们面临的问题是
1。由于硬件故障导致系统崩溃。
2。当系统出现时，我们尝试在数据库中插入一些记录。但是在这个时候我们看到Postgres占用了大量的CPU和CPU。记忆。
大约42％的CPU消耗。这引起了人们的关注。
3。我们重新编制了数据库的索引，这有助于减少cpu和amp;记忆消耗。
我的问题是
A）Postgres数据库的弹性是否足以处理硬件系统故障？或者它有时会导致其表的损坏索引？我在Postgres网站上看到硬件故障可能导致损坏的索引。除此之外，还有其他可能导致此类腐败的情况。
B）如果Postgres已经对其处理损坏索引的方式进行了改进/增强，请您告诉我有关错误ID或其中一些文档的更多信息吗？我们的申请不做任何REINDEXING。如果我们应该认真地将它纳入我们的应用程序中，那么我处于两难境地。
答案 0 :(得分：1)
Postgres数据库的弹性不足以处理硬件系统 失败？或者它有时会导致其表的损坏索引？一世 在Postgres网站上阅读硬件故障可能导致损坏 索引。
“硬件故障导致损坏的索引”的哪个部分你不明白？ （笑）我想维护PostgreSQL网站的人大致知道他们在说什么。
硬件故障 - 尤其是磁盘子系统中的故障 - 可能会将垃圾写入磁盘。严重故障会对磁盘表面造成物理损坏。特别引人注目的硬件故障可以将磁盘的各个部分重新分配到多个城市街区。 （在客户现场爆炸;他们说有些碎片落在20英里外。我已经学会了在这种情况下不要太依赖dbms弹性。）
有很多方法可以降低硬件故障的风险。但是，他们中的大多数与PostgreSQL没有任何关系。冗余硬件 - 电源，NIC，RAID磁盘系统 - 电池备份缓存（或禁用写缓存），服务器复制，冷和热故障转移。这些都与PostgreSQL自身的弹性无关。
我不知道PostgreSQL在多大程度上诊断了自己索引的状态。如果我以后有时间，我会查看PostgreSQL source code。