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?


> 
> 
> The files are about 7 months old.

Are there newer files that would indicate that the streaming is working?

> 
> 
> Thanks,
> 
> Edson
> 
>     > 
>     > 
>     > Regards,
>     > 
>     > Edson
>     > 
>     >     > 
>     >     > 
>     >     > Edson
>     >     > 
>     > 
>     >     -- 
>     >     Adrian Klaver
>     >     adrian.klaver@aklaver.com
>     > 
> 
> 
>     -- 
>     Adrian Klaver
>     adrian.klaver@aklaver.com
> 


-- 
Adrian Klaver
adrian.klaver@aklaver.com