RE: Replication: slave server has 3x size of production server?

---

De: Adrian Klaver <adrian.klaver@aklaver.com>
Enviado: sábado, 22 de fevereiro de 2020 18:12
Para: Edson Richter <edsonrichter@hotmail.com>; pgsql-general <pgsql-general@postgresql.org>
Assunto: Re: Replication: slave server has 3x size of production server?

 

On 2/22/20 11:23 AM, Edson Richter wrote:
>     ------------------------------------------------------------------------
>
>     *De:* Adrian Klaver <adrian.klaver@aklaver.com>
>     *Enviado:* sábado, 22 de fevereiro de 2020 16:16
>     *Para:* Edson Richter <edsonrichter@hotmail.com>; pgsql-general
>     <pgsql-general@postgresql.org>
>     *Assunto:* Re: Replication: slave server has 3x size of production
>     server?
>     On 2/22/20 11:03 AM, Edson Richter wrote:
>     >     ------------------------------------------------------------------------
>     >
>
>     >
>     >
>     > Streaming replication. Initiated via pg_basebackup.
>     >
>     > Settings on master server:
>     >
>     > # - Sending Server(s) -
>     > # Set these on the master and on any standby that will send replication
>     > data.
>     > max_wal_senders = 2             # max number of walsender processes
>     > (change requires restart)
>     > wal_keep_segments = 25          # in logfile segments, 16MB each; 0 disables
>     > #wal_sender_timeout = 60s       # in milliseconds; 0 disables
>     > max_replication_slots = 2       # max number of replication
>     > slots (change requires restart)
>     > #track_commit_timestamp = off   # collect timestamp of transaction
>     > commit (change requires restart)
>     > # - Master Server -
>     > # These settings are ignored on a standby server.
>     > #synchronous_standby_names = '' # standby servers that provide sync
>     > rep number of sync standbys and comma-separated list of
>     > application_name from standby(s); '*' = all
>     > #vacuum_defer_cleanup_age = 0   # number of xacts by which cleanup is
>     > delayed
>     >
>     >
>     >
>     > Settings on slave server:
>     >
>     > # - Standby Servers -
>     > # These settings are ignored on a master server.
>     > hot_standby = on                        # "on" allows queries during
>     > recovery (change requires restart)
>     > max_standby_archive_delay = -1          # max delay before canceling
>     > queries when reading WAL from archive; -1 allows indefinite delay
>     > max_standby_streaming_delay = -1        # max delay before canceling
>     > queries when reading streaming WAL; -1 allows indefinite delay
>     > wal_receiver_status_interval = 10s      # send replies at least this
>     > often 0 disables
>     > hot_standby_feedback = on               # send info from standby to
>     > prevent query conflicts
>     > wal_receiver_timeout = 0                # time that receiver waits for
>     > communication from master in milliseconds; 0 disables
>     > wal_retrieve_retry_interval = 5s        # time to wait before retrying
>     > to retrieve WAL after a failed attempt
>
>     What are the settings for:
>
>     archive_mode
>     archive_command
>
>     on the standby?
>
>     Are the files in pg_xlog on the standby mostly from well in the past?
>
>
> Actually, standby server is sending wals to a backup (barman) server:
>
> archive_mode = always           # enables archiving; off, on, or always
> (change requires restart)
> archive_command = 'rsync -e "ssh -2 -C -p 2022" -az %p
> barman@192.168.0.2:/dados/barman/dbcluster/incoming/%f'

And the above is working, the files are showing up on the barman server?