begriffs open source - ai-pg/blob - full-docs/src/sgml/html/warm-standby-failover.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>26.3. Failover</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="warm-standby.html" title="26.2. Log-Shipping Standby Servers" /><link rel="next" href="hot-standby.html" title="26.4. Hot Standby" /></head><body id="docContent" class="container-fluid col-10"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">26.3. Failover</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="warm-standby.html" title="26.2. Log-Shipping Standby Servers">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="high-availability.html" title="Chapter 26. High Availability, Load Balancing, and Replication">Up</a></td><th width="60%" align="center">Chapter 26. High Availability, Load Balancing, and Replication</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="hot-standby.html" title="26.4. Hot Standby">Next</a></td></tr></table><hr /></div><div class="sect1" id="WARM-STANDBY-FAILOVER"><div class="titlepage"><div><div><h2 class="title" style="clear: both">26.3. Failover <a href="#WARM-STANDBY-FAILOVER" class="id_link">#</a></h2></div></div></div><p>
   3     If the primary server fails then the standby server should begin
   4     failover procedures.
   5    </p><p>
   6     If the standby server fails then no failover need take place. If the
   7     standby server can be restarted, even some time later, then the recovery
   8     process can also be restarted immediately, taking advantage of
   9     restartable recovery. If the standby server cannot be restarted, then a
  10     full new standby server instance should be created.
  11    </p><p>
  12     If the primary server fails and the standby server becomes the
  13     new primary, and then the old primary restarts, you must have
  14     a mechanism for informing the old primary that it is no longer the primary. This is
  15     sometimes known as <acronym class="acronym">STONITH</acronym> (Shoot The Other Node In The Head), which is
  16     necessary to avoid situations where both systems think they are the
  17     primary, which will lead to confusion and ultimately data loss.
  18    </p><p>
  19     Many failover systems use just two systems, the primary and the standby,
  20     connected by some kind of heartbeat mechanism to continually verify the
  21     connectivity between the two and the viability of the primary. It is
  22     also possible to use a third system (called a witness server) to prevent
  23     some cases of inappropriate failover, but the additional complexity
  24     might not be worthwhile unless it is set up with sufficient care and
  25     rigorous testing.
  26    </p><p>
  27     <span class="productname">PostgreSQL</span> does not provide the system
  28     software required to identify a failure on the primary and notify
  29     the standby database server.  Many such tools exist and are well
  30     integrated with the operating system facilities required for
  31     successful failover, such as IP address migration.
  32    </p><p>
  33     Once failover to the standby occurs, there is only a
  34     single server in operation. This is known as a degenerate state.
  35     The former standby is now the primary, but the former primary is down
  36     and might stay down.  To return to normal operation, a standby server
  37     must be recreated,
  38     either on the former primary system when it comes up, or on a third,
  39     possibly new, system. The <a class="xref" href="app-pgrewind.html" title="pg_rewind"><span class="refentrytitle"><span class="application">pg_rewind</span></span></a> utility can be
  40     used to speed up this process on large clusters.
  41     Once complete, the primary and standby can be
  42     considered to have switched roles. Some people choose to use a third
  43     server to provide backup for the new primary until the new standby
  44     server is recreated,
  45     though clearly this complicates the system configuration and
  46     operational processes.
  47    </p><p>
  48     So, switching from primary to standby server can be fast but requires
  49     some time to re-prepare the failover cluster. Regular switching from
  50     primary to standby is useful, since it allows regular downtime on
  51     each system for maintenance. This also serves as a test of the
  52     failover mechanism to ensure that it will really work when you need it.
  53     Written administration procedures are advised.
  54    </p><p>
  55     If you have opted for logical replication slot synchronization (see
  56     <a class="xref" href="logicaldecoding-explanation.html#LOGICALDECODING-REPLICATION-SLOTS-SYNCHRONIZATION" title="47.2.3. Replication Slot Synchronization">Section 47.2.3</a>),
  57     then before switching to the standby server, it is recommended to check
  58     if the logical slots synchronized on the standby server are ready
  59     for failover. This can be done by following the steps described in
  60     <a class="xref" href="logical-replication-failover.html" title="29.3. Logical Replication Failover">Section 29.3</a>.
  61    </p><p>
  62     To trigger failover of a log-shipping standby server, run
  63     <code class="command">pg_ctl promote</code> or call <code class="function">pg_promote()</code>.
  64     If you're setting up reporting servers that are only used to offload
  65     read-only queries from the primary, not for high availability purposes,
  66     you don't need to promote.
  67    </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="warm-standby.html" title="26.2. Log-Shipping Standby Servers">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="high-availability.html" title="Chapter 26. High Availability, Load Balancing, and Replication">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="hot-standby.html" title="26.4. Hot Standby">Next</a></td></tr><tr><td width="40%" align="left" valign="top">26.2. Log-Shipping Standby Servers </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"> 26.4. Hot Standby</td></tr></table></div></body></html>