Τι είναι τα WAL στη PostgreSQL και πώς τα ρυθμίζουμε
Πιστοποιήσεις:
- Τι είναι τα WAL στη PostgreSQL και πώς τα ρυθμίζουμε - 6 Αύγουστος 2026
- Τι είναι το MVCC και το Vacuum στη βάση δεδομένων της PostgreSQL και πώς αποφεύγουμε το Bloat - 29 Ιούλιος 2026
- Πώς στέλνουμε email μέσα από Oracle Database όταν αποτύχει ένα RDBMS_SCHEDULER Job - 22 Απρίλιος 2026
Σε αυτό το άρθρο θα δούμε τον μηχανισμό που συνδέει τη μνήμη με τον δίσκο και εξασφαλίζει ότι δεν θα χάσουμε δεδομένα αν πέσει η βάση δεδομένων (π.χ. απο ρεύμα): τα Write-Ahead Logs (WAL) και τα Checkpoints.
Όταν εκτελούμε ένα INSERT, UPDATE ή DELETE, η αλλαγή γίνεται αρχικά στη μνήμη (shared_buffer) και αμέσως μετά καταγράφεται στο WAL file στο δίσκο, ώστε να επιβεβαιωθεί ότι η συναλλαγή ολοκληρώθηκε. Αν ο server κρασάρει, η PostgreSQL στην επανεκκίνηση διαβάζει τα WAL files και ξαναπερνάει όσες αλλαγές δεν είχαν προλάβει να γραφτούν μόνιμα στους πίνακες.
Για όσους προέρχονται από Oracle, τα WAL files είναι το αντίστοιχο των Redo Logs, ενώ στον SQL Server είναι το Transaction Log. Στην PostgreSQL βρισκονται στον φάκελο pg_wal ως αρχεία των 16MB.
Τι είναι το Checkpoint;
Δεν μπορούμε να κρατάμε τις αλλαγές μόνο στη μνήμη, γιατί αν έπεφτε το ρεύμα, η επανεκκίνηση θα έπαιρνε ώρες διαβάζοντας WAL files ημερών. Το Checkpoint είναι η διαδικασία κατά την οποία η PostgreSQL παίρνει όλες τις αλλαγές από τη μνήμη και τις γράφει φυσικά στους πίνακες στο δίσκο. Μόλις τελειώσει, τα παλιά WAL files που δεν χρειάζονται άλλο διαγράφονται.
Αν το checkpoint γράψει πολύ όγκο δεδομένων απότομα, ο δίσκος φτάνει στο 100% και η βάση δεδομένων κολλάει. Γι’ αυτό χρειάζεται σωστό tuning.
Πώς τα ρυθμίζουμε στο service της PostgreSQL
Οι προεπιλεγμένες ρυθμίσεις της PostgreSQL είναι πολύ χαμηλές, σε παραγωγικές βάσεις δεδομένων προσαρμόζουμε τις βασικές παραμέτρους στο postgresql.conf, οι οποίες ειναι δυναμικές δεν χρειάζεται να πέσει το service απλά reload μέσω SQL (SELECT pg_reload_conf();):
max_wal_size
Ορίζει πόσος όγκος WAL επιτρέπεται να μαζευτεί πριν η βάση αναγκαστεί να κάνει Checkpoint. Το 1GB (default) είναι πολύ μικρό και αναγκάζει τη βάση να κάνει συνεχώς checkpoints. Σε παραγωγικά συστήματα το ανεβάζουμε σε 16GB που ειναι το standard, σε πολύ βάσεις με χιλιάδες εγγραφές μπορεί να χρειαστεί να το παμε 32GB ή ακόμα και 64GB.
checkpoint_timeout
Ορίζει τον μέγιστο χρόνο ανάμεσα σε δύο checkpoints. Τα 5 λεπτά (default) είναι πολύ συχνό διάστημα, οπότε το ανεβάζουμε σε 15m για να αραιώσουμε τις εγγραφές στο δίσκο.
checkpoint_completion_target
Ορίζει σε πόσο ποσοστό του χρόνου checkpoint_timeout πρέπει να απλωθεί η εγγραφή των δεδομένων. Με τιμή 0.9 και checkpoint_timeout 15, η PostgreSQL γράφει σταδιακά τα δεδομένα μέσα σε 13.5 λεπτά. Αυτό απλώνει την εγραφή και εξαφανίζει τα κολλήματα. Στις νέες εκδόσεις είναι ήδη 0.9 και το αφήνουμε εκεί.
Παράδειγμα:
vi $PGDATA/postgresql.conf
checkpoint_timeout = 15m
max_wal_size = 16GB
min_wal_size = 2GB
checkpoint_completion_target = 0.9Πώς βλέπουμε αν χρειάζεται tuning
Για να δούμε αν τα checkpoints γίνονται στην ώρα τους ή αν εξαναγκάζονται επειδή γεμίζει το max_wal_size, τρέχουμε το παρακάτω query:
SELECT
checkpoints_timed,
checkpoints_req,
checkpoint_write_time,
checkpoint_sync_time,
ROUND(100.0 * checkpoints_req / NULLIF(checkpoints_timed + checkpoints_req, 0), 2) AS forced_checkpoint_pct
FROM pg_stat_bgwriter;
Στα αποτελέσματα, το checkpoints_timed δείχνει τα checkpoints που έγιναν κανονικά βάσει χρόνου, ενώ το checkpoints_req δείχνει τα αναγκαστικά επειδή γεμίσαμε το max_wal_size.
Στόχος μας είναι το ποσοστό forced_checkpoint_pct να είναι κάτω από 10%. Αν βλέπετε μεγαλύτερο ποσοστό, σημαίνει ότι η βάση δεδομένων παράγει WAL πολύ γρήγορα και πρέπει να αυξήσετε το max_wal_size.
Πηγές:
