RE: Replication: slave server has 3x size of production server? - Mailing list pgsql-general
| From | Edson Richter |
|---|---|
| Subject | RE: Replication: slave server has 3x size of production server? |
| Date | |
| Msg-id | MN2PR01MB53271A46CE28B2FDF93EE77DCFEE0@MN2PR01MB5327.prod.exchangelabs.com Whole thread Raw |
| In response to | Re: Replication: slave server has 3x size of production server? (Adrian Klaver <adrian.klaver@aklaver.com>) |
| Responses |
Re: Replication: slave server has 3x size of production server?
(Adrian Klaver <adrian.klaver@aklaver.com>)
|
| List | pgsql-general |
De: Adrian Klaver <adrian.klaver@aklaver.com>
Enviado: sábado, 22 de fevereiro de 2020 15:50
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 10:05 AM, Edson Richter wrote:
> ------------------------------------------------------------------------
>
> *De:* Adrian Klaver <adrian.klaver@aklaver.com>
> *Enviado:* sábado, 22 de fevereiro de 2020 14:33
> *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 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@aklaver.com
pgsql-general by date: