PostgreSQL 18 aktiviert standardmäßig Daten-Checksummen

Warum Checksummen wichtig sind

Änderungen in PostgreSQL 18

• Cluster-Upgrades müssen mit den Checksummen-Einstellungen übereinstimmen (explizit in den PostgreSQL 18-Versionshinweisen erwähnt). Beim Upgrade über pg_upgrade müssen sowohl der Quell- als auch der Zielcluster Checksummen aktiviert oder deaktiviert haben. Wenn Sie von einem älteren Cluster ohne Checksummen aktualisieren müssen, initialisieren Sie den neuen Cluster mit –no-data-checksums oder aktivieren Sie zuerst Checksummen auf dem alten Cluster.
• Statistiken zur Überwachung von Fehlern – PostgreSQL verfügt bereits über zwei Spalten in pg_stat_database: checksum_failures, die die Anzahl der Seiten zählen, deren Checksummen fehlgeschlagen sind, und checksum_last_failure, den Zeitstempel des letzten Fehlers. Diese Metriken ermöglichen es Ihnen, bei Korruptionsereignissen über alle Datenbanken im Cluster hinweg zu warnen.

Aktivieren und Deaktivieren von Checksummen mit pg_checksums

• Der Cluster muss sauber heruntergefahren werden, bevor pg_checksums ausgeführt wird.
• Das Überprüfen von Checksummen (–check) scannt jede Datei in PGDATA und gibt einen Exit-Code ungleich Null zurück, wenn eine Nichtübereinstimmung gefunden wird.
• Das Aktivieren von Checksummen (–enable) schreibt jeden Beziehungsblock neu und aktualisiert das Checksummenfeld auf der Festplatte. Das Deaktivieren von Checksummen (–disable) aktualisiert nur die Steuerdatei – es schreibt keine Seiten neu.
• Optionen wie –progress zeigen den Fortschritt an, –no-sync überspringt fsync nach Änderungen und –filenode beschränkt die Überprüfung auf eine bestimmte Beziehung.
• Auf großen oder replizierten Clustern kann das Aktivieren von Checksummen lange dauern; alle Standby-Server müssen gestoppt oder neu erstellt werden, damit alle Knoten denselben Checksummenstatus beibehalten (explizit in der Dokumentation erwähnt).

Upgrade-Strategie

• Deaktivieren Sie Checksummen auf dem neuen Cluster: Führen Sie initdb mit –no-data-checksums aus, damit pg_upgrade die Migration zulässt. Nach dem Upgrade können Sie Checksummen offline mit pg_checksums –enable aktivieren.
• Aktivieren Sie zuerst Checksummen auf dem alten Cluster: Fahren Sie den alten Server herunter, führen Sie pg_checksums –enable -D $PGDATA aus (auf jedem Knoten, wenn Sie Streaming-Replikation verwenden), starten Sie dann den Server und überprüfen Sie den neuen SHOW data_checksums-Wert. Wenn Sie PostgreSQL 18 initialisieren, erbt es den aktivierten Zustand.

Behandlung von Checksummenfehlern

• ignore_checksum_failure – Wenn deaktiviert (Standard), bricht der Server die aktuelle Transaktion beim ersten Checksummenfehler ab. Wenn es auf on gesetzt ist, protokolliert es eine Warnung und setzt die Verarbeitung fort, sodass Abfragen beschädigte Blöcke überspringen können. Diese Option kann Beschädigungen verbergen, Abstürze verursachen oder falsche Daten zurückgeben; nur Superuser können es ändern.
• zero_damaged_pages – Wenn ein beschädigter Seitenheader oder eine Checksumme erkannt wird, bewirkt das Setzen dieses Parameters auf on, dass PostgreSQL die gesamte 8-KB-Seite im Speicher durch Nullen ersetzt und dann die Verarbeitung fortsetzt. Die genullte Seite wird später auf die Festplatte geschrieben, wodurch alle Tupel auf dieser Seite zerstört werden. Verwenden Sie dies nur, wenn Sie Backup- oder Standby-Optionen ausgeschöpft haben. Das Deaktivieren von zero_damaged_pages stellt keine Daten wieder her und wirkt sich nur darauf aus, wie zukünftige beschädigte Seiten behandelt werden.

-- Mit ignore_checksum_failure=off stoppt die Abfrage beim ersten Fehler:
test=# SELECT * FROM pg_toast.pg_toast_17453;
WARNING: page verification failed, calculated checksum 19601 but expected 152
ERROR: invalid page in block 0 of relation base/16384/16402

-- Mit ignore_checksum_failure=on protokolliert der Server Warnungen und scannt weiter, bis er gute Daten findet:
test=# SET ignore_checksum_failure = ON;
test=# SELECT * FROM pg_toast.pg_toast_17453;
WARNING: page verification failed, calculated checksum 29668 but expected 57724
WARNING: page verification failed, calculated checksum 63113 but expected 3172
WARNING: page verification failed, calculated checksum 59128 but expected 3155

test=# SET zero_damaged_pages = ON;
test=# SELECT * FROM pg_toast.pg_toast_17453;
WARNING: page verification failed, calculated checksum 29668 but expected 57724
WARNING: invalid page in block 204 of relation base/16384/17464; zeroing out page
WARNING: page verification failed, calculated checksum 63113 but expected 3172
WARNING: invalid page in block 222 of relation base/16384/17464; zeroing out page

Autovacuum-Interaktion

Warum wir Checksummen begrüßen sollten

/*
* Die folgenden Überprüfungen beweisen nicht, dass der Header korrekt ist, sondern nur, dass
* es vernünftig genug aussieht, um in den Pufferpool aufgenommen zu werden. Spätere Verwendung von 
* der Block kann immer noch Probleme aufdecken, weshalb wir die
* Checksummenoption anbieten.
*/
if ((p->pd_flags & ~PD_VALID_FLAG_BITS) == 0 &&
p->pd_lower <= p->pd_upper &&
p->pd_upper <= p->pd_special &&
p->pd_special <= BLCKSZ &&
p->pd_special == MAXALIGN(p->pd_special))
header_sane = true;

if (header_sane && !checksum_failure)
return true;

SELECT * FROM page_header(get_raw_page('pg_toast.pg_toast_32840', 100));
 lsn | checksum | flags | lower | upper | special | pagesize | version | prune_xid
------------+----------+-------+-------+-------+---------+----------+---------+-----------
 0/2B2FCD68 | 0 | 4 | 40 | 64 | 8192 | 8192 | 4 | 0
(1 row)

ERROR: XX001-invalid page in block 578 of relation base/16384/28751

ERROR: invalid memory alloc request size 18446744073709551594
DEBUG: server process (PID 76) was terminated by signal 11: Segmentation fault

58P01 - could not access status of transaction 3047172894
XX000 - MultiXactId 1074710815 has not been created yet -- apparent wraparound
WARNING: Concurrent insert in progress within table "test_table_bytea"

Fazit

• PostgreSQL-Checksummen & Base-Backup