begriffs open source - ai-pg/blob - full-docs/html/wal-intro.html

   1 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
   2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>28.3. Write-Ahead Logging (WAL)</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="pgsql-docs@lists.postgresql.org" /><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><link rel="prev" href="checksums.html" title="28.2. Data Checksums" /><link rel="next" href="wal-async-commit.html" title="28.4. Asynchronous Commit" /></head><body id="docContent" class="container-fluid col-10"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">28.3. Write-Ahead Logging (<acronym class="acronym">WAL</acronym>)</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="checksums.html" title="28.2. Data Checksums">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="wal.html" title="Chapter 28. Reliability and the Write-Ahead Log">Up</a></td><th width="60%" align="center">Chapter 28. Reliability and the Write-Ahead Log</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 18.0 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="wal-async-commit.html" title="28.4. Asynchronous Commit">Next</a></td></tr></table><hr /></div><div class="sect1" id="WAL-INTRO"><div class="titlepage"><div><div><h2 class="title" style="clear: both">28.3. Write-Ahead Logging (<acronym class="acronym">WAL</acronym>) <a href="#WAL-INTRO" class="id_link">#</a></h2></div></div></div><a id="id-1.6.15.5.2" class="indexterm"></a><a id="id-1.6.15.5.3" class="indexterm"></a><p>
   3     <em class="firstterm">Write-Ahead Logging</em> (<acronym class="acronym">WAL</acronym>)
   4     is a standard method for ensuring data integrity.  A detailed
   5     description can be found in most (if not all) books about
   6     transaction processing. Briefly, <acronym class="acronym">WAL</acronym>'s central
   7     concept is that changes to data files (where tables and indexes
   8     reside) must be written only after those changes have been logged,
   9     that is, after WAL records describing the changes have been flushed
  10     to permanent storage. If we follow this procedure, we do not need
  11     to flush data pages to disk on every transaction commit, because we
  12     know that in the event of a crash we will be able to recover the
  13     database using the log: any changes that have not been applied to
  14     the data pages can be redone from the WAL records.  (This is
  15     roll-forward recovery, also known as REDO.)
  16    </p><div class="tip"><h3 class="title">Tip</h3><p>
  17      Because <acronym class="acronym">WAL</acronym> restores database file
  18      contents after a crash, journaled file systems are not necessary for
  19      reliable storage of the data files or WAL files.  In fact, journaling
  20      overhead can reduce performance, especially if journaling
  21      causes file system <span class="emphasis"><em>data</em></span> to be flushed
  22      to disk.  Fortunately, data flushing during journaling can
  23      often be disabled with a file system mount option, e.g.,
  24      <code class="literal">data=writeback</code> on a Linux ext3 file system.
  25      Journaled file systems do improve boot speed after a crash.
  26     </p></div><p>
  27     Using <acronym class="acronym">WAL</acronym> results in a
  28     significantly reduced number of disk writes, because only the WAL
  29     file needs to be flushed to disk to guarantee that a transaction is
  30     committed, rather than every data file changed by the transaction.
  31     The WAL file is written sequentially,
  32     and so the cost of syncing the WAL is much less than the cost of
  33     flushing the data pages.  This is especially true for servers
  34     handling many small transactions touching different parts of the data
  35     store.  Furthermore, when the server is processing many small concurrent
  36     transactions, one <code class="function">fsync</code> of the WAL file may
  37     suffice to commit many transactions.
  38    </p><p>
  39     <acronym class="acronym">WAL</acronym> also makes it possible to support on-line
  40     backup and point-in-time recovery, as described in <a class="xref" href="continuous-archiving.html" title="25.3. Continuous Archiving and Point-in-Time Recovery (PITR)">Section 25.3</a>.  By archiving the WAL data we can support
  41     reverting to any time instant covered by the available WAL data:
  42     we simply install a prior physical backup of the database, and
  43     replay the WAL just as far as the desired time.  What's more,
  44     the physical backup doesn't have to be an instantaneous snapshot
  45     of the database state — if it is made over some period of time,
  46     then replaying the WAL for that period will fix any internal
  47     inconsistencies.
  48    </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="checksums.html" title="28.2. Data Checksums">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="wal.html" title="Chapter 28. Reliability and the Write-Ahead Log">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="wal-async-commit.html" title="28.4. Asynchronous Commit">Next</a></td></tr><tr><td width="40%" align="left" valign="top">28.2. Data Checksums </td><td width="20%" align="center"><a accesskey="h" href="index.html" title="PostgreSQL 18.0 Documentation">Home</a></td><td width="40%" align="right" valign="top"> 28.4. Asynchronous Commit</td></tr></table></div></body></html>