Postgresql Index Korruption Ursache - Postgresql Bug oder Hardware-Fehler

Question

Ich habe Postgresql 9.5.2 Produktionsserver, die einige schwerwiegende Probleme mit Indizes hatte. Das stärkste Beweisstück, dass Anspruch unterstützt, ist Inkonsistenz zwischen einigen Abfragen:

select count(*) from x inner join y on x.a = y.a 
select *  from x inner join y on x.a = y.a 

Die COUNT (*) Abfrage einer andere Zahl als die Anzahl der Zeilen, die von der select * Abfrage, die gerade zurückgegebenen Zeilen zurück zurückkehren würde. Das erste, was ich ausprobiert habe, war eine Vakuumanalyse, aber das behebt das Problem nicht. Um schließlich den Server wieder funktionsfähig zu machen, löschte er alle Indizes und baute sie neu auf. An diesem Punkt wurden die Ergebnisse zwischen den Abfragen select * und select count (*) konsistent.

Keine der Tabellen hat Trigger. Tabelle x hat 1,7 Millionen Zeilen und Tabelle y hat 6,9 Millionen Zeilen und 600.000 gelöschte Zeilen, und die Tabellen sind mit einem Fremdschlüsselfeld a verknüpft, das der Primärschlüssel in Tabelle x und einer Nicht-Null-Fremdschlüsseleinschränkung in Tabelle b ist . Der Datenbankserver wird in einer virtuellen Maschine gehostet. Der Server ist der einzige Knoten und es gibt keine Replikation zu anderen Servern. Das System ist nie abgestürzt, und obwohl ich weiß, dass ein Absturz-Server oder Postgres-Dienst Indizes beschädigen kann, habe ich keinen Grund zu glauben, dass einer dieser Fälle passierte, weil a) der Postgres-Dienst nie nicht verfügbar war und b) der Server dies anzeigt war lange Zeit, lange bevor sich dieses Problem manifestierte.

Alle diese Daten deuten darauf hin, dass das Problem war, ein Index funktionierte nicht richtig. Meine Forschung zu beschädigten Indizes weist im Allgemeinen auf zwei Ursachen hin, auf Fehler in PostgreSQL oder auf Hardwarefehler.

Die Lösung für einen Hardwarefehler und einen Fehler in der Datenbank selbst werden mit radikal verschiedenen Techniken gelöst, nämlich mit dem Kauf von Hardware und dem Schreiben von Programmen zur Überprüfung der Integrität der Indizes und gegebenenfalls zur Korrektur die Probleme.

Welche Beweise kann ich für jede Theorie sammeln (Hardware-Fehler vs. Software-Fehler)?

Answer 1

Der beste Schutz gegen Hardwareprobleme besteht darin, Seitenprüfsummen zu aktivieren, indem Sie die --data-checksums Option initdb beim Erstellen des Clusters verwenden.
Aber das wird nicht helfen, frühere Probleme zu untersuchen, und es erfordert einen Dump/Reload des Datenbankclusters.

Wenn Sie physische Backups machen (mit pg_basebackup oder mit pg_start_backup() und pg_stop_backup), wäre es interessant, das letzte Backup zu finden, wo die Dinge noch in Ordnung waren. Das mag mühsam sein, aber es wird das Fenster eingrenzen, wo nach Problemen gesucht wird.

Haben Sie fsync = off oder full_page_writes = off? Oder verwenden Sie unreliable storage? Dann kann Ihre Datenbank durch einen Absturz beschädigt werden, selbst wenn es keinen Bug gibt und die Hardware in Ordnung ist. Überprüfen Sie das Datenbankprotokoll auf Abstürze.

Um herauszufinden, ob Sie unter Hardwareproblemen leiden, sehen Sie sich die Protokolldateien des Betriebssystems an und führen Sie Hardwaretests durch.

Um nach bekannten Softwareproblemen zu suchen, schauen Sie auf release notes. Wenn Sie einen beschädigten Index haben, können Sie den pgsql-hackers mailing list um Hilfe bitten.