|
- <?xml version="1.0" encoding="UTF-8" standalone="no"?>
- <!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 V1.79.1" /><link rel="prev" href="warm-standby.html" title="26.2. Log-Shipping Standby Servers" /><link rel="next" href="log-shipping-alternative.html" title="26.4. Alternative Method for Log Shipping" /></head><body><div xmlns="http://www.w3.org/TR/xhtml1/transitional" 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 12.4 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="log-shipping-alternative.html" title="26.4. Alternative Method for Log Shipping">Next</a></td></tr></table><hr></hr></div><div class="sect1" id="WARM-STANDBY-FAILOVER"><div class="titlepage"><div><div><h2 class="title" style="clear: both">26.3. Failover</h2></div></div></div><p>
- If the primary server fails then the standby server should begin
- failover procedures.
- </p><p>
- If the standby server fails then no failover need take place. If the
- standby server can be restarted, even some time later, then the recovery
- process can also be restarted immediately, taking advantage of
- restartable recovery. If the standby server cannot be restarted, then a
- full new standby server instance should be created.
- </p><p>
- If the primary server fails and the standby server becomes the
- new primary, and then the old primary restarts, you must have
- a mechanism for informing the old primary that it is no longer the primary. This is
- sometimes known as <acronym class="acronym">STONITH</acronym> (Shoot The Other Node In The Head), which is
- necessary to avoid situations where both systems think they are the
- primary, which will lead to confusion and ultimately data loss.
- </p><p>
- Many failover systems use just two systems, the primary and the standby,
- connected by some kind of heartbeat mechanism to continually verify the
- connectivity between the two and the viability of the primary. It is
- also possible to use a third system (called a witness server) to prevent
- some cases of inappropriate failover, but the additional complexity
- might not be worthwhile unless it is set up with sufficient care and
- rigorous testing.
- </p><p>
- <span class="productname">PostgreSQL</span> does not provide the system
- software required to identify a failure on the primary and notify
- the standby database server. Many such tools exist and are well
- integrated with the operating system facilities required for
- successful failover, such as IP address migration.
- </p><p>
- Once failover to the standby occurs, there is only a
- single server in operation. This is known as a degenerate state.
- The former standby is now the primary, but the former primary is down
- and might stay down. To return to normal operation, a standby server
- must be recreated,
- either on the former primary system when it comes up, or on a third,
- 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
- used to speed up this process on large clusters.
- Once complete, the primary and standby can be
- considered to have switched roles. Some people choose to use a third
- server to provide backup for the new primary until the new standby
- server is recreated,
- though clearly this complicates the system configuration and
- operational processes.
- </p><p>
- So, switching from primary to standby server can be fast but requires
- some time to re-prepare the failover cluster. Regular switching from
- primary to standby is useful, since it allows regular downtime on
- each system for maintenance. This also serves as a test of the
- failover mechanism to ensure that it will really work when you need it.
- Written administration procedures are advised.
- </p><p>
- To trigger failover of a log-shipping standby server, run
- <code class="command">pg_ctl promote</code>, call <code class="function">pg_promote</code>,
- or create a trigger file with the file name and path specified by the
- <code class="varname">promote_trigger_file</code>. If you're planning to use
- <code class="command">pg_ctl promote</code> or to call
- <code class="function">pg_promote</code> to fail over,
- <code class="varname">promote_trigger_file</code> is not required. If you're
- setting up the reporting servers that are only used to offload read-only
- queries from the primary, not for high availability purposes, you don't
- need to promote it.
- </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">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="high-availability.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="log-shipping-alternative.html">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">Home</a></td><td width="40%" align="right" valign="top"> 26.4. Alternative Method for Log Shipping</td></tr></table></div></body></html>
|
