Search Postgresql Archives

Re: primary_conninfo and restore_command ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Mar 10, 2022 at 7:22 PM Luca Ferrari <fluca1978@xxxxxxxxx> wrote:
>
> Hi all,
> a friend of mine has shown to me a "strange" configuration of its
> physical replication server (13): he has both primary_conninfo and
> primary_slot_name, with replication slots active when queried on the
> master. So far so good, but in the configuration he has also
> restore_command to restore archived WALs from a centralized location.
> Does this make sense?
> Because if the replica cannot connect to the master, it will not start
> at all (so I guess no restore_command will be executed). On the other
> hand if the replica can connect to the primary the WALs will be
> shipped by means of streaming.
> Am I missing something?

Yes, restore_command gets executed even in standby mode when
walreceiver is unable to receive wal from primary i.e. primary stopped
sending WAL, see some comments on it [1]. It looks like
restore_command in standby mode isn't mandatory, but is advisable I
guess. I hope that clarifies your question.

[1] WaitForWALToBecomeAvailable:

     *
     * If standby mode is turned off while reading WAL from stream, we move
     * to XLOG_FROM_ARCHIVE and reset lastSourceFailed, to force fetching
     * the files (which would be required at end of recovery, e.g., timeline
     * history file) from archive or pg_wal. We don't need to kill WAL receiver
     * here because it's already stopped when standby mode is turned off at
     * the end of recovery.
     *-------
     */

           case XLOG_FROM_STREAM:

                    /*
                     * Failure while streaming. Most likely, we got here
                     * because streaming replication was terminated, or
                     * promotion was triggered. But we also get here if we
                     * find an invalid record in the WAL streamed from master,
                     * in which case something is seriously wrong. There's
                     * little chance that the problem will just go away, but
                     * PANIC is not good for availability either, especially
                     * in hot standby mode. So, we treat that the same as
                     * disconnection, and retry from archive/pg_wal again. The
                     * WAL in the archive should be identical to what was
                     * streamed, so it's unlikely that it helps, but one can
                     * hope...
                     */

Regards,
Bharath Rupireddy.





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux