________________________________ De: Adrian Klaver <adrian.kla...@aklaver.com> Enviado: sábado, 22 de fevereiro de 2020 15:50 Para: Edson Richter <edsonrich...@hotmail.com>; pgsql-general <pgsql-gene...@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.kla...@aklaver.com> > *Enviado:* sábado, 22 de fevereiro de 2020 14:33 > *Para:* Edson Richter <edsonrich...@hotmail.com>; pgsql-general > <pgsql-gene...@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.kla...@aklaver.com