Baoding-FenShuaJiang
/
Green_GoodERP18_FSJ_Standard
Volgen 1
Ster 0
Wiki 捐赠
gooderp18绿色标准版
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Branch: master
Branches Labels
${ item.name }
Maak branch ${ searchTerm }
van 'master'
${ noResults }
Green_GoodERP18_FSJ_Standard/PostgreSQL/doc/postgresql/html/runtime-config-replication....

501 lines
37KB
Ruw Permalink Blame Geschiedenis 

  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>19.6. Replication</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="runtime-config-wal.html" title="19.5. Write Ahead Log" /><link rel="next" href="runtime-config-query.html" title="19.7. Query Planning" /></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">19.6. Replication</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="runtime-config-wal.html" title="19.5. Write Ahead Log">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="runtime-config.html" title="Chapter 19. Server Configuration">Up</a></td><th width="60%" align="center">Chapter 19. Server Configuration</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="runtime-config-query.html" title="19.7. Query Planning">Next</a></td></tr></table><hr></hr></div><div class="sect1" id="RUNTIME-CONFIG-REPLICATION"><div class="titlepage"><div><div><h2 class="title" style="clear: both">19.6. Replication</h2></div></div></div><div class="toc"><dl class="toc"><dt><span class="sect2"><a href="runtime-config-replication.html#RUNTIME-CONFIG-REPLICATION-SENDER">19.6.1. Sending Servers</a></span></dt><dt><span class="sect2"><a href="runtime-config-replication.html#RUNTIME-CONFIG-REPLICATION-MASTER">19.6.2. Master Server</a></span></dt><dt><span class="sect2"><a href="runtime-config-replication.html#RUNTIME-CONFIG-REPLICATION-STANDBY">19.6.3. Standby Servers</a></span></dt><dt><span class="sect2"><a href="runtime-config-replication.html#RUNTIME-CONFIG-REPLICATION-SUBSCRIBER">19.6.4. Subscribers</a></span></dt></dl></div><p>

  3.      These settings control the behavior of the built-in

  4.      <em class="firstterm">streaming replication</em> feature (see

  5.      <a class="xref" href="warm-standby.html#STREAMING-REPLICATION" title="26.2.5. Streaming Replication">Section 26.2.5</a>).  Servers will be either a

  6.      master or a standby server.  Masters can send data, while standbys

  7.      are always receivers of replicated data.  When cascading replication

  8.      (see <a class="xref" href="warm-standby.html#CASCADING-REPLICATION" title="26.2.7. Cascading Replication">Section 26.2.7</a>) is used, standby servers

  9.      can also be senders, as well as receivers.

  10.      Parameters are mainly for sending and standby servers, though some

  11.      parameters have meaning only on the master server.  Settings may vary

  12.      across the cluster without problems if that is required.

  13.     </p><div class="sect2" id="RUNTIME-CONFIG-REPLICATION-SENDER"><div class="titlepage"><div><div><h3 class="title">19.6.1. Sending Servers</h3></div></div></div><p>

  14.       These parameters can be set on any server that is

  15.       to send replication data to one or more standby servers.

  16.       The master is always a sending server, so these parameters must

  17.       always be set on the master.

  18.       The role and meaning of these parameters does not change after a

  19.       standby becomes the master.

  20.      </p><div class="variablelist"><dl class="variablelist"><dt id="GUC-MAX-WAL-SENDERS"><span class="term"><code class="varname">max_wal_senders</code> (<code class="type">integer</code>)

  21.        <a id="id-1.6.6.9.3.3.1.1.3" class="indexterm"></a>

  22.        </span></dt><dd><p>

  23.         Specifies the maximum number of concurrent connections from standby

  24.         servers or streaming base backup clients (i.e., the maximum number of

  25.         simultaneously running WAL sender processes). The default is

  26.         <code class="literal">10</code>.  The value <code class="literal">0</code> means

  27.         replication is disabled.  Abrupt streaming client disconnection might

  28.         leave an orphaned connection slot behind until a timeout is reached,

  29.         so this parameter should be set slightly higher than the maximum

  30.         number of expected clients so disconnected clients can immediately

  31.         reconnect.  This parameter can only be set at server start.  Also,

  32.         <code class="varname">wal_level</code> must be set to

  33.         <code class="literal">replica</code> or higher to allow connections from standby

  34.         servers.

  35.        </p><p>

  36.          When running a standby server, you must set this parameter to the

  37.          same or higher value than on the master server. Otherwise, queries

  38.          will not be allowed in the standby server.

  39.         </p></dd><dt id="GUC-MAX-REPLICATION-SLOTS"><span class="term"><code class="varname">max_replication_slots</code> (<code class="type">integer</code>)

  40.        <a id="id-1.6.6.9.3.3.2.1.3" class="indexterm"></a>

  41.        </span></dt><dd><p>

  42.          Specifies the maximum number of replication slots

  43.          (see <a class="xref" href="warm-standby.html#STREAMING-REPLICATION-SLOTS" title="26.2.6. Replication Slots">Section 26.2.6</a>) that the server

  44.          can support. The default is 10.  This parameter can only be set at

  45.          server start.

  46.          Setting it to a lower value than the number of currently

  47.          existing replication slots will prevent the server from starting.

  48.          Also, <code class="varname">wal_level</code> must be set

  49.          to <code class="literal">replica</code> or higher to allow replication slots to

  50.          be used.

  51.         </p></dd><dt id="GUC-WAL-KEEP-SEGMENTS"><span class="term"><code class="varname">wal_keep_segments</code> (<code class="type">integer</code>)

  52.        <a id="id-1.6.6.9.3.3.3.1.3" class="indexterm"></a>

  53.        </span></dt><dd><p>

  54.         Specifies the minimum number of past log file segments kept in the

  55.         <code class="filename">pg_wal</code>

  56.         directory, in case a standby server needs to fetch them for streaming

  57.         replication. Each segment is normally 16 megabytes. If a standby

  58.         server connected to the sending server falls behind by more than

  59.         <code class="varname">wal_keep_segments</code> segments, the sending server might remove

  60.         a WAL segment still needed by the standby, in which case the

  61.         replication connection will be terminated.  Downstream connections

  62.         will also eventually fail as a result.  (However, the standby

  63.         server can recover by fetching the segment from archive, if WAL

  64.         archiving is in use.)

  65.        </p><p>

  66.         This sets only the minimum number of segments retained in

  67.         <code class="filename">pg_wal</code>; the system might need to retain more segments

  68.         for WAL archival or to recover from a checkpoint. If

  69.         <code class="varname">wal_keep_segments</code> is zero (the default), the system

  70.         doesn't keep any extra segments for standby purposes, so the number

  71.         of old WAL segments available to standby servers is a function of

  72.         the location of the previous checkpoint and status of WAL

  73.         archiving.

  74.         This parameter can only be set in the

  75.         <code class="filename">postgresql.conf</code> file or on the server command line.

  76.        </p></dd><dt id="GUC-WAL-SENDER-TIMEOUT"><span class="term"><code class="varname">wal_sender_timeout</code> (<code class="type">integer</code>)

  77.       <a id="id-1.6.6.9.3.3.4.1.3" class="indexterm"></a>

  78.       </span></dt><dd><p>

  79.         Terminate replication connections that are inactive for longer

  80.         than this amount of time. This is useful for

  81.         the sending server to detect a standby crash or network outage.

  82.         If this value is specified without units, it is taken as milliseconds.

  83.         The default value is 60 seconds.

  84.         A value of zero disables the timeout mechanism.

  85.        </p><p>

  86.         With a cluster distributed across multiple geographic

  87.         locations, using different values per location brings more flexibility

  88.         in the cluster management. A smaller value is useful for faster

  89.         failure detection with a standby having a low-latency network

  90.         connection, and a larger value helps in judging better the health

  91.         of a standby if located on a remote location, with a high-latency

  92.         network connection.

  93.        </p></dd><dt id="GUC-TRACK-COMMIT-TIMESTAMP"><span class="term"><code class="varname">track_commit_timestamp</code> (<code class="type">boolean</code>)

  94.       <a id="id-1.6.6.9.3.3.5.1.3" class="indexterm"></a>

  95.       </span></dt><dd><p>

  96.         Record commit time of transactions. This parameter

  97.         can only be set in <code class="filename">postgresql.conf</code> file or on the server

  98.         command line. The default value is <code class="literal">off</code>.

  99.        </p></dd></dl></div></div><div class="sect2" id="RUNTIME-CONFIG-REPLICATION-MASTER"><div class="titlepage"><div><div><h3 class="title">19.6.2. Master Server</h3></div></div></div><p>

  100.       These parameters can be set on the master/primary server that is

  101.       to send replication data to one or more standby servers.

  102.       Note that in addition to these parameters,

  103.       <a class="xref" href="runtime-config-wal.html#GUC-WAL-LEVEL">wal_level</a> must be set appropriately on the master

  104.       server, and optionally WAL archiving can be enabled as

  105.       well (see <a class="xref" href="runtime-config-wal.html#RUNTIME-CONFIG-WAL-ARCHIVING" title="19.5.3. Archiving">Section 19.5.3</a>).

  106.       The values of these parameters on standby servers are irrelevant,

  107.       although you may wish to set them there in preparation for the

  108.       possibility of a standby becoming the master.

  109.      </p><div class="variablelist"><dl class="variablelist"><dt id="GUC-SYNCHRONOUS-STANDBY-NAMES"><span class="term"><code class="varname">synchronous_standby_names</code> (<code class="type">string</code>)

  110.       <a id="id-1.6.6.9.4.3.1.1.3" class="indexterm"></a>

  111.       </span></dt><dd><p>

  112.         Specifies a list of standby servers that can support

  113.         <em class="firstterm">synchronous replication</em>, as described in

  114.         <a class="xref" href="warm-standby.html#SYNCHRONOUS-REPLICATION" title="26.2.8. Synchronous Replication">Section 26.2.8</a>.

  115.         There will be one or more active synchronous standbys;

  116.         transactions waiting for commit will be allowed to proceed after

  117.         these standby servers confirm receipt of their data.

  118.         The synchronous standbys will be those whose names appear

  119.         in this list, and

  120.         that are both currently connected and streaming data in real-time

  121.         (as shown by a state of <code class="literal">streaming</code> in the <a class="link" href="monitoring-stats.html#PG-STAT-REPLICATION-VIEW" title="Table 27.5. pg_stat_replication View"><code class="literal">pg_stat_replication</code></a>

  122.         view).

  123.         Specifying more than one synchronous standby can allow for very high

  124.         availability and protection against data loss.

  125.        </p><p>

  126.         The name of a standby server for this purpose is the

  127.         <code class="varname">application_name</code> setting of the standby, as set in the

  128.         standby's connection information.  In case of a physical replication

  129.         standby, this should be set in the <code class="varname">primary_conninfo</code>

  130.         setting; the default is the setting of <a class="xref" href="runtime-config-logging.html#GUC-CLUSTER-NAME">cluster_name</a>

  131.         if set, else <code class="literal">walreceiver</code>.

  132.         For logical replication, this can be set in the connection

  133.         information of the subscription, and it defaults to the

  134.         subscription name.  For other replication stream consumers,

  135.         consult their documentation.

  136.        </p><p>

  137.         This parameter specifies a list of standby servers using

  138.         either of the following syntaxes:

  139. </p><pre class="synopsis">

  140. [FIRST] <em class="replaceable"><code>num_sync</code></em> ( <em class="replaceable"><code>standby_name</code></em> [, ...] )

  141. ANY <em class="replaceable"><code>num_sync</code></em> ( <em class="replaceable"><code>standby_name</code></em> [, ...] )

  142. <em class="replaceable"><code>standby_name</code></em> [, ...]

  143. </pre><p>

  144.         where <em class="replaceable"><code>num_sync</code></em> is

  145.         the number of synchronous standbys that transactions need to

  146.         wait for replies from,

  147.         and <em class="replaceable"><code>standby_name</code></em>

  148.         is the name of a standby server.

  149.         <code class="literal">FIRST</code> and <code class="literal">ANY</code> specify the method to choose

  150.         synchronous standbys from the listed servers.

  151.        </p><p>

  152.         The keyword <code class="literal">FIRST</code>, coupled with

  153.         <em class="replaceable"><code>num_sync</code></em>, specifies a

  154.         priority-based synchronous replication and makes transaction commits

  155.         wait until their WAL records are replicated to

  156.         <em class="replaceable"><code>num_sync</code></em> synchronous

  157.         standbys chosen based on their priorities. For example, a setting of

  158.         <code class="literal">FIRST 3 (s1, s2, s3, s4)</code> will cause each commit to wait for

  159.         replies from three higher-priority standbys chosen from standby servers

  160.         <code class="literal">s1</code>, <code class="literal">s2</code>, <code class="literal">s3</code> and <code class="literal">s4</code>.

  161.         The standbys whose names appear earlier in the list are given higher

  162.         priority and will be considered as synchronous. Other standby servers

  163.         appearing later in this list represent potential synchronous standbys.

  164.         If any of the current synchronous standbys disconnects for whatever

  165.         reason, it will be replaced immediately with the next-highest-priority

  166.         standby. The keyword <code class="literal">FIRST</code> is optional.

  167.        </p><p>

  168.         The keyword <code class="literal">ANY</code>, coupled with

  169.         <em class="replaceable"><code>num_sync</code></em>, specifies a

  170.         quorum-based synchronous replication and makes transaction commits

  171.         wait until their WAL records are replicated to <span class="emphasis"><em>at least</em></span>

  172.         <em class="replaceable"><code>num_sync</code></em> listed standbys.

  173.         For example, a setting of <code class="literal">ANY 3 (s1, s2, s3, s4)</code> will cause

  174.         each commit to proceed as soon as at least any three standbys of

  175.         <code class="literal">s1</code>, <code class="literal">s2</code>, <code class="literal">s3</code> and <code class="literal">s4</code>

  176.         reply.

  177.        </p><p>

  178.         <code class="literal">FIRST</code> and <code class="literal">ANY</code> are case-insensitive. If these

  179.         keywords are used as the name of a standby server,

  180.         its <em class="replaceable"><code>standby_name</code></em> must

  181.         be double-quoted.

  182.        </p><p>

  183.         The third syntax was used before <span class="productname">PostgreSQL</span>

  184.         version 9.6 and is still supported. It's the same as the first syntax

  185.         with <code class="literal">FIRST</code> and

  186.         <em class="replaceable"><code>num_sync</code></em> equal to 1.

  187.         For example, <code class="literal">FIRST 1 (s1, s2)</code> and <code class="literal">s1, s2</code> have

  188.         the same meaning: either <code class="literal">s1</code> or <code class="literal">s2</code> is chosen

  189.         as a synchronous standby.

  190.        </p><p>

  191.         The special entry <code class="literal">*</code> matches any standby name.

  192.        </p><p>

  193.         There is no mechanism to enforce uniqueness of standby names.  In case

  194.         of duplicates one of the matching standbys will be considered as

  195.         higher priority, though exactly which one is indeterminate.

  196.        </p><div class="note"><h3 class="title">Note</h3><p>

  197.          Each <em class="replaceable"><code>standby_name</code></em>

  198.          should have the form of a valid SQL identifier, unless it

  199.          is <code class="literal">*</code>.  You can use double-quoting if necessary.  But note

  200.          that <em class="replaceable"><code>standby_name</code></em>s are

  201.          compared to standby application names case-insensitively, whether

  202.          double-quoted or not.

  203.         </p></div><p>

  204.         If no synchronous standby names are specified here, then synchronous

  205.         replication is not enabled and transaction commits will not wait for

  206.         replication.  This is the default configuration.  Even when

  207.         synchronous replication is enabled, individual transactions can be

  208.         configured not to wait for replication by setting the

  209.         <a class="xref" href="runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT">synchronous_commit</a> parameter to

  210.         <code class="literal">local</code> or <code class="literal">off</code>.

  211.        </p><p>

  212.         This parameter can only be set in the <code class="filename">postgresql.conf</code>

  213.         file or on the server command line.

  214.        </p></dd><dt id="GUC-VACUUM-DEFER-CLEANUP-AGE"><span class="term"><code class="varname">vacuum_defer_cleanup_age</code> (<code class="type">integer</code>)

  215.       <a id="id-1.6.6.9.4.3.2.1.3" class="indexterm"></a>

  216.       </span></dt><dd><p>

  217.         Specifies the number of transactions by which <code class="command">VACUUM</code> and

  218.         <acronym class="acronym">HOT</acronym> updates will defer cleanup of dead row versions. The

  219.         default is zero transactions, meaning that dead row versions can be

  220.         removed as soon as possible, that is, as soon as they are no longer

  221.         visible to any open transaction.  You may wish to set this to a

  222.         non-zero value on a primary server that is supporting hot standby

  223.         servers, as described in <a class="xref" href="hot-standby.html" title="26.5. Hot Standby">Section 26.5</a>.  This allows

  224.         more time for queries on the standby to complete without incurring

  225.         conflicts due to early cleanup of rows.  However, since the value

  226.         is measured in terms of number of write transactions occurring on the

  227.         primary server, it is difficult to predict just how much additional

  228.         grace time will be made available to standby queries.

  229.         This parameter can only be set in the <code class="filename">postgresql.conf</code>

  230.         file or on the server command line.

  231.        </p><p>

  232.         You should also consider setting <code class="varname">hot_standby_feedback</code>

  233.         on standby server(s) as an alternative to using this parameter.

  234.        </p><p>

  235.         This does not prevent cleanup of dead rows which have reached the age

  236.         specified by <code class="varname">old_snapshot_threshold</code>.

  237.        </p></dd></dl></div></div><div class="sect2" id="RUNTIME-CONFIG-REPLICATION-STANDBY"><div class="titlepage"><div><div><h3 class="title">19.6.3. Standby Servers</h3></div></div></div><p>

  238.       These settings control the behavior of a standby server that is

  239.       to receive replication data.  Their values on the master server

  240.       are irrelevant.

  241.      </p><div class="variablelist"><dl class="variablelist"><dt id="GUC-PRIMARY-CONNINFO"><span class="term"><code class="varname">primary_conninfo</code> (<code class="type">string</code>)

  242.         <a id="id-1.6.6.9.5.3.1.1.3" class="indexterm"></a>

  243.         </span></dt><dd><p>

  244.           Specifies a connection string to be used for the standby server

  245.           to connect with a sending server. This string is in the format

  246.           described in <a class="xref" href="libpq-connect.html#LIBPQ-CONNSTRING" title="33.1.1. Connection Strings">Section 33.1.1</a>. If any option is

  247.           unspecified in this string, then the corresponding environment

  248.           variable (see <a class="xref" href="libpq-envars.html" title="33.14. Environment Variables">Section 33.14</a>) is checked. If the

  249.           environment variable is not set either, then

  250.           defaults are used.

  251.          </p><p>

  252.           The connection string should specify the host name (or address)

  253.           of the sending server, as well as the port number if it is not

  254.           the same as the standby server's default.

  255.           Also specify a user name corresponding to a suitably-privileged role

  256.           on the sending server (see

  257.           <a class="xref" href="warm-standby.html#STREAMING-REPLICATION-AUTHENTICATION" title="26.2.5.1. Authentication">Section 26.2.5.1</a>).

  258.           A password needs to be provided too, if the sender demands password

  259.           authentication.  It can be provided in the

  260.           <code class="varname">primary_conninfo</code> string, or in a separate

  261.           <code class="filename">~/.pgpass</code> file on the standby server (use

  262.           <code class="literal">replication</code> as the database name).

  263.           Do not specify a database name in the

  264.           <code class="varname">primary_conninfo</code> string.

  265.          </p><p>

  266.           This parameter can only be set at server start.

  267.           This setting has no effect if the server is not in standby mode.

  268.          </p></dd><dt id="GUC-PRIMARY-SLOT-NAME"><span class="term"><code class="varname">primary_slot_name</code> (<code class="type">string</code>)

  269.         <a id="id-1.6.6.9.5.3.2.1.3" class="indexterm"></a>

  270.         </span></dt><dd><p>

  271.           Optionally specifies an existing replication slot to be used when

  272.           connecting to the sending server via streaming replication to control

  273.           resource removal on the upstream node

  274.           (see <a class="xref" href="warm-standby.html#STREAMING-REPLICATION-SLOTS" title="26.2.6. Replication Slots">Section 26.2.6</a>).

  275.           This parameter can only be set at server start.

  276.           This setting has no effect if <code class="varname">primary_conninfo</code> is not

  277.           set.

  278.          </p></dd><dt id="GUC-PROMOTE-TRIGGER-FILE"><span class="term"><code class="varname">promote_trigger_file</code> (<code class="type">string</code>)

  279.         <a id="id-1.6.6.9.5.3.3.1.3" class="indexterm"></a>

  280.         </span></dt><dd><p>

  281.           Specifies a trigger file whose presence ends recovery in the

  282.           standby.  Even if this value is not set, you can still promote

  283.           the standby using <code class="command">pg_ctl promote</code> or calling

  284.           <code class="function">pg_promote</code>.

  285.           This parameter can only be set in the <code class="filename">postgresql.conf</code>

  286.           file or on the server command line.

  287.          </p></dd><dt id="GUC-HOT-STANDBY"><span class="term"><code class="varname">hot_standby</code> (<code class="type">boolean</code>)

  288.       <a id="id-1.6.6.9.5.3.4.1.3" class="indexterm"></a>

  289.       </span></dt><dd><p>

  290.         Specifies whether or not you can connect and run queries during

  291.         recovery, as described in <a class="xref" href="hot-standby.html" title="26.5. Hot Standby">Section 26.5</a>.

  292.         The default value is <code class="literal">on</code>.

  293.         This parameter can only be set at server start. It only has effect

  294.         during archive recovery or in standby mode.

  295.        </p></dd><dt id="GUC-MAX-STANDBY-ARCHIVE-DELAY"><span class="term"><code class="varname">max_standby_archive_delay</code> (<code class="type">integer</code>)

  296.       <a id="id-1.6.6.9.5.3.5.1.3" class="indexterm"></a>

  297.       </span></dt><dd><p>

  298.         When Hot Standby is active, this parameter determines how long the

  299.         standby server should wait before canceling standby queries that

  300.         conflict with about-to-be-applied WAL entries, as described in

  301.         <a class="xref" href="hot-standby.html#HOT-STANDBY-CONFLICT" title="26.5.2. Handling Query Conflicts">Section 26.5.2</a>.

  302.         <code class="varname">max_standby_archive_delay</code> applies when WAL data is

  303.         being read from WAL archive (and is therefore not current).

  304.         If this value is specified without units, it is taken as milliseconds.

  305.         The default is 30 seconds.

  306.         A value of -1 allows the standby to wait forever for conflicting

  307.         queries to complete.

  308.         This parameter can only be set in the <code class="filename">postgresql.conf</code>

  309.         file or on the server command line.

  310.        </p><p>

  311.         Note that <code class="varname">max_standby_archive_delay</code> is not the same as the

  312.         maximum length of time a query can run before cancellation; rather it

  313.         is the maximum total time allowed to apply any one WAL segment's data.

  314.         Thus, if one query has resulted in significant delay earlier in the

  315.         WAL segment, subsequent conflicting queries will have much less grace

  316.         time.

  317.        </p></dd><dt id="GUC-MAX-STANDBY-STREAMING-DELAY"><span class="term"><code class="varname">max_standby_streaming_delay</code> (<code class="type">integer</code>)

  318.       <a id="id-1.6.6.9.5.3.6.1.3" class="indexterm"></a>

  319.       </span></dt><dd><p>

  320.         When Hot Standby is active, this parameter determines how long the

  321.         standby server should wait before canceling standby queries that

  322.         conflict with about-to-be-applied WAL entries, as described in

  323.         <a class="xref" href="hot-standby.html#HOT-STANDBY-CONFLICT" title="26.5.2. Handling Query Conflicts">Section 26.5.2</a>.

  324.         <code class="varname">max_standby_streaming_delay</code> applies when WAL data is

  325.         being received via streaming replication.

  326.         If this value is specified without units, it is taken as milliseconds.

  327.         The default is 30 seconds.

  328.         A value of -1 allows the standby to wait forever for conflicting

  329.         queries to complete.

  330.         This parameter can only be set in the <code class="filename">postgresql.conf</code>

  331.         file or on the server command line.

  332.        </p><p>

  333.         Note that <code class="varname">max_standby_streaming_delay</code> is not the same as

  334.         the maximum length of time a query can run before cancellation; rather

  335.         it is the maximum total time allowed to apply WAL data once it has

  336.         been received from the primary server.  Thus, if one query has

  337.         resulted in significant delay, subsequent conflicting queries will

  338.         have much less grace time until the standby server has caught up

  339.         again.

  340.        </p></dd><dt id="GUC-WAL-RECEIVER-STATUS-INTERVAL"><span class="term"><code class="varname">wal_receiver_status_interval</code> (<code class="type">integer</code>)

  341.       <a id="id-1.6.6.9.5.3.7.1.3" class="indexterm"></a>

  342.       </span></dt><dd><p>

  343.        Specifies the minimum frequency for the WAL receiver

  344.        process on the standby to send information about replication progress

  345.        to the primary or upstream standby, where it can be seen using the

  346.        <a class="link" href="monitoring-stats.html#PG-STAT-REPLICATION-VIEW" title="Table 27.5. pg_stat_replication View"><code class="literal">pg_stat_replication</code></a>

  347.        view.  The standby will report

  348.        the last write-ahead log location it has written, the last position it

  349.        has flushed to disk, and the last position it has applied.

  350.        This parameter's

  351.        value is the maximum amount of time between reports.  Updates are

  352.        sent each time the write or flush positions change, or at least as

  353.        often as specified by this parameter.  Thus, the apply position may

  354.        lag slightly behind the true position.

  355.        If this value is specified without units, it is taken as seconds.

  356.        The default value is 10 seconds.

  357.        Setting this parameter to zero disables status updates completely.

  358.        This parameter can only be set in

  359.        the <code class="filename">postgresql.conf</code> file or on the server

  360.        command line.

  361.       </p></dd><dt id="GUC-HOT-STANDBY-FEEDBACK"><span class="term"><code class="varname">hot_standby_feedback</code> (<code class="type">boolean</code>)

  362.       <a id="id-1.6.6.9.5.3.8.1.3" class="indexterm"></a>

  363.       </span></dt><dd><p>

  364.         Specifies whether or not a hot standby will send feedback to the primary

  365.         or upstream standby

  366.         about queries currently executing on the standby. This parameter can

  367.         be used to eliminate query cancels caused by cleanup records, but

  368.         can cause database bloat on the primary for some workloads.

  369.         Feedback messages will not be sent more frequently than once per

  370.         <code class="varname">wal_receiver_status_interval</code>. The default value is

  371.         <code class="literal">off</code>. This parameter can only be set in the

  372.         <code class="filename">postgresql.conf</code> file or on the server command line.

  373.        </p><p>

  374.         If cascaded replication is in use the feedback is passed upstream

  375.         until it eventually reaches the primary.  Standbys make no other use

  376.         of feedback they receive other than to pass upstream.

  377.        </p><p>

  378.         This setting does not override the behavior of

  379.         <code class="varname">old_snapshot_threshold</code> on the primary; a snapshot on the

  380.         standby which exceeds the primary's age threshold can become invalid,

  381.         resulting in cancellation of transactions on the standby.  This is

  382.         because <code class="varname">old_snapshot_threshold</code> is intended to provide an

  383.         absolute limit on the time which dead rows can contribute to bloat,

  384.         which would otherwise be violated because of the configuration of a

  385.         standby.

  386.        </p></dd><dt id="GUC-WAL-RECEIVER-TIMEOUT"><span class="term"><code class="varname">wal_receiver_timeout</code> (<code class="type">integer</code>)

  387.       <a id="id-1.6.6.9.5.3.9.1.3" class="indexterm"></a>

  388.       </span></dt><dd><p>

  389.         Terminate replication connections that are inactive for longer

  390.         than this amount of time. This is useful for

  391.         the receiving standby server to detect a primary node crash or network

  392.         outage.

  393.         If this value is specified without units, it is taken as milliseconds.

  394.         The default value is 60 seconds.

  395.         A value of zero disables the timeout mechanism.

  396.         This parameter can only be set in

  397.         the <code class="filename">postgresql.conf</code> file or on the server

  398.         command line.

  399.        </p></dd><dt id="GUC-WAL-RETRIEVE-RETRY-INTERVAL"><span class="term"><code class="varname">wal_retrieve_retry_interval</code> (<code class="type">integer</code>)

  400.       <a id="id-1.6.6.9.5.3.10.1.3" class="indexterm"></a>

  401.       </span></dt><dd><p>

  402.         Specifies how long the standby server should wait when WAL data is not

  403.         available from any sources (streaming replication,

  404.         local <code class="filename">pg_wal</code> or WAL archive) before trying

  405.         again to retrieve WAL data.

  406.         If this value is specified without units, it is taken as milliseconds.

  407.         The default value is 5 seconds.

  408.         This parameter can only be set in

  409.         the <code class="filename">postgresql.conf</code> file or on the server

  410.         command line.

  411.        </p><p>

  412.         This parameter is useful in configurations where a node in recovery

  413.         needs to control the amount of time to wait for new WAL data to be

  414.         available. For example, in archive recovery, it is possible to

  415.         make the recovery more responsive in the detection of a new WAL

  416.         log file by reducing the value of this parameter. On a system with

  417.         low WAL activity, increasing it reduces the amount of requests necessary

  418.         to access WAL archives, something useful for example in cloud

  419.         environments where the amount of times an infrastructure is accessed

  420.         is taken into account.

  421.        </p></dd><dt id="GUC-RECOVERY-MIN-APPLY-DELAY"><span class="term"><code class="varname">recovery_min_apply_delay</code> (<code class="type">integer</code>)

  422.       <a id="id-1.6.6.9.5.3.11.1.3" class="indexterm"></a>

  423.       </span></dt><dd><p>

  424.         By default, a standby server restores WAL records from the

  425.         sending server as soon as possible. It may be useful to have a time-delayed

  426.         copy of the data, offering opportunities to correct data loss errors.

  427.         This parameter allows you to delay recovery by a specified amount

  428.         of time.  For example, if

  429.         you set this parameter to <code class="literal">5min</code>, the standby will

  430.         replay each transaction commit only when the system time on the standby

  431.         is at least five minutes past the commit time reported by the master.

  432.         If this value is specified without units, it is taken as milliseconds.

  433.         The default is zero, adding no delay.

  434.        </p><p>

  435.         It is possible that the replication delay between servers exceeds the

  436.         value of this parameter, in which case no delay is added.

  437.         Note that the delay is calculated between the WAL time stamp as written

  438.         on master and the current time on the standby. Delays in transfer

  439.         because of network lag or cascading replication configurations

  440.         may reduce the actual wait time significantly. If the system

  441.         clocks on master and standby are not synchronized, this may lead to

  442.         recovery applying records earlier than expected; but that is not a

  443.         major issue because useful settings of this parameter are much larger

  444.         than typical time deviations between servers.

  445.        </p><p>

  446.         The delay occurs only on WAL records for transaction commits.

  447.         Other records are replayed as quickly as possible, which

  448.         is not a problem because MVCC visibility rules ensure their effects

  449.         are not visible until the corresponding commit record is applied.

  450.        </p><p>

  451.         The delay occurs once the database in recovery has reached a consistent

  452.         state, until the standby is promoted or triggered. After that the standby

  453.         will end recovery without further waiting.

  454.        </p><p>

  455.         This parameter is intended for use with streaming replication deployments;

  456.         however, if the parameter is specified it will be honored in all cases

  457.         except crash recovery.

  458. 

  459.         <code class="varname">hot_standby_feedback</code> will be delayed by use of this feature

  460.         which could lead to bloat on the master; use both together with care.

  461. 

  462.         </p><div class="warning"><h3 class="title">Warning</h3><p>

  463.           Synchronous replication is affected by this setting when <code class="varname">synchronous_commit</code>

  464.           is set to <code class="literal">remote_apply</code>; every <code class="literal">COMMIT</code>

  465.           will need to wait to be applied.

  466.          </p></div><p>

  467.        </p><p>

  468.         This parameter can only be set in the <code class="filename">postgresql.conf</code>

  469.         file or on the server command line.

  470.        </p></dd></dl></div></div><div class="sect2" id="RUNTIME-CONFIG-REPLICATION-SUBSCRIBER"><div class="titlepage"><div><div><h3 class="title">19.6.4. Subscribers</h3></div></div></div><p>

  471.       These settings control the behavior of a logical replication subscriber.

  472.       Their values on the publisher are irrelevant.

  473.      </p><p>

  474.       Note that <code class="varname">wal_receiver_timeout</code>,

  475.       <code class="varname">wal_receiver_status_interval</code> and

  476.       <code class="varname">wal_retrieve_retry_interval</code> configuration parameters

  477.       affect the logical replication workers as well.

  478.      </p><div class="variablelist"><dl class="variablelist"><dt id="GUC-MAX-LOGICAL-REPLICATION-WORKERS"><span class="term"><code class="varname">max_logical_replication_workers</code> (<code class="type">int</code>)

  479.       <a id="id-1.6.6.9.6.4.1.1.3" class="indexterm"></a>

  480.       </span></dt><dd><p>

  481.         Specifies maximum number of logical replication workers. This includes

  482.         both apply workers and table synchronization workers.

  483.        </p><p>

  484.         Logical replication workers are taken from the pool defined by

  485.         <code class="varname">max_worker_processes</code>.

  486.        </p><p>

  487.         The default value is 4.

  488.        </p></dd><dt id="GUC-MAX-SYNC-WORKERS-PER-SUBSCRIPTION"><span class="term"><code class="varname">max_sync_workers_per_subscription</code> (<code class="type">integer</code>)

  489.       <a id="id-1.6.6.9.6.4.2.1.3" class="indexterm"></a>

  490.       </span></dt><dd><p>

  491.         Maximum number of synchronization workers per subscription. This

  492.         parameter controls the amount of parallelism of the initial data copy

  493.         during the subscription initialization or when new tables are added.

  494.        </p><p>

  495.         Currently, there can be only one synchronization worker per table.

  496.        </p><p>

  497.         The synchronization workers are taken from the pool defined by

  498.         <code class="varname">max_logical_replication_workers</code>.

  499.        </p><p>

  500.         The default value is 2.

  501.        </p></dd></dl></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="runtime-config-wal.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="runtime-config.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="runtime-config-query.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">19.5. Write Ahead Log </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> 19.7. Query Planning</td></tr></table></div></body></html>
上海开阖软件有限公司 沪ICP备12045867号-1