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

[Edson Richter <edsonrichter@xxxxxxxxxxx>]

---

De: Adrian Klaver <adrian.klaver@xxxxxxxxxxx>
Enviado: sábado, 22 de fevereiro de 2020 15:50
Para: Edson Richter <edsonrichter@xxxxxxxxxxx>; pgsql-general <pgsql-general@xxxxxxxxxxxxxx>
Assunto: Re: Replication: slave server has 3x size of production server?

 

On 2/22/20 10:05 AM, Edson Richter wrote:
>     ------------------------------------------------------------------------
>
>     *De:* Adrian Klaver <adrian.klaver@xxxxxxxxxxx>
>     *Enviado:* sábado, 22 de fevereiro de 2020 14:33
>     *Para:* Edson Richter <edsonrichter@xxxxxxxxxxx>; pgsql-general
>     <pgsql-general@xxxxxxxxxxxxxx>
>     *Assunto:* Re: Replication: slave server has 3x size of production
>     server?
>     On 2/22/20 9:25 AM, Edson Richter wrote:
>     > Hi!
>     >
>     > I've a database cluster created at 9.6.10 linux x64 server rhel. I made
>     > progressive upgrades, first upgrading slave and then upgrading master.
>     > Actually both are running 9.6.17.
>     > Current production server has 196Gb in size.
>     > Nevertheless, the replicated (slave) server has 598 Gb in size.
>     > Replication server has 3x size of production server, is that normal?
>
>     How are you measuring the sizes?
>
>
> This is the command:
>
> du --max-depth 1 -h pgDbCluster
>
>
> Production:
>
> du --max-depth 1 -h pgDbCluster
>
> 56M     pgDbCluster/pg_log
> 444K    pgDbCluster/global
> 4,0K    pgDbCluster/pg_stat
> 4,0K    pgDbCluster/pg_snapshots
> 16K     pgDbCluster/pg_logical
> 20K     pgDbCluster/pg_replslot
> 61M     pgDbCluster/pg_subtrans
> 4,0K    pgDbCluster/pg_commit_ts
> 465M    pgDbCluster/pg_xlog
> 4,0K    pgDbCluster/pg_twophase
> 12M     pgDbCluster/pg_multixact
> 4,0K    pgDbCluster/pg_serial
> 195G    pgDbCluster/base
> 284K    pgDbCluster/pg_stat_tmp
> 12M     pgDbCluster/pg_clog
> 4,0K    pgDbCluster/pg_dynshmem
> 12K     pgDbCluster/pg_notify
> 4,0K    pgDbCluster/pg_tblspc
> 196G    pgDbCluster
>
>
> Slave:
>
> du -h --max-depth 1 pgDbCluster
>
> 403G    pgDbCluster/pg_xlog
> 120K    pgDbCluster/pg_log
> 424K    pgDbCluster/global
> 0       pgDbCluster/pg_stat
> 0       pgDbCluster/pg_snapshots
> 4,0K    pgDbCluster/pg_logical
> 8,0K    pgDbCluster/pg_replslot
> 60M     pgDbCluster/pg_subtrans
> 0       pgDbCluster/pg_commit_ts
> 0       pgDbCluster/pg_twophase
> 11M     pgDbCluster/pg_multixact
> 0       pgDbCluster/pg_serial
> 195G    pgDbCluster/base
> 12M     pgDbCluster/pg_clog
> 0       pgDbCluster/pg_dynshmem
> 8,0K    pgDbCluster/pg_notify
> 12K     pgDbCluster/pg_stat_tmp
> 0       pgDbCluster/pg_tblspc
> 598G    pgDbCluster

So the WAL logs are not being cleared.

What replication method is being used?

What are the settings for the replication?

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

Regards,

Edson

>
>
> Edson
>

--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx